From nobody@sourceforge.net  Thu Mar  1 02:37:59 2001
From: nobody@sourceforge.net (nobody)
Date: Wed, 28 Feb 2001 18:37:59 -0800
Subject: [Python-bugs-list] [ python-Bugs-404322 ] Python 2.1a and solaris8/x86
Message-ID: <E14YIyd-0000ve-00@usw-sf-web3.sourceforge.net>

Bugs #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: david arnold
Date: 2001-02-28 18:37

Message:
Logged In: YES 
user_id=78574

i see the same on SPARC (just to provide a confirmation):

    SunOS ladybug 5.8 Generic_108528-03 sun4u sparc

i think it is basically every module?  (this is a second
pass, so the compilation is already done):

gcc   -o python Modules/python.o \
                libpython2.1.a -lpthread -lsocket -lnsl
-ldl  -lthread   -lm  
./python ./setup.py build
running build
running build_ext
building 'struct' extension
skipping /tmp/Python-2.1a2/Modules/structmodule.c
(build/temp.solaris-2.8-sun4u-2.1/structmodule.o up-to-date)
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
Text relocation remains                         referenced
    against symbol                  offset      in file
<unknown>                           0x11bc     
build/temp.solaris-2.8-sun4u-2.1/structmodule.o
<unknown>                           0x11b8     
build/temp.solaris-2.8-sun4u-2.1/structmodule.o
<unknown>                           0x11f8     
build/temp.solaris-2.8-sun4u-2.1/structmodule.o
<unknown>                           0x1c30     
build/temp.solaris-2.8-sun4u-2.1/structmodule.o
<unknown>                           0x11f4     
build/temp.solaris-2.8-sun4u-2.1/structmodule.o
<unknown>                           0x11e4     
build/temp.solaris-2.8-sun4u-2.1/structmodule.o

etc ...


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

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  Thu Mar  1 04:50:17 2001
From: nobody@sourceforge.net (nobody)
Date: Wed, 28 Feb 2001 20:50:17 -0800
Subject: [Python-bugs-list] [ python-Bugs-228591 ] C-level GC API is not documented
Message-ID: <E14YL2f-0001t5-00@usw-sf-web3.sourceforge.net>

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

Category: Documentation
Group: Feature Request
Status: Open
Priority: 6
Submitted By: Fred L. Drake, Jr.
Assigned to: Fred L. Drake, Jr.
Summary: C-level GC API is not documented

Initial Comment:
The C macros and functions needed to interface with the garbage collector and used to implement GC-aware types are not documented.

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

Comment By: Fred L. Drake, Jr.
Date: 2001-02-28 20:50

Message:
Logged In: YES 
user_id=3066

Neil has sent me some text; it's up to me to integrate.  So this is back on my plate.

Thanks, Neil!

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

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


From nobody@sourceforge.net  Thu Mar  1 04:52:43 2001
From: nobody@sourceforge.net (nobody)
Date: Wed, 28 Feb 2001 20:52:43 -0800
Subject: [Python-bugs-list] [ python-Bugs-232637 ] can't compile modules on AIX 4.2.1 (for real this time)
Message-ID: <E14YL51-0001tx-00@usw-sf-web3.sourceforge.net>

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

Category: Build
Group: None
Status: Open
Priority: 5
Submitted By: Benjamin Collar
Assigned to: A.M. Kuchling
Summary: can't compile modules on AIX 4.2.1 (for real this time)

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


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

Comment By: Fred L. Drake, Jr.
Date: 2001-02-28 20:52

Message:
Logged In: YES 
user_id=3066

This relates to the move to distutils, but may have already been fixed.  Andrew?

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

Comment By: Benjamin Collar
Date: 2001-02-22 11:47

Message:
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"?

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

Comment By: M.-A. Lemburg
Date: 2001-02-16 01:51

Message:
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 ?!

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

Comment By: M.-A. Lemburg
Date: 2001-02-16 01:45

Message:
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)

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

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


From nobody@sourceforge.net  Thu Mar  1 04:53:20 2001
From: nobody@sourceforge.net (nobody)
Date: Wed, 28 Feb 2001 20:53:20 -0800
Subject: [Python-bugs-list] [ python-Bugs-232609 ] 2.1a2 possible include/library mismatch in setup.py
Message-ID: <E14YL5c-0001uC-00@usw-sf-web3.sourceforge.net>

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

Category: Build
Group: None
Status: Open
Priority: 5
Submitted By: Mark Favas
Assigned to: A.M. Kuchling
Summary: 2.1a2 possible include/library mismatch in setup.py

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

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

Comment By: Fred L. Drake, Jr.
Date: 2001-02-28 20:53

Message:
Logged In: YES 
user_id=3066

distutils migration issue....

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

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


From nobody@sourceforge.net  Thu Mar  1 04:55:47 2001
From: nobody@sourceforge.net (nobody)
Date: Wed, 28 Feb 2001 20:55:47 -0800
Subject: [Python-bugs-list] [ python-Bugs-404274 ] Linking error on AIX (Python 1.5.2)
Message-ID: <E14YL7z-0001vX-00@usw-sf-web3.sourceforge.net>

Bugs #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: Greg Ward
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


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

Comment By: Fred L. Drake, Jr.
Date: 2001-02-28 20:55

Message:
Logged In: YES 
user_id=3066

Greg, you're the distutils guru...

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

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


From nobody@sourceforge.net  Thu Mar  1 06:17:36 2001
From: nobody@sourceforge.net (nobody)
Date: Wed, 28 Feb 2001 22:17:36 -0800
Subject: [Python-bugs-list] [ python-Bugs-404240 ] time_t  can be unsigned
Message-ID: <E14YMPA-0002T0-00@usw-sf-web3.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: Uwe Zessin
Date: 2001-02-28 22:17

Message:
Logged In: YES 
user_id=155755

According to:
http://www.openvms.compaq.com/commercial/c/5763p048.htm#inde
x_x_1396

It uses '(time_t)(-1)'.

I have done a little bit more research and found out that
this is already used in TIMEMODULE.C at line 507:
    'if (tt == ((time_t)(-1)) {'

Other manuals are at:
http://www.openvms.compaq.com/commercial/c/index_alpha.htm

It is possible that there is more code that assumes that
a time_t is always a signed type - see the #if block just
below line 715 in IMPORT.C.

(I'm currently holding a training and I will be going
abroad for some days - if you don't hear from me for
some time, please understand that it's not that I have
lost interest, OK? I try to check my mailbox from time
to time...)


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

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  Thu Mar  1 06:37:08 2001
From: nobody@sourceforge.net (nobody)
Date: Wed, 28 Feb 2001 22:37:08 -0800
Subject: [Python-bugs-list] [ python-Bugs-404240 ] time_t  can be unsigned
Message-ID: <E14YMi4-0004pp-00@usw-sf-web2.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: Closed
Priority: 5
Submitted By: Uwe Zessin
Assigned to: Fred L. Drake, Jr.
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 22:37

Message:
Logged In: YES 
user_id=3066

Fixed in Python/import.c revision 2.168.

The second area you point out has having possible signedness assumptions regarding time_t actually does not: since the only values a time_t will have at that point are positive (regardless of signedness), the test only determines whether or not the value fits in 4 bytes.

Thanks!

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

Comment By: Uwe Zessin
Date: 2001-02-28 22:17

Message:
Logged In: YES 
user_id=155755

According to:
http://www.openvms.compaq.com/commercial/c/5763p048.htm#inde
x_x_1396

It uses '(time_t)(-1)'.

I have done a little bit more research and found out that
this is already used in TIMEMODULE.C at line 507:
    'if (tt == ((time_t)(-1)) {'

Other manuals are at:
http://www.openvms.compaq.com/commercial/c/index_alpha.htm

It is possible that there is more code that assumes that
a time_t is always a signed type - see the #if block just
below line 715 in IMPORT.C.

(I'm currently holding a training and I will be going
abroad for some days - if you don't hear from me for
some time, please understand that it's not that I have
lost interest, OK? I try to check my mailbox from time
to time...)


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

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  Thu Mar  1 19:21:32 2001
From: nobody@sourceforge.net (nobody)
Date: Thu, 01 Mar 2001 11:21:32 -0800
Subject: [Python-bugs-list] [ python-Bugs-405227 ] sizeof(Py_UNICODE)==2 ????
Message-ID: <E14YYdo-0001xR-00@usw-sf-web1.sourceforge.net>

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

Category: Unicode
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Jon Saenz
Assigned to: Nobody/Anonymous
Summary: sizeof(Py_UNICODE)==2 ????

Initial Comment:
We are trying to install Python 2.0 in a Cray T3E.

After a painful process of removing several modules
which produce some errors (mmap, sha, md5), we get core
dumps when we run python because under this platform,
there does not exist a 16-bit numeric type. Unsigned
short is 4 bytes long.

We have finally defined unicode objects as unsigned
short, despite they are 4 bytes long, and we have
changed a sentence in 
Objects/unicodeobject.c
to:
if (sizeof(Py_UNICODE)!=sizeof(unsigned short){

It compiles and runs now, but the test on regular
expressions crashes and the whole regression test does,
too.

Support of Unicode for this platform is not correct in
version 2.0 of Python.

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

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


From nobody@sourceforge.net  Thu Mar  1 22:05:16 2001
From: nobody@sourceforge.net (nobody)
Date: Thu, 01 Mar 2001 14:05:16 -0800
Subject: [Python-bugs-list] [ python-Bugs-405227 ] sizeof(Py_UNICODE)==2 ????
Message-ID: <E14YbCG-0001nc-00@usw-sf-web3.sourceforge.net>

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

Category: Unicode
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Jon Saenz
Assigned to: M.-A. Lemburg
Summary: sizeof(Py_UNICODE)==2 ????

Initial Comment:
We are trying to install Python 2.0 in a Cray T3E.

After a painful process of removing several modules
which produce some errors (mmap, sha, md5), we get core
dumps when we run python because under this platform,
there does not exist a 16-bit numeric type. Unsigned
short is 4 bytes long.

We have finally defined unicode objects as unsigned
short, despite they are 4 bytes long, and we have
changed a sentence in 
Objects/unicodeobject.c
to:
if (sizeof(Py_UNICODE)!=sizeof(unsigned short){

It compiles and runs now, but the test on regular
expressions crashes and the whole regression test does,
too.

Support of Unicode for this platform is not correct in
version 2.0 of Python.

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

Comment By: Fred L. Drake, Jr.
Date: 2001-03-01 14:05

Message:
Logged In: YES 
user_id=3066

Marc-Andre, can you deal with the general Unicode issues here and then pass this along to Fredrik for SRE updates?  (Or better yet, work in parallel?)

Thanks!

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

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


From nobody@sourceforge.net  Thu Mar  1 23:08:36 2001
From: nobody@sourceforge.net (nobody)
Date: Thu, 01 Mar 2001 15:08:36 -0800
Subject: [Python-bugs-list] [ python-Bugs-405227 ] sizeof(Py_UNICODE)==2 ????
Message-ID: <E14YcBY-0002Lh-00@usw-sf-web3.sourceforge.net>

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

Category: Unicode
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Jon Saenz
Assigned to: M.-A. Lemburg
Summary: sizeof(Py_UNICODE)==2 ????

Initial Comment:
We are trying to install Python 2.0 in a Cray T3E.

After a painful process of removing several modules
which produce some errors (mmap, sha, md5), we get core
dumps when we run python because under this platform,
there does not exist a 16-bit numeric type. Unsigned
short is 4 bytes long.

We have finally defined unicode objects as unsigned
short, despite they are 4 bytes long, and we have
changed a sentence in 
Objects/unicodeobject.c
to:
if (sizeof(Py_UNICODE)!=sizeof(unsigned short){

It compiles and runs now, but the test on regular
expressions crashes and the whole regression test does,
too.

Support of Unicode for this platform is not correct in
version 2.0 of Python.

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

Comment By: Jon Saenz
Date: 2001-03-01 15:08

Message:
Logged In: YES 
user_id=12122

We have finally given up to install Python in the Cray T3E
due to its lack of support of shared objects. This causes
difficulties in the loading of different external libraries
(Numeric, Lapack, and so on) because of the static linking.

In any case, we still think that this "bug" should be
repaired. There may be other platforms which:
1) Do not support Unicode, so that the Unicode feature of
Python is useless in these cases.
2) The users may be interested in using Python in them (for
Numeric applications, for instance)
3) May not have a 16-bit native numerical type.

Under these circunstances, the current version of Python can
not be used.

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

Comment By: Fred L. Drake, Jr.
Date: 2001-03-01 14:05

Message:
Logged In: YES 
user_id=3066

Marc-Andre, can you deal with the general Unicode issues here and then pass this along to Fredrik for SRE updates?  (Or better yet, work in parallel?)

Thanks!

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

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


From nobody@sourceforge.net  Thu Mar  1 23:08:54 2001
From: nobody@sourceforge.net (nobody)
Date: Thu, 01 Mar 2001 15:08:54 -0800
Subject: [Python-bugs-list] [ python-Bugs-405227 ] sizeof(Py_UNICODE)==2 ????
Message-ID: <E14YcBq-0002Ls-00@usw-sf-web3.sourceforge.net>

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

Category: Unicode
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Jon Saenz
Assigned to: M.-A. Lemburg
Summary: sizeof(Py_UNICODE)==2 ????

Initial Comment:
We are trying to install Python 2.0 in a Cray T3E.

After a painful process of removing several modules
which produce some errors (mmap, sha, md5), we get core
dumps when we run python because under this platform,
there does not exist a 16-bit numeric type. Unsigned
short is 4 bytes long.

We have finally defined unicode objects as unsigned
short, despite they are 4 bytes long, and we have
changed a sentence in 
Objects/unicodeobject.c
to:
if (sizeof(Py_UNICODE)!=sizeof(unsigned short){

It compiles and runs now, but the test on regular
expressions crashes and the whole regression test does,
too.

Support of Unicode for this platform is not correct in
version 2.0 of Python.

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

Comment By: Jon Saenz
Date: 2001-03-01 15:08

Message:
Logged In: YES 
user_id=12122

We have finally given up to install Python in the Cray T3E
due to its lack of support of shared objects. This causes
difficulties in the loading of different external libraries
(Numeric, Lapack, and so on) because of the static linking.

In any case, we still think that this "bug" should be
repaired. There may be other platforms which:
1) Do not support Unicode, so that the Unicode feature of
Python is useless in these cases.
2) The users may be interested in using Python in them (for
Numeric applications, for instance)
3) May not have a 16-bit native numerical type.

Under these circunstances, the current version of Python can
not be used.

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

Comment By: Jon Saenz
Date: 2001-03-01 15:08

Message:
Logged In: YES 
user_id=12122

We have finally given up to install Python in the Cray T3E
due to its lack of support of shared objects. This causes
difficulties in the loading of different external libraries
(Numeric, Lapack, and so on) because of the static linking.

In any case, we still think that this "bug" should be
repaired. There may be other platforms which:
1) Do not support Unicode, so that the Unicode feature of
Python is useless in these cases.
2) The users may be interested in using Python in them (for
Numeric applications, for instance)
3) May not have a 16-bit native numerical type.

Under these circunstances, the current version of Python can
not be used.

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

Comment By: Fred L. Drake, Jr.
Date: 2001-03-01 14:05

Message:
Logged In: YES 
user_id=3066

Marc-Andre, can you deal with the general Unicode issues here and then pass this along to Fredrik for SRE updates?  (Or better yet, work in parallel?)

Thanks!

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

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


From nobody@sourceforge.net  Thu Mar  1 23:09:33 2001
From: nobody@sourceforge.net (nobody)
Date: Thu, 01 Mar 2001 15:09:33 -0800
Subject: [Python-bugs-list] [ python-Bugs-405227 ] sizeof(Py_UNICODE)==2 ????
Message-ID: <E14YcCT-0002MS-00@usw-sf-web3.sourceforge.net>

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

Category: Unicode
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Jon Saenz
Assigned to: M.-A. Lemburg
Summary: sizeof(Py_UNICODE)==2 ????

Initial Comment:
We are trying to install Python 2.0 in a Cray T3E.

After a painful process of removing several modules
which produce some errors (mmap, sha, md5), we get core
dumps when we run python because under this platform,
there does not exist a 16-bit numeric type. Unsigned
short is 4 bytes long.

We have finally defined unicode objects as unsigned
short, despite they are 4 bytes long, and we have
changed a sentence in 
Objects/unicodeobject.c
to:
if (sizeof(Py_UNICODE)!=sizeof(unsigned short){

It compiles and runs now, but the test on regular
expressions crashes and the whole regression test does,
too.

Support of Unicode for this platform is not correct in
version 2.0 of Python.

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

Comment By: Jon Saenz
Date: 2001-03-01 15:09

Message:
Logged In: YES 
user_id=12122

We have finally given up to install Python in the Cray T3E
due to its lack of support of shared objects. This causes
difficulties in the loading of different external libraries
(Numeric, Lapack, and so on) because of the static linking.

In any case, we still think that this "bug" should be
repaired. There may be other platforms which:
1) Do not support Unicode, so that the Unicode feature of
Python is useless in these cases.
2) The users may be interested in using Python in them (for
Numeric applications, for instance)
3) May not have a 16-bit native numerical type.

Under these circunstances, the current version of Python can
not be used.

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

Comment By: Jon Saenz
Date: 2001-03-01 15:08

Message:
Logged In: YES 
user_id=12122

We have finally given up to install Python in the Cray T3E
due to its lack of support of shared objects. This causes
difficulties in the loading of different external libraries
(Numeric, Lapack, and so on) because of the static linking.

In any case, we still think that this "bug" should be
repaired. There may be other platforms which:
1) Do not support Unicode, so that the Unicode feature of
Python is useless in these cases.
2) The users may be interested in using Python in them (for
Numeric applications, for instance)
3) May not have a 16-bit native numerical type.

Under these circunstances, the current version of Python can
not be used.

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

Comment By: Jon Saenz
Date: 2001-03-01 15:08

Message:
Logged In: YES 
user_id=12122

We have finally given up to install Python in the Cray T3E
due to its lack of support of shared objects. This causes
difficulties in the loading of different external libraries
(Numeric, Lapack, and so on) because of the static linking.

In any case, we still think that this "bug" should be
repaired. There may be other platforms which:
1) Do not support Unicode, so that the Unicode feature of
Python is useless in these cases.
2) The users may be interested in using Python in them (for
Numeric applications, for instance)
3) May not have a 16-bit native numerical type.

Under these circunstances, the current version of Python can
not be used.

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

Comment By: Fred L. Drake, Jr.
Date: 2001-03-01 14:05

Message:
Logged In: YES 
user_id=3066

Marc-Andre, can you deal with the general Unicode issues here and then pass this along to Fredrik for SRE updates?  (Or better yet, work in parallel?)

Thanks!

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

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


From nobody@sourceforge.net  Thu Mar  1 23:29:14 2001
From: nobody@sourceforge.net (nobody)
Date: Thu, 01 Mar 2001 15:29:14 -0800
Subject: [Python-bugs-list] [ python-Bugs-405227 ] sizeof(Py_UNICODE)==2 ????
Message-ID: <E14YcVW-0005B5-00@usw-sf-web1.sourceforge.net>

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

Category: Unicode
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Jon Saenz
Assigned to: M.-A. Lemburg
Summary: sizeof(Py_UNICODE)==2 ????

Initial Comment:
We are trying to install Python 2.0 in a Cray T3E.

After a painful process of removing several modules
which produce some errors (mmap, sha, md5), we get core
dumps when we run python because under this platform,
there does not exist a 16-bit numeric type. Unsigned
short is 4 bytes long.

We have finally defined unicode objects as unsigned
short, despite they are 4 bytes long, and we have
changed a sentence in 
Objects/unicodeobject.c
to:
if (sizeof(Py_UNICODE)!=sizeof(unsigned short){

It compiles and runs now, but the test on regular
expressions crashes and the whole regression test does,
too.

Support of Unicode for this platform is not correct in
version 2.0 of Python.

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

Comment By: Tim Peters
Date: 2001-03-01 15:29

Message:
Logged In: YES 
user_id=31435

Notes:

+ Python was ported to T3E last year, IIRC by Marc Poinot.  
May want to track him down.

+ Python's Unicode support doesn't rely on any platform 
Unicode support.  Whether it's "useless" depends on the 
user, not the platform.

+ Face it <wink>:  Crays are the only platforms that don't 
have a native 16-bit integer type.

+ Even so, I believe at least SRE is happy to work with 32-
bit Unicode (glibc's wchar_t is 4 bytes, IIRC), so that 
much was likely a shallow problem.


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

Comment By: Jon Saenz
Date: 2001-03-01 15:09

Message:
Logged In: YES 
user_id=12122

We have finally given up to install Python in the Cray T3E
due to its lack of support of shared objects. This causes
difficulties in the loading of different external libraries
(Numeric, Lapack, and so on) because of the static linking.

In any case, we still think that this "bug" should be
repaired. There may be other platforms which:
1) Do not support Unicode, so that the Unicode feature of
Python is useless in these cases.
2) The users may be interested in using Python in them (for
Numeric applications, for instance)
3) May not have a 16-bit native numerical type.

Under these circunstances, the current version of Python can
not be used.

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

Comment By: Jon Saenz
Date: 2001-03-01 15:08

Message:
Logged In: YES 
user_id=12122

We have finally given up to install Python in the Cray T3E
due to its lack of support of shared objects. This causes
difficulties in the loading of different external libraries
(Numeric, Lapack, and so on) because of the static linking.

In any case, we still think that this "bug" should be
repaired. There may be other platforms which:
1) Do not support Unicode, so that the Unicode feature of
Python is useless in these cases.
2) The users may be interested in using Python in them (for
Numeric applications, for instance)
3) May not have a 16-bit native numerical type.

Under these circunstances, the current version of Python can
not be used.

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

Comment By: Jon Saenz
Date: 2001-03-01 15:08

Message:
Logged In: YES 
user_id=12122

We have finally given up to install Python in the Cray T3E
due to its lack of support of shared objects. This causes
difficulties in the loading of different external libraries
(Numeric, Lapack, and so on) because of the static linking.

In any case, we still think that this "bug" should be
repaired. There may be other platforms which:
1) Do not support Unicode, so that the Unicode feature of
Python is useless in these cases.
2) The users may be interested in using Python in them (for
Numeric applications, for instance)
3) May not have a 16-bit native numerical type.

Under these circunstances, the current version of Python can
not be used.

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

Comment By: Fred L. Drake, Jr.
Date: 2001-03-01 14:05

Message:
Logged In: YES 
user_id=3066

Marc-Andre, can you deal with the general Unicode issues here and then pass this along to Fredrik for SRE updates?  (Or better yet, work in parallel?)

Thanks!

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

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


From nobody@sourceforge.net  Fri Mar  2 02:26:35 2001
From: nobody@sourceforge.net (nobody)
Date: Thu, 01 Mar 2001 18:26:35 -0800
Subject: [Python-bugs-list] [ python-Bugs-405341 ] Reminder -- nested scopes TO DO list
Message-ID: <E14YfH9-0003tw-00@usw-sf-web3.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Guido van Rossum
Assigned to: Jeremy Hylton
Summary: Reminder -- nested scopes TO DO list

Initial Comment:
Subject: [Python-Dev] nested scopes and future status
From: Jeremy Hylton <jeremy@alum.mit.edu>
To: python-dev@python.org
Date: Thu, 1 Mar 2001 18:34:44 -0500 (EST)

There are several loose ends in the nested scopes
changes that I won't
have time to fix before the beta.  Here's a laundry
list of tasks that
remain.  I don't think any of these is crucial for the
release.
Holler if there's something you'd like me to fix
tonight.

- Integrate the parsing of future statements into the
_symtable
  module's interface.  This interface is new with 2.1
and
  undocumented, so it's deficiency here will not affect
any code.

- Update traceback.py to understand SyntaxErrors that
have a text
  attribute and an offset of None.  It should not print
the caret.

- PyErr_ProgramText() should be called when an
exception is printed
  rather than when it is raised.

- Fix pdb to support nested scopes.

- Produce a better error message/warning for code like
this:
  def f(x):
      def g():
          exec ...
          print x
  The warning message should say that exec is not
allowed in a nested
  function with free variables.  It currently says that
g *contains* a
  nested function with free variables.

- Update the documentation.

Jeremy


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

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


From nobody@sourceforge.net  Fri Mar  2 03:45:17 2001
From: nobody@sourceforge.net (nobody)
Date: Thu, 01 Mar 2001 19:45:17 -0800
Subject: [Python-bugs-list] [ python-Bugs-405346 ] bug in unicodedata.c in 2.1a2
Message-ID: <E14YgVJ-0007zW-00@usw-sf-web1.sourceforge.net>

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

Category: Unicode
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Nobody/Anonymous
Summary: bug in unicodedata.c in 2.1a2

Initial Comment:
test_ucn fails on unicode('\N{blah}','unicode-escape')
and similar (illegal unicode char name) because of
an incorrect return value on failure in getcode()
in Modules/unicodedata.c.  Here is the patch:

--- Modules/unicodedata.c.old   Fri Mar  2 12:35:04 2001
+++ Modules/unicodedata.c       Fri Mar  2 12:35:04 2001
@@ -368,7 +368,7 @@
        i = (i + incr) & mask;
        v = code_hash[i];
        if (!v)
-           return -1;
+           return 0;
        if (cmpname(v, name, namelen)) {
            *code = v;
            return 1;


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

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


From nobody@sourceforge.net  Fri Mar  2 03:50:20 2001
From: nobody@sourceforge.net (nobody)
Date: Thu, 01 Mar 2001 19:50:20 -0800
Subject: [Python-bugs-list] [ python-Bugs-405350 ] 2.1b1 termios module fails to compile
Message-ID: <E14YgaC-0004Vs-00@usw-sf-web3.sourceforge.net>

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

Category: Build
Group: None
Status: Open
Priority: 5
Submitted By: Mark Favas
Assigned to: Nobody/Anonymous
Summary: 2.1b1 termios module fails to compile

Initial Comment:
On Tru64 Unix, V4.0F with Compaq's C compiler:
Modules/termios.c fails to compile with
building 'termios' extension
cc -O -Olimit 1500 -I. -I./Include -IInclude/
-I/usr/local/include -c Modules/termios.c -o
build/temp.osf1-V4.0-alpha-2.1/termios.o
cc: Error: Modules/termios.c, line 394: In the
initializer for termios_constants[66].value, "XTABS" is
not declared. (undeclared)
        {"XTABS", XTABS},
------------------^
cc: Error: Modules/termios.c, line 452: In the
initializer for termios_constants[107].value, "VSWTC"
is not declared. (undeclared)
        {"VSWTC", VSWTC},
------------------^
cc: Error: Modules/termios.c, line 453: In the
initializer for termios_constants[108].value, "VSWTCH"
is not declared. (undeclared)
        {"VSWTCH", VSWTCH},
-------------------^
WARNING: building of extension "termios" failed:
command 'cc' failed with exit status 1

The fix is obvious - some more #ifdef's. I'll submit a
patch...


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

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


From nobody@sourceforge.net  Fri Mar  2 03:55:32 2001
From: nobody@sourceforge.net (nobody)
Date: Thu, 01 Mar 2001 19:55:32 -0800
Subject: [Python-bugs-list] [ python-Bugs-405346 ] bug in unicodedata.c in 2.1a2
Message-ID: <E14YgfE-000868-00@usw-sf-web1.sourceforge.net>

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

Category: Unicode
Group: None
Status: Closed
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Nobody/Anonymous
Summary: bug in unicodedata.c in 2.1a2

Initial Comment:
test_ucn fails on unicode('\N{blah}','unicode-escape')
and similar (illegal unicode char name) because of
an incorrect return value on failure in getcode()
in Modules/unicodedata.c.  Here is the patch:

--- Modules/unicodedata.c.old   Fri Mar  2 12:35:04 2001
+++ Modules/unicodedata.c       Fri Mar  2 12:35:04 2001
@@ -368,7 +368,7 @@
        i = (i + incr) & mask;
        v = code_hash[i];
        if (!v)
-           return -1;
+           return 0;
        if (cmpname(v, name, namelen)) {
            *code = v;
            return 1;


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

Comment By: Tim Peters
Date: 2001-03-01 19:55

Message:
Logged In: YES 
user_id=31435

This was already fixed on 18-Feb-2001, in revision 2.10.

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

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


From nobody@sourceforge.net  Fri Mar  2 04:16:53 2001
From: nobody@sourceforge.net (nobody)
Date: Thu, 01 Mar 2001 20:16:53 -0800
Subject: [Python-bugs-list] [ python-Bugs-405351 ] 2.1b1 - dlmodule on 64-bit platform
Message-ID: <E14Ygzt-0004gb-00@usw-sf-web3.sourceforge.net>

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

Category: Extension Modules
Group: None
Status: Open
Priority: 5
Submitted By: Mark Favas
Assigned to: Nobody/Anonymous
Summary: 2.1b1 - dlmodule on 64-bit platform

Initial Comment:
Platform: Tru64 Unix, V4.0F.
setup.py builds Modules/dlmodule.c automatically
(without errors) but "make test" fails with
SystemError: module dl requires sizeof(int) ==
sizeof(long) == sizeof(char*)

On this platform, ints are 4 bytes, longs and pointers
are 8 bytes, so this module will not run, and probably
should not be built in the first place.

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

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


From nobody@sourceforge.net  Fri Mar  2 04:37:50 2001
From: nobody@sourceforge.net (nobody)
Date: Thu, 01 Mar 2001 20:37:50 -0800
Subject: [Python-bugs-list] [ python-Bugs-405358 ] Python2.0 re module: greedy regexp bug
Message-ID: <E14YhKA-0006u4-00@usw-sf-web2.sourceforge.net>

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

Category: Regular Expressions
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Nobody/Anonymous
Summary: Python2.0 re module: greedy regexp bug

Initial Comment:
Python-2.0 fails to correctly handle cases when greedy
and non-greedy regular expressions are present in the
same pattern. In some cases non-greedy are more
aggressive than greedy searches!!

Here is an example:

TESTB-BED system: San Solaris 2.6
Python 2.0 (#1, Dec  9 2000, 12:35:40) 
[GCC 2.95.2 19991024 (release)] on sunos5

Please, run the following code to see the bug:

import re
str='first_XXXX_last'
#                   \1  \2    \3
mo = re.search(r'^(.*?)(X*)(.*?)$', str)
# above, the groups \1 and \3 are NON-greedy regexp
# while group \2 is greedy.
# Unfortunately Python-2.0 demonstrates buggy behavior
# here:
print "BUGGY result:", mo.groups()
print "should be   : ('first_', 'XXXX', '_last')"
#EOF

When I run the code above it prints the following:

BUGGY result: ('', '', 'first_XXXX_last')
should be   : ('first_', 'XXXX', '_last')
>>> 

Thanks,
--Leo  <slonika@yahoo.com>


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

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


From nobody@sourceforge.net  Fri Mar  2 04:37:38 2001
From: nobody@sourceforge.net (nobody)
Date: Thu, 01 Mar 2001 20:37:38 -0800
Subject: [Python-bugs-list] [ python-Bugs-405350 ] 2.1b1 termios module fails to compile
Message-ID: <E14YhJy-0004pJ-00@usw-sf-web3.sourceforge.net>

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

Category: Build
Group: None
Status: Open
Priority: 5
Submitted By: Mark Favas
Assigned to: Nobody/Anonymous
Summary: 2.1b1 termios module fails to compile

Initial Comment:
On Tru64 Unix, V4.0F with Compaq's C compiler:
Modules/termios.c fails to compile with
building 'termios' extension
cc -O -Olimit 1500 -I. -I./Include -IInclude/
-I/usr/local/include -c Modules/termios.c -o
build/temp.osf1-V4.0-alpha-2.1/termios.o
cc: Error: Modules/termios.c, line 394: In the
initializer for termios_constants[66].value, "XTABS" is
not declared. (undeclared)
        {"XTABS", XTABS},
------------------^
cc: Error: Modules/termios.c, line 452: In the
initializer for termios_constants[107].value, "VSWTC"
is not declared. (undeclared)
        {"VSWTC", VSWTC},
------------------^
cc: Error: Modules/termios.c, line 453: In the
initializer for termios_constants[108].value, "VSWTCH"
is not declared. (undeclared)
        {"VSWTCH", VSWTCH},
-------------------^
WARNING: building of extension "termios" failed:
command 'cc' failed with exit status 1

The fix is obvious - some more #ifdef's. I'll submit a
patch...


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

Comment By: Mark Favas
Date: 2001-03-01 20:37

Message:
Logged In: YES 
user_id=44979

Tried to upload patch (#405355), but doesn't seem to get
there...

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

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


From nobody@sourceforge.net  Fri Mar  2 05:35:12 2001
From: nobody@sourceforge.net (nobody)
Date: Thu, 01 Mar 2001 21:35:12 -0800
Subject: [Python-bugs-list] [ python-Bugs-405358 ] Python2.0 re module: greedy regexp bug
Message-ID: <E14YiDg-0000cc-00@usw-sf-web1.sourceforge.net>

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

Category: Regular Expressions
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Fredrik Lundh
Summary: Python2.0 re module: greedy regexp bug

Initial Comment:
Python-2.0 fails to correctly handle cases when greedy
and non-greedy regular expressions are present in the
same pattern. In some cases non-greedy are more
aggressive than greedy searches!!

Here is an example:

TESTB-BED system: San Solaris 2.6
Python 2.0 (#1, Dec  9 2000, 12:35:40) 
[GCC 2.95.2 19991024 (release)] on sunos5

Please, run the following code to see the bug:

import re
str='first_XXXX_last'
#                   \1  \2    \3
mo = re.search(r'^(.*?)(X*)(.*?)$', str)
# above, the groups \1 and \3 are NON-greedy regexp
# while group \2 is greedy.
# Unfortunately Python-2.0 demonstrates buggy behavior
# here:
print "BUGGY result:", mo.groups()
print "should be   : ('first_', 'XXXX', '_last')"
#EOF

When I run the code above it prints the following:

BUGGY result: ('', '', 'first_XXXX_last')
should be   : ('first_', 'XXXX', '_last')
>>> 

Thanks,
--Leo  <slonika@yahoo.com>


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

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


From nobody@sourceforge.net  Fri Mar  2 05:36:00 2001
From: nobody@sourceforge.net (nobody)
Date: Thu, 01 Mar 2001 21:36:00 -0800
Subject: [Python-bugs-list] [ python-Bugs-405350 ] 2.1b1 termios module fails to compile
Message-ID: <E14YiES-0005CI-00@usw-sf-web3.sourceforge.net>

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

Category: Build
Group: None
Status: Open
Priority: 5
Submitted By: Mark Favas
Assigned to: Fred L. Drake, Jr.
Summary: 2.1b1 termios module fails to compile

Initial Comment:
On Tru64 Unix, V4.0F with Compaq's C compiler:
Modules/termios.c fails to compile with
building 'termios' extension
cc -O -Olimit 1500 -I. -I./Include -IInclude/
-I/usr/local/include -c Modules/termios.c -o
build/temp.osf1-V4.0-alpha-2.1/termios.o
cc: Error: Modules/termios.c, line 394: In the
initializer for termios_constants[66].value, "XTABS" is
not declared. (undeclared)
        {"XTABS", XTABS},
------------------^
cc: Error: Modules/termios.c, line 452: In the
initializer for termios_constants[107].value, "VSWTC"
is not declared. (undeclared)
        {"VSWTC", VSWTC},
------------------^
cc: Error: Modules/termios.c, line 453: In the
initializer for termios_constants[108].value, "VSWTCH"
is not declared. (undeclared)
        {"VSWTCH", VSWTCH},
-------------------^
WARNING: building of extension "termios" failed:
command 'cc' failed with exit status 1

The fix is obvious - some more #ifdef's. I'll submit a
patch...


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

Comment By: Mark Favas
Date: 2001-03-01 20:37

Message:
Logged In: YES 
user_id=44979

Tried to upload patch (#405355), but doesn't seem to get
there...

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

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


From nobody@sourceforge.net  Fri Mar  2 05:36:15 2001
From: nobody@sourceforge.net (nobody)
Date: Thu, 01 Mar 2001 21:36:15 -0800
Subject: [Python-bugs-list] [ python-Bugs-405351 ] 2.1b1 - dlmodule on 64-bit platform
Message-ID: <E14YiEh-0000dJ-00@usw-sf-web1.sourceforge.net>

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

Category: Extension Modules
Group: None
Status: Open
Priority: 5
Submitted By: Mark Favas
Assigned to: A.M. Kuchling
Summary: 2.1b1 - dlmodule on 64-bit platform

Initial Comment:
Platform: Tru64 Unix, V4.0F.
setup.py builds Modules/dlmodule.c automatically
(without errors) but "make test" fails with
SystemError: module dl requires sizeof(int) ==
sizeof(long) == sizeof(char*)

On this platform, ints are 4 bytes, longs and pointers
are 8 bytes, so this module will not run, and probably
should not be built in the first place.

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

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


From nobody@sourceforge.net  Fri Mar  2 05:37:22 2001
From: nobody@sourceforge.net (nobody)
Date: Thu, 01 Mar 2001 21:37:22 -0800
Subject: [Python-bugs-list] [ python-Bugs-404827 ] Python Makefile: LIBOBJS incorrect
Message-ID: <E14YiFm-0007JX-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: Neil Schemenauer
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  Fri Mar  2 05:38:37 2001
From: nobody@sourceforge.net (nobody)
Date: Thu, 01 Mar 2001 21:38:37 -0800
Subject: [Python-bugs-list] [ python-Bugs-232276 ] make install not working
Message-ID: <E14YiGz-0007KA-00@usw-sf-web2.sourceforge.net>

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

Category: Installation
Group: Irreproducible
Status: Closed
Priority: 3
Submitted By: Nobody/Anonymous
Assigned to: Guido van Rossum
Summary: make install not working

Initial Comment:
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'


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

Comment By: Guido van Rossum
Date: 2001-03-01 21:38

Message:
Logged In: YES 
user_id=6380

No feedback from submitter -- closing with "works for me".


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

Comment By: Guido van Rossum
Date: 2001-02-14 06:36

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

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

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


From nobody@sourceforge.net  Fri Mar  2 05:39:25 2001
From: nobody@sourceforge.net (nobody)
Date: Thu, 01 Mar 2001 21:39:25 -0800
Subject: [Python-bugs-list] [ python-Bugs-404545 ] frozen package import uses wrong files
Message-ID: <E14YiHl-0007KY-00@usw-sf-web2.sourceforge.net>

Bugs #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: Guido van Rossum
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  Fri Mar  2 05:42:19 2001
From: nobody@sourceforge.net (nobody)
Date: Thu, 01 Mar 2001 21:42:19 -0800
Subject: [Python-bugs-list] [ python-Bugs-233050 ] Python-2.1a2 tests failed on NetBSD 1.5 i386
Message-ID: <E14YiKZ-0007Lw-00@usw-sf-web2.sourceforge.net>

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

Category: Build
Group: Platform-specific
Status: Open
Priority: 3
Submitted By: Anders Andersen
Assigned to: Nobody/Anonymous
Summary: Python-2.1a2 tests failed on NetBSD 1.5 i386

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


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

Comment By: Anders Andersen
Date: 2001-02-18 23:18

Message:
The last test was test_ucn and not test_mailbox.  Sorry
about the cut and paste error.


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

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


From nobody@sourceforge.net  Fri Mar  2 05:43:37 2001
From: nobody@sourceforge.net (nobody)
Date: Thu, 01 Mar 2001 21:43:37 -0800
Subject: [Python-bugs-list] [ python-Bugs-404322 ] Python 2.1a and solaris8/x86
Message-ID: <E14YiLp-0005GG-00@usw-sf-web3.sourceforge.net>

Bugs #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: Neil Schemenauer
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: david arnold
Date: 2001-02-28 18:37

Message:
Logged In: YES 
user_id=78574

i see the same on SPARC (just to provide a confirmation):

    SunOS ladybug 5.8 Generic_108528-03 sun4u sparc

i think it is basically every module?  (this is a second
pass, so the compilation is already done):

gcc   -o python Modules/python.o \
                libpython2.1.a -lpthread -lsocket -lnsl
-ldl  -lthread   -lm  
./python ./setup.py build
running build
running build_ext
building 'struct' extension
skipping /tmp/Python-2.1a2/Modules/structmodule.c
(build/temp.solaris-2.8-sun4u-2.1/structmodule.o up-to-date)
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
Text relocation remains                         referenced
    against symbol                  offset      in file
<unknown>                           0x11bc     
build/temp.solaris-2.8-sun4u-2.1/structmodule.o
<unknown>                           0x11b8     
build/temp.solaris-2.8-sun4u-2.1/structmodule.o
<unknown>                           0x11f8     
build/temp.solaris-2.8-sun4u-2.1/structmodule.o
<unknown>                           0x1c30     
build/temp.solaris-2.8-sun4u-2.1/structmodule.o
<unknown>                           0x11f4     
build/temp.solaris-2.8-sun4u-2.1/structmodule.o
<unknown>                           0x11e4     
build/temp.solaris-2.8-sun4u-2.1/structmodule.o

etc ...


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

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  Fri Mar  2 05:43:40 2001
From: nobody@sourceforge.net (nobody)
Date: Thu, 01 Mar 2001 21:43:40 -0800
Subject: [Python-bugs-list] [ python-Bugs-232460 ] SSL Support (Apparently) Broken on Solaris
Message-ID: <E14YiLs-0005GP-00@usw-sf-web3.sourceforge.net>

Bugs #232460, was updated on 2001-02-14 19:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=232460&group_id=5470

Category: Extension Modules
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: David M. Beazley
Assigned to: Neil Schemenauer
Summary: SSL Support (Apparently) Broken on Solaris

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

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

Comment By: David M. Beazley
Date: 2001-02-15 06:12

Message:
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


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

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


From nobody@sourceforge.net  Fri Mar  2 05:44:20 2001
From: nobody@sourceforge.net (nobody)
Date: Thu, 01 Mar 2001 21:44:20 -0800
Subject: [Python-bugs-list] [ python-Bugs-233084 ] nis.match('username', 'aliases') does not work under Linux
Message-ID: <E14YiMW-0005Gb-00@usw-sf-web3.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Fred L. Drake, Jr.
Summary: nis.match('username', 'aliases') does not work under Linux

Initial Comment:
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}
 };


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

Comment By: Nobody/Anonymous
Date: 2001-02-23 11:52

Message:
You are all going down on this one

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

Comment By: Fred L. Drake, Jr.
Date: 2001-02-19 13:33

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

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

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


From nobody@sourceforge.net  Fri Mar  2 05:47:57 2001
From: nobody@sourceforge.net (nobody)
Date: Thu, 01 Mar 2001 21:47:57 -0800
Subject: [Python-bugs-list] [ python-Bugs-233050 ] Python-2.1a2 tests failed on NetBSD 1.5 i386
Message-ID: <E14YiQ1-0007OA-00@usw-sf-web2.sourceforge.net>

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

Category: Build
Group: Platform-specific
Status: Open
Priority: 3
Submitted By: Anders Andersen
Assigned to: Nobody/Anonymous
Summary: Python-2.1a2 tests failed on NetBSD 1.5 i386

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


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

Comment By: Guido van Rossum
Date: 2001-03-01 21:47

Message:
Logged In: YES 
user_id=6380

Thanks for the reports.  Can't do much about most of these.

The test_mailbox.py failure (the real one) should be fixed
in 2.1b1,
I just checked in a fix that makes it test for the right
exception.

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

Comment By: Anders Andersen
Date: 2001-02-18 23:18

Message:
The last test was test_ucn and not test_mailbox.  Sorry
about the cut and paste error.


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

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


From nobody@sourceforge.net  Fri Mar  2 05:48:12 2001
From: nobody@sourceforge.net (nobody)
Date: Thu, 01 Mar 2001 21:48:12 -0800
Subject: [Python-bugs-list] [ python-Bugs-233050 ] Python-2.1a2 tests failed on NetBSD 1.5 i386
Message-ID: <E14YiQG-0005IZ-00@usw-sf-web3.sourceforge.net>

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

Category: Build
Group: Platform-specific
Status: Open
Priority: 3
Submitted By: Anders Andersen
Assigned to: Guido van Rossum
Summary: Python-2.1a2 tests failed on NetBSD 1.5 i386

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


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

Comment By: Guido van Rossum
Date: 2001-03-01 21:47

Message:
Logged In: YES 
user_id=6380

Thanks for the reports.  Can't do much about most of these.

The test_mailbox.py failure (the real one) should be fixed
in 2.1b1,
I just checked in a fix that makes it test for the right
exception.

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

Comment By: Anders Andersen
Date: 2001-02-18 23:18

Message:
The last test was test_ucn and not test_mailbox.  Sorry
about the cut and paste error.


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

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


From nobody@sourceforge.net  Fri Mar  2 06:35:32 2001
From: nobody@sourceforge.net (nobody)
Date: Thu, 01 Mar 2001 22:35:32 -0800
Subject: [Python-bugs-list] [ python-Bugs-404827 ] Python Makefile: LIBOBJS incorrect
Message-ID: <E14YjA4-0001E3-00@usw-sf-web1.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: Neil Schemenauer
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: Neil Schemenauer
Date: 2001-03-01 22:35

Message:
Logged In: YES 
user_id=35752

There is no patch attached.  It looks like the sourceforge
patch monster is still hungry.  Can you please email it
to me directly or post a URL?

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

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  Fri Mar  2 06:44:40 2001
From: nobody@sourceforge.net (nobody)
Date: Thu, 01 Mar 2001 22:44:40 -0800
Subject: [Python-bugs-list] [ python-Bugs-404322 ] Python 2.1a and solaris8/x86
Message-ID: <E14YjIu-0007lR-00@usw-sf-web2.sourceforge.net>

Bugs #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: Martin v. Löwis
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: Neil Schemenauer
Date: 2001-03-01 22:44

Message:
Logged In: YES 
user_id=35752

Looks like the same bug as 405329 (Cannot compile Python
2.1a2 on Solaris).

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

Comment By: david arnold
Date: 2001-02-28 18:37

Message:
Logged In: YES 
user_id=78574

i see the same on SPARC (just to provide a confirmation):

    SunOS ladybug 5.8 Generic_108528-03 sun4u sparc

i think it is basically every module?  (this is a second
pass, so the compilation is already done):

gcc   -o python Modules/python.o \
                libpython2.1.a -lpthread -lsocket -lnsl
-ldl  -lthread   -lm  
./python ./setup.py build
running build
running build_ext
building 'struct' extension
skipping /tmp/Python-2.1a2/Modules/structmodule.c
(build/temp.solaris-2.8-sun4u-2.1/structmodule.o up-to-date)
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
Text relocation remains                         referenced
    against symbol                  offset      in file
<unknown>                           0x11bc     
build/temp.solaris-2.8-sun4u-2.1/structmodule.o
<unknown>                           0x11b8     
build/temp.solaris-2.8-sun4u-2.1/structmodule.o
<unknown>                           0x11f8     
build/temp.solaris-2.8-sun4u-2.1/structmodule.o
<unknown>                           0x1c30     
build/temp.solaris-2.8-sun4u-2.1/structmodule.o
<unknown>                           0x11f4     
build/temp.solaris-2.8-sun4u-2.1/structmodule.o
<unknown>                           0x11e4     
build/temp.solaris-2.8-sun4u-2.1/structmodule.o

etc ...


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

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  Fri Mar  2 06:52:34 2001
From: nobody@sourceforge.net (nobody)
Date: Thu, 01 Mar 2001 22:52:34 -0800
Subject: [Python-bugs-list] [ python-Bugs-405350 ] 2.1b1 termios module fails to compile
Message-ID: <E14YjQY-0005kP-00@usw-sf-web3.sourceforge.net>

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

Category: Extension Modules
Group: None
Status: Closed
Priority: 5
Submitted By: Mark Favas
Assigned to: Fred L. Drake, Jr.
Summary: 2.1b1 termios module fails to compile

Initial Comment:
On Tru64 Unix, V4.0F with Compaq's C compiler:
Modules/termios.c fails to compile with
building 'termios' extension
cc -O -Olimit 1500 -I. -I./Include -IInclude/
-I/usr/local/include -c Modules/termios.c -o
build/temp.osf1-V4.0-alpha-2.1/termios.o
cc: Error: Modules/termios.c, line 394: In the
initializer for termios_constants[66].value, "XTABS" is
not declared. (undeclared)
        {"XTABS", XTABS},
------------------^
cc: Error: Modules/termios.c, line 452: In the
initializer for termios_constants[107].value, "VSWTC"
is not declared. (undeclared)
        {"VSWTC", VSWTC},
------------------^
cc: Error: Modules/termios.c, line 453: In the
initializer for termios_constants[108].value, "VSWTCH"
is not declared. (undeclared)
        {"VSWTCH", VSWTCH},
-------------------^
WARNING: building of extension "termios" failed:
command 'cc' failed with exit status 1

The fix is obvious - some more #ifdef's. I'll submit a
patch...


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

Comment By: Fred L. Drake, Jr.
Date: 2001-03-01 22:52

Message:
Logged In: YES 
user_id=3066

Fixed in Modules/termios.c revision 2.18.

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

Comment By: Mark Favas
Date: 2001-03-01 20:37

Message:
Logged In: YES 
user_id=44979

Tried to upload patch (#405355), but doesn't seem to get
there...

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

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


From nobody@sourceforge.net  Fri Mar  2 08:14:44 2001
From: nobody@sourceforge.net (nobody)
Date: Fri, 02 Mar 2001 00:14:44 -0800
Subject: [Python-bugs-list] [ python-Bugs-405358 ] Python2.0 re module: greedy regexp bug
Message-ID: <E14Yki4-0008Pg-00@usw-sf-web2.sourceforge.net>

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

Category: Regular Expressions
Group: Not a Bug
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Fredrik Lundh
Summary: Python2.0 re module: greedy regexp bug

Initial Comment:
Python-2.0 fails to correctly handle cases when greedy
and non-greedy regular expressions are present in the
same pattern. In some cases non-greedy are more
aggressive than greedy searches!!

Here is an example:

TESTB-BED system: San Solaris 2.6
Python 2.0 (#1, Dec  9 2000, 12:35:40) 
[GCC 2.95.2 19991024 (release)] on sunos5

Please, run the following code to see the bug:

import re
str='first_XXXX_last'
#                   \1  \2    \3
mo = re.search(r'^(.*?)(X*)(.*?)$', str)
# above, the groups \1 and \3 are NON-greedy regexp
# while group \2 is greedy.
# Unfortunately Python-2.0 demonstrates buggy behavior
# here:
print "BUGGY result:", mo.groups()
print "should be   : ('first_', 'XXXX', '_last')"
#EOF

When I run the code above it prints the following:

BUGGY result: ('', '', 'first_XXXX_last')
should be   : ('first_', 'XXXX', '_last')
>>> 

Thanks,
--Leo  <slonika@yahoo.com>


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

Comment By: Fredrik Lundh
Date: 2001-03-02 00:14

Message:
Logged In: YES 
user_id=38376

you forgot that X* and .*? may both match empty strings.

try changing one of them to a +, and the expression will 
work as you expected.

Cheers /F

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

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


From nobody@sourceforge.net  Fri Mar  2 08:18:58 2001
From: nobody@sourceforge.net (nobody)
Date: Fri, 02 Mar 2001 00:18:58 -0800
Subject: [Python-bugs-list] [ python-Bugs-405358 ] Python2.0 re module: greedy regexp bug
Message-ID: <E14YkmA-0008RS-00@usw-sf-web2.sourceforge.net>

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

Category: Regular Expressions
Group: Not a Bug
Status: Closed
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Fredrik Lundh
Summary: Python2.0 re module: greedy regexp bug

Initial Comment:
Python-2.0 fails to correctly handle cases when greedy
and non-greedy regular expressions are present in the
same pattern. In some cases non-greedy are more
aggressive than greedy searches!!

Here is an example:

TESTB-BED system: San Solaris 2.6
Python 2.0 (#1, Dec  9 2000, 12:35:40) 
[GCC 2.95.2 19991024 (release)] on sunos5

Please, run the following code to see the bug:

import re
str='first_XXXX_last'
#                   \1  \2    \3
mo = re.search(r'^(.*?)(X*)(.*?)$', str)
# above, the groups \1 and \3 are NON-greedy regexp
# while group \2 is greedy.
# Unfortunately Python-2.0 demonstrates buggy behavior
# here:
print "BUGGY result:", mo.groups()
print "should be   : ('first_', 'XXXX', '_last')"
#EOF

When I run the code above it prints the following:

BUGGY result: ('', '', 'first_XXXX_last')
should be   : ('first_', 'XXXX', '_last')
>>> 

Thanks,
--Leo  <slonika@yahoo.com>


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

Comment By: Fredrik Lundh
Date: 2001-03-02 00:14

Message:
Logged In: YES 
user_id=38376

you forgot that X* and .*? may both match empty strings.

try changing one of them to a +, and the expression will 
work as you expected.

Cheers /F

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

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


From nobody@sourceforge.net  Fri Mar  2 08:25:01 2001
From: nobody@sourceforge.net (nobody)
Date: Fri, 02 Mar 2001 00:25:01 -0800
Subject: [Python-bugs-list] [ python-Bugs-232815 ] getname() already in use by OS
Message-ID: <E14Yks1-0008Uw-00@usw-sf-web2.sourceforge.net>

Bugs #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-03-02 00:25

Message:
Logged In: YES 
user_id=38376

> I think the Compaq C/ DEC C compilers are quite
> good - I have to blame myself :-(

I did find it a bit hard to believe that the VMS
versions wouldn't be as good as the true64 compilers
(which are as good as they come ;-)

The unsigned complaints are valid, but I'm not sure
how to address them; I don't want the code to break
if someone changes the Py_UCS4 declaration.  I'll
leave this one open for now, and ask the python-dev
crowd for advice.

Cheers /F

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

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  Fri Mar  2 10:42:30 2001
From: nobody@sourceforge.net (nobody)
Date: Fri, 02 Mar 2001 02:42:30 -0800
Subject: [Python-bugs-list] [ python-Bugs-233790 ] [Irix] re package does not work.
Message-ID: <E14Yn14-00012O-00@usw-sf-web2.sourceforge.net>

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

Category: Python Interpreter Core
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Fredrik Lundh
Summary: [Irix] re package does not work.

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


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

Comment By: Fredrik Lundh
Date: 2001-03-02 02:42

Message:
Logged In: YES 
user_id=38376

ouch.

what does the test suite say?  (lib/tests/test_sre)

have you tried compiling _sre.c with less/no optimization?

do you get any warnings from the compiler when compiling 
the _sre module?

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

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


From nobody@sourceforge.net  Fri Mar  2 11:30:30 2001
From: nobody@sourceforge.net (nobody)
Date: Fri, 02 Mar 2001 03:30:30 -0800
Subject: [Python-bugs-list] [ python-Bugs-404322 ] Python 2.1a and solaris8/x86
Message-ID: <E14YnlW-0004Qq-00@usw-sf-web1.sourceforge.net>

Bugs #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: Closed
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Martin v. Löwis
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: Martin v. Löwis
Date: 2001-03-02 03:30

Message:
Logged In: YES 
user_id=21627

At least part of the bug has been fixed, by passing -fPIC to
gcc. If the bug persists for x86 in 2.1b1, please re-report
it. Then also indicate whether you are using binutils or the
system linker, and the linker version.

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

Comment By: Neil Schemenauer
Date: 2001-03-01 22:44

Message:
Logged In: YES 
user_id=35752

Looks like the same bug as 405329 (Cannot compile Python
2.1a2 on Solaris).

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

Comment By: david arnold
Date: 2001-02-28 18:37

Message:
Logged In: YES 
user_id=78574

i see the same on SPARC (just to provide a confirmation):

    SunOS ladybug 5.8 Generic_108528-03 sun4u sparc

i think it is basically every module?  (this is a second
pass, so the compilation is already done):

gcc   -o python Modules/python.o \
                libpython2.1.a -lpthread -lsocket -lnsl
-ldl  -lthread   -lm  
./python ./setup.py build
running build
running build_ext
building 'struct' extension
skipping /tmp/Python-2.1a2/Modules/structmodule.c
(build/temp.solaris-2.8-sun4u-2.1/structmodule.o up-to-date)
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
Text relocation remains                         referenced
    against symbol                  offset      in file
<unknown>                           0x11bc     
build/temp.solaris-2.8-sun4u-2.1/structmodule.o
<unknown>                           0x11b8     
build/temp.solaris-2.8-sun4u-2.1/structmodule.o
<unknown>                           0x11f8     
build/temp.solaris-2.8-sun4u-2.1/structmodule.o
<unknown>                           0x1c30     
build/temp.solaris-2.8-sun4u-2.1/structmodule.o
<unknown>                           0x11f4     
build/temp.solaris-2.8-sun4u-2.1/structmodule.o
<unknown>                           0x11e4     
build/temp.solaris-2.8-sun4u-2.1/structmodule.o

etc ...


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

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  Fri Mar  2 12:27:51 2001
From: nobody@sourceforge.net (nobody)
Date: Fri, 02 Mar 2001 04:27:51 -0800
Subject: [Python-bugs-list] [ python-Bugs-210637 ] ihooks on windows and pythoncom (PR#294)
Message-ID: <E14Yof1-0001o6-00@usw-sf-web2.sourceforge.net>

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

Category: Windows
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Mark Hammond
Summary: ihooks on windows and pythoncom (PR#294)

Initial Comment:
Jitterbug-Id: 294
Submitted-By: mak@mikroplan.com.pl
Date: Thu, 13 Apr 2000 04:09:35 -0400 (EDT)
Version: cvs
OS: windows


Hi,

Python module ihooks is not so compatible with builtin imp while importing
modules whose name is stored in registry eg. pythoncom/pywintypes.

import ihooks
ihooks.install()
import pythoncom

This code will fail inside pythonwin ide too !




====================================================================
Audit trail:
Tue Jul 11 08:29:17 2000	guido	moved from incoming to open

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

Comment By: Grzegorz Makarewicz
Date: 2001-03-02 04:27

Message:
Logged In: YES 
user_id=141704

BasicModuleLoader.find_module_in_dir is searching for main 
modules only in frozen and builtin. The imp searches the 
registry, too.

ModuleLoader.find_module_in_dir should call the functions 
from the inherited object.

so this patch should help:
--- V:\py21\Lib\ihooks.py	Mon Feb 12 08:55:46 2001
+++ ihooks.py	Sun Feb 18 04:39:39 2001
@@ -122,8 +122,13 @@
 
     def find_module_in_dir(self, name, dir):
         if dir is None:
-            return self.find_builtin_module(name)
-        else:
+            result = self.find_builtin_module(name)
+            if result is not None:
+                return result
+            try:
+                return imp.find_module(name, None)
+            except:
+                return None
             try:
                 return imp.find_module(name, [dir])
             except ImportError:
@@ -237,7 +242,7 @@
 
     def find_module_in_dir(self, name, dir, 
allow_packages=1):
         if dir is None:
-            return self.find_builtin_module(name)
+            return BasicModuleLoader.find_module_in_dir
(self,name,dir)
         if allow_packages:
             fullname = self.hooks.path_join(dir, name)
             if self.hooks.path_isdir(fullname):


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

Comment By: Mark Hammond
Date: 2000-08-30 23:23

Message:
Leaving open, but moving down the priority and resolution lists.  A patch would help bump it back up :-)

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

Comment By: Mark Hammond
Date: 2000-08-13 23:42

Message:
This needs a resolution.  The "registered module" code in the code also needs to support HKEY_CURRENT_USER along with the HKEY_LOCAL_MACHINE it does now.

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

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


From nobody@sourceforge.net  Fri Mar  2 13:32:03 2001
From: nobody@sourceforge.net (nobody)
Date: Fri, 02 Mar 2001 05:32:03 -0800
Subject: [Python-bugs-list] [ python-Bugs-405427 ] SQL2000+XML returns "400.100" status
Message-ID: <E14Ypf9-0000Jn-00@usw-sf-web3.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Luke Kenneth Casson Leighton
Assigned to: Nobody/Anonymous
Summary: SQL2000+XML returns "400.100" status

Initial Comment:
httplib.py expects status codes to be "integers" - of
the form 400, 200, 502 etc etc.

if you run the SQL 2000 server with its XML interface
which is accessed over HTTP, and you do an invalid
query, the HTTP response code is "400.100".  the line
that says self.status = status = int(status) freaks out
and says, erk, can't convert status of value 400.100 to
an integer.

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

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


From nobody@sourceforge.net  Fri Mar  2 15:22:13 2001
From: nobody@sourceforge.net (nobody)
Date: Fri, 02 Mar 2001 07:22:13 -0800
Subject: [Python-bugs-list] [ python-Bugs-404827 ] Python Makefile: LIBOBJS incorrect
Message-ID: <E14YrNl-00076u-00@usw-sf-web1.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: Build
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Neil Schemenauer
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: Neil Schemenauer
Date: 2001-03-02 07:22

Message:
Logged In: YES 
user_id=35752

Okay, I understand the problem.  You solution is correct
but it will only work with GNU make.  We must be portable.
Can you try the attached patch (assuming SF accepts it)?

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

Comment By: Neil Schemenauer
Date: 2001-03-01 22:35

Message:
Logged In: YES 
user_id=35752

There is no patch attached.  It looks like the sourceforge
patch monster is still hungry.  Can you please email it
to me directly or post a URL?

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

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  Fri Mar  2 15:49:05 2001
From: nobody@sourceforge.net (nobody)
Date: Fri, 02 Mar 2001 07:49:05 -0800
Subject: [Python-bugs-list] [ python-Bugs-232460 ] SSL Support (Apparently) Broken on Solaris
Message-ID: <E14Yrnl-0003c7-00@usw-sf-web2.sourceforge.net>

Bugs #232460, was updated on 2001-02-14 19:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=232460&group_id=5470

Category: Extension Modules
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: David M. Beazley
Assigned to: A.M. Kuchling
Summary: SSL Support (Apparently) Broken on Solaris

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

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

Comment By: Neil Schemenauer
Date: 2001-03-02 07:49

Message:
Logged In: YES 
user_id=35752

It looks like patch "[ #405101 ] Add Random Seeding to
OpenSSL" might fix this.  Assigning to Andrew since he
is assigned that patch too.


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

Comment By: David M. Beazley
Date: 2001-02-15 06:12

Message:
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


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

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


From nobody@sourceforge.net  Fri Mar  2 23:07:18 2001
From: nobody@sourceforge.net (nobody)
Date: Fri, 02 Mar 2001 15:07:18 -0800
Subject: [Python-bugs-list] [ python-Bugs-405553 ] pydoc.help broken in IDLE
Message-ID: <E14Yydq-00041D-00@usw-sf-web1.sourceforge.net>

Bugs #405553, was updated on 2001-03-02 15:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405553&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 7
Submitted By: Guido van Rossum
Assigned to: Ka-Ping Yee
Summary: pydoc.help broken in IDLE

Initial Comment:
pydoc has an (undocumented?) feature that after "from
pydoc import help" in an interactive interpreter,
help(object) or help("modulename") gives help.

This doesn't work right in IDLE:

On Unix, it brings up a pager in the terminal window
where IDLE was started.  That's not what you want!!!

On Windows, where IDLE is normally started from the
Start menu, it gives an error, complaining about an
invalid file descriptor.

Perhaps it should invoke a stupid internal pager, like
the one used by the license() built-in command?  That
"just works" in IDLE!


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

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


From nobody@sourceforge.net  Fri Mar  2 23:10:21 2001
From: nobody@sourceforge.net (nobody)
Date: Fri, 02 Mar 2001 15:10:21 -0800
Subject: [Python-bugs-list] [ python-Bugs-405554 ] pydoc should be integrated with HTML doc
Message-ID: <E14Yygn-00044g-00@usw-sf-web1.sourceforge.net>

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

Category: Python Library
Group: Feature Request
Status: Open
Priority: 5
Submitted By: Guido van Rossum
Assigned to: Nobody/Anonymous
Summary: pydoc should be integrated with HTML doc

Initial Comment:
I really like pydoc, but it misses one feature compared
to perldoc: often the *good* documentation for a module
or class is in the library reference manual.  There
should be a way to get that integrated with the stuff
that pydoc extracts from the doc strings. 

(Wasn't this Paul Prescod's original idea?)


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

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


From nobody@sourceforge.net  Fri Mar  2 23:38:16 2001
From: nobody@sourceforge.net (nobody)
Date: Fri, 02 Mar 2001 15:38:16 -0800
Subject: [Python-bugs-list] [ python-Bugs-231439 ] python and Python interfaces should use cc -G for so's
Message-ID: <E14Yz7o-00058H-00@usw-sf-web3.sourceforge.net>

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

Category: Build
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Larry Rosenman
Assigned to: Neil Schemenauer
Summary: python and Python interfaces should use cc -G for so's

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


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

Comment By: Martin v. Löwis
Date: 2001-03-02 15:38

Message:
Logged In: YES 
user_id=21627

Can you provide an example compiler invocation to see what
options are actually used? One -c invocation and one linker
invocation would be good.

What about -KPIC -Ki486 -belf -Wl,-Bexport? This is what is
currently used on SCO_SV.

Can you please try the attached patch (patch1 if upload
succeeds)?

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

Comment By: Larry Rosenman
Date: 2001-02-10 16:41

Message:
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
$ 


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

Comment By: Neil Schemenauer
Date: 2001-02-10 12:46

Message:
What does "uname -u" say for UnixWare?

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

Comment By: A.M. Kuchling
Date: 2001-02-08 09:23

Message:
Assigning to Neil.

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

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


From nobody@sourceforge.net  Fri Mar  2 23:40:02 2001
From: nobody@sourceforge.net (nobody)
Date: Fri, 02 Mar 2001 15:40:02 -0800
Subject: [Python-bugs-list] [ python-Bugs-231439 ] python and Python interfaces should use cc -G for so's
Message-ID: <E14Yz9W-00059q-00@usw-sf-web3.sourceforge.net>

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

Category: Build
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Larry Rosenman
Assigned to: Neil Schemenauer
Summary: python and Python interfaces should use cc -G for so's

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


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

Comment By: Martin v. Löwis
Date: 2001-03-02 15:40

Message:
Logged In: YES 
user_id=21627

OK, upload fails, so try this inline. You may succeed with
cut-n-paste from the HTML source

Index: configure.in
===================================================================
RCS file: /cvsroot/python/python/dist/src/configure.in,v
retrieving revision 1.207
diff -u -r1.207 configure.in
--- configure.in	2001/02/27 04:45:05	1.207
+++ configure.in	2001/03/02 23:36:10
@@ -576,6 +576,11 @@
 		else
 			LDSHARED="ld -Bshareable ${LDFLAGS}"
 		fi;;
+	UnixWare*)
+		if test "$GCC" = "yes"
+		then LDSHARED='$(CC) -shared'
+		else LDSHARED="cc -G";
+		fi ;;
 	SCO_SV*) LDSHARED="cc -G -KPIC -Ki486 -belf
-Wl,-Bexport";;
 	Monterey*) LDSHARED="cc -G -dy -Bdynamic -Bexport
-L/usr/lib/ia64l64";;
 	CYGWIN*) LDSHARED="gcc -shared
-Wl,--enable-auto-image-base";;
@@ -601,6 +606,11 @@
 	BSD/OS*/4*) CCSHARED="-fpic";;
 	OpenBSD*) CCSHARED="-fpic";;
 	FreeBSD*|NetBSD*) CCSHARED="-fPIC";;
+	UnixWare*)
+		if test "$GCC" = "yes"
+		then LDSHARED='$(CC) -fPIC'
+		else LDSHARED="cc -KPIC";
+		fi ;;
 	SCO_SV*) CCSHARED="-KPIC -dy -Bdynamic";;
 	Monterey*) CCSHARED="-G";;
 	IRIX*/6*)  case $CC in


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

Comment By: Martin v. Löwis
Date: 2001-03-02 15:38

Message:
Logged In: YES 
user_id=21627

Can you provide an example compiler invocation to see what
options are actually used? One -c invocation and one linker
invocation would be good.

What about -KPIC -Ki486 -belf -Wl,-Bexport? This is what is
currently used on SCO_SV.

Can you please try the attached patch (patch1 if upload
succeeds)?

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

Comment By: Larry Rosenman
Date: 2001-02-10 16:41

Message:
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
$ 


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

Comment By: Neil Schemenauer
Date: 2001-02-10 12:46

Message:
What does "uname -u" say for UnixWare?

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

Comment By: A.M. Kuchling
Date: 2001-02-08 09:23

Message:
Assigning to Neil.

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

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


From nobody@sourceforge.net  Sat Mar  3 00:03:53 2001
From: nobody@sourceforge.net (nobody)
Date: Fri, 02 Mar 2001 16:03:53 -0800
Subject: [Python-bugs-list] [ python-Bugs-405427 ] SQL2000+XML returns "400.100" status
Message-ID: <E14YzWb-0005PT-00@usw-sf-web3.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Luke Kenneth Casson Leighton
Assigned to: Nobody/Anonymous
Summary: SQL2000+XML returns "400.100" status

Initial Comment:
httplib.py expects status codes to be "integers" - of
the form 400, 200, 502 etc etc.

if you run the SQL 2000 server with its XML interface
which is accessed over HTTP, and you do an invalid
query, the HTTP response code is "400.100".  the line
that says self.status = status = int(status) freaks out
and says, erk, can't convert status of value 400.100 to
an integer.

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

Comment By: Martin v. Löwis
Date: 2001-03-02 16:03

Message:
Logged In: YES 
user_id=21627

Assuming that the response is something like

HTTP/1.1 400.100 Something went wrong

I think that the server is misbehaving. Such a response is a
clear violation of RFC 2616 (Hypertext Transfer Protocol --
-- HTTP/1.1), section 6.1.,

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase
CRLF

Section 6.1.1 elaborates the meaning of Status-code,
defining it as "a 3-digit integer result code". Maybe MS
misunderstood the meaning of extension-code, which is an
alternative to Status-code, not an additional piece of
information sent after a full-stop.

I propose to close this as "Won't Fix". Since the server
does not use the HTTP protocol, it does not need to be
supported in httplib. If you need that function, you'll have
to specialize httplib, e.g. by inheriting from HTTPResponse.


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

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


From nobody@sourceforge.net  Sat Mar  3 02:00:32 2001
From: nobody@sourceforge.net (nobody)
Date: Fri, 02 Mar 2001 18:00:32 -0800
Subject: [Python-bugs-list] [ python-Bugs-231439 ] python and Python interfaces should use cc -G for so's
Message-ID: <E14Z1LU-0008Sw-00@usw-sf-web2.sourceforge.net>

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

Category: Build
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Larry Rosenman
Assigned to: Neil Schemenauer
Summary: python and Python interfaces should use cc -G for so's

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


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

Comment By: Larry Rosenman
Date: 2001-03-02 18:00

Message:
Logged In: YES 
user_id=36452

What about -KPIC -Ki486 -belf -Wl,-Bexport? This is what is
                                currently used on SCO_SV

I'd lose the -Ki486 -belf as they are not needed for 
UnixWare. 

You can look at man pages at:

http://uw7doc.sco.com

or my site at:
http://www.lerctr.org:457

I also gave neil (nas) a login, and can do the same for you. 

LER


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

Comment By: Martin v. Löwis
Date: 2001-03-02 15:40

Message:
Logged In: YES 
user_id=21627

OK, upload fails, so try this inline. You may succeed with
cut-n-paste from the HTML source

Index: configure.in
===================================================================
RCS file: /cvsroot/python/python/dist/src/configure.in,v
retrieving revision 1.207
diff -u -r1.207 configure.in
--- configure.in	2001/02/27 04:45:05	1.207
+++ configure.in	2001/03/02 23:36:10
@@ -576,6 +576,11 @@
 		else
 			LDSHARED="ld -Bshareable ${LDFLAGS}"
 		fi;;
+	UnixWare*)
+		if test "$GCC" = "yes"
+		then LDSHARED='$(CC) -shared'
+		else LDSHARED="cc -G";
+		fi ;;
 	SCO_SV*) LDSHARED="cc -G -KPIC -Ki486 -belf
-Wl,-Bexport";;
 	Monterey*) LDSHARED="cc -G -dy -Bdynamic -Bexport
-L/usr/lib/ia64l64";;
 	CYGWIN*) LDSHARED="gcc -shared
-Wl,--enable-auto-image-base";;
@@ -601,6 +606,11 @@
 	BSD/OS*/4*) CCSHARED="-fpic";;
 	OpenBSD*) CCSHARED="-fpic";;
 	FreeBSD*|NetBSD*) CCSHARED="-fPIC";;
+	UnixWare*)
+		if test "$GCC" = "yes"
+		then LDSHARED='$(CC) -fPIC'
+		else LDSHARED="cc -KPIC";
+		fi ;;
 	SCO_SV*) CCSHARED="-KPIC -dy -Bdynamic";;
 	Monterey*) CCSHARED="-G";;
 	IRIX*/6*)  case $CC in


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

Comment By: Martin v. Löwis
Date: 2001-03-02 15:38

Message:
Logged In: YES 
user_id=21627

Can you provide an example compiler invocation to see what
options are actually used? One -c invocation and one linker
invocation would be good.

What about -KPIC -Ki486 -belf -Wl,-Bexport? This is what is
currently used on SCO_SV.

Can you please try the attached patch (patch1 if upload
succeeds)?

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

Comment By: Larry Rosenman
Date: 2001-02-10 16:41

Message:
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
$ 


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

Comment By: Neil Schemenauer
Date: 2001-02-10 12:46

Message:
What does "uname -u" say for UnixWare?

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

Comment By: A.M. Kuchling
Date: 2001-02-08 09:23

Message:
Assigning to Neil.

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

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


From nobody@sourceforge.net  Sat Mar  3 03:33:16 2001
From: nobody@sourceforge.net (nobody)
Date: Fri, 02 Mar 2001 19:33:16 -0800
Subject: [Python-bugs-list] [ python-Bugs-405583 ] Objects never freed with nested scopes
Message-ID: <E14Z2nE-0000dM-00@usw-sf-web2.sourceforge.net>

Bugs #405583, was updated on 2001-03-02 19:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405583&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Priority: 5
Submitted By: Atsuo Ishimoto
Assigned to: Nobody/Anonymous
Summary: Objects never freed with nested scopes

Initial Comment:
With this code,

from __future__ import nested_scopes
class foo:
    def __del__(self): print "del foo"

def f1():
    x = foo()
    def f2():x
    f2()

for i in range(10000):
    f1()

I see no "del foo" message.


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

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


From nobody@sourceforge.net  Sat Mar  3 17:34:17 2001
From: nobody@sourceforge.net (nobody)
Date: Sat, 03 Mar 2001 09:34:17 -0800
Subject: [Python-bugs-list] [ python-Bugs-405583 ] Objects never freed with nested scopes
Message-ID: <E14ZFv7-0006EW-00@usw-sf-web2.sourceforge.net>

Bugs #405583, was updated on 2001-03-02 19:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405583&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Priority: 7
Submitted By: Atsuo Ishimoto
Assigned to: Jeremy Hylton
Summary: Objects never freed with nested scopes

Initial Comment:
With this code,

from __future__ import nested_scopes
class foo:
    def __del__(self): print "del foo"

def f1():
    x = foo()
    def f2():x
    f2()

for i in range(10000):
    f1()

I see no "del foo" message.


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

Comment By: Fred L. Drake, Jr.
Date: 2001-03-03 09:34

Message:
Logged In: YES 
user_id=3066

Assigned to Jeremy Hylton.

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

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


From nobody@sourceforge.net  Sat Mar  3 17:41:39 2001
From: nobody@sourceforge.net (nobody)
Date: Sat, 03 Mar 2001 09:41:39 -0800
Subject: [Python-bugs-list] [ python-Bugs-405427 ] SQL2000+XML returns "400.100" status
Message-ID: <E14ZG2F-0006Ht-00@usw-sf-web2.sourceforge.net>

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

Category: Python Library
Group: Feature Request
Status: Open
Priority: 4
Submitted By: Luke Kenneth Casson Leighton
Assigned to: Jeremy Hylton
Summary: SQL2000+XML returns "400.100" status

Initial Comment:
httplib.py expects status codes to be "integers" - of
the form 400, 200, 502 etc etc.

if you run the SQL 2000 server with its XML interface
which is accessed over HTTP, and you do an invalid
query, the HTTP response code is "400.100".  the line
that says self.status = status = int(status) freaks out
and says, erk, can't convert status of value 400.100 to
an integer.

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

Comment By: Fred L. Drake, Jr.
Date: 2001-03-03 09:41

Message:
Logged In: YES 
user_id=3066

Sounds to me like a problem with the server; the response is invalid.  Section 6.1.1 of the HTTP/1.1 RFC states that response codes should be three digits, not three digits and then some dotted thing:

ftp://ftp.isi.edu/in-notes/rfc2616.txt

It may be appropriate to make httplib only examine the first three digits when converting to an integer, but I'm not sure that's really a good idea.

Assigned to Jeremy since he's been playing with urllib2.

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

Comment By: Martin v. Löwis
Date: 2001-03-02 16:03

Message:
Logged In: YES 
user_id=21627

Assuming that the response is something like

HTTP/1.1 400.100 Something went wrong

I think that the server is misbehaving. Such a response is a
clear violation of RFC 2616 (Hypertext Transfer Protocol --
-- HTTP/1.1), section 6.1.,

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase
CRLF

Section 6.1.1 elaborates the meaning of Status-code,
defining it as "a 3-digit integer result code". Maybe MS
misunderstood the meaning of extension-code, which is an
alternative to Status-code, not an additional piece of
information sent after a full-stop.

I propose to close this as "Won't Fix". Since the server
does not use the HTTP protocol, it does not need to be
supported in httplib. If you need that function, you'll have
to specialize httplib, e.g. by inheriting from HTTPResponse.


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

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


From nobody@sourceforge.net  Sat Mar  3 17:45:54 2001
From: nobody@sourceforge.net (nobody)
Date: Sat, 03 Mar 2001 09:45:54 -0800
Subject: [Python-bugs-list] [ python-Bugs-405676 ] Quasi hang in RE code
Message-ID: <E14ZG6M-0006Jj-00@usw-sf-web2.sourceforge.net>

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

Category: Regular Expressions
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Nobody/Anonymous
Summary: Quasi hang in RE code

Initial Comment:
When running the attached .py file with the attached
input file, python will "hang" (after 10 seconds, it
finally does return on my PII-400, but something is
obviously broken) when returning from chop_chunks. GDB
revealed this stack trace, pointing to re code.

The input

(gdb) bt
#0  0x8074b7f in sre_match (state=0xbfffebc8,
pattern=0x8252538, level=3)
    at Modules/_sre.c:671
#1  0x807523f in sre_match (state=0xbfffebc8,
pattern=0x8252536, level=2)
    at Modules/_sre.c:1043
#2  0x8075074 in sre_match (state=0xbfffebc8,
pattern=0x825251a, level=1)
    at Modules/_sre.c:947
#3  0x80754de in sre_search (state=0xbfffebc8,
pattern=0x8252510)
    at Modules/_sre.c:1200
#4  0x8076bb2 in pattern_search (self=0x82524f0,
args=0x822874c, kw=0x0)
    at ./Modules/_sre.c:1616
#5  0x8058a54 in call_cfunction (func=0x823a690,
arg=0x822874c, kw=0x0)
    at Python/ceval.c:2731
#6  0x805898c in call_object (func=0x823a690,
arg=0x822874c, kw=0x0)
    at Python/ceval.c:2703
#7  0x8059100 in do_call (func=0x823a690,
pp_stack=0xbffff04c, na=1, nk=0)
    at Python/ceval.c:3014

This is with

Python 2.1b1 (#1, Mar  3 2001, 12:47:09)
[GCC 2.96 20000731 (Red Hat Linux 7.0)] on linux2
Type "copyright", "credits" or "license" for more
information.


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

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


From nobody@sourceforge.net  Sat Mar  3 18:04:06 2001
From: nobody@sourceforge.net (nobody)
Date: Sat, 03 Mar 2001 10:04:06 -0800
Subject: [Python-bugs-list] [ python-Bugs-405676 ] Quasi hang in RE code
Message-ID: <E14ZGNy-0006RX-00@usw-sf-web2.sourceforge.net>

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

Category: Regular Expressions
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Fredrik Lundh
Summary: Quasi hang in RE code

Initial Comment:
When running the attached .py file with the attached
input file, python will "hang" (after 10 seconds, it
finally does return on my PII-400, but something is
obviously broken) when returning from chop_chunks. GDB
revealed this stack trace, pointing to re code.

The input

(gdb) bt
#0  0x8074b7f in sre_match (state=0xbfffebc8,
pattern=0x8252538, level=3)
    at Modules/_sre.c:671
#1  0x807523f in sre_match (state=0xbfffebc8,
pattern=0x8252536, level=2)
    at Modules/_sre.c:1043
#2  0x8075074 in sre_match (state=0xbfffebc8,
pattern=0x825251a, level=1)
    at Modules/_sre.c:947
#3  0x80754de in sre_search (state=0xbfffebc8,
pattern=0x8252510)
    at Modules/_sre.c:1200
#4  0x8076bb2 in pattern_search (self=0x82524f0,
args=0x822874c, kw=0x0)
    at ./Modules/_sre.c:1616
#5  0x8058a54 in call_cfunction (func=0x823a690,
arg=0x822874c, kw=0x0)
    at Python/ceval.c:2731
#6  0x805898c in call_object (func=0x823a690,
arg=0x822874c, kw=0x0)
    at Python/ceval.c:2703
#7  0x8059100 in do_call (func=0x823a690,
pp_stack=0xbffff04c, na=1, nk=0)
    at Python/ceval.c:3014

This is with

Python 2.1b1 (#1, Mar  3 2001, 12:47:09)
[GCC 2.96 20000731 (Red Hat Linux 7.0)] on linux2
Type "copyright", "credits" or "license" for more
information.


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

Comment By: Tim Peters
Date: 2001-03-03 10:04

Message:
Logged In: YES 
user_id=31435

Assigned to effbot.

Anonymous submitter, you should be aware that the usual 
outcome for one of these is that the regexp turns out to 
have been written in a way that *requires* exponential time 
in some cases.  See Friedl's "Master Regular Expressions" 
(O'Reilly) for details.

Given that that is the usual case, people will be more 
motivated to look at this if you could whittle it down to a 
minimal example (one regexp, one string).

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

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


From nobody@sourceforge.net  Sun Mar  4 02:32:33 2001
From: nobody@sourceforge.net (nobody)
Date: Sat, 03 Mar 2001 18:32:33 -0800
Subject: [Python-bugs-list] [ python-Bugs-405553 ] pydoc.help broken in IDLE
Message-ID: <E14ZOK1-0001Tm-00@usw-sf-web2.sourceforge.net>

Bugs #405553, was updated on 2001-03-02 15:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405553&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 7
Submitted By: Guido van Rossum
Assigned to: Ka-Ping Yee
Summary: pydoc.help broken in IDLE

Initial Comment:
pydoc has an (undocumented?) feature that after "from
pydoc import help" in an interactive interpreter,
help(object) or help("modulename") gives help.

This doesn't work right in IDLE:

On Unix, it brings up a pager in the terminal window
where IDLE was started.  That's not what you want!!!

On Windows, where IDLE is normally started from the
Start menu, it gives an error, complaining about an
invalid file descriptor.

Perhaps it should invoke a stupid internal pager, like
the one used by the license() built-in command?  That
"just works" in IDLE!


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

Comment By: Ka-Ping Yee
Date: 2001-03-03 18:32

Message:
Logged In: YES 
user_id=45338

The pydoc.getpager() routine was written to try to take
care of this case by making sure that sys.stdout is a real
file and sys.stdin is a tty before launching an interactive
pager.  I just tried it now in IDLE with

Python 2.1a2 (#1, Mar  1 2001, 00:10:25) 
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on
linux2
Type "copyright", "credits" or "license" for more
information.
IDLE 0.6 -- press F1 for help
>>> from pydoc import help
>>> help('atexit')
Help on module atexit:

NAME
    atexit

...

and it worked fine.

I bet you tried "help('sys')", didn't you?  That clobbers
sys.stdin and sys.stdout by reloading 'sys'.  Not sure what
to do about that.  I suppose i could just add a special case
to never reload built-in modules.


-- ?!ng

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

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


From nobody@sourceforge.net  Sun Mar  4 02:35:55 2001
From: nobody@sourceforge.net (nobody)
Date: Sat, 03 Mar 2001 18:35:55 -0800
Subject: [Python-bugs-list] [ python-Bugs-405553 ] pydoc.help broken in IDLE
Message-ID: <E14ZONH-0001VL-00@usw-sf-web2.sourceforge.net>

Bugs #405553, was updated on 2001-03-02 15:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405553&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 7
Submitted By: Guido van Rossum
Assigned to: Ka-Ping Yee
Summary: pydoc.help broken in IDLE

Initial Comment:
pydoc has an (undocumented?) feature that after "from
pydoc import help" in an interactive interpreter,
help(object) or help("modulename") gives help.

This doesn't work right in IDLE:

On Unix, it brings up a pager in the terminal window
where IDLE was started.  That's not what you want!!!

On Windows, where IDLE is normally started from the
Start menu, it gives an error, complaining about an
invalid file descriptor.

Perhaps it should invoke a stupid internal pager, like
the one used by the license() built-in command?  That
"just works" in IDLE!


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

Comment By: Ka-Ping Yee
Date: 2001-03-03 18:35

Message:
Logged In: YES 
user_id=45338

Here's a little patch.  It just looks for __file__.

I tried help('sys') and all was well.

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

Comment By: Ka-Ping Yee
Date: 2001-03-03 18:32

Message:
Logged In: YES 
user_id=45338

The pydoc.getpager() routine was written to try to take
care of this case by making sure that sys.stdout is a real
file and sys.stdin is a tty before launching an interactive
pager.  I just tried it now in IDLE with

Python 2.1a2 (#1, Mar  1 2001, 00:10:25) 
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on
linux2
Type "copyright", "credits" or "license" for more
information.
IDLE 0.6 -- press F1 for help
>>> from pydoc import help
>>> help('atexit')
Help on module atexit:

NAME
    atexit

...

and it worked fine.

I bet you tried "help('sys')", didn't you?  That clobbers
sys.stdin and sys.stdout by reloading 'sys'.  Not sure what
to do about that.  I suppose i could just add a special case
to never reload built-in modules.


-- ?!ng

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

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


From nobody@sourceforge.net  Sun Mar  4 05:50:20 2001
From: nobody@sourceforge.net (nobody)
Date: Sat, 03 Mar 2001 21:50:20 -0800
Subject: [Python-bugs-list] [ python-Bugs-230075 ] dbmmodule build fails on Debian GNU/Linux unstable (Sid)
Message-ID: <E14ZRPQ-0002ol-00@usw-sf-web2.sourceforge.net>

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

Category: Build
Group: Platform-specific
Status: Closed
Priority: 5
Submitted By: Kalle Svensson
Assigned to: Neil Schemenauer
Summary: dbmmodule build fails on Debian GNU/Linux unstable (Sid)

Initial Comment:
When building on Debian GNU/Linux unstable, the build fails with:

/home/kalle/src/python/dist/src/Modules/dbmmodule.c:24: #error "No ndbm.h available!"
error: command 'gcc' failed with exit status 1
make: *** [sharedmods] Error 1

The *dbm.h files available are
/usr/include/dbm.h
/usr/include/gdbm.h
/usr/include/gdbm-ndbm.h

All are part of the package libgdbmg1-dev.

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

Comment By: Neil Schemenauer
Date: 2001-03-03 21:50

Message:
Logged In: YES 
user_id=35752

Python is looking for gdbm/ndbm.h.  I could add more logic
to look for gdbm-ndbm.h but I don't think its worth it.
libc6 includes db1 which can be used by dbmmodule.
configure is not finding db1/ndbm.h because ndbm.h includes
db.h.  I think it should include db1/db.h instead.  So, it
looks like a Debian unstable bug.  I'm downloading Debian
libc6_2.2.2-1 right now.  Perhaps the bug has been fixed.

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

Comment By: Kalle Svensson
Date: 2001-01-25 12:21

Message:
Forgot to say that it's Python out of CVS, updated Thu Jan 25 21:23:52 CET 2001.

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

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


From nobody@sourceforge.net  Sun Mar  4 06:26:54 2001
From: nobody@sourceforge.net (nobody)
Date: Sat, 03 Mar 2001 22:26:54 -0800
Subject: [Python-bugs-list] [ python-Bugs-230075 ] dbmmodule build fails on Debian GNU/Linux unstable (Sid)
Message-ID: <E14ZRyo-000321-00@usw-sf-web2.sourceforge.net>

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

Category: Build
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Kalle Svensson
Assigned to: A.M. Kuchling
Summary: dbmmodule build fails on Debian GNU/Linux unstable (Sid)

Initial Comment:
When building on Debian GNU/Linux unstable, the build fails with:

/home/kalle/src/python/dist/src/Modules/dbmmodule.c:24: #error "No ndbm.h available!"
error: command 'gcc' failed with exit status 1
make: *** [sharedmods] Error 1

The *dbm.h files available are
/usr/include/dbm.h
/usr/include/gdbm.h
/usr/include/gdbm-ndbm.h

All are part of the package libgdbmg1-dev.

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

Comment By: Neil Schemenauer
Date: 2001-03-03 22:26

Message:
Logged In: YES 
user_id=35752

db1/ndbm.h from libc6_2.2.2-1 still includes db.h instead
of db1/db.h.  I think I understand the reason now.  If you
want to use db1 or gdbm as a dbm compatible database you
have to link with the approprate library.  Therefore,
if you should add both -ldb1 and -Idb1.

I've created a patch to setup.py which does this.  Andrew?
BTW, I'm not sure if the "if platform not in ['cygwin']"
is needed anymore.  I bet it could be removed.

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

Comment By: Neil Schemenauer
Date: 2001-03-03 21:50

Message:
Logged In: YES 
user_id=35752

Python is looking for gdbm/ndbm.h.  I could add more logic
to look for gdbm-ndbm.h but I don't think its worth it.
libc6 includes db1 which can be used by dbmmodule.
configure is not finding db1/ndbm.h because ndbm.h includes
db.h.  I think it should include db1/db.h instead.  So, it
looks like a Debian unstable bug.  I'm downloading Debian
libc6_2.2.2-1 right now.  Perhaps the bug has been fixed.

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

Comment By: Kalle Svensson
Date: 2001-01-25 12:21

Message:
Forgot to say that it's Python out of CVS, updated Thu Jan 25 21:23:52 CET 2001.

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

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


From nobody@sourceforge.net  Sun Mar  4 06:29:59 2001
From: nobody@sourceforge.net (nobody)
Date: Sat, 03 Mar 2001 22:29:59 -0800
Subject: [Python-bugs-list] [ python-Bugs-233668 ] install-sh has no -d option but 2.1a2 Makefile uses it
Message-ID: <E14ZS1n-0006Vz-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: Neil Schemenauer
Date: 2001-03-03 22:29

Message:
Logged In: YES 
user_id=35752

Yes, this has been fixed.

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

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  Sun Mar  4 06:40:15 2001
From: nobody@sourceforge.net (nobody)
Date: Sat, 03 Mar 2001 22:40:15 -0800
Subject: [Python-bugs-list] [ python-Bugs-404827 ] Python Makefile: LIBOBJS incorrect
Message-ID: <E14ZSBj-0000hZ-00@usw-sf-web3.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: Build
Group: None
Status: Closed
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Neil Schemenauer
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: Neil Schemenauer
Date: 2001-03-03 22:40

Message:
Logged In: YES 
user_id=35752

Fixed in configure.in 1.207.

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

Comment By: Neil Schemenauer
Date: 2001-03-02 07:22

Message:
Logged In: YES 
user_id=35752

Okay, I understand the problem.  You solution is correct
but it will only work with GNU make.  We must be portable.
Can you try the attached patch (assuming SF accepts it)?

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

Comment By: Neil Schemenauer
Date: 2001-03-01 22:35

Message:
Logged In: YES 
user_id=35752

There is no patch attached.  It looks like the sourceforge
patch monster is still hungry.  Can you please email it
to me directly or post a URL?

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

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  Sun Mar  4 07:37:43 2001
From: nobody@sourceforge.net (nobody)
Date: Sat, 03 Mar 2001 23:37:43 -0800
Subject: [Python-bugs-list] [ python-Bugs-231439 ] python and Python interfaces should use cc -G for so's
Message-ID: <E14ZT5L-00012E-00@usw-sf-web3.sourceforge.net>

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

Category: Build
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Larry Rosenman
Assigned to: Martin v. Löwis
Summary: python and Python interfaces should use cc -G for so's

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


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

Comment By: Neil Schemenauer
Date: 2001-03-03 23:37

Message:
Logged In: YES 
user_id=35752

Martin, with your patch I get:

ImportError: Python 2.1b1 (#1, Mar  4 2001, 01:30:18) [C] on
unixware5
Type "copyright", "credits" or "license" for more
information.
>>> import zlib
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
dynamic linker: ./python: relocation error: symbol not
found: _PyObject_New; referenced from:
/home/nas/Python-2.1b1/build/lib.unixware-5-i386-2.1/zlib.so

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

Comment By: Larry Rosenman
Date: 2001-03-02 18:00

Message:
Logged In: YES 
user_id=36452

What about -KPIC -Ki486 -belf -Wl,-Bexport? This is what is
                                currently used on SCO_SV

I'd lose the -Ki486 -belf as they are not needed for 
UnixWare. 

You can look at man pages at:

http://uw7doc.sco.com

or my site at:
http://www.lerctr.org:457

I also gave neil (nas) a login, and can do the same for you. 

LER


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

Comment By: Martin v. Löwis
Date: 2001-03-02 15:40

Message:
Logged In: YES 
user_id=21627

OK, upload fails, so try this inline. You may succeed with
cut-n-paste from the HTML source

Index: configure.in
===================================================================
RCS file: /cvsroot/python/python/dist/src/configure.in,v
retrieving revision 1.207
diff -u -r1.207 configure.in
--- configure.in	2001/02/27 04:45:05	1.207
+++ configure.in	2001/03/02 23:36:10
@@ -576,6 +576,11 @@
 		else
 			LDSHARED="ld -Bshareable ${LDFLAGS}"
 		fi;;
+	UnixWare*)
+		if test "$GCC" = "yes"
+		then LDSHARED='$(CC) -shared'
+		else LDSHARED="cc -G";
+		fi ;;
 	SCO_SV*) LDSHARED="cc -G -KPIC -Ki486 -belf
-Wl,-Bexport";;
 	Monterey*) LDSHARED="cc -G -dy -Bdynamic -Bexport
-L/usr/lib/ia64l64";;
 	CYGWIN*) LDSHARED="gcc -shared
-Wl,--enable-auto-image-base";;
@@ -601,6 +606,11 @@
 	BSD/OS*/4*) CCSHARED="-fpic";;
 	OpenBSD*) CCSHARED="-fpic";;
 	FreeBSD*|NetBSD*) CCSHARED="-fPIC";;
+	UnixWare*)
+		if test "$GCC" = "yes"
+		then LDSHARED='$(CC) -fPIC'
+		else LDSHARED="cc -KPIC";
+		fi ;;
 	SCO_SV*) CCSHARED="-KPIC -dy -Bdynamic";;
 	Monterey*) CCSHARED="-G";;
 	IRIX*/6*)  case $CC in


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

Comment By: Martin v. Löwis
Date: 2001-03-02 15:38

Message:
Logged In: YES 
user_id=21627

Can you provide an example compiler invocation to see what
options are actually used? One -c invocation and one linker
invocation would be good.

What about -KPIC -Ki486 -belf -Wl,-Bexport? This is what is
currently used on SCO_SV.

Can you please try the attached patch (patch1 if upload
succeeds)?

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

Comment By: Larry Rosenman
Date: 2001-02-10 16:41

Message:
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
$ 


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

Comment By: Neil Schemenauer
Date: 2001-02-10 12:46

Message:
What does "uname -u" say for UnixWare?

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

Comment By: A.M. Kuchling
Date: 2001-02-08 09:23

Message:
Assigning to Neil.

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

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


From nobody@sourceforge.net  Sun Mar  4 14:10:27 2001
From: nobody@sourceforge.net (nobody)
Date: Sun, 04 Mar 2001 06:10:27 -0800
Subject: [Python-bugs-list] [ python-Bugs-405427 ] SQL2000+XML returns "400.100" status
Message-ID: <E14ZZDP-0002YP-00@usw-sf-web1.sourceforge.net>

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

Category: Python Library
Group: Feature Request
Status: Open
Priority: 4
Submitted By: Luke Kenneth Casson Leighton
Assigned to: Jeremy Hylton
Summary: SQL2000+XML returns "400.100" status

Initial Comment:
httplib.py expects status codes to be "integers" - of
the form 400, 200, 502 etc etc.

if you run the SQL 2000 server with its XML interface
which is accessed over HTTP, and you do an invalid
query, the HTTP response code is "400.100".  the line
that says self.status = status = int(status) freaks out
and says, erk, can't convert status of value 400.100 to
an integer.

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

Comment By: Luke Kenneth Casson Leighton
Date: 2001-03-04 06:10

Message:
Logged In: YES 
user_id=80200

ha ha, surely you jest: you expect ms to conform fully
to rfcs?  i will check the return type of the HTTP response
for you: it may not be responding with HTTP/1.1 but
may be responding with some new/silly draft HTML thing.

whoops.

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

Comment By: Fred L. Drake, Jr.
Date: 2001-03-03 09:41

Message:
Logged In: YES 
user_id=3066

Sounds to me like a problem with the server; the response is invalid.  Section 6.1.1 of the HTTP/1.1 RFC states that response codes should be three digits, not three digits and then some dotted thing:

ftp://ftp.isi.edu/in-notes/rfc2616.txt

It may be appropriate to make httplib only examine the first three digits when converting to an integer, but I'm not sure that's really a good idea.

Assigned to Jeremy since he's been playing with urllib2.

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

Comment By: Martin v. Löwis
Date: 2001-03-02 16:03

Message:
Logged In: YES 
user_id=21627

Assuming that the response is something like

HTTP/1.1 400.100 Something went wrong

I think that the server is misbehaving. Such a response is a
clear violation of RFC 2616 (Hypertext Transfer Protocol --
-- HTTP/1.1), section 6.1.,

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase
CRLF

Section 6.1.1 elaborates the meaning of Status-code,
defining it as "a 3-digit integer result code". Maybe MS
misunderstood the meaning of extension-code, which is an
alternative to Status-code, not an additional piece of
information sent after a full-stop.

I propose to close this as "Won't Fix". Since the server
does not use the HTTP protocol, it does not need to be
supported in httplib. If you need that function, you'll have
to specialize httplib, e.g. by inheriting from HTTPResponse.


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

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


From nobody@sourceforge.net  Sun Mar  4 14:17:06 2001
From: nobody@sourceforge.net (nobody)
Date: Sun, 04 Mar 2001 06:17:06 -0800
Subject: [Python-bugs-list] [ python-Bugs-405831 ] popen3 read fails in blocks
Message-ID: <E14ZZJq-0003ae-00@usw-sf-web3.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Luke Kenneth Casson Leighton
Assigned to: Nobody/Anonymous
Summary: popen3 read fails in blocks

Initial Comment:
bash$ python2
from popen2 import popen3
r,w,e = popen3("bash")
w.write("ls")
w.flush()
print select([r],[],[],0)
[r],[],[]
t = r.read(50)
print t
"file1
file2
"
print select([r],[],[],0)
[],[],[]

r,w,e = popen3("bash")
w.write("ls")
w.close()
t = r.read(50)
print t
"file1
file2
[50 bytes of file listings]
"
t = r.read(50)
print t
"file3
file4
[50 more bytes of file listings]
"

print select([r],[],[],0)
[r],[],[]

what is going on????

when you do a w.flush(), the read file descriptor
can get the first 50 bytes, and then select
will *always* return [],[],[] - EVEN if there's
really more data pending to be read.

it is as if there is double-buffering being
done in os.popen3() which select() is failing
to access.

this is standard-compiled version of python 2.0
on linux mandrake 7.1.  if it makes any difference.

luke

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

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


From nobody@sourceforge.net  Sun Mar  4 14:53:29 2001
From: nobody@sourceforge.net (nobody)
Date: Sun, 04 Mar 2001 06:53:29 -0800
Subject: [Python-bugs-list] [ python-Bugs-405837 ] getting PyRun_String() true result
Message-ID: <E14ZZt3-0007Ku-00@usw-sf-web2.sourceforge.net>

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

Category: Python Interpreter Core
Group: Feature Request
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Nobody/Anonymous
Summary: getting PyRun_String() true result

Initial Comment:
It seems impossible to build am embedded Python
interpreter extension which actually allows getting
the result of the evaluation of a string from the
interpreter, as it is done in interactive mode, as in
the following:
  def f: pass
  f
prints:
  <function f at 0x8069694>

But in C (called twice with the 2 above strings):
  PyRun_String(string, Py_file_input, globals, globals)
returns None.

I found a workaround by patching the core in ceval.c,
eval_code2() (inspired by the PRINT_EXPR case):

...
case POP_TOP:
  v = POP();
PyDict_SetItemString(f->f_globals, "_", v); /* added */
  Py_DECREF(v);
  continue;
...

and then:
  PyRun_String(string, Py_file_input, globals, globals)
  result =PyDict_GetItemString(globals, "_")
returns the '<function f at 0x8069694>' correct result.


My goal is to allow the tclpython extension (at
http://jfontain.free.fr/) to work without having to
insert print statements on the Python side to be able
to pass data to the Tcl interpreter.

Please forgive me if there is an obvious way to do the
above without patching the core, but I am new to Python
(I like it already though :-)

Jean-Luc Fontaine

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

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


From nobody@sourceforge.net  Sun Mar  4 15:20:00 2001
From: nobody@sourceforge.net (nobody)
Date: Sun, 04 Mar 2001 07:20:00 -0800
Subject: [Python-bugs-list] [ python-Bugs-233668 ] install-sh has no -d option but 2.1a2 Makefile uses it
Message-ID: <E14ZaIi-0007Xc-00@usw-sf-web2.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: Closed
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-03-04 07:19

Message:
Logged In: YES 
user_id=3066

Since this has been fixed, let's close the bug report...

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

Comment By: Neil Schemenauer
Date: 2001-03-03 22:29

Message:
Logged In: YES 
user_id=35752

Yes, this has been fixed.

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

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  Sun Mar  4 15:50:54 2001
From: nobody@sourceforge.net (nobody)
Date: Sun, 04 Mar 2001 07:50:54 -0800
Subject: [Python-bugs-list] [ python-Bugs-405427 ] SQL2000+XML returns "400.100" status
Message-ID: <E14Zamc-0005JA-00@usw-sf-web3.sourceforge.net>

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

Category: Python Library
Group: Feature Request
Status: Open
Priority: 4
Submitted By: Luke Kenneth Casson Leighton
Assigned to: Jeremy Hylton
Summary: SQL2000+XML returns "400.100" status

Initial Comment:
httplib.py expects status codes to be "integers" - of
the form 400, 200, 502 etc etc.

if you run the SQL 2000 server with its XML interface
which is accessed over HTTP, and you do an invalid
query, the HTTP response code is "400.100".  the line
that says self.status = status = int(status) freaks out
and says, erk, can't convert status of value 400.100 to
an integer.

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

Comment By: Fred L. Drake, Jr.
Date: 2001-03-04 07:50

Message:
Logged In: YES 
user_id=3066

I wasn't suggesting that this was a problem with your application code; this is clearly a problem with the SQL2000 server.  It has nothing to do with either HTML or XML, only the transport mechanism (HTTP).  Both HTTP/1.0 and HTTP/1.1 define the response code to be three digits.

The issue for httplib is how best to handle the error; I'm not sure what the best way is.  You certainly are suggesting that the current behavior isn't quite right for working with the SQL2000 server.

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

Comment By: Luke Kenneth Casson Leighton
Date: 2001-03-04 06:10

Message:
Logged In: YES 
user_id=80200

ha ha, surely you jest: you expect ms to conform fully
to rfcs?  i will check the return type of the HTTP response
for you: it may not be responding with HTTP/1.1 but
may be responding with some new/silly draft HTML thing.

whoops.

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

Comment By: Fred L. Drake, Jr.
Date: 2001-03-03 09:41

Message:
Logged In: YES 
user_id=3066

Sounds to me like a problem with the server; the response is invalid.  Section 6.1.1 of the HTTP/1.1 RFC states that response codes should be three digits, not three digits and then some dotted thing:

ftp://ftp.isi.edu/in-notes/rfc2616.txt

It may be appropriate to make httplib only examine the first three digits when converting to an integer, but I'm not sure that's really a good idea.

Assigned to Jeremy since he's been playing with urllib2.

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

Comment By: Martin v. Löwis
Date: 2001-03-02 16:03

Message:
Logged In: YES 
user_id=21627

Assuming that the response is something like

HTTP/1.1 400.100 Something went wrong

I think that the server is misbehaving. Such a response is a
clear violation of RFC 2616 (Hypertext Transfer Protocol --
-- HTTP/1.1), section 6.1.,

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase
CRLF

Section 6.1.1 elaborates the meaning of Status-code,
defining it as "a 3-digit integer result code". Maybe MS
misunderstood the meaning of extension-code, which is an
alternative to Status-code, not an additional piece of
information sent after a full-stop.

I propose to close this as "Won't Fix". Since the server
does not use the HTTP protocol, it does not need to be
supported in httplib. If you need that function, you'll have
to specialize httplib, e.g. by inheriting from HTTPResponse.


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

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


From nobody@sourceforge.net  Sun Mar  4 16:33:58 2001
From: nobody@sourceforge.net (nobody)
Date: Sun, 04 Mar 2001 08:33:58 -0800
Subject: [Python-bugs-list] [ python-Bugs-405427 ] SQL2000+XML returns "400.100" status
Message-ID: <E14ZbSI-0005CA-00@usw-sf-web1.sourceforge.net>

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

Category: Python Library
Group: Feature Request
Status: Open
Priority: 4
Submitted By: Luke Kenneth Casson Leighton
Assigned to: Jeremy Hylton
Summary: SQL2000+XML returns "400.100" status

Initial Comment:
httplib.py expects status codes to be "integers" - of
the form 400, 200, 502 etc etc.

if you run the SQL 2000 server with its XML interface
which is accessed over HTTP, and you do an invalid
query, the HTTP response code is "400.100".  the line
that says self.status = status = int(status) freaks out
and says, erk, can't convert status of value 400.100 to
an integer.

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

Comment By: Martin v. Löwis
Date: 2001-03-04 08:33

Message:
Logged In: YES 
user_id=21627

I originally proposed that the current behaviour is fine: If
the other end violates the protocol, you get an exception.
In further review, I find that raising BadStatusLine might
be more appropriate. I'll try to come up with a patch.

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

Comment By: Fred L. Drake, Jr.
Date: 2001-03-04 07:50

Message:
Logged In: YES 
user_id=3066

I wasn't suggesting that this was a problem with your application code; this is clearly a problem with the SQL2000 server.  It has nothing to do with either HTML or XML, only the transport mechanism (HTTP).  Both HTTP/1.0 and HTTP/1.1 define the response code to be three digits.

The issue for httplib is how best to handle the error; I'm not sure what the best way is.  You certainly are suggesting that the current behavior isn't quite right for working with the SQL2000 server.

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

Comment By: Luke Kenneth Casson Leighton
Date: 2001-03-04 06:10

Message:
Logged In: YES 
user_id=80200

ha ha, surely you jest: you expect ms to conform fully
to rfcs?  i will check the return type of the HTTP response
for you: it may not be responding with HTTP/1.1 but
may be responding with some new/silly draft HTML thing.

whoops.

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

Comment By: Fred L. Drake, Jr.
Date: 2001-03-03 09:41

Message:
Logged In: YES 
user_id=3066

Sounds to me like a problem with the server; the response is invalid.  Section 6.1.1 of the HTTP/1.1 RFC states that response codes should be three digits, not three digits and then some dotted thing:

ftp://ftp.isi.edu/in-notes/rfc2616.txt

It may be appropriate to make httplib only examine the first three digits when converting to an integer, but I'm not sure that's really a good idea.

Assigned to Jeremy since he's been playing with urllib2.

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

Comment By: Martin v. Löwis
Date: 2001-03-02 16:03

Message:
Logged In: YES 
user_id=21627

Assuming that the response is something like

HTTP/1.1 400.100 Something went wrong

I think that the server is misbehaving. Such a response is a
clear violation of RFC 2616 (Hypertext Transfer Protocol --
-- HTTP/1.1), section 6.1.,

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase
CRLF

Section 6.1.1 elaborates the meaning of Status-code,
defining it as "a 3-digit integer result code". Maybe MS
misunderstood the meaning of extension-code, which is an
alternative to Status-code, not an additional piece of
information sent after a full-stop.

I propose to close this as "Won't Fix". Since the server
does not use the HTTP protocol, it does not need to be
supported in httplib. If you need that function, you'll have
to specialize httplib, e.g. by inheriting from HTTPResponse.


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

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


From nobody@sourceforge.net  Sun Mar  4 17:00:33 2001
From: nobody@sourceforge.net (nobody)
Date: Sun, 04 Mar 2001 09:00:33 -0800
Subject: [Python-bugs-list] [ python-Bugs-405427 ] SQL2000+XML returns "400.100" status
Message-ID: <E14Zbs1-0005pu-00@usw-sf-web3.sourceforge.net>

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

Category: Python Library
Group: Feature Request
Status: Open
Priority: 4
Submitted By: Luke Kenneth Casson Leighton
Assigned to: Jeremy Hylton
Summary: SQL2000+XML returns "400.100" status

Initial Comment:
httplib.py expects status codes to be "integers" - of
the form 400, 200, 502 etc etc.

if you run the SQL 2000 server with its XML interface
which is accessed over HTTP, and you do an invalid
query, the HTTP response code is "400.100".  the line
that says self.status = status = int(status) freaks out
and says, erk, can't convert status of value 400.100 to
an integer.

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

Comment By: Martin v. Löwis
Date: 2001-03-04 09:00

Message:
Logged In: YES 
user_id=21627

A patch for this bug is available at
https://sourceforge.net/tracker/index.php?func=detail&aid=405845&group_id=5470&atid=305470

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

Comment By: Martin v. Löwis
Date: 2001-03-04 08:33

Message:
Logged In: YES 
user_id=21627

I originally proposed that the current behaviour is fine: If
the other end violates the protocol, you get an exception.
In further review, I find that raising BadStatusLine might
be more appropriate. I'll try to come up with a patch.

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

Comment By: Fred L. Drake, Jr.
Date: 2001-03-04 07:50

Message:
Logged In: YES 
user_id=3066

I wasn't suggesting that this was a problem with your application code; this is clearly a problem with the SQL2000 server.  It has nothing to do with either HTML or XML, only the transport mechanism (HTTP).  Both HTTP/1.0 and HTTP/1.1 define the response code to be three digits.

The issue for httplib is how best to handle the error; I'm not sure what the best way is.  You certainly are suggesting that the current behavior isn't quite right for working with the SQL2000 server.

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

Comment By: Luke Kenneth Casson Leighton
Date: 2001-03-04 06:10

Message:
Logged In: YES 
user_id=80200

ha ha, surely you jest: you expect ms to conform fully
to rfcs?  i will check the return type of the HTTP response
for you: it may not be responding with HTTP/1.1 but
may be responding with some new/silly draft HTML thing.

whoops.

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

Comment By: Fred L. Drake, Jr.
Date: 2001-03-03 09:41

Message:
Logged In: YES 
user_id=3066

Sounds to me like a problem with the server; the response is invalid.  Section 6.1.1 of the HTTP/1.1 RFC states that response codes should be three digits, not three digits and then some dotted thing:

ftp://ftp.isi.edu/in-notes/rfc2616.txt

It may be appropriate to make httplib only examine the first three digits when converting to an integer, but I'm not sure that's really a good idea.

Assigned to Jeremy since he's been playing with urllib2.

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

Comment By: Martin v. Löwis
Date: 2001-03-02 16:03

Message:
Logged In: YES 
user_id=21627

Assuming that the response is something like

HTTP/1.1 400.100 Something went wrong

I think that the server is misbehaving. Such a response is a
clear violation of RFC 2616 (Hypertext Transfer Protocol --
-- HTTP/1.1), section 6.1.,

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase
CRLF

Section 6.1.1 elaborates the meaning of Status-code,
defining it as "a 3-digit integer result code". Maybe MS
misunderstood the meaning of extension-code, which is an
alternative to Status-code, not an additional piece of
information sent after a full-stop.

I propose to close this as "Won't Fix". Since the server
does not use the HTTP protocol, it does not need to be
supported in httplib. If you need that function, you'll have
to specialize httplib, e.g. by inheriting from HTTPResponse.


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

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


From nobody@sourceforge.net  Sun Mar  4 17:28:38 2001
From: nobody@sourceforge.net (nobody)
Date: Sun, 04 Mar 2001 09:28:38 -0800
Subject: [Python-bugs-list] [ python-Bugs-405849 ] print (float) of Python 2.0
Message-ID: <E14ZcJC-0008SU-00@usw-sf-web2.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Nobody/Anonymous
Summary: print (float) of Python 2.0

Initial Comment:
Python's float type is double precision.
Look at the position where the numbers are rounded. 


Result on Python 2.0 (or 2.1 alpha 2)

>>> 0.8
0.80000000000000004
>>> print 0.80000000000000004
0.8
>>> print 0.8000000000004
0.8
>>> print 0.7999999999999
0.8
>>> print 0.7999999999995
0.8
>>> print 0.7999999999994
0.799999999999



Result on Jython 2.0

>>> 0.8
0.8
>>> print 0.80000000000000004
0.8
>>> print 0.8000000000004
0.8000000000004
>>> print 0.7999999999999
0.7999999999999
>>> print 0.7999999999995
0.7999999999995
>>> print 0.7999999999994
0.7999999999994



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

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


From nobody@sourceforge.net  Sun Mar  4 18:08:10 2001
From: nobody@sourceforge.net (nobody)
Date: Sun, 04 Mar 2001 10:08:10 -0800
Subject: [Python-bugs-list] [ python-Bugs-405583 ] Objects never freed with nested scopes
Message-ID: <E14ZcvS-0006KT-00@usw-sf-web3.sourceforge.net>

Bugs #405583, was updated on 2001-03-02 19:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405583&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Priority: 7
Submitted By: Atsuo Ishimoto
Assigned to: Jeremy Hylton
Summary: Objects never freed with nested scopes

Initial Comment:
With this code,

from __future__ import nested_scopes
class foo:
    def __del__(self): print "del foo"

def f1():
    x = foo()
    def f2():x
    f2()

for i in range(10000):
    f1()

I see no "del foo" message.


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

Comment By: Martin v. Löwis
Date: 2001-03-04 10:08

Message:
Logged In: YES 
user_id=21627

I believe there are two missing decrefs: In STORE_DEREF,
PyCell_Set will incref the object, so the object POPped from
the stack must be decref'ed. In addition, GC requires that
the clear procedure not only sets the pointers to zero, but
actually decrefs the objects (i.e. breaks the cycle). A
patch is included below

Index: Objects/cellobject.c
===================================================================
RCS file:
/cvsroot/python/python/dist/src/Objects/cellobject.c,v
retrieving revision 1.1
diff -u -r1.1 cellobject.c
--- Objects/cellobject.c	2001/01/25 20:04:14	1.1
+++ Objects/cellobject.c	2001/03/04 18:04:45
@@ -83,6 +83,7 @@
 static int
 cell_clear(PyCellObject *op)
 {
+	Py_XDECREF(op->ob_ref);
 	op->ob_ref = NULL;
 	return 0;
 }
Index: Python/ceval.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Python/ceval.c,v
retrieving revision 2.230
diff -u -r2.230 ceval.c
--- Python/ceval.c	2001/02/16 11:52:31	2.230
+++ Python/ceval.c	2001/03/04 18:04:49
@@ -1670,6 +1670,7 @@
 			w = POP();
 			x = freevars[oparg];
 			PyCell_Set(x, w);
+			Py_DECREF(w);
 			continue;
 
 		case BUILD_TUPLE:


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

Comment By: Fred L. Drake, Jr.
Date: 2001-03-03 09:34

Message:
Logged In: YES 
user_id=3066

Assigned to Jeremy Hylton.

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

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


From nobody@sourceforge.net  Sun Mar  4 18:22:23 2001
From: nobody@sourceforge.net (nobody)
Date: Sun, 04 Mar 2001 10:22:23 -0800
Subject: [Python-bugs-list] [ python-Bugs-405837 ] getting PyRun_String() true result
Message-ID: <E14Zd9D-0000Oe-00@usw-sf-web2.sourceforge.net>

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

Category: Python Interpreter Core
Group: Feature Request
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Nobody/Anonymous
Summary: getting PyRun_String() true result

Initial Comment:
It seems impossible to build am embedded Python
interpreter extension which actually allows getting
the result of the evaluation of a string from the
interpreter, as it is done in interactive mode, as in
the following:
  def f: pass
  f
prints:
  <function f at 0x8069694>

But in C (called twice with the 2 above strings):
  PyRun_String(string, Py_file_input, globals, globals)
returns None.

I found a workaround by patching the core in ceval.c,
eval_code2() (inspired by the PRINT_EXPR case):

...
case POP_TOP:
  v = POP();
PyDict_SetItemString(f->f_globals, "_", v); /* added */
  Py_DECREF(v);
  continue;
...

and then:
  PyRun_String(string, Py_file_input, globals, globals)
  result =PyDict_GetItemString(globals, "_")
returns the '<function f at 0x8069694>' correct result.


My goal is to allow the tclpython extension (at
http://jfontain.free.fr/) to work without having to
insert print statements on the Python side to be able
to pass data to the Tcl interpreter.

Please forgive me if there is an obvious way to do the
above without patching the core, but I am new to Python
(I like it already though :-)

Jean-Luc Fontaine

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

Comment By: Martin v. Löwis
Date: 2001-03-04 10:22

Message:
Logged In: YES 
user_id=21627

Sure there is. PyRun_SimpleString executes a string in "file
mode"; this has no result. The interactive interpreter, when
it prints a result, runs the string in "eval mode" - only
evaluation gives a result.

To evaluate a string, use Py_RunString with Py_eval_input,
or perhaps Py_single_input.

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

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


From nobody@sourceforge.net  Sun Mar  4 18:31:30 2001
From: nobody@sourceforge.net (nobody)
Date: Sun, 04 Mar 2001 10:31:30 -0800
Subject: [Python-bugs-list] [ python-Bugs-405849 ] print (float) of Python 2.0
Message-ID: <E14ZdI2-0006Us-00@usw-sf-web3.sourceforge.net>

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

Category: None
Group: None
Status: Closed
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Nobody/Anonymous
Summary: print (float) of Python 2.0

Initial Comment:
Python's float type is double precision.
Look at the position where the numbers are rounded. 


Result on Python 2.0 (or 2.1 alpha 2)

>>> 0.8
0.80000000000000004
>>> print 0.80000000000000004
0.8
>>> print 0.8000000000004
0.8
>>> print 0.7999999999999
0.8
>>> print 0.7999999999995
0.8
>>> print 0.7999999999994
0.799999999999



Result on Jython 2.0

>>> 0.8
0.8
>>> print 0.80000000000000004
0.8
>>> print 0.8000000000004
0.8000000000004
>>> print 0.7999999999999
0.7999999999999
>>> print 0.7999999999995
0.7999999999995
>>> print 0.7999999999994
0.7999999999994



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

Comment By: Martin v. Löwis
Date: 2001-03-04 10:31

Message:
Logged In: YES 
user_id=21627

What is the bug that you want to report? It is perfectly
fine that CPython and Jython behave differently in this
respect. CPython uses the C double type, and inherits all
its semantics; Jython uses the Java double type - which
might be different, since the C standard does not say what
double is (only that it is more precise than float).

If you meant to report a more specific problem than the mere
difference, please re-report.

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

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


From nobody@sourceforge.net  Sun Mar  4 22:57:04 2001
From: nobody@sourceforge.net (nobody)
Date: Sun, 04 Mar 2001 14:57:04 -0800
Subject: [Python-bugs-list] [ python-Bugs-405894 ] sre fails on r'[\w-]' patterns
Message-ID: <E14ZhR2-00006G-00@usw-sf-web3.sourceforge.net>

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

Category: Regular Expressions
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Nobody/Anonymous
Summary: sre fails on r'[\w-]' patterns

Initial Comment:
Trying to match "email" addresses I used a patern from
"Python Essential Reference" (middle of page 115):
   import re
   addrStr = 'peterb@selresearch.net'
   print
re.search(r'([a-zA-Z][\w-]*@[\w-]+(?:\.[\w-]+)+)',
addrStr)

By default this brings in sre these days I believe.
On the same machine if I explicitly import pre this
works
(after changing it to be pre.search(...) ;-).
Explicitly importing sre causes the same failure as
just importing re.

The machine I'm on is a:
  SunOS burn 5.8 Generic_108528-02 sun4u sparc
SUNW,Ultra-1
with Python 1.6 compiled with gcc 2.95.2 with no
special attention given.

I have isolated it to the character class r'[\w-]'
failing,
and indeed the test suite doesn't test for this case.

Thought you should know -

Thanks for all the great software

;;peter

- - - - here is a run on my machine showing the
behavior - - -

burn <14:54:55># python
Python 1.6 (#1, Feb 28 2001, 12:56:49)  [GCC 2.95.2
19991024 (release)] on sunos5
Copyright (c) 1995-2000 Corporation for National
Research Initiatives.
All Rights Reserved.
Copyright (c) 1991-1995 Stichting Mathematisch Centrum,
Amsterdam.
All Rights Reserved.
>>> import re
>>> addrStr = 'peterb@selresearch.net'
>>> print
re.search(r'([a-zA-Z][\w-]*@[\w-]+(?:\.[\w-]+)+)',
addrStr)
None
>>> 
>>> import pre
>>> print
pre.search(r'([a-zA-Z][\w-]*@[\w-]+(?:\.[\w-]+)+)',
addrStr)
<pre.MatchObject instance at 1c1058>
>>> print
pre.search(r'([a-zA-Z][\w-]*@[\w-]+(?:\.[\w-]+)+)',
addrStr).span()
(0, 22)
>>> 
>>> import sre
>>> print
sre.search(r'([a-zA-Z][\w-]*@[\w-]+(?:\.[\w-]+)+)',
addrStr)
None
>>> 
>>> ^D
burn <14:56:58># 

- - - - end of run - - - -




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

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


From nobody@sourceforge.net  Mon Mar  5 01:22:42 2001
From: nobody@sourceforge.net (nobody)
Date: Sun, 04 Mar 2001 17:22:42 -0800
Subject: [Python-bugs-list] [ python-Bugs-231560 ] pdb imports 'repr', causing name collision
Message-ID: <E14Zjhy-0003US-00@usw-sf-web2.sourceforge.net>

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

Category: Python Library
Group: None
Status: Closed
Priority: 5
Submitted By: Greg Ward
Assigned to: Greg Ward
Summary: pdb imports 'repr', causing name collision

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


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

Comment By: Greg Ward
Date: 2001-03-04 17:22

Message:
Logged In: YES 
user_id=14422

Works for me now with 2.1b1.

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

Comment By: Tim Peters
Date: 2001-02-09 15:29

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

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

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


From nobody@sourceforge.net  Mon Mar  5 05:44:44 2001
From: nobody@sourceforge.net (nobody)
Date: Sun, 04 Mar 2001 21:44:44 -0800
Subject: [Python-bugs-list] [ python-Bugs-405939 ] HTTPConnection Host hdr wrong w/ proxy
Message-ID: <E14ZnnY-0005HB-00@usw-sf-web1.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Ernie Sasaki
Assigned to: Nobody/Anonymous
Summary: HTTPConnection Host hdr wrong w/ proxy

Initial Comment:
The HTTPConnection class' putrequest() method is 
incorrect if self._http_vsn == 11 and a proxy is in 
use.

Currently the following is done in httplib.py revision 
1.33:

if self.port == HTTP_PORT:
    self.putheader('Host', self.host)
else:
    self.putheader('Host', "%s:%s" % (self.host, 
self.port))

However if a proxy is in use, self.host is the proxy 
address, and url contains the "realhost" which should 
be in the Host header. (urllib does the right thing 
here but it uses the HTTP class and not 
HTTPConnection. It doesn't see this problem because 
then HTTP/1.0 is used and no Host header is sent 
automatically.)

Instead the following is correct:

match = httpRE.search(url)
if match:
    self.putheader('Host', match.group(1))
else:
    if self.port == HTTP_PORT:
        self.putheader('Host', self.host)
    else:
	self.putheader('Host', "%s:%s" % (self.host, 
self.port))

where:

httpRE = re.compile(r'(?i)http://([^/]+)')


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

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


From nobody@sourceforge.net  Mon Mar  5 08:04:34 2001
From: nobody@sourceforge.net (nobody)
Date: Mon, 05 Mar 2001 00:04:34 -0800
Subject: [Python-bugs-list] [ python-Bugs-405894 ] sre fails on r'[\w-]' patterns
Message-ID: <E14Zpys-0006kI-00@usw-sf-web1.sourceforge.net>

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

Category: Regular Expressions
Group: Platform-specific
Status: Closed
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Nobody/Anonymous
Summary: sre fails on r'[\w-]' patterns

Initial Comment:
Trying to match "email" addresses I used a patern from
"Python Essential Reference" (middle of page 115):
   import re
   addrStr = 'peterb@selresearch.net'
   print
re.search(r'([a-zA-Z][\w-]*@[\w-]+(?:\.[\w-]+)+)',
addrStr)

By default this brings in sre these days I believe.
On the same machine if I explicitly import pre this
works
(after changing it to be pre.search(...) ;-).
Explicitly importing sre causes the same failure as
just importing re.

The machine I'm on is a:
  SunOS burn 5.8 Generic_108528-02 sun4u sparc
SUNW,Ultra-1
with Python 1.6 compiled with gcc 2.95.2 with no
special attention given.

I have isolated it to the character class r'[\w-]'
failing,
and indeed the test suite doesn't test for this case.

Thought you should know -

Thanks for all the great software

;;peter

- - - - here is a run on my machine showing the
behavior - - -

burn <14:54:55># python
Python 1.6 (#1, Feb 28 2001, 12:56:49)  [GCC 2.95.2
19991024 (release)] on sunos5
Copyright (c) 1995-2000 Corporation for National
Research Initiatives.
All Rights Reserved.
Copyright (c) 1991-1995 Stichting Mathematisch Centrum,
Amsterdam.
All Rights Reserved.
>>> import re
>>> addrStr = 'peterb@selresearch.net'
>>> print
re.search(r'([a-zA-Z][\w-]*@[\w-]+(?:\.[\w-]+)+)',
addrStr)
None
>>> 
>>> import pre
>>> print
pre.search(r'([a-zA-Z][\w-]*@[\w-]+(?:\.[\w-]+)+)',
addrStr)
<pre.MatchObject instance at 1c1058>
>>> print
pre.search(r'([a-zA-Z][\w-]*@[\w-]+(?:\.[\w-]+)+)',
addrStr).span()
(0, 22)
>>> 
>>> import sre
>>> print
sre.search(r'([a-zA-Z][\w-]*@[\w-]+(?:\.[\w-]+)+)',
addrStr)
None
>>> 
>>> ^D
burn <14:56:58># 

- - - - end of run - - - -




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

Comment By: Martin v. Löwis
Date: 2001-03-05 00:04

Message:
Logged In: YES 
user_id=21627

This bug has been fixed in Python 2.0.

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

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


From nobody@sourceforge.net  Mon Mar  5 08:39:58 2001
From: nobody@sourceforge.net (nobody)
Date: Mon, 05 Mar 2001 00:39:58 -0800
Subject: [Python-bugs-list] [ python-Bugs-405939 ] HTTPConnection Host hdr wrong w/ proxy
Message-ID: <E14ZqX8-00076j-00@usw-sf-web1.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Ernie Sasaki
Assigned to: Nobody/Anonymous
Summary: HTTPConnection Host hdr wrong w/ proxy

Initial Comment:
The HTTPConnection class' putrequest() method is 
incorrect if self._http_vsn == 11 and a proxy is in 
use.

Currently the following is done in httplib.py revision 
1.33:

if self.port == HTTP_PORT:
    self.putheader('Host', self.host)
else:
    self.putheader('Host', "%s:%s" % (self.host, 
self.port))

However if a proxy is in use, self.host is the proxy 
address, and url contains the "realhost" which should 
be in the Host header. (urllib does the right thing 
here but it uses the HTTP class and not 
HTTPConnection. It doesn't see this problem because 
then HTTP/1.0 is used and no Host header is sent 
automatically.)

Instead the following is correct:

match = httpRE.search(url)
if match:
    self.putheader('Host', match.group(1))
else:
    if self.port == HTTP_PORT:
        self.putheader('Host', self.host)
    else:
	self.putheader('Host', "%s:%s" % (self.host, 
self.port))

where:

httpRE = re.compile(r'(?i)http://([^/]+)')


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

Comment By: Martin v. Löwis
Date: 2001-03-05 00:39

Message:
Logged In: YES 
user_id=21627

Why is that a bug? RFC 2616, section 5.2, states

# If Request-URI is an absoluteURI, the host is part of the 
# Request-URI. Any Host header field value in the request 
# MUST be ignored.

So in the presence of an absolute URI, the Host: field does
not matter. It is certainly nicer to fill in the right Host:
field, but I'd like to understand the problem before
applying a fix. Your patch is incomplete, IMO: it does not
deal with the user/password part in the URL.

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

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


From nobody@sourceforge.net  Mon Mar  5 10:14:51 2001
From: nobody@sourceforge.net (nobody)
Date: Mon, 05 Mar 2001 02:14:51 -0800
Subject: [Python-bugs-list] [ python-Bugs-231439 ] python and Python interfaces should use cc -G for so's
Message-ID: <E14Zs0x-0007Hf-00@usw-sf-web2.sourceforge.net>

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

Category: Build
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Larry Rosenman
Assigned to: Martin v. Löwis
Summary: python and Python interfaces should use cc -G for so's

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


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

Comment By: Martin v. Löwis
Date: 2001-03-05 02:14

Message:
Logged In: YES 
user_id=21627

Can you please try adding -Wl,-Bexport into LINKFORSHARED?
This is essentially the same as SCO_SV, except that
-Bdynamic -dy appear to be the default on Unixware.

This option will cause symbols in the python executable to
be exported to shared libraries. By default, only shared
libraries export all their symbols; for executables, -Bhide
is the default. That should cause _PyObject_New to be
available.

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

Comment By: Neil Schemenauer
Date: 2001-03-03 23:37

Message:
Logged In: YES 
user_id=35752

Martin, with your patch I get:

ImportError: Python 2.1b1 (#1, Mar  4 2001, 01:30:18) [C] on
unixware5
Type "copyright", "credits" or "license" for more
information.
>>> import zlib
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
dynamic linker: ./python: relocation error: symbol not
found: _PyObject_New; referenced from:
/home/nas/Python-2.1b1/build/lib.unixware-5-i386-2.1/zlib.so

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

Comment By: Larry Rosenman
Date: 2001-03-02 18:00

Message:
Logged In: YES 
user_id=36452

What about -KPIC -Ki486 -belf -Wl,-Bexport? This is what is
                                currently used on SCO_SV

I'd lose the -Ki486 -belf as they are not needed for 
UnixWare. 

You can look at man pages at:

http://uw7doc.sco.com

or my site at:
http://www.lerctr.org:457

I also gave neil (nas) a login, and can do the same for you. 

LER


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

Comment By: Martin v. Löwis
Date: 2001-03-02 15:40

Message:
Logged In: YES 
user_id=21627

OK, upload fails, so try this inline. You may succeed with
cut-n-paste from the HTML source

Index: configure.in
===================================================================
RCS file: /cvsroot/python/python/dist/src/configure.in,v
retrieving revision 1.207
diff -u -r1.207 configure.in
--- configure.in	2001/02/27 04:45:05	1.207
+++ configure.in	2001/03/02 23:36:10
@@ -576,6 +576,11 @@
 		else
 			LDSHARED="ld -Bshareable ${LDFLAGS}"
 		fi;;
+	UnixWare*)
+		if test "$GCC" = "yes"
+		then LDSHARED='$(CC) -shared'
+		else LDSHARED="cc -G";
+		fi ;;
 	SCO_SV*) LDSHARED="cc -G -KPIC -Ki486 -belf
-Wl,-Bexport";;
 	Monterey*) LDSHARED="cc -G -dy -Bdynamic -Bexport
-L/usr/lib/ia64l64";;
 	CYGWIN*) LDSHARED="gcc -shared
-Wl,--enable-auto-image-base";;
@@ -601,6 +606,11 @@
 	BSD/OS*/4*) CCSHARED="-fpic";;
 	OpenBSD*) CCSHARED="-fpic";;
 	FreeBSD*|NetBSD*) CCSHARED="-fPIC";;
+	UnixWare*)
+		if test "$GCC" = "yes"
+		then LDSHARED='$(CC) -fPIC'
+		else LDSHARED="cc -KPIC";
+		fi ;;
 	SCO_SV*) CCSHARED="-KPIC -dy -Bdynamic";;
 	Monterey*) CCSHARED="-G";;
 	IRIX*/6*)  case $CC in


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

Comment By: Martin v. Löwis
Date: 2001-03-02 15:38

Message:
Logged In: YES 
user_id=21627

Can you provide an example compiler invocation to see what
options are actually used? One -c invocation and one linker
invocation would be good.

What about -KPIC -Ki486 -belf -Wl,-Bexport? This is what is
currently used on SCO_SV.

Can you please try the attached patch (patch1 if upload
succeeds)?

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

Comment By: Larry Rosenman
Date: 2001-02-10 16:41

Message:
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
$ 


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

Comment By: Neil Schemenauer
Date: 2001-02-10 12:46

Message:
What does "uname -u" say for UnixWare?

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

Comment By: A.M. Kuchling
Date: 2001-02-08 09:23

Message:
Assigning to Neil.

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

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


From nobody@sourceforge.net  Mon Mar  5 11:42:48 2001
From: nobody@sourceforge.net (nobody)
Date: Mon, 05 Mar 2001 03:42:48 -0800
Subject: [Python-bugs-list] [ python-Bugs-405999 ] getopt: extra args behavior wrong
Message-ID: <E14ZtO4-0007vB-00@usw-sf-web2.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Gregor Hoffleit
Assigned to: Nobody/Anonymous
Summary: getopt: extra args behavior wrong

Initial Comment:
[Forwarded from the Debian bug tracking system,
Bug#87722]
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=87722&repeatmerged=yes

Sender: Wichert Akkerman <wichert@cistron.nl>

getopt claims to behave just like GNU getopt, but it
does not. If I use
this code snippet:

------------------------------------------------------------------------------
(opt,args) = getopt.getopt(sys.argv[1:], 'ab')

print "Options decoded: " + string.join(map(lambda x:
x[0], opt), ', ')
print "Extra arguments: " +  string.join(args, ', ')
------------------------------------------------------------------------------

Then this result is correct:

[fog;/tmp]-26> ./x.py -a -b bla
Options decoded: -a, -b
Extra arguments: bla

But this is wrong:

[fog;/tmp]-27> ./x.py -a bla -b 
Options decoded: -a
Extra arguments: bla, -b

That should give the exact same result, but doesn't.
The problem seems
to be that the while loop used to iterate over the
arguments aborts
at the first non-option argument, while it should
continue to check
all arguments for possible options.

This problem persist in python2-base.

Wichert.


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

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


From nobody@sourceforge.net  Mon Mar  5 12:22:11 2001
From: nobody@sourceforge.net (nobody)
Date: Mon, 05 Mar 2001 04:22:11 -0800
Subject: [Python-bugs-list] [ python-Bugs-405427 ] SQL2000+XML returns "400.100" status
Message-ID: <E14Zu0B-0005nH-00@usw-sf-web3.sourceforge.net>

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

Category: Python Library
Group: Feature Request
Status: Open
Priority: 4
Submitted By: Luke Kenneth Casson Leighton
Assigned to: Jeremy Hylton
Summary: SQL2000+XML returns "400.100" status

Initial Comment:
httplib.py expects status codes to be "integers" - of
the form 400, 200, 502 etc etc.

if you run the SQL 2000 server with its XML interface
which is accessed over HTTP, and you do an invalid
query, the HTTP response code is "400.100".  the line
that says self.status = status = int(status) freaks out
and says, erk, can't convert status of value 400.100 to
an integer.

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

Comment By: Luke Kenneth Casson Leighton
Date: 2001-03-05 04:22

Message:
Logged In: YES 
user_id=80200

hmmm....

other-thoughts.  over-riding the HTTPResponse class is
fine... _if_ it's
easy to replace a single function that, say, deals with the
error code
conversion.  but to override a class just to fix one line?

...does anyone have contacts for bug-reporting at microsoft?


Script started on Mon Mar  5 13:17:59 2001
[lkcl@knight python]$ telnet 192.168.5.63 80
Trying 192.168.5.63...
Connected to 192.168.5.63.
Escape character is '^]'.
GET /DCRP
HTTP/1.1 400.100 Bad Request
Server: Microsoft-IIS/5.0
Date: Mon, 05 Mar 2001 12:18:59 GMT
Content-type: text/html

<H3>ERROR: 400.100 Bad Request</H3><b>HResult:</b>
0x80004005<br>
<b>Source:</b> Microsoft SQL isapi extension<br>
<b>Description:</b> Query not specified<br>Connection closed
by foreign host.
[lkcl@knight python]$ exit

Script done on Mon Mar  5 13:18:12 2001
~                                                    

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

Comment By: Martin v. Löwis
Date: 2001-03-04 09:00

Message:
Logged In: YES 
user_id=21627

A patch for this bug is available at
https://sourceforge.net/tracker/index.php?func=detail&aid=405845&group_id=5470&atid=305470

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

Comment By: Martin v. Löwis
Date: 2001-03-04 08:33

Message:
Logged In: YES 
user_id=21627

I originally proposed that the current behaviour is fine: If
the other end violates the protocol, you get an exception.
In further review, I find that raising BadStatusLine might
be more appropriate. I'll try to come up with a patch.

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

Comment By: Fred L. Drake, Jr.
Date: 2001-03-04 07:50

Message:
Logged In: YES 
user_id=3066

I wasn't suggesting that this was a problem with your application code; this is clearly a problem with the SQL2000 server.  It has nothing to do with either HTML or XML, only the transport mechanism (HTTP).  Both HTTP/1.0 and HTTP/1.1 define the response code to be three digits.

The issue for httplib is how best to handle the error; I'm not sure what the best way is.  You certainly are suggesting that the current behavior isn't quite right for working with the SQL2000 server.

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

Comment By: Luke Kenneth Casson Leighton
Date: 2001-03-04 06:10

Message:
Logged In: YES 
user_id=80200

ha ha, surely you jest: you expect ms to conform fully
to rfcs?  i will check the return type of the HTTP response
for you: it may not be responding with HTTP/1.1 but
may be responding with some new/silly draft HTML thing.

whoops.

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

Comment By: Fred L. Drake, Jr.
Date: 2001-03-03 09:41

Message:
Logged In: YES 
user_id=3066

Sounds to me like a problem with the server; the response is invalid.  Section 6.1.1 of the HTTP/1.1 RFC states that response codes should be three digits, not three digits and then some dotted thing:

ftp://ftp.isi.edu/in-notes/rfc2616.txt

It may be appropriate to make httplib only examine the first three digits when converting to an integer, but I'm not sure that's really a good idea.

Assigned to Jeremy since he's been playing with urllib2.

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

Comment By: Martin v. Löwis
Date: 2001-03-02 16:03

Message:
Logged In: YES 
user_id=21627

Assuming that the response is something like

HTTP/1.1 400.100 Something went wrong

I think that the server is misbehaving. Such a response is a
clear violation of RFC 2616 (Hypertext Transfer Protocol --
-- HTTP/1.1), section 6.1.,

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase
CRLF

Section 6.1.1 elaborates the meaning of Status-code,
defining it as "a 3-digit integer result code". Maybe MS
misunderstood the meaning of extension-code, which is an
alternative to Status-code, not an additional piece of
information sent after a full-stop.

I propose to close this as "Won't Fix". Since the server
does not use the HTTP protocol, it does not need to be
supported in httplib. If you need that function, you'll have
to specialize httplib, e.g. by inheriting from HTTPResponse.


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

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


From nobody@sourceforge.net  Mon Mar  5 16:47:50 2001
From: nobody@sourceforge.net (nobody)
Date: Mon, 05 Mar 2001 08:47:50 -0800
Subject: [Python-bugs-list] [ python-Bugs-406049 ] crash on nested listcomps
Message-ID: <E14Zy9G-00028Z-00@usw-sf-web2.sourceforge.net>

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

Category: Python Interpreter Core
Group: None
Status: Open
Priority: 5
Submitted By: David Goodger
Assigned to: Nobody/Anonymous
Summary: crash on nested listcomps

Initial Comment:
(if you need to contact me: dgoodger@atsautomation.com)

I got an aborted interpreter under both QNX 4.25 and 
Windows NT 4.0:

Python 2.1b1 (#2, Mar 05 2001, 11:19:23) [C] on qnxJ
Type "copyright", "credits" or "license" for more 
information.
>>> l=[[[0,0,0] for i in range(3)] for j in range(3)]
Fatal Python error: unknown scope for _[2] in ?(0) in 
<stdin>
symbols: {'i': 2, 'l': 2, 'j': 2, 'range': 8, '_[1]': 
2}
locals: {'l': 1, 'j': 2, '_[1]': 3, 'i': 0}
globals: {'range': 1}

%1 - 32637 Abort                python


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

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


From nobody@sourceforge.net  Mon Mar  5 18:36:24 2001
From: nobody@sourceforge.net (nobody)
Date: Mon, 05 Mar 2001 10:36:24 -0800
Subject: [Python-bugs-list] [ python-Bugs-406049 ] crash on nested listcomps
Message-ID: <E14ZzqK-0000ZG-00@usw-sf-web3.sourceforge.net>

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

Category: Python Interpreter Core
Group: None
Status: Open
Priority: 5
Submitted By: David Goodger
Assigned to: Nobody/Anonymous
Summary: crash on nested listcomps

Initial Comment:
(if you need to contact me: dgoodger@atsautomation.com)

I got an aborted interpreter under both QNX 4.25 and 
Windows NT 4.0:

Python 2.1b1 (#2, Mar 05 2001, 11:19:23) [C] on qnxJ
Type "copyright", "credits" or "license" for more 
information.
>>> l=[[[0,0,0] for i in range(3)] for j in range(3)]
Fatal Python error: unknown scope for _[2] in ?(0) in 
<stdin>
symbols: {'i': 2, 'l': 2, 'j': 2, 'range': 8, '_[1]': 
2}
locals: {'l': 1, 'j': 2, '_[1]': 3, 'i': 0}
globals: {'range': 1}

%1 - 32637 Abort                python


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

Comment By: Michael Hudson
Date: 2001-03-05 10:36

Message:
Logged In: YES 
user_id=6656

tee hee.  fun one.

see patch #406076 for a fix & test case.  not sure the fix
is exactly what's wanted though.  the problem is that
--st->st_tmpname is called before symtable_node is called on
the first node in the listcomp. this patch gets rid of the
decrement and resets st_tmpname in symtable_enter_scope.

and doesn't pass make test.  hang on...

I want to rewrite Python/compile.c in OCaml one of these days...

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

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


From nobody@sourceforge.net  Mon Mar  5 18:51:34 2001
From: nobody@sourceforge.net (nobody)
Date: Mon, 05 Mar 2001 10:51:34 -0800
Subject: [Python-bugs-list] [ python-Bugs-405837 ] getting PyRun_String() true result
Message-ID: <E14a050-0003Ex-00@usw-sf-web2.sourceforge.net>

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

Category: Python Interpreter Core
Group: Feature Request
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Nobody/Anonymous
Summary: getting PyRun_String() true result

Initial Comment:
It seems impossible to build am embedded Python
interpreter extension which actually allows getting
the result of the evaluation of a string from the
interpreter, as it is done in interactive mode, as in
the following:
  def f: pass
  f
prints:
  <function f at 0x8069694>

But in C (called twice with the 2 above strings):
  PyRun_String(string, Py_file_input, globals, globals)
returns None.

I found a workaround by patching the core in ceval.c,
eval_code2() (inspired by the PRINT_EXPR case):

...
case POP_TOP:
  v = POP();
PyDict_SetItemString(f->f_globals, "_", v); /* added */
  Py_DECREF(v);
  continue;
...

and then:
  PyRun_String(string, Py_file_input, globals, globals)
  result =PyDict_GetItemString(globals, "_")
returns the '<function f at 0x8069694>' correct result.


My goal is to allow the tclpython extension (at
http://jfontain.free.fr/) to work without having to
insert print statements on the Python side to be able
to pass data to the Tcl interpreter.

Please forgive me if there is an obvious way to do the
above without patching the core, but I am new to Python
(I like it already though :-)

Jean-Luc Fontaine

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

Comment By: Nobody/Anonymous
Date: 2001-03-05 10:51

Message:
Logged In: NO 

> To evaluate a string, use Py_RunString with Py_eval_input,
> or perhaps Py_single_input.

Py_eval_input is for "isolated expressions", and
Py_single_input "for a single statement", so how do I
execute whole modules except by using Py_file_input, the
only remaining option?

I actually tested all the above options thoroughly and found
that only Py_file_input did the job, but without a way to
get at the result.

Please let me know whether there is something that I missed,
as I am stuck at the moment. If needed, I will be happy to
send you sample code that illustrates the problem.

Thank you very much for your prompt response.

Jean-Luc

PS: passing "def f(): pass\n" to Py_eval_input returns a
"SyntaxError: invalid syntax"


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

Comment By: Martin v. Löwis
Date: 2001-03-04 10:22

Message:
Logged In: YES 
user_id=21627

Sure there is. PyRun_SimpleString executes a string in "file
mode"; this has no result. The interactive interpreter, when
it prints a result, runs the string in "eval mode" - only
evaluation gives a result.

To evaluate a string, use Py_RunString with Py_eval_input,
or perhaps Py_single_input.

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

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


From nobody@sourceforge.net  Mon Mar  5 20:31:39 2001
From: nobody@sourceforge.net (nobody)
Date: Mon, 05 Mar 2001 12:31:39 -0800
Subject: [Python-bugs-list] [ python-Bugs-405939 ] HTTPConnection Host hdr wrong w/ proxy
Message-ID: <E14a1dr-0001aW-00@usw-sf-web3.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Ernie Sasaki
Assigned to: Nobody/Anonymous
Summary: HTTPConnection Host hdr wrong w/ proxy

Initial Comment:
The HTTPConnection class' putrequest() method is 
incorrect if self._http_vsn == 11 and a proxy is in 
use.

Currently the following is done in httplib.py revision 
1.33:

if self.port == HTTP_PORT:
    self.putheader('Host', self.host)
else:
    self.putheader('Host', "%s:%s" % (self.host, 
self.port))

However if a proxy is in use, self.host is the proxy 
address, and url contains the "realhost" which should 
be in the Host header. (urllib does the right thing 
here but it uses the HTTP class and not 
HTTPConnection. It doesn't see this problem because 
then HTTP/1.0 is used and no Host header is sent 
automatically.)

Instead the following is correct:

match = httpRE.search(url)
if match:
    self.putheader('Host', match.group(1))
else:
    if self.port == HTTP_PORT:
        self.putheader('Host', self.host)
    else:
	self.putheader('Host', "%s:%s" % (self.host, 
self.port))

where:

httpRE = re.compile(r'(?i)http://([^/]+)')


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

Comment By: Ernie Sasaki
Date: 2001-03-05 12:31

Message:
Logged In: YES 
user_id=139439

Well, my not very good answers are (notwithstanding your 
quote):

1). This is what Netscape 4.7 does.

2). This is what urllib's open_http does.

3). I rather you didn't send a Host header at all rather 
than a wrong one.  It just makes no sense to me to give the 
origin server a Host header that relates to the proxy's 
address. How would the virtual host mechanism (mentioned in 
the section you quote) ever work thru a proxy then?? You 
need the concept of a host different from what is specified 
in the Request-URI.

4). I speculate (with only secondhand evidence) that a 
proxy can change the absoluteURI to an absolute path when 
passing it on to the origin server. In that case, the Host 
header would indeed determine the host.

As far as the patch being incomplete: In no part of httplib 
does any special handling of an embedded user/password 
appear. It is assumed that you'll take care of sending the 
Authorization header yourself.

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

Comment By: Martin v. Löwis
Date: 2001-03-05 00:39

Message:
Logged In: YES 
user_id=21627

Why is that a bug? RFC 2616, section 5.2, states

# If Request-URI is an absoluteURI, the host is part of the 
# Request-URI. Any Host header field value in the request 
# MUST be ignored.

So in the presence of an absolute URI, the Host: field does
not matter. It is certainly nicer to fill in the right Host:
field, but I'd like to understand the problem before
applying a fix. Your patch is incomplete, IMO: it does not
deal with the user/password part in the URL.

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

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


From nobody@sourceforge.net  Mon Mar  5 23:44:53 2001
From: nobody@sourceforge.net (nobody)
Date: Mon, 05 Mar 2001 15:44:53 -0800
Subject: [Python-bugs-list] [ python-Bugs-405939 ] HTTPConnection Host hdr wrong w/ proxy
Message-ID: <E14a4er-000381-00@usw-sf-web3.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Ernie Sasaki
Assigned to: Nobody/Anonymous
Summary: HTTPConnection Host hdr wrong w/ proxy

Initial Comment:
The HTTPConnection class' putrequest() method is 
incorrect if self._http_vsn == 11 and a proxy is in 
use.

Currently the following is done in httplib.py revision 
1.33:

if self.port == HTTP_PORT:
    self.putheader('Host', self.host)
else:
    self.putheader('Host', "%s:%s" % (self.host, 
self.port))

However if a proxy is in use, self.host is the proxy 
address, and url contains the "realhost" which should 
be in the Host header. (urllib does the right thing 
here but it uses the HTTP class and not 
HTTPConnection. It doesn't see this problem because 
then HTTP/1.0 is used and no Host header is sent 
automatically.)

Instead the following is correct:

match = httpRE.search(url)
if match:
    self.putheader('Host', match.group(1))
else:
    if self.port == HTTP_PORT:
        self.putheader('Host', self.host)
    else:
	self.putheader('Host', "%s:%s" % (self.host, 
self.port))

where:

httpRE = re.compile(r'(?i)http://([^/]+)')


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

Comment By: Martin v. Löwis
Date: 2001-03-05 15:44

Message:
Logged In: YES 
user_id=21627

1 and 2 are probably good reasons why httplib should follow.
3 is no option, since RFC 2616 states that a client MUST
send a Host header in a 1.1 request, even though a server
MUST ignore it if an absolute URI is present; otherwise I'd
agree that it would be best not to send any at all.

As for 4, I agree that the proxy can change the Request-URI.
However, to conform to http 1.1, I think it also needs to
update the Host: header accordingly.

I'd like to get some report on actual problems caused by
this bug. If so, what is the specific proxy software being
used, etc.

On user/password issue: So far, httplib does not deal with
the request URI at all. The issue is how to process an
absoluteURI that contains a userinfo. It would be clearly
wrong to copy the userinfo into the Host: header, as your
code would do. What is not clear to me is whether RFC 2616
allows userinfo to be present in a Request-URI.

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

Comment By: Ernie Sasaki
Date: 2001-03-05 12:31

Message:
Logged In: YES 
user_id=139439

Well, my not very good answers are (notwithstanding your 
quote):

1). This is what Netscape 4.7 does.

2). This is what urllib's open_http does.

3). I rather you didn't send a Host header at all rather 
than a wrong one.  It just makes no sense to me to give the 
origin server a Host header that relates to the proxy's 
address. How would the virtual host mechanism (mentioned in 
the section you quote) ever work thru a proxy then?? You 
need the concept of a host different from what is specified 
in the Request-URI.

4). I speculate (with only secondhand evidence) that a 
proxy can change the absoluteURI to an absolute path when 
passing it on to the origin server. In that case, the Host 
header would indeed determine the host.

As far as the patch being incomplete: In no part of httplib 
does any special handling of an embedded user/password 
appear. It is assumed that you'll take care of sending the 
Authorization header yourself.

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

Comment By: Martin v. Löwis
Date: 2001-03-05 00:39

Message:
Logged In: YES 
user_id=21627

Why is that a bug? RFC 2616, section 5.2, states

# If Request-URI is an absoluteURI, the host is part of the 
# Request-URI. Any Host header field value in the request 
# MUST be ignored.

So in the presence of an absolute URI, the Host: field does
not matter. It is certainly nicer to fill in the right Host:
field, but I'd like to understand the problem before
applying a fix. Your patch is incomplete, IMO: it does not
deal with the user/password part in the URL.

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

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


From nobody@sourceforge.net  Tue Mar  6 03:32:39 2001
From: nobody@sourceforge.net (nobody)
Date: Mon, 05 Mar 2001 19:32:39 -0800
Subject: [Python-bugs-list] [ python-Bugs-406191 ] Mac OS X installation notes
Message-ID: <E14a8DH-0003R3-00@usw-sf-web1.sourceforge.net>

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

Category: Installation
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Nobody/Anonymous
Summary: Mac OS X installation notes

Initial Comment:
I'm running a very recent Mac OS X build ("4K78"); here is 
what I found necessary in order to get 2.1b1 to build on that 
system.  It might be best to add notes about these things to 
the platform-specific part of the README.

First, though, please correct the spelling in the README
of "Mac OS X" -- the name has *two* spaces in it.  Spelling
it in a way inconsistent with Apple's intent makes it
harder (mac *os *x)  to find out where in the configure/
makefile it's mentioned.

Notes:


 - configure:
  OPT="-g -traditional-cpp"  ./configure --with-suffix=.exe --with-dyld


 - limit stacksize 2m
     (It defaults to a half-meg, and then one of the regular 
expression tests fails.)

 - disable the test_largefile test (I moved its source aside).
     This test should be enabled only on a Unix UFS filesystem.
 
- termios.h tries to define a bunch of things that do not exist 
on Mac OS X.

*** Modules/termios.c   Thu Mar  1 22:50:58 2001
--- ../Python-2.1b1-fixed/Modules/termios.c   Mon Mar  5 
15:43:05 2001
***************
*** 358,364 ****
        {"INLCR", INLCR},
        {"IGNCR", IGNCR},
        {"ICRNL", ICRNL},
!       {"IUCLC", IUCLC},
        {"IXON", IXON},
        {"IXANY", IXANY},
        {"IXOFF", IXOFF},
--- 358,364 ----
        {"INLCR", INLCR},
        {"IGNCR", IGNCR},
        {"ICRNL", ICRNL},
!       /* {"IUCLC", IUCLC}, No such thing on Mac OS X. */
        {"IXON", IXON},
        {"IXANY", IXANY},
        {"IXOFF", IXOFF},
***************
*** 366,405 ****
  
        /* struct termios.c_oflag constants */
        {"OPOST", OPOST},
!       {"OLCUC", OLCUC},
        {"ONLCR", ONLCR},
!       {"OCRNL", OCRNL},
!       {"ONOCR", ONOCR},
!       {"ONLRET", ONLRET},
!       {"OFILL", OFILL},
!       {"OFDEL", OFDEL},
!       {"NLDLY", NLDLY},
!       {"CRDLY", CRDLY},
!       {"TABDLY", TABDLY},
!       {"BSDLY", BSDLY},
!       {"VTDLY", VTDLY},
!       {"FFDLY", FFDLY},
  
        /* struct termios.c_oflag-related values (delay mask) */
!       {"NL0", NL0},
!       {"NL1", NL1},
!       {"CR0", CR0},
!       {"CR1", CR1},
!       {"CR2", CR2},
!       {"CR3", CR3},
!       {"TAB0", TAB0},
!       {"TAB1", TAB1},
!       {"TAB2", TAB2},
!       {"TAB3", TAB3},
  #ifdef XTABS
        {"XTABS", XTABS},
  #endif
!       {"BS0", BS0},
!       {"BS1", BS1},
!       {"VT0", VT0},
!       {"VT1", VT1},
!       {"FF0", FF0},
!       {"FF1", FF1},
  
        /* struct termios.c_cflag constants */
        {"CSIZE", CSIZE},
--- 366,405 ----
  
        /* struct termios.c_oflag constants */
        {"OPOST", OPOST},
!       /* {"OLCUC", OLCUC}, No such thing on Mac OS X. */
        {"ONLCR", ONLCR},
!       /* {"OCRNL", OCRNL}, No such thing on Mac OS X. */
!       /* {"ONOCR", ONOCR}, */
!       /* {"ONLRET", ONLRET}, */
!       /* {"OFILL", OFILL}, */
!       /* {"OFDEL", OFDEL}, */
!       /* {"NLDLY", NLDLY}, */
!       /* {"CRDLY", CRDLY}, */
!       /* {"TABDLY", TABDLY}, */
!       /* {"BSDLY", BSDLY}, */
!       /* {"VTDLY", VTDLY}, */
!       /* {"FFDLY", FFDLY}, */
  
        /* struct termios.c_oflag-related values (delay mask) */
!       /* {"NL0", NL0},
!           {"NL1", NL1},
!           {"CR0", CR0},
!           {"CR1", CR1},
!           {"CR2", CR2},
!           {"CR3", CR3},
!           {"TAB0", TAB0},
!           {"TAB1", TAB1},
!           {"TAB2", TAB2},
!           {"TAB3", TAB3}, */
  #ifdef XTABS
        {"XTABS", XTABS},
  #endif
!       /* {"BS0", BS0},
!          {"BS1", BS1},
!          {"VT0", VT0},
!          {"VT1", VT1},
!          {"FF0", FF0},
!          {"FF1", FF1}, */
  
        /* struct termios.c_cflag constants */
        {"CSIZE", CSIZE},


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

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


From nobody@sourceforge.net  Tue Mar  6 06:51:29 2001
From: nobody@sourceforge.net (nobody)
Date: Mon, 05 Mar 2001 22:51:29 -0800
Subject: [Python-bugs-list] [ python-Bugs-232787 ] 2.1a1 compiler warnings under Solaris 8 with gcc
Message-ID: <E14aBJh-0000M2-00@usw-sf-web2.sourceforge.net>

Bugs #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: Martin v. Löwis
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: Martin v. Löwis
Date: 2001-03-05 22:51

Message:
Logged In: YES 
user_id=21627

I'll analyse this further.

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

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 Mar  6 07:06:02 2001
From: nobody@sourceforge.net (nobody)
Date: Mon, 05 Mar 2001 23:06:02 -0800
Subject: [Python-bugs-list] [ python-Bugs-406191 ] Mac OS X installation notes
Message-ID: <E14aBXm-0006H8-00@usw-sf-web3.sourceforge.net>

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

Category: Installation
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Nobody/Anonymous
Summary: Mac OS X installation notes

Initial Comment:
I'm running a very recent Mac OS X build ("4K78"); here is 
what I found necessary in order to get 2.1b1 to build on that 
system.  It might be best to add notes about these things to 
the platform-specific part of the README.

First, though, please correct the spelling in the README
of "Mac OS X" -- the name has *two* spaces in it.  Spelling
it in a way inconsistent with Apple's intent makes it
harder (mac *os *x)  to find out where in the configure/
makefile it's mentioned.

Notes:


 - configure:
  OPT="-g -traditional-cpp"  ./configure --with-suffix=.exe --with-dyld


 - limit stacksize 2m
     (It defaults to a half-meg, and then one of the regular 
expression tests fails.)

 - disable the test_largefile test (I moved its source aside).
     This test should be enabled only on a Unix UFS filesystem.
 
- termios.h tries to define a bunch of things that do not exist 
on Mac OS X.

*** Modules/termios.c   Thu Mar  1 22:50:58 2001
--- ../Python-2.1b1-fixed/Modules/termios.c   Mon Mar  5 
15:43:05 2001
***************
*** 358,364 ****
        {"INLCR", INLCR},
        {"IGNCR", IGNCR},
        {"ICRNL", ICRNL},
!       {"IUCLC", IUCLC},
        {"IXON", IXON},
        {"IXANY", IXANY},
        {"IXOFF", IXOFF},
--- 358,364 ----
        {"INLCR", INLCR},
        {"IGNCR", IGNCR},
        {"ICRNL", ICRNL},
!       /* {"IUCLC", IUCLC}, No such thing on Mac OS X. */
        {"IXON", IXON},
        {"IXANY", IXANY},
        {"IXOFF", IXOFF},
***************
*** 366,405 ****
  
        /* struct termios.c_oflag constants */
        {"OPOST", OPOST},
!       {"OLCUC", OLCUC},
        {"ONLCR", ONLCR},
!       {"OCRNL", OCRNL},
!       {"ONOCR", ONOCR},
!       {"ONLRET", ONLRET},
!       {"OFILL", OFILL},
!       {"OFDEL", OFDEL},
!       {"NLDLY", NLDLY},
!       {"CRDLY", CRDLY},
!       {"TABDLY", TABDLY},
!       {"BSDLY", BSDLY},
!       {"VTDLY", VTDLY},
!       {"FFDLY", FFDLY},
  
        /* struct termios.c_oflag-related values (delay mask) */
!       {"NL0", NL0},
!       {"NL1", NL1},
!       {"CR0", CR0},
!       {"CR1", CR1},
!       {"CR2", CR2},
!       {"CR3", CR3},
!       {"TAB0", TAB0},
!       {"TAB1", TAB1},
!       {"TAB2", TAB2},
!       {"TAB3", TAB3},
  #ifdef XTABS
        {"XTABS", XTABS},
  #endif
!       {"BS0", BS0},
!       {"BS1", BS1},
!       {"VT0", VT0},
!       {"VT1", VT1},
!       {"FF0", FF0},
!       {"FF1", FF1},
  
        /* struct termios.c_cflag constants */
        {"CSIZE", CSIZE},
--- 366,405 ----
  
        /* struct termios.c_oflag constants */
        {"OPOST", OPOST},
!       /* {"OLCUC", OLCUC}, No such thing on Mac OS X. */
        {"ONLCR", ONLCR},
!       /* {"OCRNL", OCRNL}, No such thing on Mac OS X. */
!       /* {"ONOCR", ONOCR}, */
!       /* {"ONLRET", ONLRET}, */
!       /* {"OFILL", OFILL}, */
!       /* {"OFDEL", OFDEL}, */
!       /* {"NLDLY", NLDLY}, */
!       /* {"CRDLY", CRDLY}, */
!       /* {"TABDLY", TABDLY}, */
!       /* {"BSDLY", BSDLY}, */
!       /* {"VTDLY", VTDLY}, */
!       /* {"FFDLY", FFDLY}, */
  
        /* struct termios.c_oflag-related values (delay mask) */
!       /* {"NL0", NL0},
!           {"NL1", NL1},
!           {"CR0", CR0},
!           {"CR1", CR1},
!           {"CR2", CR2},
!           {"CR3", CR3},
!           {"TAB0", TAB0},
!           {"TAB1", TAB1},
!           {"TAB2", TAB2},
!           {"TAB3", TAB3}, */
  #ifdef XTABS
        {"XTABS", XTABS},
  #endif
!       /* {"BS0", BS0},
!          {"BS1", BS1},
!          {"VT0", VT0},
!          {"VT1", VT1},
!          {"FF0", FF0},
!          {"FF1", FF1}, */
  
        /* struct termios.c_cflag constants */
        {"CSIZE", CSIZE},


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

Comment By: Martin v. Löwis
Date: 2001-03-05 23:06

Message:
Logged In: YES 
user_id=21627

Can you produce a patch that does most of this
automatically? Ideally, such a patch would work so that no
other system is affected. E.g. instead of commenting-out
certain constants, an #ifdef would be more desirable.
Likewise, the compiler options are best put into
configure.in, in a way that they are used on all systems
requiring these settings, and ignored on all other systems.
That,of course, requires that a test is introduced to find
out whether you've got the right kind of system.

In addition, I'd prefer if the number of settings needed is
reduced to the absolute minimum. E.g. why is it *necessary*
to compiler Python with -g on Mac OS X? Also, if --with-dyld
is *mandatory* on Mac OS X, why can you specify it as an
option? On all other systems, not using dynamic loading is
not an option. OTOH, if the LDSHARED case of -nostdlib -r
(which you get when you omit --with-dyld) works fine on your
system, why is it necessary to specify --with-dyld.

In short, instead of giving long instructions how to do it
right, I'd prefer if Python configuration did it right on
its own. If you are unsure how to achieve this effect, I
suggest you ask on the pythonmac list. Please upload any
patch you come up with into the patch manager, adding a
comment here that a patch is available.

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

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


From nobody@sourceforge.net  Tue Mar  6 11:24:11 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 03:24:11 -0800
Subject: [Python-bugs-list] [ python-Bugs-225217 ] urllib2.py and proxies (Python 2.0)
Message-ID: <E14aFZb-0008KH-00@usw-sf-web1.sourceforge.net>

Bugs #225217, was updated on 2000-12-09 22:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=225217&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: The Written Word (china)
Assigned to: Jeremy Hylton
Summary: urllib2.py and proxies (Python 2.0)

Initial Comment:
Consider the following program:

  import os, sys, urllib2
  from urllib2 import urlopen
        
  os.environ['http_proxy'] = 'http://[HOST]:5865'
   
  authinfo = urllib2.HTTPBasicAuthHandler ()
  authinfo.add_password ('[REALM]', 'http://[URL]', '[login]', 
  '[password]')
        
  opener = urllib2.build_opener (authinfo)
  urllib2.install_opener (opener)

  url = urlopen ('http://[URL]/')
  print url.info ()
  url.close ()

Urllib2.py does not work if we wish to do BASIC authentication to a URL through a proxy. Chances are it also will not work if the proxy requires BASIC authentication too and the URL requires BASIC authentication. Here's the error I receive (Solaris 7/SPARC but platform does not matter):

    File "/tmp/a.py", line 15, in ?                          
      url = urlopen ('http://updates.thewrittenword.com/')
    File "/opt/TWWfsw/pkgutils12/lib/python20/lib/python2.0/urllib2.py",
  line 137, in urlopen
      return _opener.open(url, data)
    File "/opt/TWWfsw/pkgutils12/lib/python20/lib/python2.0/urllib2.py",
  line 325, in open
      '_open', req)
    File "/opt/TWWfsw/pkgutils12/lib/python20/lib/python2.0/urllib2.py",
  line 304, in _call_chain
      result = func(*args)
    File "/opt/TWWfsw/pkgutils12/lib/python20/lib/python2.0/urllib2.py",
  line 764, in http_open
      return self.parent.error('http', req, fp, code, msg, hdrs)
    File "/opt/TWWfsw/pkgutils12/lib/python20/lib/python2.0/urllib2.py",
  line 351, in error
      return self._call_chain(*args)
    File "/opt/TWWfsw/pkgutils12/lib/python20/lib/python2.0/urllib2.py",
  line 304, in _call_chain
      result = func(*args)
    File "/opt/TWWfsw/pkgutils12/lib/python20/lib/python2.0/urllib2.py",
  line 430, in http_error_default
      raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
  urllib2.HTTPError: HTTP Error 401: Authorization Required


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

Comment By: Nobody/Anonymous
Date: 2001-03-06 03:24

Message:
Logged In: NO 

alike for $ftp_proxy:
  File "/usr/local/lib/python2.0/urllib.py", line 61, in
urlopen
    return _urlopener.open(url)
  File "/usr/local/lib/python2.0/urllib.py", line 166, in
open
    return getattr(self, name)(url)
  File "/usr/local/lib/python2.0/urllib.py", line 416, in
open_ftp
    host, path = splithost(url)
  File "/usr/local/lib/python2.0/urllib.py", line 885, in
splithost
    match = _hostprog.match(url)
TypeError: expected string or buffer


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

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


From nobody@sourceforge.net  Tue Mar  6 12:19:01 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 04:19:01 -0800
Subject: [Python-bugs-list] [ python-Bugs-232787 ] 2.1a1 compiler warnings under Solaris 8 with gcc
Message-ID: <E14aGQf-0002hY-00@usw-sf-web2.sourceforge.net>

Bugs #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: Closed
Priority: 5
Submitted By: Mark Favas
Assigned to: Martin v. Löwis
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: Martin v. Löwis
Date: 2001-03-06 04:19

Message:
Logged In: YES 
user_id=21627

Fixed most of these problems, in the following file
revisions: acconfig.h 1.45, config.h.in 2.89, configure.in
1.210, timemodule.c 2.108, intobject.c 2.56, errors.c 2.62,
floatobject 2.80

The SIG_* problems remain and are document in signalmodule.c
2.58. 
For fpectl, sunmath.h needs to be included, but it is
difficult to find its location (unless compilation uses
SunPRO). No attempt was made to deal with the curses
warnings, since different warnings are produced when ncurses
is installed.

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

Comment By: Martin v. Löwis
Date: 2001-03-05 22:51

Message:
Logged In: YES 
user_id=21627

I'll analyse this further.

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

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 Mar  6 13:06:25 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 05:06:25 -0800
Subject: [Python-bugs-list] [ python-Bugs-406280 ] Python 2.1b1 - pydoc shows nothing
Message-ID: <E14aHAX-0000xU-00@usw-sf-web1.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Python 2.1b1 - pydoc shows nothing

Initial Comment:
Platform: Windows 2000, Python 2.1b1

The pydoc script works fine in "serve documents to a 
browser" mode (python pydoc). Also, running it as a 
command line application, as "python pydoc pydoc", 
works fine when the environment variable PAGER is 
unset.

However, when I have PAGER=less, I get no output at 
all.

It looks like a bug in pydoc.pipepager(), which is the 
result of a bug in os.popen(). I can work around the 
bug by using pydoc.tempfilepager() in place of 
pydoc.pipepager(), but I don't know what the 
underlying popen() bug is.

To demonstrate the os.popen() bug, see the attached 
interactive session:

C:\Data>python21
Python 2.1b1 (#11, Mar  2 2001, 11:23:29) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
>>> import os
>>> a = os.popen("more", "w")
>>> a.write("Hello")
>>> a.close()

Run this, and note that the "More" program never 
starts...

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

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


From nobody@sourceforge.net  Tue Mar  6 13:46:03 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 05:46:03 -0800
Subject: [Python-bugs-list] [ python-Bugs-406292 ] Typo in os.py
Message-ID: <E14aHmt-0003Os-00@usw-sf-web2.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 13:45:38 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 05:45:38 -0800
Subject: [Python-bugs-list] [ python-Bugs-406293 ] Typo in os.py
Message-ID: <E14aHmU-0001Rr-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 13:45:43 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 05:45:43 -0800
Subject: [Python-bugs-list] [ python-Bugs-406294 ] Typo in os.py
Message-ID: <E14aHmZ-0001Rz-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 13:46:18 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 05:46:18 -0800
Subject: [Python-bugs-list] [ python-Bugs-406295 ] Typo in os.py
Message-ID: <E14aHn8-0003PC-00@usw-sf-web2.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 13:45:52 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 05:45:52 -0800
Subject: [Python-bugs-list] [ python-Bugs-406296 ] Typo in os.py
Message-ID: <E14aHmi-0001S8-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 13:46:26 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 05:46:26 -0800
Subject: [Python-bugs-list] [ python-Bugs-406297 ] Typo in os.py
Message-ID: <E14aHnG-0003PK-00@usw-sf-web2.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 13:46:16 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 05:46:16 -0800
Subject: [Python-bugs-list] [ python-Bugs-406298 ] Typo in os.py
Message-ID: <E14aHn6-0000lW-00@usw-sf-web3.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 13:46:07 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 05:46:07 -0800
Subject: [Python-bugs-list] [ python-Bugs-406299 ] Typo in os.py
Message-ID: <E14aHmx-0001SM-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 13:46:18 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 05:46:18 -0800
Subject: [Python-bugs-list] [ python-Bugs-406300 ] Typo in os.py
Message-ID: <E14aHn8-0001Se-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 13:46:57 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 05:46:57 -0800
Subject: [Python-bugs-list] [ python-Bugs-406301 ] Typo in os.py
Message-ID: <E14aHnl-0003Pr-00@usw-sf-web2.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 13:46:50 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 05:46:50 -0800
Subject: [Python-bugs-list] [ python-Bugs-406302 ] Typo in os.py
Message-ID: <E14aHne-0000lq-00@usw-sf-web3.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 13:48:35 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 05:48:35 -0800
Subject: [Python-bugs-list] [ python-Bugs-406304 ] Typo in os.py
Message-ID: <E14aHpL-0003Qe-00@usw-sf-web2.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 13:48:14 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 05:48:14 -0800
Subject: [Python-bugs-list] [ python-Bugs-406305 ] Typo in os.py
Message-ID: <E14aHp0-0001Tg-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 13:48:22 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 05:48:22 -0800
Subject: [Python-bugs-list] [ python-Bugs-406306 ] Typo in os.py
Message-ID: <E14aHp8-0001Tw-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 13:48:28 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 05:48:28 -0800
Subject: [Python-bugs-list] [ python-Bugs-406307 ] Typo in os.py
Message-ID: <E14aHpE-0001U4-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 13:48:33 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 05:48:33 -0800
Subject: [Python-bugs-list] [ python-Bugs-406308 ] Typo in os.py
Message-ID: <E14aHpJ-0001UE-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 13:48:54 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 05:48:54 -0800
Subject: [Python-bugs-list] [ python-Bugs-406309 ] Typo in os.py
Message-ID: <E14aHpe-0000mg-00@usw-sf-web3.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 13:49:00 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 05:49:00 -0800
Subject: [Python-bugs-list] [ python-Bugs-406310 ] Typo in os.py
Message-ID: <E14aHpk-0000mv-00@usw-sf-web3.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 13:49:21 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 05:49:21 -0800
Subject: [Python-bugs-list] [ python-Bugs-406311 ] Typo in os.py
Message-ID: <E14aHq5-0003RE-00@usw-sf-web2.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 13:48:56 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 05:48:56 -0800
Subject: [Python-bugs-list] [ python-Bugs-406312 ] Typo in os.py
Message-ID: <E14aHpg-0001UW-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 13:49:16 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 05:49:16 -0800
Subject: [Python-bugs-list] [ python-Bugs-406313 ] Typo in os.py
Message-ID: <E14aHq0-0000nB-00@usw-sf-web3.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 13:49:34 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 05:49:34 -0800
Subject: [Python-bugs-list] [ python-Bugs-406314 ] Typo in os.py
Message-ID: <E14aHqI-0003Rf-00@usw-sf-web2.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 13:56:08 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 05:56:08 -0800
Subject: [Python-bugs-list] [ python-Bugs-406318 ] Typo in os.py
Message-ID: <E14aHwe-0000qG-00@usw-sf-web3.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 13:56:01 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 05:56:01 -0800
Subject: [Python-bugs-list] [ python-Bugs-406319 ] Typo in os.py
Message-ID: <E14aHwX-0001ZV-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 13:56:25 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 05:56:25 -0800
Subject: [Python-bugs-list] [ python-Bugs-406320 ] Typo in os.py
Message-ID: <E14aHwv-0000qe-00@usw-sf-web3.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 13:56:48 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 05:56:48 -0800
Subject: [Python-bugs-list] [ python-Bugs-406321 ] Typo in os.py
Message-ID: <E14aHxI-0003Uw-00@usw-sf-web2.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 13:56:28 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 05:56:28 -0800
Subject: [Python-bugs-list] [ python-Bugs-406322 ] Typo in os.py
Message-ID: <E14aHwy-0001Zl-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 13:57:05 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 05:57:05 -0800
Subject: [Python-bugs-list] [ python-Bugs-406323 ] Typo in os.py
Message-ID: <E14aHxZ-0003VD-00@usw-sf-web2.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 13:57:11 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 05:57:11 -0800
Subject: [Python-bugs-list] [ python-Bugs-406324 ] Typo in os.py
Message-ID: <E14aHxf-0003VS-00@usw-sf-web2.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 13:57:03 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 05:57:03 -0800
Subject: [Python-bugs-list] [ python-Bugs-406325 ] Typo in os.py
Message-ID: <E14aHxX-0000qr-00@usw-sf-web3.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 13:57:12 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 05:57:12 -0800
Subject: [Python-bugs-list] [ python-Bugs-406326 ] Typo in os.py
Message-ID: <E14aHxg-0000r6-00@usw-sf-web3.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 13:57:20 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 05:57:20 -0800
Subject: [Python-bugs-list] [ python-Bugs-406327 ] Typo in os.py
Message-ID: <E14aHxo-0000rH-00@usw-sf-web3.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 13:57:43 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 05:57:43 -0800
Subject: [Python-bugs-list] [ python-Bugs-406328 ] Typo in os.py
Message-ID: <E14aHyB-0003Vl-00@usw-sf-web2.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 15:29:48 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 07:29:48 -0800
Subject: [Python-bugs-list] [ python-Bugs-406296 ] Typo in os.py
Message-ID: <E14aJPI-0002gl-00@usw-sf-web1.sourceforge.net>

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

Category: Python Library
Group: None
Status: Closed
Priority: 5
Submitted By: Paul Moore
Assigned to: Skip Montanaro
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

Comment By: Skip Montanaro
Date: 2001-03-06 07:29

Message:
Logged In: YES 
user_id=44345

thanks - fixed


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

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


From nobody@sourceforge.net  Tue Mar  6 18:49:00 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:49:00 -0800
Subject: [Python-bugs-list] [ python-Bugs-406302 ] Typo in os.py
Message-ID: <E14aMW4-0005BC-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:49:01 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:49:01 -0800
Subject: [Python-bugs-list] [ python-Bugs-406305 ] Typo in os.py
Message-ID: <E14aMW5-0005BZ-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:49:02 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:49:02 -0800
Subject: [Python-bugs-list] [ python-Bugs-406307 ] Typo in os.py
Message-ID: <E14aMW6-0005Bu-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:49:03 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:49:03 -0800
Subject: [Python-bugs-list] [ python-Bugs-406308 ] Typo in os.py
Message-ID: <E14aMW7-0005C2-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:49:01 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:49:01 -0800
Subject: [Python-bugs-list] [ python-Bugs-406304 ] Typo in os.py
Message-ID: <E14aMW5-0005BR-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:49:06 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:49:06 -0800
Subject: [Python-bugs-list] [ python-Bugs-406311 ] Typo in os.py
Message-ID: <E14aMWA-0005CQ-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:49:02 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:49:02 -0800
Subject: [Python-bugs-list] [ python-Bugs-406306 ] Typo in os.py
Message-ID: <E14aMW6-0005Bm-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:49:10 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:49:10 -0800
Subject: [Python-bugs-list] [ python-Bugs-406319 ] Typo in os.py
Message-ID: <E14aMWE-0005D4-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:49:11 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:49:11 -0800
Subject: [Python-bugs-list] [ python-Bugs-406321 ] Typo in os.py
Message-ID: <E14aMWF-0005DO-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:49:10 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:49:10 -0800
Subject: [Python-bugs-list] [ python-Bugs-406320 ] Typo in os.py
Message-ID: <E14aMWE-0005DC-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:49:09 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:49:09 -0800
Subject: [Python-bugs-list] [ python-Bugs-406314 ] Typo in os.py
Message-ID: <E14aMWD-0005Co-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:49:04 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:49:04 -0800
Subject: [Python-bugs-list] [ python-Bugs-406309 ] Typo in os.py
Message-ID: <E14aMW8-0005CA-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:49:05 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:49:05 -0800
Subject: [Python-bugs-list] [ python-Bugs-406310 ] Typo in os.py
Message-ID: <E14aMW9-0005CI-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:49:15 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:49:15 -0800
Subject: [Python-bugs-list] [ python-Bugs-406327 ] Typo in os.py
Message-ID: <E14aMWJ-0005EA-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:49:15 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:49:15 -0800
Subject: [Python-bugs-list] [ python-Bugs-406328 ] Typo in os.py
Message-ID: <E14aMWJ-0005EI-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:49:07 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:49:07 -0800
Subject: [Python-bugs-list] [ python-Bugs-406312 ] Typo in os.py
Message-ID: <E14aMWB-0005CY-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:49:14 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:49:14 -0800
Subject: [Python-bugs-list] [ python-Bugs-406326 ] Typo in os.py
Message-ID: <E14aMWI-0005E2-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:49:08 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:49:08 -0800
Subject: [Python-bugs-list] [ python-Bugs-406313 ] Typo in os.py
Message-ID: <E14aMWC-0005Cg-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:49:09 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:49:09 -0800
Subject: [Python-bugs-list] [ python-Bugs-406318 ] Typo in os.py
Message-ID: <E14aMWD-0005Cw-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:49:11 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:49:11 -0800
Subject: [Python-bugs-list] [ python-Bugs-406322 ] Typo in os.py
Message-ID: <E14aMWF-0005DW-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:49:12 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:49:12 -0800
Subject: [Python-bugs-list] [ python-Bugs-406323 ] Typo in os.py
Message-ID: <E14aMWG-0005De-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:49:13 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:49:13 -0800
Subject: [Python-bugs-list] [ python-Bugs-406325 ] Typo in os.py
Message-ID: <E14aMWH-0005Du-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:49:13 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:49:13 -0800
Subject: [Python-bugs-list] [ python-Bugs-406324 ] Typo in os.py
Message-ID: <E14aMWH-0005Dm-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:49:51 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:49:51 -0800
Subject: [Python-bugs-list] [ python-Bugs-406292 ] Typo in os.py
Message-ID: <E14aMWt-0005Ej-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:49:51 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:49:51 -0800
Subject: [Python-bugs-list] [ python-Bugs-406293 ] Typo in os.py
Message-ID: <E14aMWt-0005Er-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:49:52 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:49:52 -0800
Subject: [Python-bugs-list] [ python-Bugs-406294 ] Typo in os.py
Message-ID: <E14aMWu-0005Ez-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:49:53 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:49:53 -0800
Subject: [Python-bugs-list] [ python-Bugs-406298 ] Typo in os.py
Message-ID: <E14aMWv-0005FF-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:49:54 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:49:54 -0800
Subject: [Python-bugs-list] [ python-Bugs-406299 ] Typo in os.py
Message-ID: <E14aMWw-0005FN-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:49:53 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:49:53 -0800
Subject: [Python-bugs-list] [ python-Bugs-406297 ] Typo in os.py
Message-ID: <E14aMWv-0005F7-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:49:55 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:49:55 -0800
Subject: [Python-bugs-list] [ python-Bugs-406300 ] Typo in os.py
Message-ID: <E14aMWx-0005FV-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:49:56 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:49:56 -0800
Subject: [Python-bugs-list] [ python-Bugs-406301 ] Typo in os.py
Message-ID: <E14aMWy-0005Fd-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:50:26 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:50:26 -0800
Subject: [Python-bugs-list] [ python-Bugs-406295 ] Typo in os.py
Message-ID: <E14aMXS-0005Ga-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:51:08 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:51:08 -0800
Subject: [Python-bugs-list] [ python-Bugs-406292 ] Typo in os.py
Message-ID: <E14aMY8-0005H9-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Closed
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:51:50 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:51:50 -0800
Subject: [Python-bugs-list] [ python-Bugs-406293 ] Typo in os.py
Message-ID: <E14aMYo-0005HY-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Closed
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:51:51 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:51:51 -0800
Subject: [Python-bugs-list] [ python-Bugs-406295 ] Typo in os.py
Message-ID: <E14aMYp-0005Ho-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Closed
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:51:52 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:51:52 -0800
Subject: [Python-bugs-list] [ python-Bugs-406297 ] Typo in os.py
Message-ID: <E14aMYq-0005Hw-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Closed
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:51:54 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:51:54 -0800
Subject: [Python-bugs-list] [ python-Bugs-406299 ] Typo in os.py
Message-ID: <E14aMYs-0005IC-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Closed
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:51:50 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:51:50 -0800
Subject: [Python-bugs-list] [ python-Bugs-406294 ] Typo in os.py
Message-ID: <E14aMYo-0005Hg-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Closed
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:51:53 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:51:53 -0800
Subject: [Python-bugs-list] [ python-Bugs-406298 ] Typo in os.py
Message-ID: <E14aMYr-0005I4-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Closed
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:51:56 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:51:56 -0800
Subject: [Python-bugs-list] [ python-Bugs-406302 ] Typo in os.py
Message-ID: <E14aMYu-0005Ia-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Closed
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:51:56 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:51:56 -0800
Subject: [Python-bugs-list] [ python-Bugs-406301 ] Typo in os.py
Message-ID: <E14aMYu-0005IS-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Closed
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:51:55 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:51:55 -0800
Subject: [Python-bugs-list] [ python-Bugs-406300 ] Typo in os.py
Message-ID: <E14aMYt-0005IK-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Closed
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:53:03 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:53:03 -0800
Subject: [Python-bugs-list] [ python-Bugs-406318 ] Typo in os.py
Message-ID: <E14aMZz-0005L0-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Closed
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:52:33 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:52:33 -0800
Subject: [Python-bugs-list] [ python-Bugs-406312 ] Typo in os.py
Message-ID: <E14aMZV-0005KB-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Closed
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:52:28 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:52:28 -0800
Subject: [Python-bugs-list] [ python-Bugs-406305 ] Typo in os.py
Message-ID: <E14aMZQ-0005JF-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Closed
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:52:34 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:52:34 -0800
Subject: [Python-bugs-list] [ python-Bugs-406314 ] Typo in os.py
Message-ID: <E14aMZW-0005KR-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Closed
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:52:30 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:52:30 -0800
Subject: [Python-bugs-list] [ python-Bugs-406308 ] Typo in os.py
Message-ID: <E14aMZS-0005Jf-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Closed
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:52:34 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:52:34 -0800
Subject: [Python-bugs-list] [ python-Bugs-406313 ] Typo in os.py
Message-ID: <E14aMZW-0005KJ-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Closed
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:52:29 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:52:29 -0800
Subject: [Python-bugs-list] [ python-Bugs-406307 ] Typo in os.py
Message-ID: <E14aMZR-0005JX-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Closed
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:52:28 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:52:28 -0800
Subject: [Python-bugs-list] [ python-Bugs-406306 ] Typo in os.py
Message-ID: <E14aMZQ-0005JN-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Closed
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:52:32 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:52:32 -0800
Subject: [Python-bugs-list] [ python-Bugs-406310 ] Typo in os.py
Message-ID: <E14aMZU-0005Jv-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Closed
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:53:07 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:53:07 -0800
Subject: [Python-bugs-list] [ python-Bugs-406322 ] Typo in os.py
Message-ID: <E14aMa3-0005LW-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Closed
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:53:09 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:53:09 -0800
Subject: [Python-bugs-list] [ python-Bugs-406324 ] Typo in os.py
Message-ID: <E14aMa5-0005Lm-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Closed
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:53:08 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:53:08 -0800
Subject: [Python-bugs-list] [ python-Bugs-406323 ] Typo in os.py
Message-ID: <E14aMa4-0005Le-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Closed
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:53:05 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:53:05 -0800
Subject: [Python-bugs-list] [ python-Bugs-406320 ] Typo in os.py
Message-ID: <E14aMa1-0005LG-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Closed
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:52:32 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:52:32 -0800
Subject: [Python-bugs-list] [ python-Bugs-406311 ] Typo in os.py
Message-ID: <E14aMZU-0005K3-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Closed
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:53:06 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:53:06 -0800
Subject: [Python-bugs-list] [ python-Bugs-406321 ] Typo in os.py
Message-ID: <E14aMa2-0005LO-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Closed
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:53:04 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:53:04 -0800
Subject: [Python-bugs-list] [ python-Bugs-406319 ] Typo in os.py
Message-ID: <E14aMa0-0005L8-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Closed
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:52:31 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:52:31 -0800
Subject: [Python-bugs-list] [ python-Bugs-406309 ] Typo in os.py
Message-ID: <E14aMZT-0005Jn-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Closed
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:53:09 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:53:09 -0800
Subject: [Python-bugs-list] [ python-Bugs-406325 ] Typo in os.py
Message-ID: <E14aMa5-0005Lu-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Closed
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:53:10 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:53:10 -0800
Subject: [Python-bugs-list] [ python-Bugs-406327 ] Typo in os.py
Message-ID: <E14aMa6-0005M2-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Closed
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:53:41 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:53:41 -0800
Subject: [Python-bugs-list] [ python-Bugs-406326 ] Typo in os.py
Message-ID: <E14aMab-0005MM-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Closed
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:53:41 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:53:41 -0800
Subject: [Python-bugs-list] [ python-Bugs-406328 ] Typo in os.py
Message-ID: <E14aMab-0005MU-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Closed
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@sourceforge.net  Tue Mar  6 18:51:58 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 10:51:58 -0800
Subject: [Python-bugs-list] [ python-Bugs-406304 ] Typo in os.py
Message-ID: <E14aMYw-0005Ii-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Closed
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Typo in os.py

Initial Comment:
There's a typo in the RISCOS part of os.py, line 167. 
The section imports riscos, then extends __all__, and 
then does "del ce". Presumably, this is a cut&paste 
error, and should be "del riscos".

I don't use RISC OS, so I'm afraid I can't check this.

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

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


From nobody@usw-sf-web2.sourceforge.net  Tue Mar  6 21:19:22 2001
From: nobody@usw-sf-web2.sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 13:19:22 -0800
Subject: [Python-bugs-list] [ python-Bugs-406459 ] nested scopes opcodes not documented
Message-ID: <E14aOra-0007RA-00@usw-sf-web2.sourceforge.net>

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

Category: Documentation
Group: None
Status: Open
Priority: 5
Submitted By: Michael Hudson
Assigned to: Fred L. Drake, Jr.
Summary: nested scopes opcodes not documented

Initial Comment:
As in summary, the description of the opcodes added to
support nested scopes are not documented - and I want
to know how they work!

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

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


From nobody@usw-sf-web2.sourceforge.net  Wed Mar  7 01:24:14 2001
From: nobody@usw-sf-web2.sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 17:24:14 -0800
Subject: [Python-bugs-list] [ python-Bugs-232787 ] 2.1a1 compiler warnings under Solaris 8 with gcc
Message-ID: <E14aSgY-0000yj-00@usw-sf-web2.sourceforge.net>

Bugs #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: Closed
Priority: 5
Submitted By: Mark Favas
Assigned to: Martin v. Löwis
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: Mark Favas
Date: 2001-03-06 17:24

Message:
Logged In: YES 
user_id=44979

With regard to the fpectlmodule issue, would not the
following work (does for me - and if somehow sunmath.h has
been included, _SUNMATH_H is set):
*** fpectlmodule.c.orig Wed Mar  7 09:21:09 2001
--- fpectlmodule.c      Wed Mar  7 09:21:20 2001
***************
*** 140,145 ****
--- 140,150 ----
         ld -G -o fpectlmodule.so -L/opt/SUNWspro/lib
fpectlmodule.o -lsunmath -lm
       */
  #include <math.h>
+ #ifndef _SUNMATH_H
+     extern void nonstandard_arithmetic(void);
+     extern int ieee_flags(const char*, const char*, const
char*, char **);
+     extern long ieee_handler(const char*, const char*,
sigfpe_handler_type);
+ #endif
      char *mode="exception", *in="all", *out;
      (void) nonstandard_arithmetic();
      (void) ieee_flags("clearall",mode,in,&out);


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

Comment By: Martin v. Löwis
Date: 2001-03-06 04:19

Message:
Logged In: YES 
user_id=21627

Fixed most of these problems, in the following file
revisions: acconfig.h 1.45, config.h.in 2.89, configure.in
1.210, timemodule.c 2.108, intobject.c 2.56, errors.c 2.62,
floatobject 2.80

The SIG_* problems remain and are document in signalmodule.c
2.58. 
For fpectl, sunmath.h needs to be included, but it is
difficult to find its location (unless compilation uses
SunPRO). No attempt was made to deal with the curses
warnings, since different warnings are produced when ncurses
is installed.

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

Comment By: Martin v. Löwis
Date: 2001-03-05 22:51

Message:
Logged In: YES 
user_id=21627

I'll analyse this further.

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

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@usw-sf-web1.sourceforge.net  Wed Mar  7 03:16:27 2001
From: nobody@usw-sf-web1.sourceforge.net (nobody)
Date: Tue, 06 Mar 2001 19:16:27 -0800
Subject: [Python-bugs-list] [ python-Bugs-406563 ] test_long loops openbsd2.8 i386
Message-ID: <E14aUR9-0002o1-00@usw-sf-web1.sourceforge.net>

Bugs #406563, was updated on 2001-03-06 19:16
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406563&group_id=5470

Category: Build
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Nobody/Anonymous
Summary: test_long loops openbsd2.8 i386

Initial Comment:
processor is a pentium 120.

build of python 2-1b1 on openbsd apparently works fine,
only hitch so far is test_long apparently looping
during make test, compiled using GCC 2.95.3 19991030
(prerelease).
I used the standard issue Openbsd 2.8 download
components.


No problems using python so far. 



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

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


From nobody@usw-sf-web2.sourceforge.net  Wed Mar  7 09:40:55 2001
From: nobody@usw-sf-web2.sourceforge.net (nobody)
Date: Wed, 07 Mar 2001 01:40:55 -0800
Subject: [Python-bugs-list] [ python-Bugs-406642 ] 2.1b1 from socket import* omits errorTab
Message-ID: <E14aaRD-0004jm-00@usw-sf-web2.sourceforge.net>

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

Category: Python Interpreter Core
Group: None
Status: Open
Priority: 5
Submitted By: Ernie Sasaki
Assigned to: Nobody/Anonymous
Summary: 2.1b1 from socket import* omits errorTab

Initial Comment:
Under Win98SE, if you say "from socket import *" at an 
interactive python 2.0 prompt, you can see errorTab in 
what dir() returns. 

With a 2.1b1 interactive prompt, if you do the same 
exact thing no errorTab is in the list. However, if 
instead you say import socket and then dir(socket), 
errorTab appears.

Not sure if this is a bug but it sure sent me on a 
wild goose chase for a while. I don't think this is 
correct Nested Scopes related behavior but I admit I 
haven't fully understood this new feature.

This came up because I've been using the 
timeoutsocket.py module from the Vaults of Parnassus 
for a few weeks. It imports from socket. In a 
different module I (very non-portably), then format an 
nice error message based on the contents of errorTab. 
This code now is broken under 2.1b1.


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

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


From nobody@usw-sf-web1.sourceforge.net  Wed Mar  7 10:25:05 2001
From: nobody@usw-sf-web1.sourceforge.net (nobody)
Date: Wed, 07 Mar 2001 02:25:05 -0800
Subject: [Python-bugs-list] [ python-Bugs-232787 ] 2.1a1 compiler warnings under Solaris 8 with gcc
Message-ID: <E14ab7x-0007Zz-00@usw-sf-web1.sourceforge.net>

Bugs #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: Closed
Priority: 5
Submitted By: Mark Favas
Assigned to: Martin v. Löwis
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: Martin v. Löwis
Date: 2001-03-07 02:25

Message:
Logged In: YES 
user_id=21627

Sounds good; applied to fpectlmodule.c 2.14.

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

Comment By: Mark Favas
Date: 2001-03-06 17:24

Message:
Logged In: YES 
user_id=44979

With regard to the fpectlmodule issue, would not the
following work (does for me - and if somehow sunmath.h has
been included, _SUNMATH_H is set):
*** fpectlmodule.c.orig Wed Mar  7 09:21:09 2001
--- fpectlmodule.c      Wed Mar  7 09:21:20 2001
***************
*** 140,145 ****
--- 140,150 ----
         ld -G -o fpectlmodule.so -L/opt/SUNWspro/lib
fpectlmodule.o -lsunmath -lm
       */
  #include <math.h>
+ #ifndef _SUNMATH_H
+     extern void nonstandard_arithmetic(void);
+     extern int ieee_flags(const char*, const char*, const
char*, char **);
+     extern long ieee_handler(const char*, const char*,
sigfpe_handler_type);
+ #endif
      char *mode="exception", *in="all", *out;
      (void) nonstandard_arithmetic();
      (void) ieee_flags("clearall",mode,in,&out);


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

Comment By: Martin v. Löwis
Date: 2001-03-06 04:19

Message:
Logged In: YES 
user_id=21627

Fixed most of these problems, in the following file
revisions: acconfig.h 1.45, config.h.in 2.89, configure.in
1.210, timemodule.c 2.108, intobject.c 2.56, errors.c 2.62,
floatobject 2.80

The SIG_* problems remain and are document in signalmodule.c
2.58. 
For fpectl, sunmath.h needs to be included, but it is
difficult to find its location (unless compilation uses
SunPRO). No attempt was made to deal with the curses
warnings, since different warnings are produced when ncurses
is installed.

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

Comment By: Martin v. Löwis
Date: 2001-03-05 22:51

Message:
Logged In: YES 
user_id=21627

I'll analyse this further.

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

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@usw-sf-web1.sourceforge.net  Wed Mar  7 12:23:08 2001
From: nobody@usw-sf-web1.sourceforge.net (nobody)
Date: Wed, 07 Mar 2001 04:23:08 -0800
Subject: [Python-bugs-list] [ python-Bugs-406563 ] test_long loops openbsd2.8 i386
Message-ID: <E14acyC-0000Ll-00@usw-sf-web1.sourceforge.net>

Bugs #406563, was updated on 2001-03-06 19:16
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406563&group_id=5470

Category: Build
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Nobody/Anonymous
Summary: test_long loops openbsd2.8 i386

Initial Comment:
processor is a pentium 120.

build of python 2-1b1 on openbsd apparently works fine,
only hitch so far is test_long apparently looping
during make test, compiled using GCC 2.95.3 19991030
(prerelease).
I used the standard issue Openbsd 2.8 download
components.


No problems using python so far. 



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

Comment By: Michael Hudson
Date: 2001-03-07 04:23

Message:
Logged In: YES 
user_id=6656

can you 
(a) log in!
(b) try rebuilding without optimizations (things like
"compiled using GCC 2.95.3 19991030 (prerelease)" don't
really inspire confidence)
(c) gdb it and send a stack trace of where it hangs.

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

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


From nobody@usw-sf-web1.sourceforge.net  Wed Mar  7 13:23:46 2001
From: nobody@usw-sf-web1.sourceforge.net (nobody)
Date: Wed, 07 Mar 2001 05:23:46 -0800
Subject: [Python-bugs-list] [ python-Bugs-406683 ] typos in urllib2 ( cvs )
Message-ID: <E14adus-000145-00@usw-sf-web1.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Bernd S. Brentrup
Assigned to: Nobody/Anonymous
Summary: typos in urllib2 ( cvs )

Initial Comment:
urllib2.ProxyHandler fails due to typos when using proxy 
autthentication, patch included.


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

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


From nobody@usw-sf-web2.sourceforge.net  Wed Mar  7 15:05:05 2001
From: nobody@usw-sf-web2.sourceforge.net (nobody)
Date: Wed, 07 Mar 2001 07:05:05 -0800
Subject: [Python-bugs-list] [ python-Bugs-406705 ] imaplib search() quoting search criteria
Message-ID: <E14afUv-0007Io-00@usw-sf-web2.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Christian Kissner
Assigned to: Nobody/Anonymous
Summary: imaplib search() quoting search criteria

Initial Comment:
Imaplib IMAP4.search() contains a bug in criteria
handling: when
sending a single word criterium it gets written to the
stream well: 
	M.search(None, 'ALL')
produces:
	GINH16 SEARCH
ALL                                         

But a criterium with a white space will be quoted:

	M.search(None,'TEXT Hello')
produces in the tcp stream:
	GINH17 SEARCH "TEXT Hello"

which gets rejected because quotes are only allowed
around
the string, not the criterium:
	GINH17 SEARCH TEXT "Hello"



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

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


From nobody@usw-sf-web3.sourceforge.net  Wed Mar  7 16:42:59 2001
From: nobody@usw-sf-web3.sourceforge.net (nobody)
Date: Wed, 07 Mar 2001 08:42:59 -0800
Subject: [Python-bugs-list] [ python-Bugs-404322 ] Python 2.1a and solaris8/x86
Message-ID: <E14ah1f-0005Gg-00@usw-sf-web3.sourceforge.net>

Bugs #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: Closed
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Martin v. Löwis
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: Nobody/Anonymous
Date: 2001-03-07 08:42

Message:
Logged In: NO 

Success: The problem does no longer occur under solaris8/x86
with Python 2.1b1.

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

Comment By: Martin v. Löwis
Date: 2001-03-02 03:30

Message:
Logged In: YES 
user_id=21627

At least part of the bug has been fixed, by passing -fPIC to
gcc. If the bug persists for x86 in 2.1b1, please re-report
it. Then also indicate whether you are using binutils or the
system linker, and the linker version.

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

Comment By: Neil Schemenauer
Date: 2001-03-01 22:44

Message:
Logged In: YES 
user_id=35752

Looks like the same bug as 405329 (Cannot compile Python
2.1a2 on Solaris).

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

Comment By: david arnold
Date: 2001-02-28 18:37

Message:
Logged In: YES 
user_id=78574

i see the same on SPARC (just to provide a confirmation):

    SunOS ladybug 5.8 Generic_108528-03 sun4u sparc

i think it is basically every module?  (this is a second
pass, so the compilation is already done):

gcc   -o python Modules/python.o \
                libpython2.1.a -lpthread -lsocket -lnsl
-ldl  -lthread   -lm  
./python ./setup.py build
running build
running build_ext
building 'struct' extension
skipping /tmp/Python-2.1a2/Modules/structmodule.c
(build/temp.solaris-2.8-sun4u-2.1/structmodule.o up-to-date)
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
Text relocation remains                         referenced
    against symbol                  offset      in file
<unknown>                           0x11bc     
build/temp.solaris-2.8-sun4u-2.1/structmodule.o
<unknown>                           0x11b8     
build/temp.solaris-2.8-sun4u-2.1/structmodule.o
<unknown>                           0x11f8     
build/temp.solaris-2.8-sun4u-2.1/structmodule.o
<unknown>                           0x1c30     
build/temp.solaris-2.8-sun4u-2.1/structmodule.o
<unknown>                           0x11f4     
build/temp.solaris-2.8-sun4u-2.1/structmodule.o
<unknown>                           0x11e4     
build/temp.solaris-2.8-sun4u-2.1/structmodule.o

etc ...


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

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@usw-sf-web2.sourceforge.net  Wed Mar  7 19:08:05 2001
From: nobody@usw-sf-web2.sourceforge.net (nobody)
Date: Wed, 07 Mar 2001 11:08:05 -0800
Subject: [Python-bugs-list] [ python-Bugs-406792 ] python2.1b1 core dumps --with-pymalloc
Message-ID: <E14ajI5-00015A-00@usw-sf-web2.sourceforge.net>

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

Category: Python Interpreter Core
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Nobody/Anonymous
Summary: python2.1b1 core dumps --with-pymalloc 

Initial Comment:
% ./configure --without-threads --with-pymalloc
% gmake
...

./python setup.py
...
Then it dumps core. Removing the  --with-pymalloc and
it runs just fine.
[281] % uname -a
HP-UX wssgped B.10.20 A 9000/782 2001125167 two-user
license
[282] % gcc --version
2.95.1


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

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


From nobody@usw-sf-web1.sourceforge.net  Wed Mar  7 20:32:04 2001
From: nobody@usw-sf-web1.sourceforge.net (nobody)
Date: Wed, 07 Mar 2001 12:32:04 -0800
Subject: [Python-bugs-list] [ python-Bugs-406815 ] python2.1b re bug (.*)?
Message-ID: <E14akbM-0006SU-00@usw-sf-web1.sourceforge.net>

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

Category: Regular Expressions
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Nobody/Anonymous
Summary: python2.1b re bug (.*)?

Initial Comment:
The script below works per expectation with python1.5.
It fails with python2.1b1

% python2.1 gar 
Traceback (most recent call last):
  File "gar", line 9, in ?
    mob = re.search("== Parameters ==\n(.*)?\s*$",
output, re.S)
  File "/usr/local/lib/python2.1/sre.py", line 55, in
search
    return _compile(pattern, flags).search(string)
  File "/usr/local/lib/python2.1/sre.py", line 131, in
_compile
    raise error, v # invalid expression
sre_constants.error: nothing to repeat

Move "?" inside the parens and it works. Replace the
"*" with a "+" and it works (at least for this example
input).

import re

output = """
Using 
== Parameters ==
line1
line2
"""
mob = re.search("== Parameters ==\n(.*)?\s*$", output,
re.S)
print mob.groups()



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

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


From nobody@usw-sf-web3.sourceforge.net  Wed Mar  7 21:11:20 2001
From: nobody@usw-sf-web3.sourceforge.net (nobody)
Date: Wed, 07 Mar 2001 13:11:20 -0800
Subject: [Python-bugs-list] [ python-Bugs-406824 ] 2.1b1 pythonpath registry error.
Message-ID: <E14alDM-0007YP-00@usw-sf-web3.sourceforge.net>

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

Category: Python Interpreter Core
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Ernie Sasaki
Assigned to: Nobody/Anonymous
Summary: 2.1b1 pythonpath registry error.

Initial Comment:
Using python 2.1b1 under Win98SE, I am unable to set 
pythonpath using the registry (setting the PYTHONPATH 
env var works). 

Stepping thru getpythonregpath() from getpathp.c, the 
registry is searched for 
HKLM\Software\Python\PythonCore\2.1\PythonPath. 
Unfortunately, the windows installer (quite 
understandably) puts things at 
HKLM\Software\Python\PythonCore\2.1b1\PythonPath so 
the registry lookup fails.

It would appear that the string table loaded in 
dl_nt.c is out-of-date but I hesitated to change the 
string loaded into dllVersionBuffer because I wasn't 
sure if there would be other consequences.

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

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


From nobody@usw-sf-web1.sourceforge.net  Thu Mar  8 00:30:22 2001
From: nobody@usw-sf-web1.sourceforge.net (nobody)
Date: Wed, 07 Mar 2001 16:30:22 -0800
Subject: [Python-bugs-list] [ python-Bugs-406867 ] nested list comprehensions crash
Message-ID: <E14aoJy-0000vj-00@usw-sf-web1.sourceforge.net>

Bugs #406867, was updated on 2001-03-07 16:30
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406867&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Nobody/Anonymous
Summary: nested list comprehensions crash

Initial Comment:
Using 2.1b1 on Win98, the following crashes:

[[i for i in [0]] for j in [0]]

with message:

  Runtime error!
  Program: C:\PYTHON20A2\PYTHONW.EXE
  abnormal program termination

2.0 is ok,
2.1a2 crashes too



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

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


From nobody@usw-sf-web1.sourceforge.net  Thu Mar  8 00:49:45 2001
From: nobody@usw-sf-web1.sourceforge.net (nobody)
Date: Wed, 07 Mar 2001 16:49:45 -0800
Subject: [Python-bugs-list] [ python-Bugs-406867 ] nested list comprehensions crash
Message-ID: <E14aocj-00019h-00@usw-sf-web1.sourceforge.net>

Bugs #406867, was updated on 2001-03-07 16:30
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406867&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Nobody/Anonymous
Summary: nested list comprehensions crash

Initial Comment:
Using 2.1b1 on Win98, the following crashes:

[[i for i in [0]] for j in [0]]

with message:

  Runtime error!
  Program: C:\PYTHON20A2\PYTHONW.EXE
  abnormal program termination

2.0 is ok,
2.1a2 crashes too



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

Comment By: Willem Broekema
Date: 2001-03-07 16:49

Message:
Logged In: YES 
user_id=158280

This is a duplicate of #406049.
Sorry to waste your time.

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

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


From nobody@usw-sf-web2.sourceforge.net  Thu Mar  8 01:07:51 2001
From: nobody@usw-sf-web2.sourceforge.net (nobody)
Date: Wed, 07 Mar 2001 17:07:51 -0800
Subject: [Python-bugs-list] [ python-Bugs-406867 ] nested list comprehensions crash
Message-ID: <E14aouF-0003pP-00@usw-sf-web2.sourceforge.net>

Bugs #406867, was updated on 2001-03-07 16:30
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406867&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Nobody/Anonymous
Summary: nested list comprehensions crash

Initial Comment:
Using 2.1b1 on Win98, the following crashes:

[[i for i in [0]] for j in [0]]

with message:

  Runtime error!
  Program: C:\PYTHON20A2\PYTHONW.EXE
  abnormal program termination

2.0 is ok,
2.1a2 crashes too



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

Comment By: Willem Broekema
Date: 2001-03-07 17:07

Message:
Logged In: YES 
user_id=158280

This is a duplicate of #406049.
Sorry to waste your time.

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

Comment By: Willem Broekema
Date: 2001-03-07 16:49

Message:
Logged In: YES 
user_id=158280

This is a duplicate of #406049.
Sorry to waste your time.

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

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


From nobody@usw-sf-web2.sourceforge.net  Thu Mar  8 01:23:07 2001
From: nobody@usw-sf-web2.sourceforge.net (nobody)
Date: Wed, 07 Mar 2001 17:23:07 -0800
Subject: [Python-bugs-list] [ python-Bugs-406867 ] nested list comprehensions crash
Message-ID: <E14ap91-0003wy-00@usw-sf-web2.sourceforge.net>

Bugs #406867, was updated on 2001-03-07 16:30
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406867&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Nobody/Anonymous
Summary: nested list comprehensions crash

Initial Comment:
Using 2.1b1 on Win98, the following crashes:

[[i for i in [0]] for j in [0]]

with message:

  Runtime error!
  Program: C:\PYTHON20A2\PYTHONW.EXE
  abnormal program termination

2.0 is ok,
2.1a2 crashes too



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

Comment By: Willem Broekema
Date: 2001-03-07 17:23

Message:
Logged In: YES 
user_id=158280

This is a duplicate of #406049.
Sorry to waste your time.

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

Comment By: Willem Broekema
Date: 2001-03-07 17:07

Message:
Logged In: YES 
user_id=158280

This is a duplicate of #406049.
Sorry to waste your time.

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

Comment By: Willem Broekema
Date: 2001-03-07 16:49

Message:
Logged In: YES 
user_id=158280

This is a duplicate of #406049.
Sorry to waste your time.

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

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


From nobody@usw-sf-web3.sourceforge.net  Thu Mar  8 02:01:58 2001
From: nobody@usw-sf-web3.sourceforge.net (nobody)
Date: Wed, 07 Mar 2001 18:01:58 -0800
Subject: [Python-bugs-list] [ python-Bugs-406867 ] nested list comprehensions crash
Message-ID: <E14apkc-0001ZC-00@usw-sf-web3.sourceforge.net>

Bugs #406867, was updated on 2001-03-07 16:30
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406867&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Nobody/Anonymous
Summary: nested list comprehensions crash

Initial Comment:
Using 2.1b1 on Win98, the following crashes:

[[i for i in [0]] for j in [0]]

with message:

  Runtime error!
  Program: C:\PYTHON20A2\PYTHONW.EXE
  abnormal program termination

2.0 is ok,
2.1a2 crashes too



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

Comment By: Willem Broekema
Date: 2001-03-07 18:01

Message:
Logged In: YES 
user_id=158280

This is a duplicate of #406049.
Sorry to waste your time.

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

Comment By: Willem Broekema
Date: 2001-03-07 17:23

Message:
Logged In: YES 
user_id=158280

This is a duplicate of #406049.
Sorry to waste your time.

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

Comment By: Willem Broekema
Date: 2001-03-07 17:07

Message:
Logged In: YES 
user_id=158280

This is a duplicate of #406049.
Sorry to waste your time.

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

Comment By: Willem Broekema
Date: 2001-03-07 16:49

Message:
Logged In: YES 
user_id=158280

This is a duplicate of #406049.
Sorry to waste your time.

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

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


From nobody@usw-sf-web3.sourceforge.net  Thu Mar  8 02:07:22 2001
From: nobody@usw-sf-web3.sourceforge.net (nobody)
Date: Wed, 07 Mar 2001 18:07:22 -0800
Subject: [Python-bugs-list] [ python-Bugs-406867 ] nested list comprehensions crash
Message-ID: <E14appq-0001c4-00@usw-sf-web3.sourceforge.net>

Bugs #406867, was updated on 2001-03-07 16:30
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406867&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Nobody/Anonymous
Summary: nested list comprehensions crash

Initial Comment:
Using 2.1b1 on Win98, the following crashes:

[[i for i in [0]] for j in [0]]

with message:

  Runtime error!
  Program: C:\PYTHON20A2\PYTHONW.EXE
  abnormal program termination

2.0 is ok,
2.1a2 crashes too



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

Comment By: Willem Broekema
Date: 2001-03-07 18:07

Message:
Logged In: YES 
user_id=158280

reloading the page by resubmitting the form is no good idea either. i'd better go to bed now and don't mess 
this system any further ;-)

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

Comment By: Willem Broekema
Date: 2001-03-07 18:01

Message:
Logged In: YES 
user_id=158280

This is a duplicate of #406049.
Sorry to waste your time.

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

Comment By: Willem Broekema
Date: 2001-03-07 17:23

Message:
Logged In: YES 
user_id=158280

This is a duplicate of #406049.
Sorry to waste your time.

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

Comment By: Willem Broekema
Date: 2001-03-07 17:07

Message:
Logged In: YES 
user_id=158280

This is a duplicate of #406049.
Sorry to waste your time.

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

Comment By: Willem Broekema
Date: 2001-03-07 16:49

Message:
Logged In: YES 
user_id=158280

This is a duplicate of #406049.
Sorry to waste your time.

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

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


From nobody@usw-sf-web3.sourceforge.net  Thu Mar  8 14:03:00 2001
From: nobody@usw-sf-web3.sourceforge.net (nobody)
Date: Thu, 08 Mar 2001 06:03:00 -0800
Subject: [Python-bugs-list] [ python-Bugs-407019 ] Python-2.1 does not compile under cygwin
Message-ID: <E14b10O-0006YN-00@usw-sf-web3.sourceforge.net>

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

Category: Build
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Nobody/Anonymous
Summary: Python-2.1 does not compile under cygwin

Initial Comment:
configure runs well.

I use:
> g++ --version
2.95.2

Errors are occuring in tokenizer.c. the pointer-variable new seems to be misinterpreted. After 
renaming it to newptr in line 192 ans subsequent lines, tokenizer.c.

The next errors occure in Parser/myreadline.c:

Parser/myreadline.c: In function `char * PyOS_StdioReadline(char *)':
Parser/myreadline.c:62: ANSI C++ forbids implicit conversion from `void *' in as
signment
Parser/myreadline.c:99: ANSI C++ forbids implicit conversion from `void *' in as
signment
Parser/myreadline.c:109: ANSI C++ forbids implicit conversion from `void *' in r
eturn
make: *** [Parser/myreadline.o] Error 1



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

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


From nobody@usw-sf-web2.sourceforge.net  Thu Mar  8 15:58:56 2001
From: nobody@usw-sf-web2.sourceforge.net (nobody)
Date: Thu, 08 Mar 2001 07:58:56 -0800
Subject: [Python-bugs-list] [ python-Bugs-406459 ] nested scopes opcodes not documented
Message-ID: <E14b2oa-0002K1-00@usw-sf-web2.sourceforge.net>

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

Category: Documentation
Group: None
Status: Open
Priority: 5
Submitted By: Michael Hudson
Assigned to: Jeremy Hylton
Summary: nested scopes opcodes not documented

Initial Comment:
As in summary, the description of the opcodes added to
support nested scopes are not documented - and I want
to know how they work!

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

Comment By: Fred L. Drake, Jr.
Date: 2001-03-08 07:58

Message:
Logged In: YES 
user_id=3066

Assigned to Jeremy since he knows what the new opcodes are and how things have changed in this arena.

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

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


From nobody@usw-sf-web1.sourceforge.net  Thu Mar  8 17:59:09 2001
From: nobody@usw-sf-web1.sourceforge.net (nobody)
Date: Thu, 08 Mar 2001 09:59:09 -0800
Subject: [Python-bugs-list] [ python-Bugs-406683 ] typos in urllib2 ( cvs )
Message-ID: <E14b4gv-0004Ny-00@usw-sf-web1.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Bernd S. Brentrup
Assigned to: Nobody/Anonymous
Summary: typos in urllib2 ( cvs )

Initial Comment:
urllib2.ProxyHandler fails due to typos when using proxy 
autthentication, patch included.


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

Comment By: Eduardo Fernandez Corrales
Date: 2001-03-08 09:59

Message:
Logged In: YES 
user_id=169128

I have corrected the patch to reflect proper Basic 
Authentication:

--- /var/local/cvs/python/dist/src/Lib/urllib2.py	Thu 
Mar  1 09:46:07 2001
+++ /usr/local/lib/python2.1/urllib2.py	Thu Mar  8 17:23:31 
2001
@@ -477,8 +477,8 @@
         host, XXX = splithost(r_type)
         if '@' in host:
             user_pass, host = host.split('@', 1)
-            user_pass = base64.encode_string(unquote
(user_passw)).strip()
-            req.addheader('Proxy-Authorization', user_pass)
+            user_pass = "Basic " + base64.encodestring
(unquote(user_pass)).strip()
+            req.add_header('Proxy-Authorization', 
user_pass)
         host = unquote(host)
         req.set_proxy(host, type)
         if orig_type == type:

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

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


From nobody@sourceforge.net  Thu Mar  8 21:55:58 2001
From: nobody@sourceforge.net (nobody)
Date: Thu, 08 Mar 2001 13:55:58 -0800
Subject: [Python-bugs-list] [ python-Bugs-407180 ] proposal: allow years before 1900
Message-ID: <E14b8O6-0001ya-00@usw-sf-web3.sourceforge.net>

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

Category: Python Library
Group: Feature Request
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Nobody/Anonymous
Summary: proposal: allow years before 1900

Initial Comment:
Handling of years before 1900: proposed change for 
python 1.5.2-2.1

from http://www.python.org/doc/current/lib/module-
time.html:

>Values 100-1899 are always
>illegal. Note that this is new as of Python 1.5.2
(a2); earlier
>versions, up to Python 1.5.1 and 1.5.2a1, would add 
1900 to year
>values below 1900.

Wouldn't the correct behaviour be just to store years 
before 1900 into
tm_year as any other year in timemodule.c gettmarg()?  
They get stored
as negative values, but there shouldn't be any 
problems with that,
judging from glibc 2.2 behaviour, documentation for 
other libc's, and
the following quote from 
http://www.platinum.com/products/wp/wp_epmdt.htm:

"While tm_year is based on 1900, the full range of 
positive and
negative values are allowed. For 32-bit integers this 
allows for dates
from 2147481748 BCE to 2147485548 CE. "


Proposed patch for python 1.5.2:

*** timemodule.c.origi  Tue Apr  6 00:54:14 1999
--- timemodule.c        Thu Mar  8 23:32:55 2001
***************
*** 345,355 ****
                        y += 1900;
                else if (0 <= y && y <= 68)
                        y += 2000;
-               else {
-                       PyErr_SetString
(PyExc_ValueError,
-                                       "year out of 
range (00-99, 1900-*)");
-                       return 0;
-               }
        }
        p->tm_year = y - 1900;
        p->tm_mon--;
--- 345,350 ----



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

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


From nobody@sourceforge.net  Fri Mar  9 11:34:33 2001
From: nobody@sourceforge.net (nobody)
Date: Fri, 09 Mar 2001 03:34:33 -0800
Subject: [Python-bugs-list] [ python-Bugs-405831 ] popen3 read fails in blocks
Message-ID: <E14bLAH-0008Ex-00@usw-sf-web1.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Luke Kenneth Casson Leighton
Assigned to: Nobody/Anonymous
Summary: popen3 read fails in blocks

Initial Comment:
bash$ python2
from popen2 import popen3
r,w,e = popen3("bash")
w.write("ls")
w.flush()
print select([r],[],[],0)
[r],[],[]
t = r.read(50)
print t
"file1
file2
"
print select([r],[],[],0)
[],[],[]

r,w,e = popen3("bash")
w.write("ls")
w.close()
t = r.read(50)
print t
"file1
file2
[50 bytes of file listings]
"
t = r.read(50)
print t
"file3
file4
[50 more bytes of file listings]
"

print select([r],[],[],0)
[r],[],[]

what is going on????

when you do a w.flush(), the read file descriptor
can get the first 50 bytes, and then select
will *always* return [],[],[] - EVEN if there's
really more data pending to be read.

it is as if there is double-buffering being
done in os.popen3() which select() is failing
to access.

this is standard-compiled version of python 2.0
on linux mandrake 7.1.  if it makes any difference.

luke

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

Comment By: Luke Kenneth Casson Leighton
Date: 2001-03-09 03:34

Message:
Logged In: YES 
user_id=80200

the following test DOES work as expected, which is good news
because i can use this in my [current] project.  the
work-around is to bypass r.read() and use
os.read(r.fileno(), 50), like so:

import os
from select import select

w,r,e = os.popen3("bash")
w.write("ls -al\n")
w.flush()

while select([r],[],[],1) == ([r],[],[]):
    print os.read(r.fileno(), 50),

this would indicate that there is double-buffering or
similar in the r.read() function.  at a guess, it is
something to do with the way that read has to work in
allowing r.read() as well as r.read(50).  so, select doesn't
work because you've already _read_ all the outstanding data,
and stored it in the r object!

which means that really, the r object must support the
select() method correctly, which at the moment it does not.

with this slightly confused reasoning, without having delved
into the code, i'm sure you can work this out.  i have
enough to go on, now :)

luke

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

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


From nobody@sourceforge.net  Fri Mar  9 13:45:56 2001
From: nobody@sourceforge.net (nobody)
Date: Fri, 09 Mar 2001 05:45:56 -0800
Subject: [Python-bugs-list] [ python-Bugs-407300 ] Win32: pydoc command isn't executable
Message-ID: <E14bNDQ-0000Rt-00@usw-sf-web3.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Win32: pydoc command isn't executable

Initial Comment:
The Python 2.1b1 binary installer for Windows supplies 
a small "pydoc" script in the main Python executable 
directory. However, this script is Unix-specific and 
does not work on Windows.

Suggestion: for Windows, include a trivial pydoc.bat 
file to start pydoc. The following one-liner works:

--- pydoc.bat ---
@python -c "import pydoc; pydoc.cli()" %*
-----------------

The only problem with this version is that it uses the 
version of python.exe found on PATH, rather than the 
version in the directory containing pydoc.bat. 
However, as the Unix script has the same issue, this 
can be viewed as a "feature"...

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

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


From nobody@sourceforge.net  Fri Mar  9 13:46:46 2001
From: nobody@sourceforge.net (nobody)
Date: Fri, 09 Mar 2001 05:46:46 -0800
Subject: [Python-bugs-list] [ python-Bugs-407301 ] Win32: pydoc command isn't executable
Message-ID: <E14bNEE-0001Lw-00@usw-sf-web1.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Win32: pydoc command isn't executable

Initial Comment:
The Python 2.1b1 binary installer for Windows supplies 
a small "pydoc" script in the main Python executable 
directory. However, this script is Unix-specific and 
does not work on Windows.

Suggestion: for Windows, include a trivial pydoc.bat 
file to start pydoc. The following one-liner works:

--- pydoc.bat ---
@python -c "import pydoc; pydoc.cli()" %*
-----------------

The only problem with this version is that it uses the 
version of python.exe found on PATH, rather than the 
version in the directory containing pydoc.bat. 
However, as the Unix script has the same issue, this 
can be viewed as a "feature"...

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

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


From nobody@sourceforge.net  Fri Mar  9 19:43:08 2001
From: nobody@sourceforge.net (nobody)
Date: Fri, 09 Mar 2001 11:43:08 -0800
Subject: [Python-bugs-list] [ python-Bugs-407379 ] SRE objects of no known type
Message-ID: <E14bSn6-0007EZ-00@usw-sf-web2.sourceforge.net>

Bugs #407379, was updated on 2001-03-09 11:43
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407379&group_id=5470

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Joshua Macy
Assigned to: Nobody/Anonymous
Summary: SRE objects of no known type

Initial Comment:
The new SRE re module doesn't seem to create pattern 
types of any type known to types.

Python 2.1b1 (#11, Mar  2 2001, 11:23:29) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
>>> import re
>>> r = re.compile('abc')
>>> type(r)
<type 'SRE_Pattern'>
>>> import types
>>> isinstance(r, types.InstanceType)
0

Python 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit 
(Intel)] on win3
Copyright 1991-1995 Stichting Mathematisch Centrum, 
Amsterdam
>>> import re
>>> r = re.compile('abc')
>>> type(r)
<type 'instance'>
>>> import types
>>> isinstance(r, types.InstanceType)
1



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

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


From nobody@sourceforge.net  Fri Mar  9 20:52:14 2001
From: nobody@sourceforge.net (nobody)
Date: Fri, 09 Mar 2001 12:52:14 -0800
Subject: [Python-bugs-list] [ python-Bugs-407394 ] future nested_scopes * 2 => seg fault
Message-ID: <E14bTry-0006WD-00@usw-sf-web1.sourceforge.net>

Bugs #407394, was updated on 2001-03-09 12:52
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407394&group_id=5470

Category: Parser/Compiler
Group: None
Status: Open
Priority: 5
Submitted By: Samuele Pedroni
Assigned to: Nobody/Anonymous
Summary: future nested_scopes * 2 => seg fault

Initial Comment:
from __future__ import nested_scopes,nested_scopes

causes a seg fault.

>>> from __future__ import nested_scopes,nested_scopes
Segmentation fault



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

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


From nobody@sourceforge.net  Sat Mar 10 01:55:51 2001
From: nobody@sourceforge.net (nobody)
Date: Fri, 09 Mar 2001 17:55:51 -0800
Subject: [Python-bugs-list] [ python-Bugs-407379 ] SRE objects of no known type
Message-ID: <E14bYbn-0001qQ-00@usw-sf-web2.sourceforge.net>

Bugs #407379, was updated on 2001-03-09 11:43
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407379&group_id=5470

Category: Extension Modules
Group: Not a Bug
Status: Closed
Priority: 5
Submitted By: Joshua Macy
Assigned to: Fred L. Drake, Jr.
Summary: SRE objects of no known type

Initial Comment:
The new SRE re module doesn't seem to create pattern 
types of any type known to types.

Python 2.1b1 (#11, Mar  2 2001, 11:23:29) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
>>> import re
>>> r = re.compile('abc')
>>> type(r)
<type 'SRE_Pattern'>
>>> import types
>>> isinstance(r, types.InstanceType)
0

Python 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit 
(Intel)] on win3
Copyright 1991-1995 Stichting Mathematisch Centrum, 
Amsterdam
>>> import re
>>> r = re.compile('abc')
>>> type(r)
<type 'instance'>
>>> import types
>>> isinstance(r, types.InstanceType)
1



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

Comment By: Fred L. Drake, Jr.
Date: 2001-03-09 17:55

Message:
Logged In: YES 
user_id=3066

SRE creates pattern objects that are of an extension type rather than an instance, so there is no entry for them in the types module.

Why do you think this is a bug?  The specific type of these objects should be irrelevant.  I'm classifying this as "Not a bug".

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

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


From nobody@sourceforge.net  Sat Mar 10 02:20:17 2001
From: nobody@sourceforge.net (nobody)
Date: Fri, 09 Mar 2001 18:20:17 -0800
Subject: [Python-bugs-list] [ python-Bugs-407394 ] future nested_scopes * 2 => seg fault
Message-ID: <E14bYzR-0001ek-00@usw-sf-web1.sourceforge.net>

Bugs #407394, was updated on 2001-03-09 12:52
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407394&group_id=5470

Category: Parser/Compiler
Group: None
Status: Closed
Priority: 5
Submitted By: Samuele Pedroni
Assigned to: Fred L. Drake, Jr.
Summary: future nested_scopes * 2 => seg fault

Initial Comment:
from __future__ import nested_scopes,nested_scopes

causes a seg fault.

>>> from __future__ import nested_scopes,nested_scopes
Segmentation fault



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

Comment By: Fred L. Drake, Jr.
Date: 2001-03-09 18:20

Message:
Logged In: YES 
user_id=3066

Fixed in Python/future.c revision 2.5.

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

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


From nobody@sourceforge.net  Sat Mar 10 03:38:33 2001
From: nobody@sourceforge.net (nobody)
Date: Fri, 09 Mar 2001 19:38:33 -0800
Subject: [Python-bugs-list] [ python-Bugs-407379 ] SRE objects of no known type
Message-ID: <E14baDB-00073l-00@usw-sf-web3.sourceforge.net>

Bugs #407379, was updated on 2001-03-09 11:43
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407379&group_id=5470

Category: Extension Modules
Group: Not a Bug
Status: Closed
Priority: 5
Submitted By: Joshua Macy
Assigned to: Fred L. Drake, Jr.
Summary: SRE objects of no known type

Initial Comment:
The new SRE re module doesn't seem to create pattern 
types of any type known to types.

Python 2.1b1 (#11, Mar  2 2001, 11:23:29) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
>>> import re
>>> r = re.compile('abc')
>>> type(r)
<type 'SRE_Pattern'>
>>> import types
>>> isinstance(r, types.InstanceType)
0

Python 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit 
(Intel)] on win3
Copyright 1991-1995 Stichting Mathematisch Centrum, 
Amsterdam
>>> import re
>>> r = re.compile('abc')
>>> type(r)
<type 'instance'>
>>> import types
>>> isinstance(r, types.InstanceType)
1



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

Comment By: Joshua Macy
Date: 2001-03-09 19:38

Message:
Logged In: YES 
user_id=7894

Well, I guess I thought it was a bug because code that used
to work, along the lines of:

if type(obj) == types.InstanceType:

now fails to catch re pattern objects where it caught them
before. Moreover, it turns out to be rather difficult to get
that behavior back; the best I've been able to come up with
so far is:

if str(type(obj)) == "<type 'SRE_Pattern'>":

or creating an re object just so that I can do:

if type(obj) == type(myreobj):

but I'm not sure how robust the first is, while the second
just seems ugly.
If the type of an re or other library object is an
accidental implementation detail subject to change between
releases, so be it; I'll just have to test harder between
releases and maintain more version-specific code.


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

Comment By: Fred L. Drake, Jr.
Date: 2001-03-09 17:55

Message:
Logged In: YES 
user_id=3066

SRE creates pattern objects that are of an extension type rather than an instance, so there is no entry for them in the types module.

Why do you think this is a bug?  The specific type of these objects should be irrelevant.  I'm classifying this as "Not a bug".

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

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


From nobody@sourceforge.net  Sat Mar 10 05:11:05 2001
From: nobody@sourceforge.net (nobody)
Date: Fri, 09 Mar 2001 21:11:05 -0800
Subject: [Python-bugs-list] [ python-Bugs-407379 ] SRE objects of no known type
Message-ID: <E14bbej-00036S-00@usw-sf-web2.sourceforge.net>

Bugs #407379, was updated on 2001-03-09 11:43
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407379&group_id=5470

Category: Extension Modules
Group: Not a Bug
Status: Closed
Priority: 5
Submitted By: Joshua Macy
Assigned to: Fred L. Drake, Jr.
Summary: SRE objects of no known type

Initial Comment:
The new SRE re module doesn't seem to create pattern 
types of any type known to types.

Python 2.1b1 (#11, Mar  2 2001, 11:23:29) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
>>> import re
>>> r = re.compile('abc')
>>> type(r)
<type 'SRE_Pattern'>
>>> import types
>>> isinstance(r, types.InstanceType)
0

Python 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit 
(Intel)] on win3
Copyright 1991-1995 Stichting Mathematisch Centrum, 
Amsterdam
>>> import re
>>> r = re.compile('abc')
>>> type(r)
<type 'instance'>
>>> import types
>>> isinstance(r, types.InstanceType)
1



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

Comment By: Fred L. Drake, Jr.
Date: 2001-03-09 21:11

Message:
Logged In: YES 
user_id=3066

This same test could be written:

pat = re.compile(...)
if type(pat) is types.InstanceType:
    pattern_type = pat.__class__
else:
    pattern_type = type(pat)

...

if isinstance(maybe_a_pattern, pattern_type):
    # looks like a pattern...
else:
    # not a pattern...

But this is a pretty fragile idiom.  Why not just assume it's a pattern, or test for the "search" or "match" attribute?  There's no reason to have suspected that the original code would work to begin with; we deal with interfaces, which are not bound to specific types of classes.

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

Comment By: Joshua Macy
Date: 2001-03-09 19:38

Message:
Logged In: YES 
user_id=7894

Well, I guess I thought it was a bug because code that used
to work, along the lines of:

if type(obj) == types.InstanceType:

now fails to catch re pattern objects where it caught them
before. Moreover, it turns out to be rather difficult to get
that behavior back; the best I've been able to come up with
so far is:

if str(type(obj)) == "<type 'SRE_Pattern'>":

or creating an re object just so that I can do:

if type(obj) == type(myreobj):

but I'm not sure how robust the first is, while the second
just seems ugly.
If the type of an re or other library object is an
accidental implementation detail subject to change between
releases, so be it; I'll just have to test harder between
releases and maintain more version-specific code.


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

Comment By: Fred L. Drake, Jr.
Date: 2001-03-09 17:55

Message:
Logged In: YES 
user_id=3066

SRE creates pattern objects that are of an extension type rather than an instance, so there is no entry for them in the types module.

Why do you think this is a bug?  The specific type of these objects should be irrelevant.  I'm classifying this as "Not a bug".

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

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


From nobody@sourceforge.net  Sat Mar 10 06:52:34 2001
From: nobody@sourceforge.net (nobody)
Date: Fri, 09 Mar 2001 22:52:34 -0800
Subject: [Python-bugs-list] [ python-Bugs-407301 ] Win32: pydoc command isn't executable
Message-ID: <E14bdEw-0004IF-00@usw-sf-web1.sourceforge.net>

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

Category: Python Library
Group: None
Status: Closed
Priority: 5
Submitted By: Paul Moore
Assigned to: Nobody/Anonymous
Summary: Win32: pydoc command isn't executable

Initial Comment:
The Python 2.1b1 binary installer for Windows supplies 
a small "pydoc" script in the main Python executable 
directory. However, this script is Unix-specific and 
does not work on Windows.

Suggestion: for Windows, include a trivial pydoc.bat 
file to start pydoc. The following one-liner works:

--- pydoc.bat ---
@python -c "import pydoc; pydoc.cli()" %*
-----------------

The only problem with this version is that it uses the 
version of python.exe found on PATH, rather than the 
version in the directory containing pydoc.bat. 
However, as the Unix script has the same issue, this 
can be viewed as a "feature"...

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

Comment By: Fred L. Drake, Jr.
Date: 2001-03-09 22:52

Message:
Logged In: YES 
user_id=3066

Duplicate of #407300.

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

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


From nobody@sourceforge.net  Sat Mar 10 07:35:39 2001
From: nobody@sourceforge.net (nobody)
Date: Fri, 09 Mar 2001 23:35:39 -0800
Subject: [Python-bugs-list] [ python-Bugs-407504 ] Bug in pwd.getpwall()
Message-ID: <E14bdud-0008SR-00@usw-sf-web3.sourceforge.net>

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

Category: Extension Modules
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Jürgen Hermann
Assigned to: Nobody/Anonymous
Summary: Bug in pwd.getpwall()

Initial Comment:
If you call getpwall() several times in a running 
process, you do not see changes made to the pwd 
database.

Probable reason: 
pwd_getpwall() in python/dist/src/Modules/pwdmodule.c 
does not call endpwent() before returning, thus 
keeping the file handle open.

Remedy:
call endpwent()

Related:
same problem could exist in grpmodule.c

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

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


From nobody@sourceforge.net  Sat Mar 10 14:28:45 2001
From: nobody@sourceforge.net (nobody)
Date: Sat, 10 Mar 2001 06:28:45 -0800
Subject: [Python-bugs-list] [ python-Bugs-407538 ] pickling fails on strings with newlines
Message-ID: <E14bkMP-0002lA-00@usw-sf-web3.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Will Partain
Assigned to: Nobody/Anonymous
Summary: pickling fails on strings with newlines

Initial Comment:
#! /usr/bin/env python

# duznae work (this is with 2.0 on solaris)

def main():
    # fails with both pickle and cPickle
    import pickle
    test_in = u"""
      Test Input
    , Line 2
    , Line 3
    """
    test_out = pickle.loads(pickle.dumps(test_in))
    print test_out

if __name__ == '__main__': main()


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407538&group_id=5470


From nobody@sourceforge.net  Sat Mar 10 15:27:52 2001
From: nobody@sourceforge.net (nobody)
Date: Sat, 10 Mar 2001 07:27:52 -0800
Subject: [Python-bugs-list] [ python-Bugs-407543 ]  Python 2.1beta1 install fails with --wi
Message-ID: <E14blHc-0007MW-00@usw-sf-web2.sourceforge.net>

Bugs #407543, was updated on 2001-03-10 07:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407543&group_id=5470

Category: Build
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Nobody/Anonymous
Summary:  Python 2.1beta1 install fails with --wi

Initial Comment:
Python 2.1beta1

platform RH6.2

if you configure with --with-cxx
the install fails with


Creating directory
/usr/local/python/lib/python2.1/config
/usr/bin/install -c -m 644 Modules/config.c
/usr/local/python/lib/python2.1/config/config.c
/usr/bin/install -c -m 644 Modules/python.o
/usr/local/python/lib/python2.1/config/python.o
/usr/bin/install: Modules/python.o: No such file or
directory
make: *** [libainstall] Error 1


This is because the makefile target libainstall is
doing :-

        $(INSTALL_DATA) Modules/python.o
$(LIBPL)/python.o

rather than        
       $(INSTALL_DATA) Modules/ccpython.o
$(LIBPL)/ccpython.o


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407543&group_id=5470


From nobody@sourceforge.net  Sat Mar 10 17:48:31 2001
From: nobody@sourceforge.net (nobody)
Date: Sat, 10 Mar 2001 09:48:31 -0800
Subject: [Python-bugs-list] [ python-Bugs-407543 ] Python 2.1beta1 install fails with --wi
Message-ID: <E14bnTj-000053-00@usw-sf-web2.sourceforge.net>

Bugs #407543, was updated on 2001-03-10 07:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407543&group_id=5470

Category: Build
Group: None
Status: Closed
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Fred L. Drake, Jr.
Summary: Python 2.1beta1 install fails with --wi

Initial Comment:
Python 2.1beta1

platform RH6.2

if you configure with --with-cxx
the install fails with


Creating directory
/usr/local/python/lib/python2.1/config
/usr/bin/install -c -m 644 Modules/config.c
/usr/local/python/lib/python2.1/config/config.c
/usr/bin/install -c -m 644 Modules/python.o
/usr/local/python/lib/python2.1/config/python.o
/usr/bin/install: Modules/python.o: No such file or
directory
make: *** [libainstall] Error 1


This is because the makefile target libainstall is
doing :-

        $(INSTALL_DATA) Modules/python.o
$(LIBPL)/python.o

rather than        
       $(INSTALL_DATA) Modules/ccpython.o
$(LIBPL)/ccpython.o


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr.
Date: 2001-03-10 09:48

Message:
Logged In: YES 
user_id=3066

This has already been fixed in CVS; the next release will not have this problem.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407543&group_id=5470


From nobody@sourceforge.net  Sat Mar 10 17:17:06 2001
From: nobody@sourceforge.net (nobody)
Date: Sat, 10 Mar 2001 09:17:06 -0800
Subject: [Python-bugs-list] [ python-Bugs-406683 ] typos in urllib2 ( cvs )
Message-ID: <E14bmzK-0008IA-00@usw-sf-web2.sourceforge.net>

Bugs #406683, was updated on 2001-03-07 05:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406683&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Bernd S. Brentrup
Assigned to: Jeremy Hylton
Summary: typos in urllib2 ( cvs )

Initial Comment:
urllib2.ProxyHandler fails due to typos when using proxy 
autthentication, patch included.


----------------------------------------------------------------------

Comment By: Eduardo Fernandez Corrales
Date: 2001-03-08 09:59

Message:
Logged In: YES 
user_id=169128

I have corrected the patch to reflect proper Basic 
Authentication:

--- /var/local/cvs/python/dist/src/Lib/urllib2.py	Thu 
Mar  1 09:46:07 2001
+++ /usr/local/lib/python2.1/urllib2.py	Thu Mar  8 17:23:31 
2001
@@ -477,8 +477,8 @@
         host, XXX = splithost(r_type)
         if '@' in host:
             user_pass, host = host.split('@', 1)
-            user_pass = base64.encode_string(unquote
(user_passw)).strip()
-            req.addheader('Proxy-Authorization', user_pass)
+            user_pass = "Basic " + base64.encodestring
(unquote(user_pass)).strip()
+            req.add_header('Proxy-Authorization', 
user_pass)
         host = unquote(host)
         req.set_proxy(host, type)
         if orig_type == type:

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406683&group_id=5470


From nobody@sourceforge.net  Sat Mar 10 19:28:01 2001
From: nobody@sourceforge.net (nobody)
Date: Sat, 10 Mar 2001 11:28:01 -0800
Subject: [Python-bugs-list] [ python-Bugs-405831 ] popen3 read fails in blocks
Message-ID: <E14bp21-00051U-00@usw-sf-web3.sourceforge.net>

Bugs #405831, was updated on 2001-03-04 06:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405831&group_id=5470

Category: Python Library
Group: Not a Bug
Status: Closed
Priority: 1
Submitted By: Luke Kenneth Casson Leighton
Assigned to: Guido van Rossum
Summary: popen3 read fails in blocks

Initial Comment:
bash$ python2
from popen2 import popen3
r,w,e = popen3("bash")
w.write("ls")
w.flush()
print select([r],[],[],0)
[r],[],[]
t = r.read(50)
print t
"file1
file2
"
print select([r],[],[],0)
[],[],[]

r,w,e = popen3("bash")
w.write("ls")
w.close()
t = r.read(50)
print t
"file1
file2
[50 bytes of file listings]
"
t = r.read(50)
print t
"file3
file4
[50 more bytes of file listings]
"

print select([r],[],[],0)
[r],[],[]

what is going on????

when you do a w.flush(), the read file descriptor
can get the first 50 bytes, and then select
will *always* return [],[],[] - EVEN if there's
really more data pending to be read.

it is as if there is double-buffering being
done in os.popen3() which select() is failing
to access.

this is standard-compiled version of python 2.0
on linux mandrake 7.1.  if it makes any difference.

luke

----------------------------------------------------------------------

Comment By: Guido van Rossum
Date: 2001-03-10 11:28

Message:
Logged In: YES 
user_id=6380

Not a bug -- you just can't do what you want there.

The data is being buffered in the file object (which is a
wrapper around a stdio file), and this makes it invisible
for select.

----------------------------------------------------------------------

Comment By: Luke Kenneth Casson Leighton
Date: 2001-03-09 03:34

Message:
Logged In: YES 
user_id=80200

the following test DOES work as expected, which is good news
because i can use this in my [current] project.  the
work-around is to bypass r.read() and use
os.read(r.fileno(), 50), like so:

import os
from select import select

w,r,e = os.popen3("bash")
w.write("ls -al\n")
w.flush()

while select([r],[],[],1) == ([r],[],[]):
    print os.read(r.fileno(), 50),

this would indicate that there is double-buffering or
similar in the r.read() function.  at a guess, it is
something to do with the way that read has to work in
allowing r.read() as well as r.read(50).  so, select doesn't
work because you've already _read_ all the outstanding data,
and stored it in the r object!

which means that really, the r object must support the
select() method correctly, which at the moment it does not.

with this slightly confused reasoning, without having delved
into the code, i'm sure you can work this out.  i have
enough to go on, now :)

luke

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405831&group_id=5470


From nobody@sourceforge.net  Sat Mar 10 19:36:40 2001
From: nobody@sourceforge.net (nobody)
Date: Sat, 10 Mar 2001 11:36:40 -0800
Subject: [Python-bugs-list] [ python-Bugs-407538 ] pickling fails on Unicode strings with newlines
Message-ID: <E14bpAO-0000uA-00@usw-sf-web2.sourceforge.net>

Bugs #407538, was updated on 2001-03-10 06:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407538&group_id=5470

Category: Python Library
Group: None
Status: Closed
Priority: 5
Submitted By: Will Partain
Assigned to: Guido van Rossum
Summary: pickling fails on Unicode strings with newlines

Initial Comment:
#! /usr/bin/env python

# duznae work (this is with 2.0 on solaris)

def main():
    # fails with both pickle and cPickle
    import pickle
    test_in = u"""
      Test Input
    , Line 2
    , Line 3
    """
    test_out = pickle.loads(pickle.dumps(test_in))
    print test_out

if __name__ == '__main__': main()


----------------------------------------------------------------------

Comment By: Guido van Rossum
Date: 2001-03-10 11:36

Message:
Logged In: YES 
user_id=6380

Thanks. This is a known bug in 2.0.  It has been fixed in
2.1.

Note that it is only a problem with Unicode strings.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407538&group_id=5470


From nobody@sourceforge.net  Sun Mar 11 03:03:43 2001
From: nobody@sourceforge.net (nobody)
Date: Sat, 10 Mar 2001 19:03:43 -0800
Subject: [Python-bugs-list] [ python-Bugs-407626 ] Trailing white space after line continue
Message-ID: <E14bw91-000426-00@usw-sf-web2.sourceforge.net>

Bugs #407626, was updated on 2001-03-10 19:03
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407626&group_id=5470

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Jeff Davis
Assigned to: Nobody/Anonymous
Summary: Trailing white space after line continue

Initial Comment:
Trailing white space after a line continue character
(\) causes an "invalid token" error when parsing.

The trailing white space can be either tabs or spaces.

Tested against Python 2.0 and 2.1b1; error occurs in
both.

Request resolution: parser should ignore trailing white
space after line continue character

Sample code:

# ok -no trailing white space past line continue char
print	'case 1a' + \
	'case 1b'

# invalid token error - one space after line continue
char
print	'case 2a' + \ 
	'case 2b'

# invalid token error - one tab after line continue
char
print	'case 3a' + \	
	'case 3b'


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407626&group_id=5470


From nobody@sourceforge.net  Sun Mar 11 03:04:00 2001
From: nobody@sourceforge.net (nobody)
Date: Sat, 10 Mar 2001 19:04:00 -0800
Subject: [Python-bugs-list] [ python-Bugs-407504 ] Bug in pwd.getpwall()
Message-ID: <E14bw9I-0000K4-00@usw-sf-web1.sourceforge.net>

Bugs #407504, was updated on 2001-03-09 23:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407504&group_id=5470

Category: Extension Modules
Group: Platform-specific
Status: Closed
Priority: 5
Submitted By: Jürgen Hermann
Assigned to: Fred L. Drake, Jr.
Summary: Bug in pwd.getpwall()

Initial Comment:
If you call getpwall() several times in a running 
process, you do not see changes made to the pwd 
database.

Probable reason: 
pwd_getpwall() in python/dist/src/Modules/pwdmodule.c 
does not call endpwent() before returning, thus 
keeping the file handle open.

Remedy:
call endpwent()

Related:
same problem could exist in grpmodule.c

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr.
Date: 2001-03-10 19:03

Message:
Logged In: YES 
user_id=3066

Fixed in Modules/grpmodule.c revision 2.15 and Modules/pwdmodule.c revision 1.25.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407504&group_id=5470


From nobody@sourceforge.net  Sun Mar 11 03:10:40 2001
From: nobody@sourceforge.net (nobody)
Date: Sat, 10 Mar 2001 19:10:40 -0800
Subject: [Python-bugs-list] [ python-Bugs-407626 ] Trailing white space after line continue
Message-ID: <E14bwFk-0000PT-00@usw-sf-web1.sourceforge.net>

Bugs #407626, was updated on 2001-03-10 19:03
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407626&group_id=5470

Category: Parser/Compiler
Group: Not a Bug
Status: Closed
Priority: 5
Submitted By: Jeff Davis
Assigned to: Fred L. Drake, Jr.
Summary: Trailing white space after line continue

Initial Comment:
Trailing white space after a line continue character
(\) causes an "invalid token" error when parsing.

The trailing white space can be either tabs or spaces.

Tested against Python 2.0 and 2.1b1; error occurs in
both.

Request resolution: parser should ignore trailing white
space after line continue character

Sample code:

# ok -no trailing white space past line continue char
print	'case 1a' + \
	'case 1b'

# invalid token error - one space after line continue
char
print	'case 2a' + \ 
	'case 2b'

# invalid token error - one tab after line continue
char
print	'case 3a' + \	
	'case 3b'


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr.
Date: 2001-03-10 19:10

Message:
Logged In: YES 
user_id=3066

Python 1.5.2 also exhibits this behavior, and I'm fairly certain all previous versions did as well.  It's not at all clear this is a bug.  Typically, languages which use a line continuation character don't allow anything between the continuation character and the end of the physical line (in some, it's actually just an "escape" that causes the newline to be treated as any other whitespace character, as in the Unix shells).

I'm marking this "Not a bug" since there is no change in behavior or other reason to consider this an error.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407626&group_id=5470


From nobody@sourceforge.net  Sun Mar 11 03:12:17 2001
From: nobody@sourceforge.net (nobody)
Date: Sat, 10 Mar 2001 19:12:17 -0800
Subject: [Python-bugs-list] [ python-Bugs-406824 ] 2.1b1 pythonpath registry error.
Message-ID: <E14bwHJ-0000QC-00@usw-sf-web1.sourceforge.net>

Bugs #406824, was updated on 2001-03-07 13:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406824&group_id=5470

Category: Python Interpreter Core
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Ernie Sasaki
Assigned to: Mark Hammond
Summary: 2.1b1 pythonpath registry error.

Initial Comment:
Using python 2.1b1 under Win98SE, I am unable to set 
pythonpath using the registry (setting the PYTHONPATH 
env var works). 

Stepping thru getpythonregpath() from getpathp.c, the 
registry is searched for 
HKLM\Software\Python\PythonCore\2.1\PythonPath. 
Unfortunately, the windows installer (quite 
understandably) puts things at 
HKLM\Software\Python\PythonCore\2.1b1\PythonPath so 
the registry lookup fails.

It would appear that the string table loaded in 
dl_nt.c is out-of-date but I hesitated to change the 
string loaded into dllVersionBuffer because I wasn't 
sure if there would be other consequences.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406824&group_id=5470


From nobody@sourceforge.net  Sun Mar 11 03:18:14 2001
From: nobody@sourceforge.net (nobody)
Date: Sat, 10 Mar 2001 19:18:14 -0800
Subject: [Python-bugs-list] [ python-Bugs-406191 ] Mac OS X installation notes
Message-ID: <E14bwN4-0000Ty-00@usw-sf-web1.sourceforge.net>

Bugs #406191, was updated on 2001-03-05 19:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406191&group_id=5470

Category: Installation
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Nobody/Anonymous
Summary: Mac OS X installation notes

Initial Comment:
I'm running a very recent Mac OS X build ("4K78"); here is 
what I found necessary in order to get 2.1b1 to build on that 
system.  It might be best to add notes about these things to 
the platform-specific part of the README.

First, though, please correct the spelling in the README
of "Mac OS X" -- the name has *two* spaces in it.  Spelling
it in a way inconsistent with Apple's intent makes it
harder (mac *os *x)  to find out where in the configure/
makefile it's mentioned.

Notes:


 - configure:
  OPT="-g -traditional-cpp"  ./configure --with-suffix=.exe --with-dyld


 - limit stacksize 2m
     (It defaults to a half-meg, and then one of the regular 
expression tests fails.)

 - disable the test_largefile test (I moved its source aside).
     This test should be enabled only on a Unix UFS filesystem.
 
- termios.h tries to define a bunch of things that do not exist 
on Mac OS X.

*** Modules/termios.c   Thu Mar  1 22:50:58 2001
--- ../Python-2.1b1-fixed/Modules/termios.c   Mon Mar  5 
15:43:05 2001
***************
*** 358,364 ****
        {"INLCR", INLCR},
        {"IGNCR", IGNCR},
        {"ICRNL", ICRNL},
!       {"IUCLC", IUCLC},
        {"IXON", IXON},
        {"IXANY", IXANY},
        {"IXOFF", IXOFF},
--- 358,364 ----
        {"INLCR", INLCR},
        {"IGNCR", IGNCR},
        {"ICRNL", ICRNL},
!       /* {"IUCLC", IUCLC}, No such thing on Mac OS X. */
        {"IXON", IXON},
        {"IXANY", IXANY},
        {"IXOFF", IXOFF},
***************
*** 366,405 ****
  
        /* struct termios.c_oflag constants */
        {"OPOST", OPOST},
!       {"OLCUC", OLCUC},
        {"ONLCR", ONLCR},
!       {"OCRNL", OCRNL},
!       {"ONOCR", ONOCR},
!       {"ONLRET", ONLRET},
!       {"OFILL", OFILL},
!       {"OFDEL", OFDEL},
!       {"NLDLY", NLDLY},
!       {"CRDLY", CRDLY},
!       {"TABDLY", TABDLY},
!       {"BSDLY", BSDLY},
!       {"VTDLY", VTDLY},
!       {"FFDLY", FFDLY},
  
        /* struct termios.c_oflag-related values (delay mask) */
!       {"NL0", NL0},
!       {"NL1", NL1},
!       {"CR0", CR0},
!       {"CR1", CR1},
!       {"CR2", CR2},
!       {"CR3", CR3},
!       {"TAB0", TAB0},
!       {"TAB1", TAB1},
!       {"TAB2", TAB2},
!       {"TAB3", TAB3},
  #ifdef XTABS
        {"XTABS", XTABS},
  #endif
!       {"BS0", BS0},
!       {"BS1", BS1},
!       {"VT0", VT0},
!       {"VT1", VT1},
!       {"FF0", FF0},
!       {"FF1", FF1},
  
        /* struct termios.c_cflag constants */
        {"CSIZE", CSIZE},
--- 366,405 ----
  
        /* struct termios.c_oflag constants */
        {"OPOST", OPOST},
!       /* {"OLCUC", OLCUC}, No such thing on Mac OS X. */
        {"ONLCR", ONLCR},
!       /* {"OCRNL", OCRNL}, No such thing on Mac OS X. */
!       /* {"ONOCR", ONOCR}, */
!       /* {"ONLRET", ONLRET}, */
!       /* {"OFILL", OFILL}, */
!       /* {"OFDEL", OFDEL}, */
!       /* {"NLDLY", NLDLY}, */
!       /* {"CRDLY", CRDLY}, */
!       /* {"TABDLY", TABDLY}, */
!       /* {"BSDLY", BSDLY}, */
!       /* {"VTDLY", VTDLY}, */
!       /* {"FFDLY", FFDLY}, */
  
        /* struct termios.c_oflag-related values (delay mask) */
!       /* {"NL0", NL0},
!           {"NL1", NL1},
!           {"CR0", CR0},
!           {"CR1", CR1},
!           {"CR2", CR2},
!           {"CR3", CR3},
!           {"TAB0", TAB0},
!           {"TAB1", TAB1},
!           {"TAB2", TAB2},
!           {"TAB3", TAB3}, */
  #ifdef XTABS
        {"XTABS", XTABS},
  #endif
!       /* {"BS0", BS0},
!          {"BS1", BS1},
!          {"VT0", VT0},
!          {"VT1", VT1},
!          {"FF0", FF0},
!          {"FF1", FF1}, */
  
        /* struct termios.c_cflag constants */
        {"CSIZE", CSIZE},


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr.
Date: 2001-03-10 19:18

Message:
Logged In: YES 
user_id=3066

The version of termios in CVS already makes the right tests for all the definitions your patch affects, so the
termios module from CVS should work without further changes.  Please let us know if you have any further problems with termios.

----------------------------------------------------------------------

Comment By: Martin v. Löwis
Date: 2001-03-05 23:06

Message:
Logged In: YES 
user_id=21627

Can you produce a patch that does most of this
automatically? Ideally, such a patch would work so that no
other system is affected. E.g. instead of commenting-out
certain constants, an #ifdef would be more desirable.
Likewise, the compiler options are best put into
configure.in, in a way that they are used on all systems
requiring these settings, and ignored on all other systems.
That,of course, requires that a test is introduced to find
out whether you've got the right kind of system.

In addition, I'd prefer if the number of settings needed is
reduced to the absolute minimum. E.g. why is it *necessary*
to compiler Python with -g on Mac OS X? Also, if --with-dyld
is *mandatory* on Mac OS X, why can you specify it as an
option? On all other systems, not using dynamic loading is
not an option. OTOH, if the LDSHARED case of -nostdlib -r
(which you get when you omit --with-dyld) works fine on your
system, why is it necessary to specify --with-dyld.

In short, instead of giving long instructions how to do it
right, I'd prefer if Python configuration did it right on
its own. If you are unsure how to achieve this effect, I
suggest you ask on the pythonmac list. Please upload any
patch you come up with into the patch manager, adding a
comment here that a patch is available.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406191&group_id=5470


From nobody@sourceforge.net  Sun Mar 11 03:24:32 2001
From: nobody@sourceforge.net (nobody)
Date: Sat, 10 Mar 2001 19:24:32 -0800
Subject: [Python-bugs-list] [ python-Bugs-407626 ] Trailing white space after line continue
Message-ID: <E14bwTA-00049p-00@usw-sf-web2.sourceforge.net>

Bugs #407626, was updated on 2001-03-10 19:03
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407626&group_id=5470

Category: Parser/Compiler
Group: Not a Bug
Status: Closed
Priority: 5
Submitted By: Jeff Davis
Assigned to: Fred L. Drake, Jr.
Summary: Trailing white space after line continue

Initial Comment:
Trailing white space after a line continue character
(\) causes an "invalid token" error when parsing.

The trailing white space can be either tabs or spaces.

Tested against Python 2.0 and 2.1b1; error occurs in
both.

Request resolution: parser should ignore trailing white
space after line continue character

Sample code:

# ok -no trailing white space past line continue char
print	'case 1a' + \
	'case 1b'

# invalid token error - one space after line continue
char
print	'case 2a' + \ 
	'case 2b'

# invalid token error - one tab after line continue
char
print	'case 3a' + \	
	'case 3b'


----------------------------------------------------------------------

Comment By: Jeff Davis
Date: 2001-03-10 19:24

Message:
Logged In: YES 
user_id=170745

Ok, I see your reasoning.  It's just annoying because while 
editing I sometimes leave trailing white space after the 
line continue, then it breaks my flow when I get an error 
and have to go back and delete a few spaces or tabs that 
don't really matter.

I'll dig through the source and see if I can change it to 
ignore trailing white space after the line continue char to 
the end of line.  I can't imagine that *not* having it 
raise an error on trailing whitespace would cause problems 
for anyone, and it would help me out.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr.
Date: 2001-03-10 19:10

Message:
Logged In: YES 
user_id=3066

Python 1.5.2 also exhibits this behavior, and I'm fairly certain all previous versions did as well.  It's not at all clear this is a bug.  Typically, languages which use a line continuation character don't allow anything between the continuation character and the end of the physical line (in some, it's actually just an "escape" that causes the newline to be treated as any other whitespace character, as in the Unix shells).

I'm marking this "Not a bug" since there is no change in behavior or other reason to consider this an error.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407626&group_id=5470


From nobody@sourceforge.net  Sun Mar 11 04:35:31 2001
From: nobody@sourceforge.net (nobody)
Date: Sat, 10 Mar 2001 20:35:31 -0800
Subject: [Python-bugs-list] [ python-Bugs-406824 ] 2.1b1 pythonpath registry error.
Message-ID: <E14bxZr-0000CP-00@usw-sf-web3.sourceforge.net>

Bugs #406824, was updated on 2001-03-07 13:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406824&group_id=5470

Category: Windows
Group: Platform-specific
Status: Closed
Priority: 5
Submitted By: Ernie Sasaki
Assigned to: Tim Peters
Summary: 2.1b1 pythonpath registry error.

Initial Comment:
Using python 2.1b1 under Win98SE, I am unable to set 
pythonpath using the registry (setting the PYTHONPATH 
env var works). 

Stepping thru getpythonregpath() from getpathp.c, the 
registry is searched for 
HKLM\Software\Python\PythonCore\2.1\PythonPath. 
Unfortunately, the windows installer (quite 
understandably) puts things at 
HKLM\Software\Python\PythonCore\2.1b1\PythonPath so 
the registry lookup fails.

It would appear that the string table loaded in 
dl_nt.c is out-of-date but I hesitated to change the 
string loaded into dllVersionBuffer because I wasn't 
sure if there would be other consequences.

----------------------------------------------------------------------

Comment By: Tim Peters
Date: 2001-03-10 20:35

Message:
Logged In: YES 
user_id=31435

Reassigned to me; closed; fixed.  MarkH wrote in email:

""""
Australia's net connection seems to be down, so I'm having 
lots of trouble getting to sourceforge.

Why does the installer write the key as "2.1b1"?  It almost 
certainly should use "2.1".  Back in the 1.5 days, we 
changed things so the minor version was not in the key 
(ie, "1.5" vs "1.5.2"), and by the same logic beta versions
etc shouldn't use a different key.

What do you think?
"""

This was simply due to magic strings getting defined in two 
different places without any obvious clue that they were 
related.  Repaired in

python_nt.rc revision: 1.13
python20.wse revision: 1.30

using "2.1" in both places, and adding comments in both 
places to remind the next guy that they have to stay in 
synch.

Ernie Sasaki:  in the meantime, feel free to rename the 
registry key to 2.1 (right-click on 2.1b1 and select 
Rename; etc).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406824&group_id=5470


From nobody@sourceforge.net  Sun Mar 11 04:58:55 2001
From: nobody@sourceforge.net (nobody)
Date: Sat, 10 Mar 2001 20:58:55 -0800
Subject: [Python-bugs-list] [ python-Bugs-407626 ] Trailing white space after line continue
Message-ID: <E14bxwV-0001Un-00@usw-sf-web1.sourceforge.net>

Bugs #407626, was updated on 2001-03-10 19:03
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407626&group_id=5470

Category: Parser/Compiler
Group: Not a Bug
Status: Closed
Priority: 5
Submitted By: Jeff Davis
Assigned to: Fred L. Drake, Jr.
Summary: Trailing white space after line continue

Initial Comment:
Trailing white space after a line continue character
(\) causes an "invalid token" error when parsing.

The trailing white space can be either tabs or spaces.

Tested against Python 2.0 and 2.1b1; error occurs in
both.

Request resolution: parser should ignore trailing white
space after line continue character

Sample code:

# ok -no trailing white space past line continue char
print	'case 1a' + \
	'case 1b'

# invalid token error - one space after line continue
char
print	'case 2a' + \ 
	'case 2b'

# invalid token error - one tab after line continue
char
print	'case 3a' + \	
	'case 3b'


----------------------------------------------------------------------

Comment By: Tim Peters
Date: 2001-03-10 20:58

Message:
Logged In: YES 
user_id=31435

Agree with Fred here:  not a bug.  The grammar does not 
allow for spaces after the backslash, and not only does 
Python rely on that, but also all the regexp-based parsers 
in assorted tools (from the Emacs python-mode thru IDLE).

The good news is that many tens of thousands of users have 
learned to live with this without any complaint <wink>.

Note that IDLE automatically strips trailing spaces when 
you hit ENTER; many other good programmer's editors do 
too.  The script Tools/Scripts/reindent.py will strip 
trailing spaces in "batch mode" for you.  Note also that 
backslash continuation is *unusual* in Python source code 
(just look at the megabytes of .py files that come with the 
distribution).

----------------------------------------------------------------------

Comment By: Jeff Davis
Date: 2001-03-10 19:24

Message:
Logged In: YES 
user_id=170745

Ok, I see your reasoning.  It's just annoying because while 
editing I sometimes leave trailing white space after the 
line continue, then it breaks my flow when I get an error 
and have to go back and delete a few spaces or tabs that 
don't really matter.

I'll dig through the source and see if I can change it to 
ignore trailing white space after the line continue char to 
the end of line.  I can't imagine that *not* having it 
raise an error on trailing whitespace would cause problems 
for anyone, and it would help me out.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr.
Date: 2001-03-10 19:10

Message:
Logged In: YES 
user_id=3066

Python 1.5.2 also exhibits this behavior, and I'm fairly certain all previous versions did as well.  It's not at all clear this is a bug.  Typically, languages which use a line continuation character don't allow anything between the continuation character and the end of the physical line (in some, it's actually just an "escape" that causes the newline to be treated as any other whitespace character, as in the Unix shells).

I'm marking this "Not a bug" since there is no change in behavior or other reason to consider this an error.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407626&group_id=5470


From nobody@sourceforge.net  Sun Mar 11 05:34:04 2001
From: nobody@sourceforge.net (nobody)
Date: Sat, 10 Mar 2001 21:34:04 -0800
Subject: [Python-bugs-list] [ python-Bugs-407626 ] Trailing white space after line continue
Message-ID: <E14byUW-0000Xh-00@usw-sf-web3.sourceforge.net>

Bugs #407626, was updated on 2001-03-10 19:03
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407626&group_id=5470

Category: Parser/Compiler
Group: Not a Bug
Status: Closed
Priority: 5
Submitted By: Jeff Davis
Assigned to: Fred L. Drake, Jr.
Summary: Trailing white space after line continue

Initial Comment:
Trailing white space after a line continue character
(\) causes an "invalid token" error when parsing.

The trailing white space can be either tabs or spaces.

Tested against Python 2.0 and 2.1b1; error occurs in
both.

Request resolution: parser should ignore trailing white
space after line continue character

Sample code:

# ok -no trailing white space past line continue char
print	'case 1a' + \
	'case 1b'

# invalid token error - one space after line continue
char
print	'case 2a' + \ 
	'case 2b'

# invalid token error - one tab after line continue
char
print	'case 3a' + \	
	'case 3b'


----------------------------------------------------------------------

Comment By: Jeff Davis
Date: 2001-03-10 21:34

Message:
Logged In: YES 
user_id=170745

I am conviced by the consistency argument - if the standard 
definition of a line continue is literally an escaped 
newline ("\n"), and white space between the escape and the 
newline isn't valid, then clearly Python's line continue 
should follow the same rules.

I'll just run a preprocessor to tidy up my python code.

On the plus side, I looked at the source code for the first 
time.  Pretty fun.

----------------------------------------------------------------------

Comment By: Tim Peters
Date: 2001-03-10 20:58

Message:
Logged In: YES 
user_id=31435

Agree with Fred here:  not a bug.  The grammar does not 
allow for spaces after the backslash, and not only does 
Python rely on that, but also all the regexp-based parsers 
in assorted tools (from the Emacs python-mode thru IDLE).

The good news is that many tens of thousands of users have 
learned to live with this without any complaint <wink>.

Note that IDLE automatically strips trailing spaces when 
you hit ENTER; many other good programmer's editors do 
too.  The script Tools/Scripts/reindent.py will strip 
trailing spaces in "batch mode" for you.  Note also that 
backslash continuation is *unusual* in Python source code 
(just look at the megabytes of .py files that come with the 
distribution).

----------------------------------------------------------------------

Comment By: Jeff Davis
Date: 2001-03-10 19:24

Message:
Logged In: YES 
user_id=170745

Ok, I see your reasoning.  It's just annoying because while 
editing I sometimes leave trailing white space after the 
line continue, then it breaks my flow when I get an error 
and have to go back and delete a few spaces or tabs that 
don't really matter.

I'll dig through the source and see if I can change it to 
ignore trailing white space after the line continue char to 
the end of line.  I can't imagine that *not* having it 
raise an error on trailing whitespace would cause problems 
for anyone, and it would help me out.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr.
Date: 2001-03-10 19:10

Message:
Logged In: YES 
user_id=3066

Python 1.5.2 also exhibits this behavior, and I'm fairly certain all previous versions did as well.  It's not at all clear this is a bug.  Typically, languages which use a line continuation character don't allow anything between the continuation character and the end of the physical line (in some, it's actually just an "escape" that causes the newline to be treated as any other whitespace character, as in the Unix shells).

I'm marking this "Not a bug" since there is no change in behavior or other reason to consider this an error.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407626&group_id=5470


From nobody@sourceforge.net  Sun Mar 11 05:38:42 2001
From: nobody@sourceforge.net (nobody)
Date: Sat, 10 Mar 2001 21:38:42 -0800
Subject: [Python-bugs-list] [ python-Bugs-407626 ] Trailing white space after line continue
Message-ID: <E14byZ0-0000Yn-00@usw-sf-web3.sourceforge.net>

Bugs #407626, was updated on 2001-03-10 19:03
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407626&group_id=5470

Category: Parser/Compiler
Group: Not a Bug
Status: Closed
Priority: 5
Submitted By: Jeff Davis
Assigned to: Fred L. Drake, Jr.
Summary: Trailing white space after line continue

Initial Comment:
Trailing white space after a line continue character
(\) causes an "invalid token" error when parsing.

The trailing white space can be either tabs or spaces.

Tested against Python 2.0 and 2.1b1; error occurs in
both.

Request resolution: parser should ignore trailing white
space after line continue character

Sample code:

# ok -no trailing white space past line continue char
print	'case 1a' + \
	'case 1b'

# invalid token error - one space after line continue
char
print	'case 2a' + \ 
	'case 2b'

# invalid token error - one tab after line continue
char
print	'case 3a' + \	
	'case 3b'


----------------------------------------------------------------------

Comment By: Jeff Davis
Date: 2001-03-10 21:38

Message:
Logged In: YES 
user_id=170745

I am conviced by the consistency argument - if the standard 
definition of a line continue is literally an escaped 
newline ("\n"), and white space between the escape and the 
newline isn't valid, then clearly Python's line continue 
should follow the same rules.

I'll just run a preprocessor to tidy up my python code.

On the plus side, I looked at the source code for the first 
time.  Pretty fun.

----------------------------------------------------------------------

Comment By: Jeff Davis
Date: 2001-03-10 21:34

Message:
Logged In: YES 
user_id=170745

I am conviced by the consistency argument - if the standard 
definition of a line continue is literally an escaped 
newline ("\n"), and white space between the escape and the 
newline isn't valid, then clearly Python's line continue 
should follow the same rules.

I'll just run a preprocessor to tidy up my python code.

On the plus side, I looked at the source code for the first 
time.  Pretty fun.

----------------------------------------------------------------------

Comment By: Tim Peters
Date: 2001-03-10 20:58

Message:
Logged In: YES 
user_id=31435

Agree with Fred here:  not a bug.  The grammar does not 
allow for spaces after the backslash, and not only does 
Python rely on that, but also all the regexp-based parsers 
in assorted tools (from the Emacs python-mode thru IDLE).

The good news is that many tens of thousands of users have 
learned to live with this without any complaint <wink>.

Note that IDLE automatically strips trailing spaces when 
you hit ENTER; many other good programmer's editors do 
too.  The script Tools/Scripts/reindent.py will strip 
trailing spaces in "batch mode" for you.  Note also that 
backslash continuation is *unusual* in Python source code 
(just look at the megabytes of .py files that come with the 
distribution).

----------------------------------------------------------------------

Comment By: Jeff Davis
Date: 2001-03-10 19:24

Message:
Logged In: YES 
user_id=170745

Ok, I see your reasoning.  It's just annoying because while 
editing I sometimes leave trailing white space after the 
line continue, then it breaks my flow when I get an error 
and have to go back and delete a few spaces or tabs that 
don't really matter.

I'll dig through the source and see if I can change it to 
ignore trailing white space after the line continue char to 
the end of line.  I can't imagine that *not* having it 
raise an error on trailing whitespace would cause problems 
for anyone, and it would help me out.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr.
Date: 2001-03-10 19:10

Message:
Logged In: YES 
user_id=3066

Python 1.5.2 also exhibits this behavior, and I'm fairly certain all previous versions did as well.  It's not at all clear this is a bug.  Typically, languages which use a line continuation character don't allow anything between the continuation character and the end of the physical line (in some, it's actually just an "escape" that causes the newline to be treated as any other whitespace character, as in the Unix shells).

I'm marking this "Not a bug" since there is no change in behavior or other reason to consider this an error.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407626&group_id=5470


From nobody@sourceforge.net  Sun Mar 11 07:42:42 2001
From: nobody@sourceforge.net (nobody)
Date: Sat, 10 Mar 2001 23:42:42 -0800
Subject: [Python-bugs-list] [ python-Bugs-407300 ] Win32: pydoc command isn't executable
Message-ID: <E14c0V0-0005ga-00@usw-sf-web2.sourceforge.net>

Bugs #407300, was updated on 2001-03-09 05:45
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407300&group_id=5470

Category: Windows
Group: Platform-specific
Status: Closed
Priority: 5
Submitted By: Paul Moore
Assigned to: Tim Peters
Summary: Win32: pydoc command isn't executable

Initial Comment:
The Python 2.1b1 binary installer for Windows supplies 
a small "pydoc" script in the main Python executable 
directory. However, this script is Unix-specific and 
does not work on Windows.

Suggestion: for Windows, include a trivial pydoc.bat 
file to start pydoc. The following one-liner works:

--- pydoc.bat ---
@python -c "import pydoc; pydoc.cli()" %*
-----------------

The only problem with this version is that it uses the 
version of python.exe found on PATH, rather than the 
version in the directory containing pydoc.bat. 
However, as the Unix script has the same issue, this 
can be viewed as a "feature"...

----------------------------------------------------------------------

Comment By: Tim Peters
Date: 2001-03-10 23:42

Message:
Logged In: YES 
user_id=31435

"%*" doesn't work under Win9X.

Changed the installer to name the file pydoc.pyw instead.

Note that the Windows installer also creates an entry for 
pydoc under Start -> Programs -> Python -> Module Docs.

Note too that due to Tk problems, we can't encourage using 
python instead of pythonw to run pydoc (Tk apps have an 
unfortunate tendency to wedge Windows when run via python; 
see other SF bugs for more on that).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407300&group_id=5470


From nobody@sourceforge.net  Sun Mar 11 15:18:39 2001
From: nobody@sourceforge.net (nobody)
Date: Sun, 11 Mar 2001 07:18:39 -0800
Subject: [Python-bugs-list] [ python-Bugs-407680 ] obmalloc.c - looks like it's corrupted
Message-ID: <E14c7cF-0000Pr-00@usw-sf-web1.sourceforge.net>

Bugs #407680, was updated on 2001-03-11 07:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407680&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Priority: 5
Submitted By: Uwe Zessin
Assigned to: Nobody/Anonymous
Summary: obmalloc.c - looks like it's corrupted

Initial Comment:
It cannot be compiled on OpenVMS with DEC C compiler.
Here is an extract from the file:

/*
 * This malloc lock
 */
SIMPLELOCK_DECL(__malloc_lock);
#define LOCK()         SIMPLELOCK_LOCK(__malloc_lock)
#define UNLOCK()       SIMPLELOCK_UNLOCK(__malloc_lock)


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407680&group_id=5470


From nobody@sourceforge.net  Sun Mar 11 18:27:20 2001
From: nobody@sourceforge.net (nobody)
Date: Sun, 11 Mar 2001 10:27:20 -0800
Subject: [Python-bugs-list] [ python-Bugs-407680 ] obmalloc.c - looks like it's corrupted
Message-ID: <E14cAYq-0002x0-00@usw-sf-web2.sourceforge.net>

Bugs #407680, was updated on 2001-03-11 07:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407680&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Priority: 5
Submitted By: Uwe Zessin
Assigned to: Nobody/Anonymous
Summary: obmalloc.c - looks like it's corrupted

Initial Comment:
It cannot be compiled on OpenVMS with DEC C compiler.
Here is an extract from the file:

/*
 * This malloc lock
 */
SIMPLELOCK_DECL(__malloc_lock);
#define LOCK()         SIMPLELOCK_LOCK(__malloc_lock)
#define UNLOCK()       SIMPLELOCK_UNLOCK(__malloc_lock)


----------------------------------------------------------------------

Comment By: Tim Peters
Date: 2001-03-11 10:27

Message:
Logged In: YES 
user_id=31435

So what (exactly) happens when you try to compile it?

I see nothing strange in the extract you posted (it's 
invoking the do-nothing SIMPLELOCK_DECL macro, defined 
earlier on line 258, then defining two other macros).

Vladimir probably should not have used a name starting with 
two underscores, though (names starting with an underscore 
and followed by either an uppercase letter or another 
underscore are reserved for use by the C implementation).  
Is *that* the problem here?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407680&group_id=5470


From nobody@sourceforge.net  Mon Mar 12 00:00:59 2001
From: nobody@sourceforge.net (nobody)
Date: Sun, 11 Mar 2001 16:00:59 -0800
Subject: [Python-bugs-list] [ python-Bugs-407777 ] 2.1b1 Lib/multifile.py typo
Message-ID: <E14cFlj-0005SD-00@usw-sf-web2.sourceforge.net>

Bugs #407777, was updated on 2001-03-11 16:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407777&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Greg Andruk
Assigned to: Nobody/Anonymous
Summary: 2.1b1 Lib/multifile.py typo

Initial Comment:
on about line 120 of Lib/multifile.py, in the read(self) method, is:

        return self.readlines().join('')

In 2.0 and earlier, this was:

        return string.joinfields(self.readlines(), '')

So, that should now be:

        return ''.join(self.readlines())

Right?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407777&group_id=5470


From nobody@sourceforge.net  Mon Mar 12 00:27:40 2001
From: nobody@sourceforge.net (nobody)
Date: Sun, 11 Mar 2001 16:27:40 -0800
Subject: [Python-bugs-list] [ python-Bugs-406280 ] Python 2.1b1 - pydoc shows nothing
Message-ID: <E14cGBY-0006Yl-00@usw-sf-web1.sourceforge.net>

Bugs #406280, was updated on 2001-03-06 05:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406280&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Tim Peters
Summary: Python 2.1b1 - pydoc shows nothing

Initial Comment:
Platform: Windows 2000, Python 2.1b1

The pydoc script works fine in "serve documents to a 
browser" mode (python pydoc). Also, running it as a 
command line application, as "python pydoc pydoc", 
works fine when the environment variable PAGER is 
unset.

However, when I have PAGER=less, I get no output at 
all.

It looks like a bug in pydoc.pipepager(), which is the 
result of a bug in os.popen(). I can work around the 
bug by using pydoc.tempfilepager() in place of 
pydoc.pipepager(), but I don't know what the 
underlying popen() bug is.

To demonstrate the os.popen() bug, see the attached 
interactive session:

C:\Data>python21
Python 2.1b1 (#11, Mar  2 2001, 11:23:29) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
>>> import os
>>> a = os.popen("more", "w")
>>> a.write("Hello")
>>> a.close()

Run this, and note that the "More" program never 
starts...

----------------------------------------------------------------------

Comment By: Guido van Rossum
Date: 2001-03-11 16:27

Message:
Logged In: YES 
user_id=6380

Assigned to Tim, because of that fine combination of
keywords:
popen and Windows.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406280&group_id=5470


From nobody@sourceforge.net  Mon Mar 12 00:43:19 2001
From: nobody@sourceforge.net (nobody)
Date: Sun, 11 Mar 2001 16:43:19 -0800
Subject: [Python-bugs-list] [ python-Bugs-407783 ] urllib2: AbstractHTTPHandler limits flexible client implementations
Message-ID: <E14cGQh-0006iu-00@usw-sf-web1.sourceforge.net>

Bugs #407783, was updated on 2001-03-11 16:43
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407783&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Bill Bumgarner
Assigned to: Nobody/Anonymous
Summary: urllib2: AbstractHTTPHandler limits flexible client implementations

Initial Comment:
The implementation of the do_open() method on the AbstractHTTPHandler class contains a couple of "features" that could be considered to be "bugs".  In any case, each time I have wanted to use urllib2 for relatively straightforward development of an HTTP client, I have had to effectively replace the HTTPHandler with one that reimplements do_open() (or http_open() in 2.0).  Maybe my usage is not the norm-- in any case, the more information, the better...

Specifics (all names in context of Python 2.1):

- AbstractHTTPHandler does not allow for anything but GET or POST requests.   GET is the default and POST happens anytime the request object contains data to be passed to the server.

This limitation is the only thing that stands in the way of using the AbstractHTTPHandler *directly* to implement, say, a WebDAV client or to do something like a site sucker that uses the HEAD method to determine if content has changed.

- [this is likely a bug]  the method will throw an exception if *any* response is received from the server other than 200.   However, HTTP defines that all 2XX responses should be treated as successful. 

In any case, there are *a lot* of contexts within which a non-200 response may be treated as a 'success' of some sort or another.  Regardless, it is really outside of the scope of the AbstractHTTPHandler's implementation to make the success/failure decision-- it should simply return  the same thing regardless of the response status.

- [a bug?] Whenever an exception is raised (a non-200 code is received), the status code and reason (as provided by the server) are both lost. 

I see that moshez has been primarily responsible for recent changes surrounding this code.  I would be happy to contribute to the evolution of the code;  please feel free to contact me directly.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407783&group_id=5470


From nobody@sourceforge.net  Mon Mar 12 02:18:26 2001
From: nobody@sourceforge.net (nobody)
Date: Sun, 11 Mar 2001 18:18:26 -0800
Subject: [Python-bugs-list] [ python-Bugs-407800 ] global in classdef affect nested scope!?
Message-ID: <E14cHuk-0006OS-00@usw-sf-web2.sourceforge.net>

Bugs #407800, was updated on 2001-03-11 18:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407800&group_id=5470

Category: Parser/Compiler
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Nobody/Anonymous
Summary: global in classdef affect nested scope!?

Initial Comment:
[pedroni]
> (II)
> from __future__ import nested_scopes

> x='top'
> def ta():
>     x='ta'
>     class A:
>         global x
>         def tata(self):
>             return x # LOAD_GLOBAL
>     return A
>
> print ta()().tata() # -> 'top'
>
> should not the global decl in class scope be ignored 
and so x be
> bound to x in ta, resulting in 'ta' as output?

[Tim Peters]
Yes, this one is clearly a bug.  Good catch!



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407800&group_id=5470


From nobody@sourceforge.net  Mon Mar 12 02:57:12 2001
From: nobody@sourceforge.net (nobody)
Date: Sun, 11 Mar 2001 18:57:12 -0800
Subject: [Python-bugs-list] [ python-Bugs-407777 ] 2.1b1 Lib/multifile.py typo
Message-ID: <E14cIWG-0008CZ-00@usw-sf-web1.sourceforge.net>

Bugs #407777, was updated on 2001-03-11 16:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407777&group_id=5470

Category: Python Library
Group: None
Status: Closed
Priority: 5
Submitted By: Greg Andruk
Assigned to: Fred L. Drake, Jr.
Summary: 2.1b1 Lib/multifile.py typo

Initial Comment:
on about line 120 of Lib/multifile.py, in the read(self) method, is:

        return self.readlines().join('')

In 2.0 and earlier, this was:

        return string.joinfields(self.readlines(), '')

So, that should now be:

        return ''.join(self.readlines())

Right?


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr.
Date: 2001-03-11 18:57

Message:
Logged In: YES 
user_id=3066

Right!  Fixed in Lib/multifile.py revision 1.17.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407777&group_id=5470


From nobody@sourceforge.net  Mon Mar 12 03:00:32 2001
From: nobody@sourceforge.net (nobody)
Date: Sun, 11 Mar 2001 19:00:32 -0800
Subject: [Python-bugs-list] [ python-Bugs-407783 ] urllib2: AbstractHTTPHandler limits flexible client implementations
Message-ID: <E14cIZU-0008FG-00@usw-sf-web1.sourceforge.net>

Bugs #407783, was updated on 2001-03-11 16:43
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407783&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Bill Bumgarner
Assigned to: Jeremy Hylton
Summary: urllib2: AbstractHTTPHandler limits flexible client implementations

Initial Comment:
The implementation of the do_open() method on the AbstractHTTPHandler class contains a couple of "features" that could be considered to be "bugs".  In any case, each time I have wanted to use urllib2 for relatively straightforward development of an HTTP client, I have had to effectively replace the HTTPHandler with one that reimplements do_open() (or http_open() in 2.0).  Maybe my usage is not the norm-- in any case, the more information, the better...

Specifics (all names in context of Python 2.1):

- AbstractHTTPHandler does not allow for anything but GET or POST requests.   GET is the default and POST happens anytime the request object contains data to be passed to the server.

This limitation is the only thing that stands in the way of using the AbstractHTTPHandler *directly* to implement, say, a WebDAV client or to do something like a site sucker that uses the HEAD method to determine if content has changed.

- [this is likely a bug]  the method will throw an exception if *any* response is received from the server other than 200.   However, HTTP defines that all 2XX responses should be treated as successful. 

In any case, there are *a lot* of contexts within which a non-200 response may be treated as a 'success' of some sort or another.  Regardless, it is really outside of the scope of the AbstractHTTPHandler's implementation to make the success/failure decision-- it should simply return  the same thing regardless of the response status.

- [a bug?] Whenever an exception is raised (a non-200 code is received), the status code and reason (as provided by the server) are both lost. 

I see that moshez has been primarily responsible for recent changes surrounding this code.  I would be happy to contribute to the evolution of the code;  please feel free to contact me directly.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407783&group_id=5470


From nobody@sourceforge.net  Mon Mar 12 03:00:59 2001
From: nobody@sourceforge.net (nobody)
Date: Sun, 11 Mar 2001 19:00:59 -0800
Subject: [Python-bugs-list] [ python-Bugs-407800 ] global in classdef affect nested scope!?
Message-ID: <E14cIZv-0008Fa-00@usw-sf-web1.sourceforge.net>

Bugs #407800, was updated on 2001-03-11 18:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407800&group_id=5470

Category: Parser/Compiler
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Jeremy Hylton
Summary: global in classdef affect nested scope!?

Initial Comment:
[pedroni]
> (II)
> from __future__ import nested_scopes

> x='top'
> def ta():
>     x='ta'
>     class A:
>         global x
>         def tata(self):
>             return x # LOAD_GLOBAL
>     return A
>
> print ta()().tata() # -> 'top'
>
> should not the global decl in class scope be ignored 
and so x be
> bound to x in ta, resulting in 'ta' as output?

[Tim Peters]
Yes, this one is clearly a bug.  Good catch!



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407800&group_id=5470


From nobody@sourceforge.net  Mon Mar 12 03:59:09 2001
From: nobody@sourceforge.net (nobody)
Date: Sun, 11 Mar 2001 19:59:09 -0800
Subject: [Python-bugs-list] [ python-Bugs-407783 ] urllib2: AbstractHTTPHandler limits flexible client implementations
Message-ID: <E14cJUD-0000RT-00@usw-sf-web1.sourceforge.net>

Bugs #407783, was updated on 2001-03-11 16:43
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407783&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Bill Bumgarner
Assigned to: Jeremy Hylton
Summary: urllib2: AbstractHTTPHandler limits flexible client implementations

Initial Comment:
The implementation of the do_open() method on the AbstractHTTPHandler class contains a couple of "features" that could be considered to be "bugs".  In any case, each time I have wanted to use urllib2 for relatively straightforward development of an HTTP client, I have had to effectively replace the HTTPHandler with one that reimplements do_open() (or http_open() in 2.0).  Maybe my usage is not the norm-- in any case, the more information, the better...

Specifics (all names in context of Python 2.1):

- AbstractHTTPHandler does not allow for anything but GET or POST requests.   GET is the default and POST happens anytime the request object contains data to be passed to the server.

This limitation is the only thing that stands in the way of using the AbstractHTTPHandler *directly* to implement, say, a WebDAV client or to do something like a site sucker that uses the HEAD method to determine if content has changed.

- [this is likely a bug]  the method will throw an exception if *any* response is received from the server other than 200.   However, HTTP defines that all 2XX responses should be treated as successful. 

In any case, there are *a lot* of contexts within which a non-200 response may be treated as a 'success' of some sort or another.  Regardless, it is really outside of the scope of the AbstractHTTPHandler's implementation to make the success/failure decision-- it should simply return  the same thing regardless of the response status.

- [a bug?] Whenever an exception is raised (a non-200 code is received), the status code and reason (as provided by the server) are both lost. 

I see that moshez has been primarily responsible for recent changes surrounding this code.  I would be happy to contribute to the evolution of the code;  please feel free to contact me directly.


----------------------------------------------------------------------

Comment By: Bill Bumgarner
Date: 2001-03-11 19:59

Message:
Logged In: YES 
user_id=103811

I realized that the exception throw behaviour is more fundamental to the underlying implementation than may have been indicated in the above description.  In particular, throwing an HTTP exception when handling a 401 is key to making the various Authentication Handlers work.

I still feel that the behaviour should be normalized across all requests such that the callee is responsible for determining error conditions or, at the lest, has access to the same data in a relatively similar format upon success or failure.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407783&group_id=5470


From nobody@sourceforge.net  Mon Mar 12 10:58:13 2001
From: nobody@sourceforge.net (nobody)
Date: Mon, 12 Mar 2001 02:58:13 -0800
Subject: [Python-bugs-list] [ python-Bugs-405831 ] popen3 read fails in blocks
Message-ID: <E14cQ1l-0004x2-00@usw-sf-web1.sourceforge.net>

Bugs #405831, was updated on 2001-03-04 06:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405831&group_id=5470

Category: Python Library
Group: Not a Bug
Status: Closed
Priority: 1
Submitted By: Luke Kenneth Casson Leighton
Assigned to: Guido van Rossum
Summary: popen3 read fails in blocks

Initial Comment:
bash$ python2
from popen2 import popen3
r,w,e = popen3("bash")
w.write("ls")
w.flush()
print select([r],[],[],0)
[r],[],[]
t = r.read(50)
print t
"file1
file2
"
print select([r],[],[],0)
[],[],[]

r,w,e = popen3("bash")
w.write("ls")
w.close()
t = r.read(50)
print t
"file1
file2
[50 bytes of file listings]
"
t = r.read(50)
print t
"file3
file4
[50 more bytes of file listings]
"

print select([r],[],[],0)
[r],[],[]

what is going on????

when you do a w.flush(), the read file descriptor
can get the first 50 bytes, and then select
will *always* return [],[],[] - EVEN if there's
really more data pending to be read.

it is as if there is double-buffering being
done in os.popen3() which select() is failing
to access.

this is standard-compiled version of python 2.0
on linux mandrake 7.1.  if it makes any difference.

luke

----------------------------------------------------------------------

Comment By: Luke Kenneth Casson Leighton
Date: 2001-03-12 02:58

Message:
Logged In: YES 
user_id=80200

hiya guido,

okay.  i understand.  thought about this: to make it "work",
you would have to either switch off the read-ahead buffering
in cases where a number of bytes to be read is specified.

or you would have to emulate select. which would cause other
problems because you can always use the file object's
fileno() method to obtain the file descriptor, directly.

... which... makes... it... uh... difficult.

proposal: can there be a function added to file object,
which can be called to disable the buffering?

... but wait, surely i'm not the only person to have been
caught out by this?

surely there are other programmers who perform read / select
loops on file objects, and this cannot just be limited to
the file objects returned by popen3?

----------------------------------------------------------------------

Comment By: Guido van Rossum
Date: 2001-03-10 11:28

Message:
Logged In: YES 
user_id=6380

Not a bug -- you just can't do what you want there.

The data is being buffered in the file object (which is a
wrapper around a stdio file), and this makes it invisible
for select.

----------------------------------------------------------------------

Comment By: Luke Kenneth Casson Leighton
Date: 2001-03-09 03:34

Message:
Logged In: YES 
user_id=80200

the following test DOES work as expected, which is good news
because i can use this in my [current] project.  the
work-around is to bypass r.read() and use
os.read(r.fileno(), 50), like so:

import os
from select import select

w,r,e = os.popen3("bash")
w.write("ls -al\n")
w.flush()

while select([r],[],[],1) == ([r],[],[]):
    print os.read(r.fileno(), 50),

this would indicate that there is double-buffering or
similar in the r.read() function.  at a guess, it is
something to do with the way that read has to work in
allowing r.read() as well as r.read(50).  so, select doesn't
work because you've already _read_ all the outstanding data,
and stored it in the r object!

which means that really, the r object must support the
select() method correctly, which at the moment it does not.

with this slightly confused reasoning, without having delved
into the code, i'm sure you can work this out.  i have
enough to go on, now :)

luke

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405831&group_id=5470


From nobody@sourceforge.net  Mon Mar 12 11:11:53 2001
From: nobody@sourceforge.net (nobody)
Date: Mon, 12 Mar 2001 03:11:53 -0800
Subject: [Python-bugs-list] [ python-Bugs-405831 ] popen3 read fails in blocks
Message-ID: <E14cQEz-0005US-00@usw-sf-web3.sourceforge.net>

Bugs #405831, was updated on 2001-03-04 06:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405831&group_id=5470

Category: Python Library
Group: Not a Bug
Status: Closed
Priority: 1
Submitted By: Luke Kenneth Casson Leighton
Assigned to: Guido van Rossum
Summary: popen3 read fails in blocks

Initial Comment:
bash$ python2
from popen2 import popen3
r,w,e = popen3("bash")
w.write("ls")
w.flush()
print select([r],[],[],0)
[r],[],[]
t = r.read(50)
print t
"file1
file2
"
print select([r],[],[],0)
[],[],[]

r,w,e = popen3("bash")
w.write("ls")
w.close()
t = r.read(50)
print t
"file1
file2
[50 bytes of file listings]
"
t = r.read(50)
print t
"file3
file4
[50 more bytes of file listings]
"

print select([r],[],[],0)
[r],[],[]

what is going on????

when you do a w.flush(), the read file descriptor
can get the first 50 bytes, and then select
will *always* return [],[],[] - EVEN if there's
really more data pending to be read.

it is as if there is double-buffering being
done in os.popen3() which select() is failing
to access.

this is standard-compiled version of python 2.0
on linux mandrake 7.1.  if it makes any difference.

luke

----------------------------------------------------------------------

Comment By: Luke Kenneth Casson Leighton
Date: 2001-03-12 03:11

Message:
Logged In: YES 
user_id=80200

okay.  just performed the following test:

from select import select
import sys
#f = open("foo.txt")
f = sys.stdin
while 1:
    ([r],w,e) = select([f],[],[],0)
    if r:
        z = r.read(50)
        if z:
            print z,

which if you run as python test.py < anyfilename.txt

works absolutely fine!

so, what is it about the file object returned from os.popen3
that makes it different from sys.stdin, that makes doing
read / select impossible on the popen3 file object but
os.read / select on the _file descriptor_ of the popen3 file
object okay?

sorry for being persistent about this :)

----------------------------------------------------------------------

Comment By: Luke Kenneth Casson Leighton
Date: 2001-03-12 02:58

Message:
Logged In: YES 
user_id=80200

hiya guido,

okay.  i understand.  thought about this: to make it "work",
you would have to either switch off the read-ahead buffering
in cases where a number of bytes to be read is specified.

or you would have to emulate select. which would cause other
problems because you can always use the file object's
fileno() method to obtain the file descriptor, directly.

... which... makes... it... uh... difficult.

proposal: can there be a function added to file object,
which can be called to disable the buffering?

... but wait, surely i'm not the only person to have been
caught out by this?

surely there are other programmers who perform read / select
loops on file objects, and this cannot just be limited to
the file objects returned by popen3?

----------------------------------------------------------------------

Comment By: Guido van Rossum
Date: 2001-03-10 11:28

Message:
Logged In: YES 
user_id=6380

Not a bug -- you just can't do what you want there.

The data is being buffered in the file object (which is a
wrapper around a stdio file), and this makes it invisible
for select.

----------------------------------------------------------------------

Comment By: Luke Kenneth Casson Leighton
Date: 2001-03-09 03:34

Message:
Logged In: YES 
user_id=80200

the following test DOES work as expected, which is good news
because i can use this in my [current] project.  the
work-around is to bypass r.read() and use
os.read(r.fileno(), 50), like so:

import os
from select import select

w,r,e = os.popen3("bash")
w.write("ls -al\n")
w.flush()

while select([r],[],[],1) == ([r],[],[]):
    print os.read(r.fileno(), 50),

this would indicate that there is double-buffering or
similar in the r.read() function.  at a guess, it is
something to do with the way that read has to work in
allowing r.read() as well as r.read(50).  so, select doesn't
work because you've already _read_ all the outstanding data,
and stored it in the r object!

which means that really, the r object must support the
select() method correctly, which at the moment it does not.

with this slightly confused reasoning, without having delved
into the code, i'm sure you can work this out.  i have
enough to go on, now :)

luke

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405831&group_id=5470


From nobody@sourceforge.net  Mon Mar 12 14:29:58 2001
From: nobody@sourceforge.net (nobody)
Date: Mon, 12 Mar 2001 06:29:58 -0800
Subject: [Python-bugs-list] [ python-Bugs-405831 ] popen3 read fails in blocks
Message-ID: <E14cTKg-0003PS-00@usw-sf-web2.sourceforge.net>

Bugs #405831, was updated on 2001-03-04 06:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405831&group_id=5470

Category: Python Library
Group: Not a Bug
Status: Closed
Priority: 1
Submitted By: Luke Kenneth Casson Leighton
Assigned to: Guido van Rossum
Summary: popen3 read fails in blocks

Initial Comment:
bash$ python2
from popen2 import popen3
r,w,e = popen3("bash")
w.write("ls")
w.flush()
print select([r],[],[],0)
[r],[],[]
t = r.read(50)
print t
"file1
file2
"
print select([r],[],[],0)
[],[],[]

r,w,e = popen3("bash")
w.write("ls")
w.close()
t = r.read(50)
print t
"file1
file2
[50 bytes of file listings]
"
t = r.read(50)
print t
"file3
file4
[50 more bytes of file listings]
"

print select([r],[],[],0)
[r],[],[]

what is going on????

when you do a w.flush(), the read file descriptor
can get the first 50 bytes, and then select
will *always* return [],[],[] - EVEN if there's
really more data pending to be read.

it is as if there is double-buffering being
done in os.popen3() which select() is failing
to access.

this is standard-compiled version of python 2.0
on linux mandrake 7.1.  if it makes any difference.

luke

----------------------------------------------------------------------

Comment By: Guido van Rossum
Date: 2001-03-12 06:29

Message:
Logged In: YES 
user_id=6380

It's all in the docs.  open() has an opetional extra
parameter
giving the buffer size, setting it to 0 makes it unbuffered,
and that's what you want.

Now, I don't know why popen3 doesn't make its file object
unbuffered, and that would be a good thing to research in
the source code and then submit a new bug report for.

----------------------------------------------------------------------

Comment By: Luke Kenneth Casson Leighton
Date: 2001-03-12 03:11

Message:
Logged In: YES 
user_id=80200

okay.  just performed the following test:

from select import select
import sys
#f = open("foo.txt")
f = sys.stdin
while 1:
    ([r],w,e) = select([f],[],[],0)
    if r:
        z = r.read(50)
        if z:
            print z,

which if you run as python test.py < anyfilename.txt

works absolutely fine!

so, what is it about the file object returned from os.popen3
that makes it different from sys.stdin, that makes doing
read / select impossible on the popen3 file object but
os.read / select on the _file descriptor_ of the popen3 file
object okay?

sorry for being persistent about this :)

----------------------------------------------------------------------

Comment By: Luke Kenneth Casson Leighton
Date: 2001-03-12 02:58

Message:
Logged In: YES 
user_id=80200

hiya guido,

okay.  i understand.  thought about this: to make it "work",
you would have to either switch off the read-ahead buffering
in cases where a number of bytes to be read is specified.

or you would have to emulate select. which would cause other
problems because you can always use the file object's
fileno() method to obtain the file descriptor, directly.

... which... makes... it... uh... difficult.

proposal: can there be a function added to file object,
which can be called to disable the buffering?

... but wait, surely i'm not the only person to have been
caught out by this?

surely there are other programmers who perform read / select
loops on file objects, and this cannot just be limited to
the file objects returned by popen3?

----------------------------------------------------------------------

Comment By: Guido van Rossum
Date: 2001-03-10 11:28

Message:
Logged In: YES 
user_id=6380

Not a bug -- you just can't do what you want there.

The data is being buffered in the file object (which is a
wrapper around a stdio file), and this makes it invisible
for select.

----------------------------------------------------------------------

Comment By: Luke Kenneth Casson Leighton
Date: 2001-03-09 03:34

Message:
Logged In: YES 
user_id=80200

the following test DOES work as expected, which is good news
because i can use this in my [current] project.  the
work-around is to bypass r.read() and use
os.read(r.fileno(), 50), like so:

import os
from select import select

w,r,e = os.popen3("bash")
w.write("ls -al\n")
w.flush()

while select([r],[],[],1) == ([r],[],[]):
    print os.read(r.fileno(), 50),

this would indicate that there is double-buffering or
similar in the r.read() function.  at a guess, it is
something to do with the way that read has to work in
allowing r.read() as well as r.read(50).  so, select doesn't
work because you've already _read_ all the outstanding data,
and stored it in the r object!

which means that really, the r object must support the
select() method correctly, which at the moment it does not.

with this slightly confused reasoning, without having delved
into the code, i'm sure you can work this out.  i have
enough to go on, now :)

luke

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405831&group_id=5470


From nobody@sourceforge.net  Mon Mar 12 14:43:21 2001
From: nobody@sourceforge.net (nobody)
Date: Mon, 12 Mar 2001 06:43:21 -0800
Subject: [Python-bugs-list] [ python-Bugs-407915 ] largefile support under Linux
Message-ID: <E14cTXd-0003Xu-00@usw-sf-web2.sourceforge.net>

Bugs #407915, was updated on 2001-03-12 06:43
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407915&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Hans-Joachim Widmaier
Assigned to: Nobody/Anonymous
Summary: largefile support under Linux

Initial Comment:
While trying to build 2.1b1 with support for large
files under Linux (2.4, glibc 2.2),
Objects/fileobject.c didn't compile:

gcc -D_FILE_OFFSET_BITS=64 -c -g -O2 -Wall
-Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H  -o
Objects/fileobject.o Objects/fileobject.c
Objects/fileobject.c: In function `_portable_ftell':
Objects/fileobject.c:267: incompatible types in return
Objects/fileobject.c:275: warning: control reaches end
of non-void function

This is because fpos_t is a structure holding 2 long
longs. After changing

    return pos
to
    return pos.__pos

I got it to compile and it seems to work ok.
This is, of course, not a portable solution.

Alas, I don't really understand why there are 3 Methods
of getting largefile support (/usr/include/feature.h)
in glibc, even less why I'm bothered with defining
CFLAGS to get it; but configure seems unable to figure
out that itself. But this is not Python's fault.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407915&group_id=5470


From nobody@sourceforge.net  Mon Mar 12 14:58:06 2001
From: nobody@sourceforge.net (nobody)
Date: Mon, 12 Mar 2001 06:58:06 -0800
Subject: [Python-bugs-list] [ python-Bugs-405831 ] popen3 read fails in blocks
Message-ID: <E14cTlu-0003gJ-00@usw-sf-web2.sourceforge.net>

Bugs #405831, was updated on 2001-03-04 06:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405831&group_id=5470

Category: Python Library
Group: Not a Bug
Status: Closed
Priority: 1
Submitted By: Luke Kenneth Casson Leighton
Assigned to: Guido van Rossum
Summary: popen3 read fails in blocks

Initial Comment:
bash$ python2
from popen2 import popen3
r,w,e = popen3("bash")
w.write("ls")
w.flush()
print select([r],[],[],0)
[r],[],[]
t = r.read(50)
print t
"file1
file2
"
print select([r],[],[],0)
[],[],[]

r,w,e = popen3("bash")
w.write("ls")
w.close()
t = r.read(50)
print t
"file1
file2
[50 bytes of file listings]
"
t = r.read(50)
print t
"file3
file4
[50 more bytes of file listings]
"

print select([r],[],[],0)
[r],[],[]

what is going on????

when you do a w.flush(), the read file descriptor
can get the first 50 bytes, and then select
will *always* return [],[],[] - EVEN if there's
really more data pending to be read.

it is as if there is double-buffering being
done in os.popen3() which select() is failing
to access.

this is standard-compiled version of python 2.0
on linux mandrake 7.1.  if it makes any difference.

luke

----------------------------------------------------------------------

Comment By: Luke Kenneth Casson Leighton
Date: 2001-03-12 06:58

Message:
Logged In: YES 
user_id=80200

okay.  tracked Lib/popen.py which calls _back_ to
popen2.Popen3 for the unix case, because unix doesn't have a
popen3.  okay, so that brings us back to the buffer
arguments.

... which are default set to -1 in Popen3's __init__!

okay, so i tested with telnetpopen3lib.py, and using a
buffer size of 0 _still_ didn't work as expected, whilst
bypassing and using os.popen2...

but... but... on unix, os.popen3 _is_ the same as using
popen2.Popen3!

aaaagh!!!

okay, i give up: i use os.popen3 and not worry about it
_any_ more :)

----------------------------------------------------------------------

Comment By: Guido van Rossum
Date: 2001-03-12 06:29

Message:
Logged In: YES 
user_id=6380

It's all in the docs.  open() has an opetional extra
parameter
giving the buffer size, setting it to 0 makes it unbuffered,
and that's what you want.

Now, I don't know why popen3 doesn't make its file object
unbuffered, and that would be a good thing to research in
the source code and then submit a new bug report for.

----------------------------------------------------------------------

Comment By: Luke Kenneth Casson Leighton
Date: 2001-03-12 03:11

Message:
Logged In: YES 
user_id=80200

okay.  just performed the following test:

from select import select
import sys
#f = open("foo.txt")
f = sys.stdin
while 1:
    ([r],w,e) = select([f],[],[],0)
    if r:
        z = r.read(50)
        if z:
            print z,

which if you run as python test.py < anyfilename.txt

works absolutely fine!

so, what is it about the file object returned from os.popen3
that makes it different from sys.stdin, that makes doing
read / select impossible on the popen3 file object but
os.read / select on the _file descriptor_ of the popen3 file
object okay?

sorry for being persistent about this :)

----------------------------------------------------------------------

Comment By: Luke Kenneth Casson Leighton
Date: 2001-03-12 02:58

Message:
Logged In: YES 
user_id=80200

hiya guido,

okay.  i understand.  thought about this: to make it "work",
you would have to either switch off the read-ahead buffering
in cases where a number of bytes to be read is specified.

or you would have to emulate select. which would cause other
problems because you can always use the file object's
fileno() method to obtain the file descriptor, directly.

... which... makes... it... uh... difficult.

proposal: can there be a function added to file object,
which can be called to disable the buffering?

... but wait, surely i'm not the only person to have been
caught out by this?

surely there are other programmers who perform read / select
loops on file objects, and this cannot just be limited to
the file objects returned by popen3?

----------------------------------------------------------------------

Comment By: Guido van Rossum
Date: 2001-03-10 11:28

Message:
Logged In: YES 
user_id=6380

Not a bug -- you just can't do what you want there.

The data is being buffered in the file object (which is a
wrapper around a stdio file), and this makes it invisible
for select.

----------------------------------------------------------------------

Comment By: Luke Kenneth Casson Leighton
Date: 2001-03-09 03:34

Message:
Logged In: YES 
user_id=80200

the following test DOES work as expected, which is good news
because i can use this in my [current] project.  the
work-around is to bypass r.read() and use
os.read(r.fileno(), 50), like so:

import os
from select import select

w,r,e = os.popen3("bash")
w.write("ls -al\n")
w.flush()

while select([r],[],[],1) == ([r],[],[]):
    print os.read(r.fileno(), 50),

this would indicate that there is double-buffering or
similar in the r.read() function.  at a guess, it is
something to do with the way that read has to work in
allowing r.read() as well as r.read(50).  so, select doesn't
work because you've already _read_ all the outstanding data,
and stored it in the r object!

which means that really, the r object must support the
select() method correctly, which at the moment it does not.

with this slightly confused reasoning, without having delved
into the code, i'm sure you can work this out.  i have
enough to go on, now :)

luke

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405831&group_id=5470


From nobody@sourceforge.net  Mon Mar 12 18:17:28 2001
From: nobody@sourceforge.net (nobody)
Date: Mon, 12 Mar 2001 10:17:28 -0800
Subject: [Python-bugs-list] [ python-Bugs-407680 ] obmalloc.c - looks like it's corrupted
Message-ID: <E14cWsq-0001q9-00@usw-sf-web1.sourceforge.net>

Bugs #407680, was updated on 2001-03-11 07:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407680&group_id=5470

Category: Python Interpreter Core
Group: Not a Bug
Status: Closed
Priority: 5
Submitted By: Uwe Zessin
Assigned to: Nobody/Anonymous
Summary: obmalloc.c - looks like it's corrupted

Initial Comment:
It cannot be compiled on OpenVMS with DEC C compiler.
Here is an extract from the file:

/*
 * This malloc lock
 */
SIMPLELOCK_DECL(__malloc_lock);
#define LOCK()         SIMPLELOCK_LOCK(__malloc_lock)
#define UNLOCK()       SIMPLELOCK_UNLOCK(__malloc_lock)


----------------------------------------------------------------------

Comment By: Uwe Zessin
Date: 2001-03-12 10:17

Message:
Logged In: YES 
user_id=155755

> So what (exactly) happens when you try to compile it?

You don't want to know ;-)

When I first looked at this I didn't realize that
OBMALLOC.C isn't a separate compile unit (at least
on my system it cannot be treated as one) and that
it is "#include"d from OBJECT.C

I would have appreciated a little note at the top
of OBMALLOC.C

I'll put a note in my build environment and close
this. I'm sorry I have wasted your time...

----------------------------------------------------------------------

Comment By: Tim Peters
Date: 2001-03-11 10:27

Message:
Logged In: YES 
user_id=31435

So what (exactly) happens when you try to compile it?

I see nothing strange in the extract you posted (it's 
invoking the do-nothing SIMPLELOCK_DECL macro, defined 
earlier on line 258, then defining two other macros).

Vladimir probably should not have used a name starting with 
two underscores, though (names starting with an underscore 
and followed by either an uppercase letter or another 
underscore are reserved for use by the C implementation).  
Is *that* the problem here?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407680&group_id=5470


From nobody@sourceforge.net  Mon Mar 12 19:25:59 2001
From: nobody@sourceforge.net (nobody)
Date: Mon, 12 Mar 2001 11:25:59 -0800
Subject: [Python-bugs-list] [ python-Bugs-407379 ] SRE objects of no known type
Message-ID: <E14cXx9-0006DX-00@usw-sf-web2.sourceforge.net>

Bugs #407379, was updated on 2001-03-09 11:43
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407379&group_id=5470

Category: Extension Modules
Group: Not a Bug
Status: Closed
Priority: 5
Submitted By: Joshua Macy
Assigned to: Fred L. Drake, Jr.
Summary: SRE objects of no known type

Initial Comment:
The new SRE re module doesn't seem to create pattern 
types of any type known to types.

Python 2.1b1 (#11, Mar  2 2001, 11:23:29) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
>>> import re
>>> r = re.compile('abc')
>>> type(r)
<type 'SRE_Pattern'>
>>> import types
>>> isinstance(r, types.InstanceType)
0

Python 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit 
(Intel)] on win3
Copyright 1991-1995 Stichting Mathematisch Centrum, 
Amsterdam
>>> import re
>>> r = re.compile('abc')
>>> type(r)
<type 'instance'>
>>> import types
>>> isinstance(r, types.InstanceType)
1



----------------------------------------------------------------------

Comment By: Joshua Macy
Date: 2001-03-12 11:25

Message:
Logged In: YES 
user_id=7894

  As it happens, I don't care whether it's really a 
pattern, or whether it supports match or search.  This is 
for an enhancement to David Mertz' xml_pickle module, so 
what we really care about is the type, not the interface 
behavior, so that we can know how to (or whether we can) 
reinstatiate the right type of object upon unpickling...

  Thanks for the suggestion, though.



----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr.
Date: 2001-03-09 21:11

Message:
Logged In: YES 
user_id=3066

This same test could be written:

pat = re.compile(...)
if type(pat) is types.InstanceType:
    pattern_type = pat.__class__
else:
    pattern_type = type(pat)

...

if isinstance(maybe_a_pattern, pattern_type):
    # looks like a pattern...
else:
    # not a pattern...

But this is a pretty fragile idiom.  Why not just assume it's a pattern, or test for the "search" or "match" attribute?  There's no reason to have suspected that the original code would work to begin with; we deal with interfaces, which are not bound to specific types of classes.

----------------------------------------------------------------------

Comment By: Joshua Macy
Date: 2001-03-09 19:38

Message:
Logged In: YES 
user_id=7894

Well, I guess I thought it was a bug because code that used
to work, along the lines of:

if type(obj) == types.InstanceType:

now fails to catch re pattern objects where it caught them
before. Moreover, it turns out to be rather difficult to get
that behavior back; the best I've been able to come up with
so far is:

if str(type(obj)) == "<type 'SRE_Pattern'>":

or creating an re object just so that I can do:

if type(obj) == type(myreobj):

but I'm not sure how robust the first is, while the second
just seems ugly.
If the type of an re or other library object is an
accidental implementation detail subject to change between
releases, so be it; I'll just have to test harder between
releases and maintain more version-specific code.


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr.
Date: 2001-03-09 17:55

Message:
Logged In: YES 
user_id=3066

SRE creates pattern objects that are of an extension type rather than an instance, so there is no entry for them in the types module.

Why do you think this is a bug?  The specific type of these objects should be irrelevant.  I'm classifying this as "Not a bug".

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407379&group_id=5470


From nobody@sourceforge.net  Mon Mar 12 21:58:01 2001
From: nobody@sourceforge.net (nobody)
Date: Mon, 12 Mar 2001 13:58:01 -0800
Subject: [Python-bugs-list] [ python-Bugs-405583 ] Objects never freed with nested scopes
Message-ID: <E14caKH-0007ev-00@usw-sf-web2.sourceforge.net>

Bugs #405583, was updated on 2001-03-02 19:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405583&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Priority: 7
Submitted By: Atsuo Ishimoto
Assigned to: Jeremy Hylton
Summary: Objects never freed with nested scopes

Initial Comment:
With this code,

from __future__ import nested_scopes
class foo:
    def __del__(self): print "del foo"

def f1():
    x = foo()
    def f2():x
    f2()

for i in range(10000):
    f1()

I see no "del foo" message.


----------------------------------------------------------------------

Comment By: Jeremy Hylton
Date: 2001-03-12 13:58

Message:
Logged In: YES 
user_id=31392

The patch from Martin seems correct, but does not resolve
the bug
report.  There are still no __del__ calls.


----------------------------------------------------------------------

Comment By: Martin v. Löwis
Date: 2001-03-04 10:08

Message:
Logged In: YES 
user_id=21627

I believe there are two missing decrefs: In STORE_DEREF,
PyCell_Set will incref the object, so the object POPped from
the stack must be decref'ed. In addition, GC requires that
the clear procedure not only sets the pointers to zero, but
actually decrefs the objects (i.e. breaks the cycle). A
patch is included below

Index: Objects/cellobject.c
===================================================================
RCS file:
/cvsroot/python/python/dist/src/Objects/cellobject.c,v
retrieving revision 1.1
diff -u -r1.1 cellobject.c
--- Objects/cellobject.c	2001/01/25 20:04:14	1.1
+++ Objects/cellobject.c	2001/03/04 18:04:45
@@ -83,6 +83,7 @@
 static int
 cell_clear(PyCellObject *op)
 {
+	Py_XDECREF(op->ob_ref);
 	op->ob_ref = NULL;
 	return 0;
 }
Index: Python/ceval.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Python/ceval.c,v
retrieving revision 2.230
diff -u -r2.230 ceval.c
--- Python/ceval.c	2001/02/16 11:52:31	2.230
+++ Python/ceval.c	2001/03/04 18:04:49
@@ -1670,6 +1670,7 @@
 			w = POP();
 			x = freevars[oparg];
 			PyCell_Set(x, w);
+			Py_DECREF(w);
 			continue;
 
 		case BUILD_TUPLE:


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr.
Date: 2001-03-03 09:34

Message:
Logged In: YES 
user_id=3066

Assigned to Jeremy Hylton.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405583&group_id=5470


From nobody@sourceforge.net  Mon Mar 12 22:01:13 2001
From: nobody@sourceforge.net (nobody)
Date: Mon, 12 Mar 2001 14:01:13 -0800
Subject: [Python-bugs-list] [ python-Bugs-407800 ] global in classdef affect nested scope!?
Message-ID: <E14caNN-0007hI-00@usw-sf-web2.sourceforge.net>

Bugs #407800, was updated on 2001-03-11 18:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407800&group_id=5470

Category: Parser/Compiler
Group: None
Status: Open
Priority: 7
Submitted By: Nobody/Anonymous
Assigned to: Jeremy Hylton
Summary: global in classdef affect nested scope!?

Initial Comment:
[pedroni]
> (II)
> from __future__ import nested_scopes

> x='top'
> def ta():
>     x='ta'
>     class A:
>         global x
>         def tata(self):
>             return x # LOAD_GLOBAL
>     return A
>
> print ta()().tata() # -> 'top'
>
> should not the global decl in class scope be ignored 
and so x be
> bound to x in ta, resulting in 'ta' as output?

[Tim Peters]
Yes, this one is clearly a bug.  Good catch!



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407800&group_id=5470


From nobody@sourceforge.net  Tue Mar 13 01:05:38 2001
From: nobody@sourceforge.net (nobody)
Date: Mon, 12 Mar 2001 17:05:38 -0800
Subject: [Python-bugs-list] [ python-Bugs-408085 ] urllib.py https redirect-302 bug
Message-ID: <E14cdFq-0003pd-00@usw-sf-web3.sourceforge.net>

Bugs #408085, was updated on 2001-03-12 17:05
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408085&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Dustin Boswell
Assigned to: Nobody/Anonymous
Summary: urllib.py https redirect-302 bug

Initial Comment:
Using urllib.urlopen("https://...") seems 
to hang because of a redirect problem. Looks 
like its trying to follow the redirect with 
http not https. 

>>> import urllib 
>>> params = ... 
>>> f = urllib.urlopen("https://...", params) 
connect: (securesite.com, 80) 
#a printout from httplib, line 354 

Traceback (most recent call last): 
File "<stdin>", line 1, in ? 
File "/usr/local/lib/python2.0/urllib.py", line 63, in
urlopen 
return _urlopener.open(url, data) 
File "/usr/local/lib/python2.0/urllib.py", line 168, in
open 
return getattr(self, name)(url, data) 
File "/usr/local/lib/python2.0/urllib.py", line 367, in
open_https 
data) 
File "/usr/local/lib/python2.0/urllib.py", line 301, in
http_error 
result = method(url, fp, errcode, errmsg, headers,
data) 
File "/usr/local/lib/python2.0/urllib.py", line 537, in
http_error_302 
return self.open(newurl, data) 
File "/usr/local/lib/python2.0/urllib.py", line 168, in
open 
return getattr(self, name)(url, data) 
File "/usr/local/lib/python2.0/urllib.py", line 269, in
open_http 
h.putrequest('POST', selector) 
File "/usr/local/lib/python2.0/httplib.py", line 428,
in putrequest 
self.send(str) 
File "/usr/local/lib/python2.0/httplib.py", line 370,
in send 
self.connect() 
File "/usr/local/lib/python2.0/httplib.py", line 354,
in connect 
self.sock.connect((self.host, self.port)) 
KeyboardInterrupt 
>>> 

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408085&group_id=5470


From nobody@sourceforge.net  Tue Mar 13 01:42:36 2001
From: nobody@sourceforge.net (nobody)
Date: Mon, 12 Mar 2001 17:42:36 -0800
Subject: [Python-bugs-list] [ python-Bugs-408098 ] python -i loses __future__
Message-ID: <E14cdpc-0000yQ-00@usw-sf-web2.sourceforge.net>

Bugs #408098, was updated on 2001-03-12 17:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408098&group_id=5470

Category: Parser/Compiler
Group: None
Status: Open
Priority: 5
Submitted By: Jeremy Hylton
Assigned to: Jeremy Hylton
Summary: python -i loses __future__

Initial Comment:
If you run a Python script that has a "from __future__
import nested_scopes" and pass the -i flag, the
interactive interpreter should have the nested_scopes
compiler flag set.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408098&group_id=5470


From nobody@sourceforge.net  Tue Mar 13 01:59:54 2001
From: nobody@sourceforge.net (nobody)
Date: Mon, 12 Mar 2001 17:59:54 -0800
Subject: [Python-bugs-list] [ python-Bugs-405583 ] Objects never freed with nested scopes
Message-ID: <E14ce6M-0007QM-00@usw-sf-web1.sourceforge.net>

Bugs #405583, was updated on 2001-03-02 19:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405583&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Closed
Priority: 7
Submitted By: Atsuo Ishimoto
Assigned to: Jeremy Hylton
Summary: Objects never freed with nested scopes

Initial Comment:
With this code,

from __future__ import nested_scopes
class foo:
    def __del__(self): print "del foo"

def f1():
    x = foo()
    def f2():x
    f2()

for i in range(10000):
    f1()

I see no "del foo" message.


----------------------------------------------------------------------

Comment By: Jeremy Hylton
Date: 2001-03-12 17:59

Message:
Logged In: YES 
user_id=31392

fixed by many small changes:
rev 2.31 of frameobject.c
rev 1.2 of cellobject.c
rev 2.231 of ceval.c


----------------------------------------------------------------------

Comment By: Jeremy Hylton
Date: 2001-03-12 13:58

Message:
Logged In: YES 
user_id=31392

The patch from Martin seems correct, but does not resolve
the bug
report.  There are still no __del__ calls.


----------------------------------------------------------------------

Comment By: Martin v. Löwis
Date: 2001-03-04 10:08

Message:
Logged In: YES 
user_id=21627

I believe there are two missing decrefs: In STORE_DEREF,
PyCell_Set will incref the object, so the object POPped from
the stack must be decref'ed. In addition, GC requires that
the clear procedure not only sets the pointers to zero, but
actually decrefs the objects (i.e. breaks the cycle). A
patch is included below

Index: Objects/cellobject.c
===================================================================
RCS file:
/cvsroot/python/python/dist/src/Objects/cellobject.c,v
retrieving revision 1.1
diff -u -r1.1 cellobject.c
--- Objects/cellobject.c	2001/01/25 20:04:14	1.1
+++ Objects/cellobject.c	2001/03/04 18:04:45
@@ -83,6 +83,7 @@
 static int
 cell_clear(PyCellObject *op)
 {
+	Py_XDECREF(op->ob_ref);
 	op->ob_ref = NULL;
 	return 0;
 }
Index: Python/ceval.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Python/ceval.c,v
retrieving revision 2.230
diff -u -r2.230 ceval.c
--- Python/ceval.c	2001/02/16 11:52:31	2.230
+++ Python/ceval.c	2001/03/04 18:04:49
@@ -1670,6 +1670,7 @@
 			w = POP();
 			x = freevars[oparg];
 			PyCell_Set(x, w);
+			Py_DECREF(w);
 			continue;
 
 		case BUILD_TUPLE:


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr.
Date: 2001-03-03 09:34

Message:
Logged In: YES 
user_id=3066

Assigned to Jeremy Hylton.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405583&group_id=5470


From nobody@sourceforge.net  Tue Mar 13 09:59:54 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 13 Mar 2001 01:59:54 -0800
Subject: [Python-bugs-list] [ python-Bugs-407300 ] Win32: pydoc command isn't executable
Message-ID: <E14clas-0004kR-00@usw-sf-web2.sourceforge.net>

Bugs #407300, was updated on 2001-03-09 05:45
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407300&group_id=5470

Category: Windows
Group: Platform-specific
Status: Closed
Priority: 5
Submitted By: Paul Moore
Assigned to: Tim Peters
Summary: Win32: pydoc command isn't executable

Initial Comment:
The Python 2.1b1 binary installer for Windows supplies 
a small "pydoc" script in the main Python executable 
directory. However, this script is Unix-specific and 
does not work on Windows.

Suggestion: for Windows, include a trivial pydoc.bat 
file to start pydoc. The following one-liner works:

--- pydoc.bat ---
@python -c "import pydoc; pydoc.cli()" %*
-----------------

The only problem with this version is that it uses the 
version of python.exe found on PATH, rather than the 
version in the directory containing pydoc.bat. 
However, as the Unix script has the same issue, this 
can be viewed as a "feature"...

----------------------------------------------------------------------

Comment By: Paul Moore
Date: 2001-03-13 01:59

Message:
Logged In: YES 
user_id=113328

Using a pyw file doesn't work, as that stops the usage
   pydoc <module>
which should display documentation in the console window.

Also, .py[w] files aren't executable without an extension. 
For example, you'd have to type pydoc.pyw, not just pydoc.

Instead of %*, use %1 %2 %3 %4 %5 %6 %7 %8 %9. And to avoid 
python.exe if there are no args (when the Tk stuff is used) 
how about

@echo off
if "%1"=="" pythonw -c "import pydoc; pydoc.cli()"
if NOT "%1"=="" python -c "import pydoc; pydoc.cli()" %1 %2 
%3 %4 %5 %6 %7 %8 %9

That should work on 9x and NT/2000. I repeat the test for 
simplicity. You could use GOTO and labels, instead...


----------------------------------------------------------------------

Comment By: Tim Peters
Date: 2001-03-10 23:42

Message:
Logged In: YES 
user_id=31435

"%*" doesn't work under Win9X.

Changed the installer to name the file pydoc.pyw instead.

Note that the Windows installer also creates an entry for 
pydoc under Start -> Programs -> Python -> Module Docs.

Note too that due to Tk problems, we can't encourage using 
python instead of pythonw to run pydoc (Tk apps have an 
unfortunate tendency to wedge Windows when run via python; 
see other SF bugs for more on that).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407300&group_id=5470


From nobody@sourceforge.net  Tue Mar 13 10:38:41 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 13 Mar 2001 02:38:41 -0800
Subject: [Python-bugs-list] [ python-Bugs-408173 ] re.py comments refer to old versions
Message-ID: <E14cmCP-0007p2-00@usw-sf-web3.sourceforge.net>

Bugs #408173, was updated on 2001-03-13 02:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408173&group_id=5470

Category: Regular Expressions
Group: None
Status: Open
Priority: 5
Submitted By: Rob W.W. Hooft
Assigned to: Nobody/Anonymous
Summary: re.py comments refer to old versions

Initial Comment:
re.py comments say that "this is for 2.0b1" and "this
will be removed in version 2.0".

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408173&group_id=5470


From nobody@sourceforge.net  Tue Mar 13 18:14:50 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 13 Mar 2001 10:14:50 -0800
Subject: [Python-bugs-list] [ python-Bugs-408271 ] crash in shelve module
Message-ID: <E14ctJq-0001eD-00@usw-sf-web1.sourceforge.net>

Bugs #408271, was updated on 2001-03-13 10:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408271&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Nobody/Anonymous
Summary: crash in shelve module

Initial Comment:
While using shelve module on SGI
sloth 271> uname -a
IRIX64 sloth 6.5 04191225 IP27

my python program crashes and
I am getting following error message:

  File "/usr/local/lib/python1.5/shelve.py", line 71,
in __setitem__
    self.dict[key] = f.getvalue()
bsddb.error: (0, 'Error')

At the time the size of the "shelve" file was quite big
(maybe this is a problem ?)
sloth 267> ls -lt *shelve
-rw-r--r--    1 ryszard  cdiApps   85778432 Mar 13
12:27 recap_mddr.shelve


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408271&group_id=5470


From nobody@sourceforge.net  Tue Mar 13 20:00:13 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 13 Mar 2001 12:00:13 -0800
Subject: [Python-bugs-list] [ python-Bugs-408308 ] UserList.py bug in getslice, *add, mul
Message-ID: <E14cuxp-0004Sv-00@usw-sf-web3.sourceforge.net>

Bugs #408308, was updated on 2001-03-13 12:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408308&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Daniel Haertle
Assigned to: Nobody/Anonymous
Summary: UserList.py bug in getslice, *add, mul 

Initial Comment:
if one explitely initializes UserList in a class derived 
form Userlist, __getslice__, __*add__ and __mul__ do not 
work.

Consider the following code:

>>> import UserList
>>> class UL(UserList.UserList):
...    def __init__(self):
...       UserList.UserList.__init__(self)
... 
>>> ul=UL()
>>> ul.append(0); ul.append(1)
>>> ul[0:2]
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "hd e18 yosi:programs:programing:python 
2.0c1:lib:UserList.py", line 27, in __getslice__
    return self.__class__(self.data[i:j])
TypeError: too many arguments; expected 1, got 2


A possible solution is to change UserList.py from

    def __getslice__(self, i, j):
        i = max(i, 0); j = max(j, 0)
        return self.__class__(self.data[i:j])

to

    def __getslice__(self, i, j):
        i = max(i, 0); j = max(j, 0)
        return self.data[i:j]

and the other methods accordingly. If for some reasons 
this is not possible, consider the code in Python1.5.2 
where __getslice__ works (but __*add__ and __mul__ 
don't)


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408308&group_id=5470


From nobody@sourceforge.net  Wed Mar 14 08:57:16 2001
From: nobody@sourceforge.net (nobody)
Date: Wed, 14 Mar 2001 00:57:16 -0800
Subject: [Python-bugs-list] [ python-Bugs-407300 ] Win32: pydoc command isn't executable
Message-ID: <E14d75o-0001oE-00@usw-sf-web3.sourceforge.net>

Bugs #407300, was updated on 2001-03-09 05:45
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407300&group_id=5470

Category: Windows
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Paul Moore
Assigned to: Tim Peters
Summary: Win32: pydoc command isn't executable

Initial Comment:
The Python 2.1b1 binary installer for Windows supplies 
a small "pydoc" script in the main Python executable 
directory. However, this script is Unix-specific and 
does not work on Windows.

Suggestion: for Windows, include a trivial pydoc.bat 
file to start pydoc. The following one-liner works:

--- pydoc.bat ---
@python -c "import pydoc; pydoc.cli()" %*
-----------------

The only problem with this version is that it uses the 
version of python.exe found on PATH, rather than the 
version in the directory containing pydoc.bat. 
However, as the Unix script has the same issue, this 
can be viewed as a "feature"...

----------------------------------------------------------------------

Comment By: Paul Moore
Date: 2001-03-13 01:59

Message:
Logged In: YES 
user_id=113328

Using a pyw file doesn't work, as that stops the usage
   pydoc <module>
which should display documentation in the console window.

Also, .py[w] files aren't executable without an extension. 
For example, you'd have to type pydoc.pyw, not just pydoc.

Instead of %*, use %1 %2 %3 %4 %5 %6 %7 %8 %9. And to avoid 
python.exe if there are no args (when the Tk stuff is used) 
how about

@echo off
if "%1"=="" pythonw -c "import pydoc; pydoc.cli()"
if NOT "%1"=="" python -c "import pydoc; pydoc.cli()" %1 %2 
%3 %4 %5 %6 %7 %8 %9

That should work on 9x and NT/2000. I repeat the test for 
simplicity. You could use GOTO and labels, instead...


----------------------------------------------------------------------

Comment By: Tim Peters
Date: 2001-03-10 23:42

Message:
Logged In: YES 
user_id=31435

"%*" doesn't work under Win9X.

Changed the installer to name the file pydoc.pyw instead.

Note that the Windows installer also creates an entry for 
pydoc under Start -> Programs -> Python -> Module Docs.

Note too that due to Tk problems, we can't encourage using 
python instead of pythonw to run pydoc (Tk apps have an 
unfortunate tendency to wedge Windows when run via python; 
see other SF bugs for more on that).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407300&group_id=5470


From noreply@sourceforge.net  Thu Mar 15 13:11:14 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Mar 2001 05:11:14 -0800
Subject: [Python-bugs-list] [ python-Bugs-408767 ] pydoc-file url
Message-ID: <E14dXX8-0006Ns-00@usw-sf-web1.sourceforge.net>

Bugs item #408767, was updated on 2001-03-15 05:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408767&group_id=5470

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: pydoc-file url

Initial Comment:
When pydoc generates pages on NT, it has a link to the file at the top right corner. This should use 
url  "file://x:/x.py" instead of "file:x:/x.py" note the two slashes after file://

This will ensure that it works with netscape as well as internet explorer. 

Regards and thanks
Santosh Kharolkar

santosh.kharolkar@ubs.com

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408767&group_id=5470


From noreply@sourceforge.net  Thu Mar 15 15:10:45 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Mar 2001 07:10:45 -0800
Subject: [Python-bugs-list] [ python-Bugs-408798 ] 5.5 bisect documentation
Message-ID: <E14dZOn-0007us-00@usw-sf-web1.sourceforge.net>

Bugs item #408798, was updated on 2001-03-15 07:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408798&group_id=5470

Category: Documentation
Group: None
Status: Open
Priority: 5
Submitted By: Greg Kochanski (gpk)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: 5.5 bisect documentation

Initial Comment:
The documentation should note that if
item compares equal to list[i], it will
return i+1.  More generally, it returns
the index of the first element that compares
greater than item, or len(list) if item is larger
than everything in list.
This means that insort() sorts with minimal
rearrangement: if two items compare equal,
they will be on the list in the order with which
they were added.   This can be relevant for
classes which define a __cmp__() method.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408798&group_id=5470


From noreply@sourceforge.net  Thu Mar 15 16:27:46 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Mar 2001 08:27:46 -0800
Subject: [Python-bugs-list] [ python-Bugs-408820 ] 'install -d' fails on BSDI systems.
Message-ID: <E14dabK-0006ab-00@usw-sf-web3.sourceforge.net>

Bugs item #408820, was updated on 2001-03-15 08:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408820&group_id=5470

Category: Installation
Group: Platform-specific
Status: Open
Priority: 6
Submitted By: Thomas Wouters (twouters)
Assigned to: Nobody/Anonymous (nobody)
Summary: 'install -d' fails on BSDI systems.

Initial Comment:
Apparently the Makefile was changed to use 'install -d'
to create directories. This does not work on BSDI. It
seems to be an autoconf failure (since configure.in
just contains 'AC_PROG_INSTALL' but I haven't
experienced this before, with other software or with
Python.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408820&group_id=5470


From noreply@sourceforge.net  Thu Mar 15 19:31:40 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Mar 2001 11:31:40 -0800
Subject: [Python-bugs-list] [ python-Bugs-408884 ] File not closed
Message-ID: <E14ddTI-0007lV-00@usw-sf-web2.sourceforge.net>

Bugs item #408884, was updated on 2001-03-15 11:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408884&group_id=5470

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Charles Hixson (quixo)
Assigned to: Nobody/Anonymous (nobody)
Summary: File not closed

Initial Comment:
Python 2.1a2 (#10, Feb 2 2001, 16:01:03) [MSC 32 bit
(Intel)] on win32

OS Win95 4.00.950 B

In IDLE 0.6 I execute a script that is intended to
create a file.  An indexing error occurs (I used a
paren instead of a square bracket to access a
dictionary).  The program aborts:
Traceback (most recent call last):
  File "C:\Docs\TIP html\tipRec2Html.py", line 509, in ?
    test()
  File "C:\Docs\TIP html\tipRec2Html.py", line 439, in test
    laTitle = leadAgencies(leadAgncy)
TypeError: object is not callable: {'sonco': 'Son Co
Transit', 'santro ....

Rerunning the program yields:

Traceback (most recent call last):
  File "C:\Docs\TIP html\tipRec2Html.py", line 509, in ?
    test()
  File "C:\Docs\TIP html\tipRec2Html.py", line 415, in test
    os.unlink(here + '\html\' + fl)
OSError: [Errno 13] Permission denied: 'C:\Docs\TIP
html\html\hson.htm'

This is the file that was being created when the prior
error occured.  It appears that the file hasn't been
released.  This can be worked around by quitting IDLE
and re-executing it.

If you look at the code you'll probably see that I'm
new to Python.  I made some obvious silly decisions,
just to keep the code easier to think about.  The html1
file mainly declares a couple of methods for writing
out descriptions of HTML table cells, either with or
without titles.  (Sorry there was only room to include
one file... if I'd thought ahead I would have zipped them.)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408884&group_id=5470


From noreply@sourceforge.net  Thu Mar 15 21:59:22 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Mar 2001 13:59:22 -0800
Subject: [Python-bugs-list] [ python-Bugs-408936 ] Python2.0 re module: greedy regexp bug 2
Message-ID: <E14dfmE-0000gn-00@usw-sf-web2.sourceforge.net>

Bugs item #408936, was updated on 2001-03-15 13:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408936&group_id=5470

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Bastian Kleineidam (calvin)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python2.0 re module: greedy regexp bug 2

Initial Comment:
Yeah, try this:
re.search(r"<!--.*?--\s*>", "<!--- bla --->")
and it does not match, but it should match, no?
In more complicated examples I even get infinite
recursion,
if youre interested, I will make a script for this.

The above example should be in the Regression Test
Suite.

Look also at [ #405358 ] Python2.0 re module: greedy
regexp bug,
perhaps this is somehow related? I dont know.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408936&group_id=5470


From noreply@sourceforge.net  Thu Mar 15 23:13:43 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Mar 2001 15:13:43 -0800
Subject: [Python-bugs-list] [ python-Bugs-408958 ] pydoc fails on exceptions.html (win2K)
Message-ID: <E14dgwB-0001Fj-00@usw-sf-web2.sourceforge.net>

Bugs item #408958, was updated on 2001-03-15 15:13
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408958&group_id=5470

Category: Python Library
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Hernan Martinez Foffani (hfoffani)
Assigned to: Nobody/Anonymous (nobody)
Summary: pydoc fails on exceptions.html (win2K)

Initial Comment:
Pydoc fails to show exceptions.html
Windows 2000, python 2.1b1
(FYI, I've got python 2.0 installed on the same 
machine)


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408958&group_id=5470


From noreply@sourceforge.net  Thu Mar 15 23:13:51 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Mar 2001 15:13:51 -0800
Subject: [Python-bugs-list] [ python-Bugs-408959 ] pydoc fails on exceptions.html (win2K)
Message-ID: <E14dgwJ-0005Pu-00@usw-sf-web1.sourceforge.net>

Bugs item #408959, was updated on 2001-03-15 15:13
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408959&group_id=5470

Category: Python Library
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: pydoc fails on exceptions.html (win2K)

Initial Comment:
Pydoc fails to show exceptions.html
Windows 2000, python 2.1b1
(FYI, I've got python 2.0 installed on the same 
machine)


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408959&group_id=5470


From noreply@sourceforge.net  Fri Mar 16 06:46:02 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Mar 2001 22:46:02 -0800
Subject: [Python-bugs-list] [ python-Bugs-408798 ] 5.5 bisect documentation
Message-ID: <E14dnzu-0004xx-00@usw-sf-web3.sourceforge.net>

Bugs item #408798, was updated on 2001-03-15 07:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408798&group_id=5470

Category: Documentation
Group: None
Status: Open
Priority: 5
Submitted By: Greg Kochanski (gpk)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: 5.5 bisect documentation

Initial Comment:
The documentation should note that if
item compares equal to list[i], it will
return i+1.  More generally, it returns
the index of the first element that compares
greater than item, or len(list) if item is larger
than everything in list.
This means that insort() sorts with minimal
rearrangement: if two items compare equal,
they will be on the list in the order with which
they were added.   This can be relevant for
classes which define a __cmp__() method.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-03-15 22:46

Message:
Logged In: YES 
user_id=31435

Note that the 2.1 docs already say this -- you can close 
this, Fred.

Greg, 2.1 also adds bisect_left and insort_left functions 
to bisect, in case you want the insertion point to be "to 
the left" of any pre-existing equal items instead.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408798&group_id=5470


From noreply@sourceforge.net  Fri Mar 16 10:27:07 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Mar 2001 02:27:07 -0800
Subject: [Python-bugs-list] [ python-Bugs-408958 ] pydoc fails on exceptions.html (win2K)
Message-ID: <E14drRr-0006MG-00@usw-sf-web2.sourceforge.net>

Bugs item #408958, was updated on 2001-03-15 15:13
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408958&group_id=5470

Category: Python Library
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Hernan Martinez Foffani (hfoffani)
Assigned to: Nobody/Anonymous (nobody)
Summary: pydoc fails on exceptions.html (win2K)

Initial Comment:
Pydoc fails to show exceptions.html
Windows 2000, python 2.1b1
(FYI, I've got python 2.0 installed on the same 
machine)


----------------------------------------------------------------------

>Comment By: Hernan Martinez Foffani (hfoffani)
Date: 2001-03-16 02:27

Message:
Logged In: YES 
user_id=112690

Aditional Info:
Windows 2000 and IE 5.5 SP1 both Spanish version.

IExplorer error is "Can't find server or DNS error"
(translated by me)

(sorry for the 2nd bug report, but sourceforge keeps 
fighting me)



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408958&group_id=5470


From noreply@sourceforge.net  Fri Mar 16 17:47:53 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Mar 2001 09:47:53 -0800
Subject: [Python-bugs-list] [ python-Bugs-408936 ] Python2.0 re module: greedy regexp bug 2
Message-ID: <E14dyKP-0001v1-00@usw-sf-web2.sourceforge.net>

Bugs item #408936, was updated on 2001-03-15 13:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408936&group_id=5470

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Bastian Kleineidam (calvin)
>Assigned to: Fredrik Lundh (effbot)
Summary: Python2.0 re module: greedy regexp bug 2

Initial Comment:
Yeah, try this:
re.search(r"<!--.*?--\s*>", "<!--- bla --->")
and it does not match, but it should match, no?
In more complicated examples I even get infinite
recursion,
if youre interested, I will make a script for this.

The above example should be in the Regression Test
Suite.

Look also at [ #405358 ] Python2.0 re module: greedy
regexp bug,
perhaps this is somehow related? I dont know.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408936&group_id=5470


From noreply@sourceforge.net  Fri Mar 16 17:48:18 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Mar 2001 09:48:18 -0800
Subject: [Python-bugs-list] [ python-Bugs-408958 ] pydoc fails on exceptions.html (win2K)
Message-ID: <E14dyKo-0001vI-00@usw-sf-web2.sourceforge.net>

Bugs item #408958, was updated on 2001-03-15 15:13
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408958&group_id=5470

Category: Python Library
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Hernan Martinez Foffani (hfoffani)
>Assigned to: Ka-Ping Yee (ping)
Summary: pydoc fails on exceptions.html (win2K)

Initial Comment:
Pydoc fails to show exceptions.html
Windows 2000, python 2.1b1
(FYI, I've got python 2.0 installed on the same 
machine)


----------------------------------------------------------------------

Comment By: Hernan Martinez Foffani (hfoffani)
Date: 2001-03-16 02:27

Message:
Logged In: YES 
user_id=112690

Aditional Info:
Windows 2000 and IE 5.5 SP1 both Spanish version.

IExplorer error is "Can't find server or DNS error"
(translated by me)

(sorry for the 2nd bug report, but sourceforge keeps 
fighting me)



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408958&group_id=5470


From noreply@sourceforge.net  Fri Mar 16 17:48:38 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Mar 2001 09:48:38 -0800
Subject: [Python-bugs-list] [ python-Bugs-408959 ] pydoc fails on exceptions.html (win2K)
Message-ID: <E14dyL8-0001vX-00@usw-sf-web2.sourceforge.net>

Bugs item #408959, was updated on 2001-03-15 15:13
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408959&group_id=5470

Category: Python Library
Group: Platform-specific
>Status: Deleted
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: pydoc fails on exceptions.html (win2K)

Initial Comment:
Pydoc fails to show exceptions.html
Windows 2000, python 2.1b1
(FYI, I've got python 2.0 installed on the same 
machine)


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408959&group_id=5470


From noreply@sourceforge.net  Fri Mar 16 17:48:50 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Mar 2001 09:48:50 -0800
Subject: [Python-bugs-list] [ python-Bugs-408767 ] pydoc-file url
Message-ID: <E14dyLK-0001vp-00@usw-sf-web2.sourceforge.net>

Bugs item #408767, was updated on 2001-03-15 05:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408767&group_id=5470

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Ka-Ping Yee (ping)
Summary: pydoc-file url

Initial Comment:
When pydoc generates pages on NT, it has a link to the file at the top right corner. This should use 
url  "file://x:/x.py" instead of "file:x:/x.py" note the two slashes after file://

This will ensure that it works with netscape as well as internet explorer. 

Regards and thanks
Santosh Kharolkar

santosh.kharolkar@ubs.com

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408767&group_id=5470


From noreply@sourceforge.net  Fri Mar 16 17:49:50 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Mar 2001 09:49:50 -0800
Subject: [Python-bugs-list] [ python-Bugs-406867 ] nested list comprehensions crash
Message-ID: <E14dyMI-0001wb-00@usw-sf-web2.sourceforge.net>

Bugs item #406867, was updated on 2001-03-07 16:30
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406867&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Deleted
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: nested list comprehensions crash

Initial Comment:
Using 2.1b1 on Win98, the following crashes:

[[i for i in [0]] for j in [0]]

with message:

  Runtime error!
  Program: C:\PYTHON20A2\PYTHONW.EXE
  abnormal program termination

2.0 is ok,
2.1a2 crashes too



----------------------------------------------------------------------

Comment By: Willem Broekema (willemb)
Date: 2001-03-07 18:07

Message:
Logged In: YES 
user_id=158280

reloading the page by resubmitting the form is no good idea either. i'd better go to bed now and don't mess 
this system any further ;-)

----------------------------------------------------------------------

Comment By: Willem Broekema (willemb)
Date: 2001-03-07 18:01

Message:
Logged In: YES 
user_id=158280

This is a duplicate of #406049.
Sorry to waste your time.

----------------------------------------------------------------------

Comment By: Willem Broekema (willemb)
Date: 2001-03-07 17:23

Message:
Logged In: YES 
user_id=158280

This is a duplicate of #406049.
Sorry to waste your time.

----------------------------------------------------------------------

Comment By: Willem Broekema (willemb)
Date: 2001-03-07 17:07

Message:
Logged In: YES 
user_id=158280

This is a duplicate of #406049.
Sorry to waste your time.

----------------------------------------------------------------------

Comment By: Willem Broekema (willemb)
Date: 2001-03-07 16:49

Message:
Logged In: YES 
user_id=158280

This is a duplicate of #406049.
Sorry to waste your time.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406867&group_id=5470


From noreply@sourceforge.net  Fri Mar 16 17:50:16 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Mar 2001 09:50:16 -0800
Subject: [Python-bugs-list] [ python-Bugs-406792 ] python2.1b1 core dumps --with-pymalloc
Message-ID: <E14dyMi-0001x3-00@usw-sf-web2.sourceforge.net>

Bugs item #406792, was updated on 2001-03-07 11:08
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406792&group_id=5470

Category: Python Interpreter Core
Group: Platform-specific
Status: Open
>Priority: 6
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: python2.1b1 core dumps --with-pymalloc 

Initial Comment:
% ./configure --without-threads --with-pymalloc
% gmake
...

./python setup.py
...
Then it dumps core. Removing the  --with-pymalloc and
it runs just fine.
[281] % uname -a
HP-UX wssgped B.10.20 A 9000/782 2001125167 two-user
license
[282] % gcc --version
2.95.1


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406792&group_id=5470


From noreply@sourceforge.net  Fri Mar 16 17:50:31 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Mar 2001 09:50:31 -0800
Subject: [Python-bugs-list] [ python-Bugs-406815 ] python2.1b re bug (.*)?
Message-ID: <E14dyMx-0001xI-00@usw-sf-web2.sourceforge.net>

Bugs item #406815, was updated on 2001-03-07 12:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406815&group_id=5470

Category: Regular Expressions
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Fredrik Lundh (effbot)
Summary: python2.1b re bug (.*)?

Initial Comment:
The script below works per expectation with python1.5.
It fails with python2.1b1

% python2.1 gar 
Traceback (most recent call last):
  File "gar", line 9, in ?
    mob = re.search("== Parameters ==\n(.*)?\s*$",
output, re.S)
  File "/usr/local/lib/python2.1/sre.py", line 55, in
search
    return _compile(pattern, flags).search(string)
  File "/usr/local/lib/python2.1/sre.py", line 131, in
_compile
    raise error, v # invalid expression
sre_constants.error: nothing to repeat

Move "?" inside the parens and it works. Replace the
"*" with a "+" and it works (at least for this example
input).

import re

output = """
Using 
== Parameters ==
line1
line2
"""
mob = re.search("== Parameters ==\n(.*)?\s*$", output,
re.S)
print mob.groups()



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406815&group_id=5470


From noreply@sourceforge.net  Fri Mar 16 17:51:09 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Mar 2001 09:51:09 -0800
Subject: [Python-bugs-list] [ python-Bugs-406049 ] crash on nested listcomps
Message-ID: <E14dyNZ-0001xw-00@usw-sf-web2.sourceforge.net>

Bugs item #406049, was updated on 2001-03-05 08:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406049&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
>Priority: 7
Submitted By: David Goodger (goodger)
>Assigned to: Jeremy Hylton (jhylton)
Summary: crash on nested listcomps

Initial Comment:
(if you need to contact me: dgoodger@atsautomation.com)

I got an aborted interpreter under both QNX 4.25 and 
Windows NT 4.0:

Python 2.1b1 (#2, Mar 05 2001, 11:19:23) [C] on qnxJ
Type "copyright", "credits" or "license" for more 
information.
>>> l=[[[0,0,0] for i in range(3)] for j in range(3)]
Fatal Python error: unknown scope for _[2] in ?(0) in 
<stdin>
symbols: {'i': 2, 'l': 2, 'j': 2, 'range': 8, '_[1]': 
2}
locals: {'l': 1, 'j': 2, '_[1]': 3, 'i': 0}
globals: {'range': 1}

%1 - 32637 Abort                python


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2001-03-05 10:36

Message:
Logged In: YES 
user_id=6656

tee hee.  fun one.

see patch #406076 for a fix & test case.  not sure the fix
is exactly what's wanted though.  the problem is that
--st->st_tmpname is called before symtable_node is called on
the first node in the listcomp. this patch gets rid of the
decrement and resets st_tmpname in symtable_enter_scope.

and doesn't pass make test.  hang on...

I want to rewrite Python/compile.c in OCaml one of these days...

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406049&group_id=5470


From noreply@sourceforge.net  Fri Mar 16 17:51:48 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Mar 2001 09:51:48 -0800
Subject: [Python-bugs-list] [ python-Bugs-407180 ] proposal: allow years before 1900
Message-ID: <E14dyOC-0001yE-00@usw-sf-web2.sourceforge.net>

Bugs item #407180, was updated on 2001-03-08 13:55
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407180&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
>Priority: 4
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: proposal: allow years before 1900

Initial Comment:
Handling of years before 1900: proposed change for 
python 1.5.2-2.1

from http://www.python.org/doc/current/lib/module-
time.html:

>Values 100-1899 are always
>illegal. Note that this is new as of Python 1.5.2
(a2); earlier
>versions, up to Python 1.5.1 and 1.5.2a1, would add 
1900 to year
>values below 1900.

Wouldn't the correct behaviour be just to store years 
before 1900 into
tm_year as any other year in timemodule.c gettmarg()?  
They get stored
as negative values, but there shouldn't be any 
problems with that,
judging from glibc 2.2 behaviour, documentation for 
other libc's, and
the following quote from 
http://www.platinum.com/products/wp/wp_epmdt.htm:

"While tm_year is based on 1900, the full range of 
positive and
negative values are allowed. For 32-bit integers this 
allows for dates
from 2147481748 BCE to 2147485548 CE. "


Proposed patch for python 1.5.2:

*** timemodule.c.origi  Tue Apr  6 00:54:14 1999
--- timemodule.c        Thu Mar  8 23:32:55 2001
***************
*** 345,355 ****
                        y += 1900;
                else if (0 <= y && y <= 68)
                        y += 2000;
-               else {
-                       PyErr_SetString
(PyExc_ValueError,
-                                       "year out of 
range (00-99, 1900-*)");
-                       return 0;
-               }
        }
        p->tm_year = y - 1900;
        p->tm_mon--;
--- 345,350 ----



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407180&group_id=5470


From noreply@sourceforge.net  Fri Mar 16 17:52:03 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Mar 2001 09:52:03 -0800
Subject: [Python-bugs-list] [ python-Bugs-405554 ] pydoc should be integrated with HTML doc
Message-ID: <E14dyOR-0001yM-00@usw-sf-web2.sourceforge.net>

Bugs item #405554, was updated on 2001-03-02 15:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405554&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
>Assigned to: Ka-Ping Yee (ping)
Summary: pydoc should be integrated with HTML doc

Initial Comment:
I really like pydoc, but it misses one feature compared
to perldoc: often the *good* documentation for a module
or class is in the library reference manual.  There
should be a way to get that integrated with the stuff
that pydoc extracts from the doc strings. 

(Wasn't this Paul Prescod's original idea?)


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405554&group_id=5470


From noreply@sourceforge.net  Fri Mar 16 17:52:49 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Mar 2001 09:52:49 -0800
Subject: [Python-bugs-list] [ python-Bugs-405999 ] getopt: extra args behavior wrong
Message-ID: <E14dyPB-0001yp-00@usw-sf-web2.sourceforge.net>

Bugs item #405999, was updated on 2001-03-05 03:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405999&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Gregor Hoffleit (flight)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: getopt: extra args behavior wrong

Initial Comment:
[Forwarded from the Debian bug tracking system,
Bug#87722]
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=87722&repeatmerged=yes

Sender: Wichert Akkerman <wichert@cistron.nl>

getopt claims to behave just like GNU getopt, but it
does not. If I use
this code snippet:

------------------------------------------------------------------------------
(opt,args) = getopt.getopt(sys.argv[1:], 'ab')

print "Options decoded: " + string.join(map(lambda x:
x[0], opt), ', ')
print "Extra arguments: " +  string.join(args, ', ')
------------------------------------------------------------------------------

Then this result is correct:

[fog;/tmp]-26> ./x.py -a -b bla
Options decoded: -a, -b
Extra arguments: bla

But this is wrong:

[fog;/tmp]-27> ./x.py -a bla -b 
Options decoded: -a
Extra arguments: bla, -b

That should give the exact same result, but doesn't.
The problem seems
to be that the while loop used to iterate over the
arguments aborts
at the first non-option argument, while it should
continue to check
all arguments for possible options.

This problem persist in python2-base.

Wichert.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405999&group_id=5470


From noreply@sourceforge.net  Fri Mar 16 17:53:19 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Mar 2001 09:53:19 -0800
Subject: [Python-bugs-list] [ python-Bugs-407915 ] largefile support under Linux
Message-ID: <E14dyPf-0001z5-00@usw-sf-web2.sourceforge.net>

Bugs item #407915, was updated on 2001-03-12 06:43
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407915&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Hans-Joachim Widmaier (hjwidmai)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: largefile support under Linux

Initial Comment:
While trying to build 2.1b1 with support for large
files under Linux (2.4, glibc 2.2),
Objects/fileobject.c didn't compile:

gcc -D_FILE_OFFSET_BITS=64 -c -g -O2 -Wall
-Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H  -o
Objects/fileobject.o Objects/fileobject.c
Objects/fileobject.c: In function `_portable_ftell':
Objects/fileobject.c:267: incompatible types in return
Objects/fileobject.c:275: warning: control reaches end
of non-void function

This is because fpos_t is a structure holding 2 long
longs. After changing

    return pos
to
    return pos.__pos

I got it to compile and it seems to work ok.
This is, of course, not a portable solution.

Alas, I don't really understand why there are 3 Methods
of getting largefile support (/usr/include/feature.h)
in glibc, even less why I'm bothered with defining
CFLAGS to get it; but configure seems unable to figure
out that itself. But this is not Python's fault.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407915&group_id=5470


From noreply@sourceforge.net  Fri Mar 16 17:54:44 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Mar 2001 09:54:44 -0800
Subject: [Python-bugs-list] [ python-Bugs-408173 ] re.py comments refer to old versions
Message-ID: <E14dyR2-0001zi-00@usw-sf-web2.sourceforge.net>

Bugs item #408173, was updated on 2001-03-13 02:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408173&group_id=5470

Category: Regular Expressions
Group: None
Status: Open
Priority: 5
Submitted By: Rob W.W. Hooft (hooft)
>Assigned to: Fredrik Lundh (effbot)
Summary: re.py comments refer to old versions

Initial Comment:
re.py comments say that "this is for 2.0b1" and "this
will be removed in version 2.0".

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408173&group_id=5470


From noreply@sourceforge.net  Fri Mar 16 18:00:17 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Mar 2001 10:00:17 -0800
Subject: [Python-bugs-list] [ python-Bugs-408308 ] UserList.py bug in getslice, *add, mul
Message-ID: <E14dyWP-000245-00@usw-sf-web2.sourceforge.net>

Bugs item #408308, was updated on 2001-03-13 12:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408308&group_id=5470

Category: Python Library
Group: None
>Status: Closed
Priority: 5
Submitted By: Daniel Haertle (dhaertle)
>Assigned to: Jeremy Hylton (jhylton)
Summary: UserList.py bug in getslice, *add, mul 

Initial Comment:
if one explitely initializes UserList in a class derived 
form Userlist, __getslice__, __*add__ and __mul__ do not 
work.

Consider the following code:

>>> import UserList
>>> class UL(UserList.UserList):
...    def __init__(self):
...       UserList.UserList.__init__(self)
... 
>>> ul=UL()
>>> ul.append(0); ul.append(1)
>>> ul[0:2]
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "hd e18 yosi:programs:programing:python 
2.0c1:lib:UserList.py", line 27, in __getslice__
    return self.__class__(self.data[i:j])
TypeError: too many arguments; expected 1, got 2


A possible solution is to change UserList.py from

    def __getslice__(self, i, j):
        i = max(i, 0); j = max(j, 0)
        return self.__class__(self.data[i:j])

to

    def __getslice__(self, i, j):
        i = max(i, 0); j = max(j, 0)
        return self.data[i:j]

and the other methods accordingly. If for some reasons 
this is not possible, consider the code in Python1.5.2 
where __getslice__ works (but __*add__ and __mul__ 
don't)


----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-03-16 10:00

Message:
Logged In: YES 
user_id=31392

The subclass you've created -- UL -- is broken.  A subclass
of 
UserList should included an __init__ that supports an
initial list.  The definition of __getslice__ is correct,
because operations on
a UserList should return a UserList -- not a real list.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408308&group_id=5470


From noreply@sourceforge.net  Fri Mar 16 18:02:59 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Mar 2001 10:02:59 -0800
Subject: [Python-bugs-list] [ python-Bugs-407019 ] Python-2.1 does not compile under cygwin
Message-ID: <E14dyZ1-00025t-00@usw-sf-web2.sourceforge.net>

Bugs item #407019, was updated on 2001-03-08 06:02
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407019&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Tim Peters (tim_one)
Summary: Python-2.1 does not compile under cygwin

Initial Comment:
configure runs well.

I use:
> g++ --version
2.95.2

Errors are occuring in tokenizer.c. the pointer-variable new seems to be misinterpreted. After 
renaming it to newptr in line 192 ans subsequent lines, tokenizer.c.

The next errors occure in Parser/myreadline.c:

Parser/myreadline.c: In function `char * PyOS_StdioReadline(char *)':
Parser/myreadline.c:62: ANSI C++ forbids implicit conversion from `void *' in as
signment
Parser/myreadline.c:99: ANSI C++ forbids implicit conversion from `void *' in as
signment
Parser/myreadline.c:109: ANSI C++ forbids implicit conversion from `void *' in r
eturn
make: *** [Parser/myreadline.o] Error 1



----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-03-16 10:02

Message:
Logged In: YES 
user_id=31392

cygwin ends with "win." right, tim?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407019&group_id=5470


From noreply@sourceforge.net  Fri Mar 16 18:03:23 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Mar 2001 10:03:23 -0800
Subject: [Python-bugs-list] [ python-Bugs-408085 ] urllib.py https redirect-302 bug
Message-ID: <E14dyZP-000262-00@usw-sf-web2.sourceforge.net>

Bugs item #408085, was updated on 2001-03-12 17:05
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408085&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Dustin Boswell (boswell)
>Assigned to: Moshe Zadka (moshez)
Summary: urllib.py https redirect-302 bug

Initial Comment:
Using urllib.urlopen("https://...") seems 
to hang because of a redirect problem. Looks 
like its trying to follow the redirect with 
http not https. 

>>> import urllib 
>>> params = ... 
>>> f = urllib.urlopen("https://...", params) 
connect: (securesite.com, 80) 
#a printout from httplib, line 354 

Traceback (most recent call last): 
File "<stdin>", line 1, in ? 
File "/usr/local/lib/python2.0/urllib.py", line 63, in
urlopen 
return _urlopener.open(url, data) 
File "/usr/local/lib/python2.0/urllib.py", line 168, in
open 
return getattr(self, name)(url, data) 
File "/usr/local/lib/python2.0/urllib.py", line 367, in
open_https 
data) 
File "/usr/local/lib/python2.0/urllib.py", line 301, in
http_error 
result = method(url, fp, errcode, errmsg, headers,
data) 
File "/usr/local/lib/python2.0/urllib.py", line 537, in
http_error_302 
return self.open(newurl, data) 
File "/usr/local/lib/python2.0/urllib.py", line 168, in
open 
return getattr(self, name)(url, data) 
File "/usr/local/lib/python2.0/urllib.py", line 269, in
open_http 
h.putrequest('POST', selector) 
File "/usr/local/lib/python2.0/httplib.py", line 428,
in putrequest 
self.send(str) 
File "/usr/local/lib/python2.0/httplib.py", line 370,
in send 
self.connect() 
File "/usr/local/lib/python2.0/httplib.py", line 354,
in connect 
self.sock.connect((self.host, self.port)) 
KeyboardInterrupt 
>>> 

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408085&group_id=5470


From noreply@sourceforge.net  Fri Mar 16 18:04:29 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Mar 2001 10:04:29 -0800
Subject: [Python-bugs-list] [ python-Bugs-405837 ] getting PyRun_String() true result
Message-ID: <E14dyaT-00026r-00@usw-sf-web2.sourceforge.net>

Bugs item #405837, was updated on 2001-03-04 06:53
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405837&group_id=5470

Category: Python Interpreter Core
Group: Feature Request
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: getting PyRun_String() true result

Initial Comment:
It seems impossible to build am embedded Python
interpreter extension which actually allows getting
the result of the evaluation of a string from the
interpreter, as it is done in interactive mode, as in
the following:
  def f: pass
  f
prints:
  <function f at 0x8069694>

But in C (called twice with the 2 above strings):
  PyRun_String(string, Py_file_input, globals, globals)
returns None.

I found a workaround by patching the core in ceval.c,
eval_code2() (inspired by the PRINT_EXPR case):

...
case POP_TOP:
  v = POP();
PyDict_SetItemString(f->f_globals, "_", v); /* added */
  Py_DECREF(v);
  continue;
...

and then:
  PyRun_String(string, Py_file_input, globals, globals)
  result =PyDict_GetItemString(globals, "_")
returns the '<function f at 0x8069694>' correct result.


My goal is to allow the tclpython extension (at
http://jfontain.free.fr/) to work without having to
insert print statements on the Python side to be able
to pass data to the Tcl interpreter.

Please forgive me if there is an obvious way to do the
above without patching the core, but I am new to Python
(I like it already though :-)

Jean-Luc Fontaine

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-03-05 10:51

Message:
Logged In: NO 

> To evaluate a string, use Py_RunString with Py_eval_input,
> or perhaps Py_single_input.

Py_eval_input is for "isolated expressions", and
Py_single_input "for a single statement", so how do I
execute whole modules except by using Py_file_input, the
only remaining option?

I actually tested all the above options thoroughly and found
that only Py_file_input did the job, but without a way to
get at the result.

Please let me know whether there is something that I missed,
as I am stuck at the moment. If needed, I will be happy to
send you sample code that illustrates the problem.

Thank you very much for your prompt response.

Jean-Luc

PS: passing "def f(): pass\n" to Py_eval_input returns a
"SyntaxError: invalid syntax"


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-03-04 10:22

Message:
Logged In: YES 
user_id=21627

Sure there is. PyRun_SimpleString executes a string in "file
mode"; this has no result. The interactive interpreter, when
it prints a result, runs the string in "eval mode" - only
evaluation gives a result.

To evaluate a string, use Py_RunString with Py_eval_input,
or perhaps Py_single_input.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405837&group_id=5470


From noreply@sourceforge.net  Fri Mar 16 17:56:40 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Mar 2001 09:56:40 -0800
Subject: [Python-bugs-list] [ python-Bugs-405939 ] HTTPConnection Host hdr wrong w/ proxy
Message-ID: <E14dySu-00021C-00@usw-sf-web2.sourceforge.net>

Bugs item #405939, was updated on 2001-03-04 21:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405939&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Ernie Sasaki (esasaki)
>Assigned to: Greg Stein (gstein)
Summary: HTTPConnection Host hdr wrong w/ proxy

Initial Comment:
The HTTPConnection class' putrequest() method is 
incorrect if self._http_vsn == 11 and a proxy is in 
use.

Currently the following is done in httplib.py revision 
1.33:

if self.port == HTTP_PORT:
    self.putheader('Host', self.host)
else:
    self.putheader('Host', "%s:%s" % (self.host, 
self.port))

However if a proxy is in use, self.host is the proxy 
address, and url contains the "realhost" which should 
be in the Host header. (urllib does the right thing 
here but it uses the HTTP class and not 
HTTPConnection. It doesn't see this problem because 
then HTTP/1.0 is used and no Host header is sent 
automatically.)

Instead the following is correct:

match = httpRE.search(url)
if match:
    self.putheader('Host', match.group(1))
else:
    if self.port == HTTP_PORT:
        self.putheader('Host', self.host)
    else:
	self.putheader('Host', "%s:%s" % (self.host, 
self.port))

where:

httpRE = re.compile(r'(?i)http://([^/]+)')


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-03-05 15:44

Message:
Logged In: YES 
user_id=21627

1 and 2 are probably good reasons why httplib should follow.
3 is no option, since RFC 2616 states that a client MUST
send a Host header in a 1.1 request, even though a server
MUST ignore it if an absolute URI is present; otherwise I'd
agree that it would be best not to send any at all.

As for 4, I agree that the proxy can change the Request-URI.
However, to conform to http 1.1, I think it also needs to
update the Host: header accordingly.

I'd like to get some report on actual problems caused by
this bug. If so, what is the specific proxy software being
used, etc.

On user/password issue: So far, httplib does not deal with
the request URI at all. The issue is how to process an
absoluteURI that contains a userinfo. It would be clearly
wrong to copy the userinfo into the Host: header, as your
code would do. What is not clear to me is whether RFC 2616
allows userinfo to be present in a Request-URI.

----------------------------------------------------------------------

Comment By: Ernie Sasaki (esasaki)
Date: 2001-03-05 12:31

Message:
Logged In: YES 
user_id=139439

Well, my not very good answers are (notwithstanding your 
quote):

1). This is what Netscape 4.7 does.

2). This is what urllib's open_http does.

3). I rather you didn't send a Host header at all rather 
than a wrong one.  It just makes no sense to me to give the 
origin server a Host header that relates to the proxy's 
address. How would the virtual host mechanism (mentioned in 
the section you quote) ever work thru a proxy then?? You 
need the concept of a host different from what is specified 
in the Request-URI.

4). I speculate (with only secondhand evidence) that a 
proxy can change the absoluteURI to an absolute path when 
passing it on to the origin server. In that case, the Host 
header would indeed determine the host.

As far as the patch being incomplete: In no part of httplib 
does any special handling of an embedded user/password 
appear. It is assumed that you'll take care of sending the 
Authorization header yourself.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-03-05 00:39

Message:
Logged In: YES 
user_id=21627

Why is that a bug? RFC 2616, section 5.2, states

# If Request-URI is an absoluteURI, the host is part of the 
# Request-URI. Any Host header field value in the request 
# MUST be ignored.

So in the presence of an absolute URI, the Host: field does
not matter. It is certainly nicer to fill in the right Host:
field, but I'd like to understand the problem before
applying a fix. Your patch is incomplete, IMO: it does not
deal with the user/password part in the URL.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405939&group_id=5470


From noreply@sourceforge.net  Fri Mar 16 18:13:01 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Mar 2001 10:13:01 -0800
Subject: [Python-bugs-list] [ python-Bugs-406683 ] typos in urllib2 ( cvs )
Message-ID: <E14dyij-0002Bt-00@usw-sf-web2.sourceforge.net>

Bugs item #406683, was updated on 2001-03-07 05:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406683&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Bernd S. Brentrup (winnegan)
>Assigned to: Moshe Zadka (moshez)
Summary: typos in urllib2 ( cvs )

Initial Comment:
urllib2.ProxyHandler fails due to typos when using proxy 
autthentication, patch included.


----------------------------------------------------------------------

Comment By: Eduardo Fernandez Corrales (ejfc)
Date: 2001-03-08 09:59

Message:
Logged In: YES 
user_id=169128

I have corrected the patch to reflect proper Basic 
Authentication:

--- /var/local/cvs/python/dist/src/Lib/urllib2.py	Thu 
Mar  1 09:46:07 2001
+++ /usr/local/lib/python2.1/urllib2.py	Thu Mar  8 17:23:31 
2001
@@ -477,8 +477,8 @@
         host, XXX = splithost(r_type)
         if '@' in host:
             user_pass, host = host.split('@', 1)
-            user_pass = base64.encode_string(unquote
(user_passw)).strip()
-            req.addheader('Proxy-Authorization', user_pass)
+            user_pass = "Basic " + base64.encodestring
(unquote(user_pass)).strip()
+            req.add_header('Proxy-Authorization', 
user_pass)
         host = unquote(host)
         req.set_proxy(host, type)
         if orig_type == type:

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406683&group_id=5470


From noreply@sourceforge.net  Fri Mar 16 18:03:54 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Mar 2001 10:03:54 -0800
Subject: [Python-bugs-list] [ python-Bugs-406642 ] 2.1b1 from socket import* omits errorTab
Message-ID: <E14dyZu-00026Y-00@usw-sf-web2.sourceforge.net>

Bugs item #406642, was updated on 2001-03-07 01:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406642&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Priority: 5
Submitted By: Ernie Sasaki (esasaki)
>Assigned to: Skip Montanaro (montanaro)
Summary: 2.1b1 from socket import* omits errorTab

Initial Comment:
Under Win98SE, if you say "from socket import *" at an 
interactive python 2.0 prompt, you can see errorTab in 
what dir() returns. 

With a 2.1b1 interactive prompt, if you do the same 
exact thing no errorTab is in the list. However, if 
instead you say import socket and then dir(socket), 
errorTab appears.

Not sure if this is a bug but it sure sent me on a 
wild goose chase for a while. I don't think this is 
correct Nested Scopes related behavior but I admit I 
haven't fully understood this new feature.

This came up because I've been using the 
timeoutsocket.py module from the Vaults of Parnassus 
for a few weeks. It imports from socket. In a 
different module I (very non-portably), then format an 
nice error message based on the contents of errorTab. 
This code now is broken under 2.1b1.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406642&group_id=5470


From noreply@sourceforge.net  Fri Mar 16 18:43:59 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Mar 2001 10:43:59 -0800
Subject: [Python-bugs-list] [ python-Bugs-407783 ] urllib2: AbstractHTTPHandler limits flexible client implementations
Message-ID: <E14dzCh-0002Yc-00@usw-sf-web3.sourceforge.net>

Bugs item #407783, was updated on 2001-03-11 16:43
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407783&group_id=5470

Category: Python Library
Group: None
Status: Open
>Priority: 4
Submitted By: Bill Bumgarner (bbum)
>Assigned to: Moshe Zadka (moshez)
Summary: urllib2: AbstractHTTPHandler limits flexible client implementations

Initial Comment:
The implementation of the do_open() method on the AbstractHTTPHandler class contains a couple of "features" that could be considered to be "bugs".  In any case, each time I have wanted to use urllib2 for relatively straightforward development of an HTTP client, I have had to effectively replace the HTTPHandler with one that reimplements do_open() (or http_open() in 2.0).  Maybe my usage is not the norm-- in any case, the more information, the better...

Specifics (all names in context of Python 2.1):

- AbstractHTTPHandler does not allow for anything but GET or POST requests.   GET is the default and POST happens anytime the request object contains data to be passed to the server.

This limitation is the only thing that stands in the way of using the AbstractHTTPHandler *directly* to implement, say, a WebDAV client or to do something like a site sucker that uses the HEAD method to determine if content has changed.

- [this is likely a bug]  the method will throw an exception if *any* response is received from the server other than 200.   However, HTTP defines that all 2XX responses should be treated as successful. 

In any case, there are *a lot* of contexts within which a non-200 response may be treated as a 'success' of some sort or another.  Regardless, it is really outside of the scope of the AbstractHTTPHandler's implementation to make the success/failure decision-- it should simply return  the same thing regardless of the response status.

- [a bug?] Whenever an exception is raised (a non-200 code is received), the status code and reason (as provided by the server) are both lost. 

I see that moshez has been primarily responsible for recent changes surrounding this code.  I would be happy to contribute to the evolution of the code;  please feel free to contact me directly.


----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-03-16 10:43

Message:
Logged In: YES 
user_id=31392

I haven't had any spare cycles to devote to urllib2 this
year.  Perhaps Moshe can be of more help in the near term. 
Following the 2.1 release, I may have more time.

I never used urllib2 it a situation that produced anything
other than vanilla responses -- 200, 401, etc.  I'm not to
surprised to hear that there are problems with 2XX cases.

Can you post some examples of the sorts of things you want
to do?  It sounds reasonable in the abstract, but some code
would help.  If not in this patch archive, perhaps on
comp.lang.python?


----------------------------------------------------------------------

Comment By: Bill Bumgarner (bbum)
Date: 2001-03-11 19:59

Message:
Logged In: YES 
user_id=103811

I realized that the exception throw behaviour is more fundamental to the underlying implementation than may have been indicated in the above description.  In particular, throwing an HTTP exception when handling a 401 is key to making the various Authentication Handlers work.

I still feel that the behaviour should be normalized across all requests such that the callee is responsible for determining error conditions or, at the lest, has access to the same data in a relatively similar format upon success or failure.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407783&group_id=5470


From noreply@sourceforge.net  Fri Mar 16 19:10:07 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Mar 2001 11:10:07 -0800
Subject: [Python-bugs-list] [ python-Bugs-225217 ] urllib2.py and proxies (Python 2.0)
Message-ID: <E14dzbz-0002mw-00@usw-sf-web3.sourceforge.net>

Bugs item #225217, was updated on 2000-12-09 22:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=225217&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: The Written Word (china) (tww-china)
>Assigned to: Moshe Zadka (moshez)
Summary: urllib2.py and proxies (Python 2.0)

Initial Comment:
Consider the following program:

  import os, sys, urllib2
  from urllib2 import urlopen
        
  os.environ['http_proxy'] = 'http://[HOST]:5865'
   
  authinfo = urllib2.HTTPBasicAuthHandler ()
  authinfo.add_password ('[REALM]', 'http://[URL]', '[login]', 
  '[password]')
        
  opener = urllib2.build_opener (authinfo)
  urllib2.install_opener (opener)

  url = urlopen ('http://[URL]/')
  print url.info ()
  url.close ()

Urllib2.py does not work if we wish to do BASIC authentication to a URL through a proxy. Chances are it also will not work if the proxy requires BASIC authentication too and the URL requires BASIC authentication. Here's the error I receive (Solaris 7/SPARC but platform does not matter):

    File "/tmp/a.py", line 15, in ?                          
      url = urlopen ('http://updates.thewrittenword.com/')
    File "/opt/TWWfsw/pkgutils12/lib/python20/lib/python2.0/urllib2.py",
  line 137, in urlopen
      return _opener.open(url, data)
    File "/opt/TWWfsw/pkgutils12/lib/python20/lib/python2.0/urllib2.py",
  line 325, in open
      '_open', req)
    File "/opt/TWWfsw/pkgutils12/lib/python20/lib/python2.0/urllib2.py",
  line 304, in _call_chain
      result = func(*args)
    File "/opt/TWWfsw/pkgutils12/lib/python20/lib/python2.0/urllib2.py",
  line 764, in http_open
      return self.parent.error('http', req, fp, code, msg, hdrs)
    File "/opt/TWWfsw/pkgutils12/lib/python20/lib/python2.0/urllib2.py",
  line 351, in error
      return self._call_chain(*args)
    File "/opt/TWWfsw/pkgutils12/lib/python20/lib/python2.0/urllib2.py",
  line 304, in _call_chain
      result = func(*args)
    File "/opt/TWWfsw/pkgutils12/lib/python20/lib/python2.0/urllib2.py",
  line 430, in http_error_default
      raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
  urllib2.HTTPError: HTTP Error 401: Authorization Required


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-03-06 03:24

Message:
Logged In: NO 

alike for $ftp_proxy:
  File "/usr/local/lib/python2.0/urllib.py", line 61, in
urlopen
    return _urlopener.open(url)
  File "/usr/local/lib/python2.0/urllib.py", line 166, in
open
    return getattr(self, name)(url)
  File "/usr/local/lib/python2.0/urllib.py", line 416, in
open_ftp
    host, path = splithost(url)
  File "/usr/local/lib/python2.0/urllib.py", line 885, in
splithost
    match = _hostprog.match(url)
TypeError: expected string or buffer


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=225217&group_id=5470


From noreply@sourceforge.net  Fri Mar 16 19:27:33 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Mar 2001 11:27:33 -0800
Subject: [Python-bugs-list] [ python-Bugs-405227 ] sizeof(Py_UNICODE)==2 ????
Message-ID: <E14dzsr-0002p7-00@usw-sf-web2.sourceforge.net>

Bugs item #405227, was updated on 2001-03-01 11:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405227&group_id=5470

Category: Unicode
Group: Platform-specific
>Status: Closed
Priority: 5
Submitted By: Jon Saenz (jsaenz)
Assigned to: M.-A. Lemburg (lemburg)
Summary: sizeof(Py_UNICODE)==2 ????

Initial Comment:
We are trying to install Python 2.0 in a Cray T3E.

After a painful process of removing several modules
which produce some errors (mmap, sha, md5), we get core
dumps when we run python because under this platform,
there does not exist a 16-bit numeric type. Unsigned
short is 4 bytes long.

We have finally defined unicode objects as unsigned
short, despite they are 4 bytes long, and we have
changed a sentence in 
Objects/unicodeobject.c
to:
if (sizeof(Py_UNICODE)!=sizeof(unsigned short){

It compiles and runs now, but the test on regular
expressions crashes and the whole regression test does,
too.

Support of Unicode for this platform is not correct in
version 2.0 of Python.

----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2001-03-16 11:27

Message:
Logged In: YES 
user_id=38388

The current Unicode implementation needs Py_UNICODE to
be a 16-bit entity and so does SRE.

To get this to work on the Cray, you could try to use a
2-char
struct which is then cast to a short in all those places
which
assume a 16-bit number representation.

Simply using a 4-byte entity as basis will not work, since
the fact that Py_UNICODE fits into 2 bytes is hard-coded
into the implementation in a number of places.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-03-01 15:29

Message:
Logged In: YES 
user_id=31435

Notes:

+ Python was ported to T3E last year, IIRC by Marc Poinot.  
May want to track him down.

+ Python's Unicode support doesn't rely on any platform 
Unicode support.  Whether it's "useless" depends on the 
user, not the platform.

+ Face it <wink>:  Crays are the only platforms that don't 
have a native 16-bit integer type.

+ Even so, I believe at least SRE is happy to work with 32-
bit Unicode (glibc's wchar_t is 4 bytes, IIRC), so that 
much was likely a shallow problem.


----------------------------------------------------------------------

Comment By: Jon Saenz (jsaenz)
Date: 2001-03-01 15:09

Message:
Logged In: YES 
user_id=12122

We have finally given up to install Python in the Cray T3E
due to its lack of support of shared objects. This causes
difficulties in the loading of different external libraries
(Numeric, Lapack, and so on) because of the static linking.

In any case, we still think that this "bug" should be
repaired. There may be other platforms which:
1) Do not support Unicode, so that the Unicode feature of
Python is useless in these cases.
2) The users may be interested in using Python in them (for
Numeric applications, for instance)
3) May not have a 16-bit native numerical type.

Under these circunstances, the current version of Python can
not be used.

----------------------------------------------------------------------

Comment By: Jon Saenz (jsaenz)
Date: 2001-03-01 15:08

Message:
Logged In: YES 
user_id=12122

We have finally given up to install Python in the Cray T3E
due to its lack of support of shared objects. This causes
difficulties in the loading of different external libraries
(Numeric, Lapack, and so on) because of the static linking.

In any case, we still think that this "bug" should be
repaired. There may be other platforms which:
1) Do not support Unicode, so that the Unicode feature of
Python is useless in these cases.
2) The users may be interested in using Python in them (for
Numeric applications, for instance)
3) May not have a 16-bit native numerical type.

Under these circunstances, the current version of Python can
not be used.

----------------------------------------------------------------------

Comment By: Jon Saenz (jsaenz)
Date: 2001-03-01 15:08

Message:
Logged In: YES 
user_id=12122

We have finally given up to install Python in the Cray T3E
due to its lack of support of shared objects. This causes
difficulties in the loading of different external libraries
(Numeric, Lapack, and so on) because of the static linking.

In any case, we still think that this "bug" should be
repaired. There may be other platforms which:
1) Do not support Unicode, so that the Unicode feature of
Python is useless in these cases.
2) The users may be interested in using Python in them (for
Numeric applications, for instance)
3) May not have a 16-bit native numerical type.

Under these circunstances, the current version of Python can
not be used.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-03-01 14:05

Message:
Logged In: YES 
user_id=3066

Marc-Andre, can you deal with the general Unicode issues here and then pass this along to Fredrik for SRE updates?  (Or better yet, work in parallel?)

Thanks!

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405227&group_id=5470


From noreply@sourceforge.net  Fri Mar 16 22:01:50 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Mar 2001 14:01:50 -0800
Subject: [Python-bugs-list] [ python-Bugs-409230 ] Python 2.1b1 dumps core on list compr.
Message-ID: <E14e2IA-0004Di-00@usw-sf-web2.sourceforge.net>

Bugs item #409230, was updated on 2001-03-16 14:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409230&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Priority: 5
Submitted By: Viktor Ferenczi (complex)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.1b1 dumps core on list compr.

Initial Comment:
Hi!

Python 2.1b1 dumps core when executing the following
statement:

print [[y for y in [x,x+1]] for x in [1,3]]

(Should print: [[1,2],[3,4]])

The problem may be related to variable scope resolving
code, because python reports "unknown scope for _[2] in
?(0)" before dumping core. This bug makes impossible to
use a list comprehension as the expression field of
another one.


-Complex-

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409230&group_id=5470


From noreply@sourceforge.net  Fri Mar 16 22:02:04 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Mar 2001 14:02:04 -0800
Subject: [Python-bugs-list] [ python-Bugs-409231 ] Python 2.1b1 dumps core on list compr.
Message-ID: <E14e2IO-0004E4-00@usw-sf-web2.sourceforge.net>

Bugs item #409231, was updated on 2001-03-16 14:02
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409231&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Priority: 5
Submitted By: Viktor Ferenczi (complex)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.1b1 dumps core on list compr.

Initial Comment:
Hi!

Python 2.1b1 dumps core when executing the following
statement:

print [[y for y in [x,x+1]] for x in [1,3]]

(Should print: [[1,2],[3,4]])

The problem may be related to variable scope resolving
code, because python reports "unknown scope for _[2] in
?(0)" before dumping core. This bug makes impossible to
use a list comprehension as the expression field of
another one.


-Complex-

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409231&group_id=5470


From noreply@sourceforge.net  Fri Mar 16 22:02:41 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Mar 2001 14:02:41 -0800
Subject: [Python-bugs-list] [ python-Bugs-409232 ] Python 2.1b1 dumps core on list compr.
Message-ID: <E14e2Iz-0004EM-00@usw-sf-web2.sourceforge.net>

Bugs item #409232, was updated on 2001-03-16 14:02
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409232&group_id=5470

Category: Python Interpreter Core
Group: Trash
Status: Open
Priority: 5
Submitted By: Viktor Ferenczi (complex)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.1b1 dumps core on list compr.

Initial Comment:
Hi!

Python 2.1b1 dumps core when executing the following
statement:

print [[y for y in [x,x+1]] for x in [1,3]]

(Should print: [[1,2],[3,4]])

The problem may be related to variable scope resolving
code, because python reports "unknown scope for _[2] in
?(0)" before dumping core. This bug makes impossible to
use a list comprehension as the expression field of
another one.


-Complex-

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409232&group_id=5470


From noreply@sourceforge.net  Fri Mar 16 22:05:08 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Mar 2001 14:05:08 -0800
Subject: [Python-bugs-list] [ python-Bugs-409232 ] Python 2.1b1 dumps core on list compr.
Message-ID: <E14e2LM-0004Fr-00@usw-sf-web2.sourceforge.net>

Bugs item #409232, was updated on 2001-03-16 14:02
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409232&group_id=5470

Category: Python Interpreter Core
Group: Trash
>Status: Deleted
Priority: 5
Submitted By: Viktor Ferenczi (complex)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.1b1 dumps core on list compr.

Initial Comment:
Hi!

Python 2.1b1 dumps core when executing the following
statement:

print [[y for y in [x,x+1]] for x in [1,3]]

(Should print: [[1,2],[3,4]])

The problem may be related to variable scope resolving
code, because python reports "unknown scope for _[2] in
?(0)" before dumping core. This bug makes impossible to
use a list comprehension as the expression field of
another one.


-Complex-

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409232&group_id=5470


From noreply@sourceforge.net  Fri Mar 16 22:05:48 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Mar 2001 14:05:48 -0800
Subject: [Python-bugs-list] [ python-Bugs-409231 ] Python 2.1b1 dumps core on list compr.
Message-ID: <E14e2M0-0004GL-00@usw-sf-web2.sourceforge.net>

Bugs item #409231, was updated on 2001-03-16 14:02
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409231&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Deleted
Priority: 5
Submitted By: Viktor Ferenczi (complex)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.1b1 dumps core on list compr.

Initial Comment:
Hi!

Python 2.1b1 dumps core when executing the following
statement:

print [[y for y in [x,x+1]] for x in [1,3]]

(Should print: [[1,2],[3,4]])

The problem may be related to variable scope resolving
code, because python reports "unknown scope for _[2] in
?(0)" before dumping core. This bug makes impossible to
use a list comprehension as the expression field of
another one.


-Complex-

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409231&group_id=5470


From noreply@sourceforge.net  Sat Mar 17 03:40:01 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Mar 2001 19:40:01 -0800
Subject: [Python-bugs-list] [ python-Bugs-409311 ] Python 2.1b1 re module is broken!
Message-ID: <E14e7ZR-0006eC-00@usw-sf-web3.sourceforge.net>

Bugs item #409311, was updated on 2001-03-16 19:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409311&group_id=5470

Category: Regular Expressions
Group: None
Status: Open
Priority: 5
Submitted By: Gregory P. Smith (greg)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.1b1 re module is broken!

Initial Comment:
the following should -not- match:

$ python
Python 2.1b1 (#1, Mar 12 2001, 18:20:53) 
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> reg = r"(?im)<dtml-var\s+([a-z_0-9]+?)\s*>"
>>> str = '<dtml-var
expr="Presentation.show(\'start\')">'
>>> import re                                
>>> re.match(reg, str)                       
<SRE_Match object at 0x810d9d0>


In python 1.5.2 and 2.0 this works fine.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409311&group_id=5470


From noreply@sourceforge.net  Sat Mar 17 04:13:02 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Mar 2001 20:13:02 -0800
Subject: [Python-bugs-list] [ python-Bugs-408798 ] 5.5 bisect documentation
Message-ID: <E14e85O-0006qo-00@usw-sf-web3.sourceforge.net>

Bugs item #408798, was updated on 2001-03-15 07:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408798&group_id=5470

Category: Documentation
Group: None
>Status: Closed
Priority: 5
Submitted By: Greg Kochanski (gpk)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: 5.5 bisect documentation

Initial Comment:
The documentation should note that if
item compares equal to list[i], it will
return i+1.  More generally, it returns
the index of the first element that compares
greater than item, or len(list) if item is larger
than everything in list.
This means that insort() sorts with minimal
rearrangement: if two items compare equal,
they will be on the list in the order with which
they were added.   This can be relevant for
classes which define a __cmp__() method.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-03-16 20:13

Message:
Logged In: YES 
user_id=3066

As Tim noted, already fixed in the sources.  This is now closed.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-03-15 22:46

Message:
Logged In: YES 
user_id=31435

Note that the 2.1 docs already say this -- you can close 
this, Fred.

Greg, 2.1 also adds bisect_left and insort_left functions 
to bisect, in case you want the insertion point to be "to 
the left" of any pre-existing equal items instead.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408798&group_id=5470


From noreply@sourceforge.net  Sat Mar 17 04:30:31 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Mar 2001 20:30:31 -0800
Subject: [Python-bugs-list] [ python-Bugs-406280 ] Python 2.1b1 - pydoc shows nothing
Message-ID: <E14e8MJ-00004q-00@usw-sf-web1.sourceforge.net>

Bugs item #406280, was updated on 2001-03-06 05:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406280&group_id=5470

Category: Python Library
Group: None
Status: Open
>Priority: 3
Submitted By: Paul Moore (pmoore)
>Assigned to: Mark Hammond (mhammond)
Summary: Python 2.1b1 - pydoc shows nothing

Initial Comment:
Platform: Windows 2000, Python 2.1b1

The pydoc script works fine in "serve documents to a 
browser" mode (python pydoc). Also, running it as a 
command line application, as "python pydoc pydoc", 
works fine when the environment variable PAGER is 
unset.

However, when I have PAGER=less, I get no output at 
all.

It looks like a bug in pydoc.pipepager(), which is the 
result of a bug in os.popen(). I can work around the 
bug by using pydoc.tempfilepager() in place of 
pydoc.pipepager(), but I don't know what the 
underlying popen() bug is.

To demonstrate the os.popen() bug, see the attached 
interactive session:

C:\Data>python21
Python 2.1b1 (#11, Mar  2 2001, 11:23:29) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
>>> import os
>>> a = os.popen("more", "w")
>>> a.write("Hello")
>>> a.close()

Run this, and note that the "More" program never 
starts...

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-03-16 20:30

Message:
Logged In: YES 
user_id=31435

Assigned to MarkH for popen insight.

"more" does start, but the output just vanishes under 
Win98SE (and, I assume, W2K too).  This I deduced via doing 
os.popen("more > somefile.txt", "w") instead; the file is 
created, and does contain the stuff written to the handle.  
Besides, the std test_popen2 test uses "more" under Windows 
too, and works fine.

Nothing unique about "more" here:  tried a number of .exe 
files, and it's all the same:  the stdout of the popen'ed 
program isn't displayed.  I assume this is because the 
original console's stdout doesn't manage to become the 
popen'ed stdout, but I don't understand it in detail.  Deep 
or shallow?

In any case, trying to implement a pager via popen like 
this goes beyond what C guarantees, so I reduced the 
priority accordingly.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-11 16:27

Message:
Logged In: YES 
user_id=6380

Assigned to Tim, because of that fine combination of
keywords:
popen and Windows.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406280&group_id=5470


From noreply@sourceforge.net  Sat Mar 17 04:36:11 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Mar 2001 20:36:11 -0800
Subject: [Python-bugs-list] [ python-Bugs-407300 ] Win32: pydoc command isn't executable
Message-ID: <E14e8Rn-00008S-00@usw-sf-web1.sourceforge.net>

Bugs item #407300, was updated on 2001-03-09 05:45
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407300&group_id=5470

Category: Windows
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Paul Moore (pmoore)
Assigned to: Tim Peters (tim_one)
Summary: Win32: pydoc command isn't executable

Initial Comment:
The Python 2.1b1 binary installer for Windows supplies 
a small "pydoc" script in the main Python executable 
directory. However, this script is Unix-specific and 
does not work on Windows.

Suggestion: for Windows, include a trivial pydoc.bat 
file to start pydoc. The following one-liner works:

--- pydoc.bat ---
@python -c "import pydoc; pydoc.cli()" %*
-----------------

The only problem with this version is that it uses the 
version of python.exe found on PATH, rather than the 
version in the directory containing pydoc.bat. 
However, as the Unix script has the same issue, this 
can be viewed as a "feature"...

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-03-16 20:36

Message:
Logged In: YES 
user_id=31435

This isn't a priority for me.  pydoc in the root directory 
is actually AMK's Tools/scripts/pydoc (in the CVS tree).  
Guido fiddled the Windows installer to install that file 
into the root directory instead of into Tools/scripts, and 
just so that the "Module Docs" program group entry had 
something to execute.  It works fine for what it was 
designed for.

----------------------------------------------------------------------

Comment By: Paul Moore (pmoore)
Date: 2001-03-13 01:59

Message:
Logged In: YES 
user_id=113328

Using a pyw file doesn't work, as that stops the usage
   pydoc <module>
which should display documentation in the console window.

Also, .py[w] files aren't executable without an extension. 
For example, you'd have to type pydoc.pyw, not just pydoc.

Instead of %*, use %1 %2 %3 %4 %5 %6 %7 %8 %9. And to avoid 
python.exe if there are no args (when the Tk stuff is used) 
how about

@echo off
if "%1"=="" pythonw -c "import pydoc; pydoc.cli()"
if NOT "%1"=="" python -c "import pydoc; pydoc.cli()" %1 %2 
%3 %4 %5 %6 %7 %8 %9

That should work on 9x and NT/2000. I repeat the test for 
simplicity. You could use GOTO and labels, instead...


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-03-10 23:42

Message:
Logged In: YES 
user_id=31435

"%*" doesn't work under Win9X.

Changed the installer to name the file pydoc.pyw instead.

Note that the Windows installer also creates an entry for 
pydoc under Start -> Programs -> Python -> Module Docs.

Note too that due to Tk problems, we can't encourage using 
python instead of pythonw to run pydoc (Tk apps have an 
unfortunate tendency to wedge Windows when run via python; 
see other SF bugs for more on that).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407300&group_id=5470


From noreply@sourceforge.net  Sat Mar 17 04:38:11 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Mar 2001 20:38:11 -0800
Subject: [Python-bugs-list] [ python-Bugs-233200 ] cPickle does not use Py_BEGIN_ALLOW_THREADS.
Message-ID: <E14e8Tj-0000AN-00@usw-sf-web1.sourceforge.net>

Bugs item #233200, was updated on 2001-02-20 00:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=233200&group_id=5470

Category: Threads
Group: None
Status: Open
Priority: 5
Submitted By: Ben Rampling (ianbanks)
>Assigned to: Tim Peters (tim_one)
Summary: cPickle does not use Py_BEGIN_ALLOW_THREADS.

Initial Comment:
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.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-03-16 20:38

Message:
Logged In: YES 
user_id=31435

Reassigned to me after asking JimF whether he objected (he 
didn't, but doesn't have time to do it himself).

----------------------------------------------------------------------

Comment By: Ben Rampling (ianbanks)
Date: 2001-02-20 19:33

Message:
 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


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-02-20 13:17

Message:
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).


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-02-20 11:54

Message:
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.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=233200&group_id=5470


From noreply@sourceforge.net  Sat Mar 17 04:54:40 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Mar 2001 20:54:40 -0800
Subject: [Python-bugs-list] [ python-Bugs-233200 ] cPickle does not use Py_BEGIN_ALLOW_THREADS.
Message-ID: <E14e8jg-00078u-00@usw-sf-web2.sourceforge.net>

Bugs item #233200, was updated on 2001-02-20 00:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=233200&group_id=5470

Category: Threads
Group: None
>Status: Closed
Priority: 5
Submitted By: Ben Rampling (ianbanks)
Assigned to: Tim Peters (tim_one)
Summary: cPickle does not use Py_BEGIN_ALLOW_THREADS.

Initial Comment:
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.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-03-16 20:54

Message:
Logged In: YES 
user_id=31435

Closed and Fixed, cPickle.c rev 2.55.

Ben, yes, Python does want you to feel safe about threads 
not blocking in simple I/O.  It was a good call!  Thank you.

Ah, btw, if you can, please build a Python from the CVS 
ttree and verify this fixes your headaches on the platforms 
you care about.  I'm not running Linux (yet).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-03-16 20:38

Message:
Logged In: YES 
user_id=31435

Reassigned to me after asking JimF whether he objected (he 
didn't, but doesn't have time to do it himself).

----------------------------------------------------------------------

Comment By: Ben Rampling (ianbanks)
Date: 2001-02-20 19:33

Message:
 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


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-02-20 13:17

Message:
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).


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-02-20 11:54

Message:
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.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=233200&group_id=5470


From noreply@sourceforge.net  Sat Mar 17 06:58:36 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Mar 2001 22:58:36 -0800
Subject: [Python-bugs-list] [ python-Bugs-409331 ] distutils does not support ObjC
Message-ID: <E14eAfc-0007sQ-00@usw-sf-web2.sourceforge.net>

Bugs item #409331, was updated on 2001-03-16 22:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409331&group_id=5470

Category: Extension Modules
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: distutils does not support ObjC

Initial Comment:
Via this patch....

Index: unixccompiler.py
=======================================
============================
RCS file: /cvsroot/python/python/dist/src/Lib/
distutils/unixccompiler.py,v
retrieving revision 1.32
diff -r1.32 unixccompiler.py
70c70
<     src_extensions = [".c",".C",".cc",".cxx",".cpp"]
---
>     src_extensions = 
[".c",".C",".cc",".cxx",".cpp",".m"]


... I added ".m" as the list of suffixes to compile as 
C source on Mac OS X.  This worked just fine and 
allowed the PyObjC module to compile via a 
normal distutils based setup.py script.

I suspect that there may need to be flags?

In general, the whole makesetup mechanism 
should be coupled with distutils because 
makesetup has a bunch more knowledge about 
the specifics of dealing with certain source file 
types!???!!

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409331&group_id=5470


From noreply@sourceforge.net  Sat Mar 17 07:00:43 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Mar 2001 23:00:43 -0800
Subject: [Python-bugs-list] [ python-Bugs-409331 ] distutils does not support ObjC
Message-ID: <E14eAhf-0007ym-00@usw-sf-web3.sourceforge.net>

Bugs item #409331, was updated on 2001-03-16 22:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409331&group_id=5470

Category: Extension Modules
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: distutils does not support ObjC

Initial Comment:
Via this patch....

Index: unixccompiler.py
=======================================
============================
RCS file: /cvsroot/python/python/dist/src/Lib/
distutils/unixccompiler.py,v
retrieving revision 1.32
diff -r1.32 unixccompiler.py
70c70
<     src_extensions = [".c",".C",".cc",".cxx",".cpp"]
---
>     src_extensions = 
[".c",".C",".cc",".cxx",".cpp",".m"]


... I added ".m" as the list of suffixes to compile as 
C source on Mac OS X.  This worked just fine and 
allowed the PyObjC module to compile via a 
normal distutils based setup.py script.

I suspect that there may need to be flags?

In general, the whole makesetup mechanism 
should be coupled with distutils because 
makesetup has a bunch more knowledge about 
the specifics of dealing with certain source file 
types!???!!

----------------------------------------------------------------------

Comment By: Bill Bumgarner (bbum)
Date: 2001-03-16 23:00

Message:
Logged In: YES 
user_id=103811

That  was submitted by me [bbum@codefab.com] in 
case anywhere needs to followup.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409331&group_id=5470


From noreply@sourceforge.net  Sat Mar 17 10:10:00 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Mar 2001 02:10:00 -0800
Subject: [Python-bugs-list] [ python-Bugs-409354 ] Meta-class inheritance problem
Message-ID: <E14eDeq-0000ie-00@usw-sf-web3.sourceforge.net>

Bugs item #409354, was updated on 2001-03-17 02:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409354&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Priority: 5
Submitted By: Lorien Dunn (loriend)
Assigned to: Nobody/Anonymous (nobody)
Summary: Meta-class inheritance problem

Initial Comment:
I've run into a bug in python 2.0. The real code that
the following pseudo code represents throws a
TypeError.

class MyDerivedClass(MyPurePythonClass,MyBoostClass):
        def __init__(self):
                MyPurePythonClass.__init__(self)
                MyBoostClass.__init__(self)

The problem occurs in MyPurePythonClass- Python says
"unbound method must be called with class instance 1st
argument". This makes sense: I'm passing a meta-class
instead of a class. David Abrahams (the main author of
boost::python) agrees that this is a Python problem,
and that it should affect Zope as well.

I think I've found the point in the python 2.0 sorce
where it occurs:


ceval.c, line 1816 (reformatted for clarity):

/*              BEGIN CODE SAMPLE               */

else
{
/* Unbound methods must be called with an instance of
the class (or a derived class) as first argument */

     if (na > 0 && (self = stack_pointer[-n]) != NULL
                && PyInstance_Check(self)
                && PyClass_IsSubclass((PyObject
*) 		 		   (((PyInstanceObject*)  self)->in_class),
class))
                  /* Handy-dandy */ ;
      else
      {
        PyErr_SetString(PyExc_TypeError, "unbound
method must be 		called with class instance 1st
argument");
        x = NULL;
        break;
      }
}

/*              END CODE SAMPLE         */


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409354&group_id=5470


From noreply@sourceforge.net  Sat Mar 17 10:10:12 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Mar 2001 02:10:12 -0800
Subject: [Python-bugs-list] [ python-Bugs-409355 ] Meta-class inheritance problem
Message-ID: <E14eDf2-0000j3-00@usw-sf-web3.sourceforge.net>

Bugs item #409355, was updated on 2001-03-17 02:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409355&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Priority: 5
Submitted By: Lorien Dunn (loriend)
Assigned to: Nobody/Anonymous (nobody)
Summary: Meta-class inheritance problem

Initial Comment:
I've run into a bug in python 2.0. The real code that
the following pseudo code represents throws a
TypeError.

class MyDerivedClass(MyPurePythonClass,MyBoostClass):
        def __init__(self):
                MyPurePythonClass.__init__(self)
                MyBoostClass.__init__(self)

The problem occurs in MyPurePythonClass- Python says
"unbound method must be called with class instance 1st
argument". This makes sense: I'm passing a meta-class
instead of a class. David Abrahams (the main author of
boost::python) agrees that this is a Python problem,
and that it should affect Zope as well.

I think I've found the point in the python 2.0 sorce
where it occurs:


ceval.c, line 1816 (reformatted for clarity):

/*              BEGIN CODE SAMPLE               */

else
{
/* Unbound methods must be called with an instance of
the class (or a derived class) as first argument */

     if (na > 0 && (self = stack_pointer[-n]) != NULL
                && PyInstance_Check(self)
                && PyClass_IsSubclass((PyObject
*) 		 		   (((PyInstanceObject*)  self)->in_class),
class))
                  /* Handy-dandy */ ;
      else
      {
        PyErr_SetString(PyExc_TypeError, "unbound
method must be 		called with class instance 1st
argument");
        x = NULL;
        break;
      }
}

/*              END CODE SAMPLE         */


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409355&group_id=5470


From noreply@sourceforge.net  Sat Mar 17 16:32:49 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Mar 2001 08:32:49 -0800
Subject: [Python-bugs-list] [ python-Bugs-409403 ] Require version in setup.py
Message-ID: <E14eJdJ-0003QB-00@usw-sf-web2.sourceforge.net>

Bugs item #409403, was updated on 2001-03-17 08:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409403&group_id=5470

Category: Distutils
Group: None
Status: Open
Priority: 5
Submitted By: A.M. Kuchling (akuchling)
Assigned to: A.M. Kuchling (akuchling)
Summary: Require version in setup.py

Initial Comment:
It should be an error to *not* have a version number
in the setup() call.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409403&group_id=5470


From noreply@sourceforge.net  Sat Mar 17 16:36:49 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Mar 2001 08:36:49 -0800
Subject: [Python-bugs-list] [ python-Bugs-230075 ] dbmmodule build fails on Debian GNU/Linux unstable (Sid)
Message-ID: <E14eJhB-0003Sf-00@usw-sf-web2.sourceforge.net>

Bugs item #230075, was updated on 2001-01-25 12:16
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=230075&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Kalle Svensson (krftkndl)
Assigned to: A.M. Kuchling (akuchling)
Summary: dbmmodule build fails on Debian GNU/Linux unstable (Sid)

Initial Comment:
When building on Debian GNU/Linux unstable, the build fails with:

/home/kalle/src/python/dist/src/Modules/dbmmodule.c:24: #error "No ndbm.h available!"
error: command 'gcc' failed with exit status 1
make: *** [sharedmods] Error 1

The *dbm.h files available are
/usr/include/dbm.h
/usr/include/gdbm.h
/usr/include/gdbm-ndbm.h

All are part of the package libgdbmg1-dev.

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2001-03-17 08:36

Message:
Logged In: YES 
user_id=11375

What does the patch look like?  You can probably go ahead
and check it in.

I'd be leery of removing the 'not in "cygwin"' check; ask
Jason Tishler if it's still needed, since he's the Cygwin 
guru.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2001-03-03 22:26

Message:
Logged In: YES 
user_id=35752

db1/ndbm.h from libc6_2.2.2-1 still includes db.h instead
of db1/db.h.  I think I understand the reason now.  If you
want to use db1 or gdbm as a dbm compatible database you
have to link with the approprate library.  Therefore,
if you should add both -ldb1 and -Idb1.

I've created a patch to setup.py which does this.  Andrew?
BTW, I'm not sure if the "if platform not in ['cygwin']"
is needed anymore.  I bet it could be removed.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2001-03-03 21:50

Message:
Logged In: YES 
user_id=35752

Python is looking for gdbm/ndbm.h.  I could add more logic
to look for gdbm-ndbm.h but I don't think its worth it.
libc6 includes db1 which can be used by dbmmodule.
configure is not finding db1/ndbm.h because ndbm.h includes
db.h.  I think it should include db1/db.h instead.  So, it
looks like a Debian unstable bug.  I'm downloading Debian
libc6_2.2.2-1 right now.  Perhaps the bug has been fixed.

----------------------------------------------------------------------

Comment By: Kalle Svensson (krftkndl)
Date: 2001-01-25 12:21

Message:
Forgot to say that it's Python out of CVS, updated Thu Jan 25 21:23:52 CET 2001.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=230075&group_id=5470


From noreply@sourceforge.net  Sat Mar 17 16:57:47 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Mar 2001 08:57:47 -0800
Subject: [Python-bugs-list] [ python-Bugs-232609 ] 2.1a2 possible include/library mismatch in setup.py
Message-ID: <E14eK1T-0003eu-00@usw-sf-web3.sourceforge.net>

Bugs item #232609, was updated on 2001-02-15 13:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=232609&group_id=5470

Category: Build
Group: None
>Status: Closed
Priority: 5
Submitted By: Mark Favas (mfavas)
Assigned to: A.M. Kuchling (akuchling)
Summary: 2.1a2 possible include/library mismatch in setup.py

Initial Comment:
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}.

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2001-03-17 08:57

Message:
Logged In: YES 
user_id=11375

Good point.  I've checked in a change to setup.py which puts 
/usr/local at the front of the  lists, and leaves
/usr/include at the end.


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-02-28 20:53

Message:
Logged In: YES 
user_id=3066

distutils migration issue....

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=232609&group_id=5470


From noreply@sourceforge.net  Sat Mar 17 17:17:35 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Mar 2001 09:17:35 -0800
Subject: [Python-bugs-list] [ python-Bugs-409419 ] gzip.py seek and tell methods are counter-productive (and seek is broken anyway)
Message-ID: <E14eKKd-0003nM-00@usw-sf-web2.sourceforge.net>

Bugs item #409419, was updated on 2001-03-17 09:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409419&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Matt Mueller (donut)
Assigned to: Nobody/Anonymous (nobody)
Summary: gzip.py seek and tell methods are counter-productive (and seek is broken anyway)

Initial Comment:
gzip.open returns an object that emulates a file type.  However, it does
not support seeking or telling.  That is not the problem, what is the
problem is that even though it does not support them, it has the methods
there anyway.  This means user code can not easily do a try: ... except:
AttributeError, to test if the object supports these methods.  Instead
it would have to except on IOError, and have no way of knowing if it was
a real file error. (other than the kludge of examing the error string)

Therefore, I believe it would be more correct if these methods were
removed entirely, or at least replace the exception with AttributeError
instead of IOError.

Oh, and if they aren't removed, the seek method should at least accept
an arg since as it is now it will never raise its desired exception
anyway.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409419&group_id=5470


From noreply@sourceforge.net  Sat Mar 17 17:17:42 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Mar 2001 09:17:42 -0800
Subject: [Python-bugs-list] [ python-Bugs-409420 ] gzip.py seek and tell methods are counter-productive (and seek is broken anyway)
Message-ID: <E14eKKk-0003nX-00@usw-sf-web2.sourceforge.net>

Bugs item #409420, was updated on 2001-03-17 09:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409420&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Matt Mueller (donut)
Assigned to: Nobody/Anonymous (nobody)
Summary: gzip.py seek and tell methods are counter-productive (and seek is broken anyway)

Initial Comment:
gzip.open returns an object that emulates a file type.  However, it does
not support seeking or telling.  That is not the problem, what is the
problem is that even though it does not support them, it has the methods
there anyway.  This means user code can not easily do a try: ... except:
AttributeError, to test if the object supports these methods.  Instead
it would have to except on IOError, and have no way of knowing if it was
a real file error. (other than the kludge of examing the error string)

Therefore, I believe it would be more correct if these methods were
removed entirely, or at least replace the exception with AttributeError
instead of IOError.

Oh, and if they aren't removed, the seek method should at least accept
an arg since as it is now it will never raise its desired exception
anyway.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409420&group_id=5470


From noreply@sourceforge.net  Sat Mar 17 17:17:36 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Mar 2001 09:17:36 -0800
Subject: [Python-bugs-list] [ python-Bugs-232637 ] can't compile modules on AIX 4.2.1 (for real this time)
Message-ID: <E14eKKe-0003oM-00@usw-sf-web3.sourceforge.net>

Bugs item #232637, was updated on 2001-02-15 15:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=232637&group_id=5470

Category: Build
Group: None
Status: Open
Priority: 5
Submitted By: Benjamin Collar (bcollar)
>Assigned to: Neil Schemenauer (nascheme)
Summary: can't compile modules on AIX 4.2.1 (for real this time)

Initial Comment:
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...


----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2001-03-17 09:17

Message:
Logged In: YES 
user_id=11375

Reassigning to Neil; I don't know why the value of CC
changes depending on the version of make.  setup.py looks at
the CC environment variable; perhaps AIX make doesn't 
pass its variables to subprocesses correctly?



----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-02-28 20:52

Message:
Logged In: YES 
user_id=3066

This relates to the move to distutils, but may have already been fixed.  Andrew?

----------------------------------------------------------------------

Comment By: Benjamin Collar (bcollar)
Date: 2001-02-22 11:47

Message:
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"?

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-02-16 01:51

Message:
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 ?!

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-02-16 01:45

Message:
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)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=232637&group_id=5470


From noreply@sourceforge.net  Sat Mar 17 17:18:28 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Mar 2001 09:18:28 -0800
Subject: [Python-bugs-list] [ python-Bugs-405351 ] 2.1b1 - dlmodule on 64-bit platform
Message-ID: <E14eKLU-0008D6-00@usw-sf-web1.sourceforge.net>

Bugs item #405351, was updated on 2001-03-01 20:16
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405351&group_id=5470

Category: Extension Modules
Group: None
>Status: Closed
Priority: 5
Submitted By: Mark Favas (mfavas)
Assigned to: A.M. Kuchling (akuchling)
Summary: 2.1b1 - dlmodule on 64-bit platform

Initial Comment:
Platform: Tru64 Unix, V4.0F.
setup.py builds Modules/dlmodule.c automatically
(without errors) but "make test" fails with
SystemError: module dl requires sizeof(int) ==
sizeof(long) == sizeof(char*)

On this platform, ints are 4 bytes, longs and pointers
are 8 bytes, so this module will not run, and probably
should not be built in the first place.

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2001-03-17 09:18

Message:
Logged In: YES 
user_id=11375

The dl module is now disabled on all platforms; few people 
seem to use it, and it's a risky module to run.  
People can enable it in Modules/Setup if they actually care.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405351&group_id=5470


From noreply@sourceforge.net  Sat Mar 17 17:18:54 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Mar 2001 09:18:54 -0800
Subject: [Python-bugs-list] [ python-Bugs-230075 ] dbmmodule build fails on Debian GNU/Linux unstable (Sid)
Message-ID: <E14eKLu-0008DM-00@usw-sf-web1.sourceforge.net>

Bugs item #230075, was updated on 2001-01-25 12:16
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=230075&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Kalle Svensson (krftkndl)
>Assigned to: Neil Schemenauer (nascheme)
Summary: dbmmodule build fails on Debian GNU/Linux unstable (Sid)

Initial Comment:
When building on Debian GNU/Linux unstable, the build fails with:

/home/kalle/src/python/dist/src/Modules/dbmmodule.c:24: #error "No ndbm.h available!"
error: command 'gcc' failed with exit status 1
make: *** [sharedmods] Error 1

The *dbm.h files available are
/usr/include/dbm.h
/usr/include/gdbm.h
/usr/include/gdbm-ndbm.h

All are part of the package libgdbmg1-dev.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2001-03-17 08:36

Message:
Logged In: YES 
user_id=11375

What does the patch look like?  You can probably go ahead
and check it in.

I'd be leery of removing the 'not in "cygwin"' check; ask
Jason Tishler if it's still needed, since he's the Cygwin 
guru.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2001-03-03 22:26

Message:
Logged In: YES 
user_id=35752

db1/ndbm.h from libc6_2.2.2-1 still includes db.h instead
of db1/db.h.  I think I understand the reason now.  If you
want to use db1 or gdbm as a dbm compatible database you
have to link with the approprate library.  Therefore,
if you should add both -ldb1 and -Idb1.

I've created a patch to setup.py which does this.  Andrew?
BTW, I'm not sure if the "if platform not in ['cygwin']"
is needed anymore.  I bet it could be removed.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2001-03-03 21:50

Message:
Logged In: YES 
user_id=35752

Python is looking for gdbm/ndbm.h.  I could add more logic
to look for gdbm-ndbm.h but I don't think its worth it.
libc6 includes db1 which can be used by dbmmodule.
configure is not finding db1/ndbm.h because ndbm.h includes
db.h.  I think it should include db1/db.h instead.  So, it
looks like a Debian unstable bug.  I'm downloading Debian
libc6_2.2.2-1 right now.  Perhaps the bug has been fixed.

----------------------------------------------------------------------

Comment By: Kalle Svensson (krftkndl)
Date: 2001-01-25 12:21

Message:
Forgot to say that it's Python out of CVS, updated Thu Jan 25 21:23:52 CET 2001.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=230075&group_id=5470


From noreply@sourceforge.net  Sat Mar 17 17:21:07 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Mar 2001 09:21:07 -0800
Subject: [Python-bugs-list] [ python-Bugs-409420 ] gzip.py seek and tell methods are counter-productive (and seek is broken anyway)
Message-ID: <E14eKO3-0003pZ-00@usw-sf-web2.sourceforge.net>

Bugs item #409420, was updated on 2001-03-17 09:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409420&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Matt Mueller (donut)
Assigned to: Nobody/Anonymous (nobody)
Summary: gzip.py seek and tell methods are counter-productive (and seek is broken anyway)

Initial Comment:
gzip.open returns an object that emulates a file type.  However, it does
not support seeking or telling.  That is not the problem, what is the
problem is that even though it does not support them, it has the methods
there anyway.  This means user code can not easily do a try: ... except:
AttributeError, to test if the object supports these methods.  Instead
it would have to except on IOError, and have no way of knowing if it was
a real file error. (other than the kludge of examing the error string)

Therefore, I believe it would be more correct if these methods were
removed entirely, or at least replace the exception with AttributeError
instead of IOError.

Oh, and if they aren't removed, the seek method should at least accept
an arg since as it is now it will never raise its desired exception
anyway.



----------------------------------------------------------------------

>Comment By: Matt Mueller (donut)
Date: 2001-03-17 09:21

Message:
Logged In: YES 
user_id=65253

Arrg.. freaking sourceforge and its reloading=resubmitting thing.. sigh.  Why can't they just do the "thank you for submitting page that then redirects you back to the previous location" like everyone else? 


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409420&group_id=5470


From noreply@sourceforge.net  Sat Mar 17 17:24:55 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Mar 2001 09:24:55 -0800
Subject: [Python-bugs-list] [ python-Bugs-409420 ] gzip.py seek and tell methods are counter-productive (and seek is broken anyway)
Message-ID: <E14eKRj-0003qy-00@usw-sf-web2.sourceforge.net>

Bugs item #409420, was updated on 2001-03-17 09:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409420&group_id=5470

Category: Python Library
Group: None
>Status: Closed
Priority: 5
Submitted By: Matt Mueller (donut)
Assigned to: Nobody/Anonymous (nobody)
Summary: gzip.py seek and tell methods are counter-productive (and seek is broken anyway)

Initial Comment:
gzip.open returns an object that emulates a file type.  However, it does
not support seeking or telling.  That is not the problem, what is the
problem is that even though it does not support them, it has the methods
there anyway.  This means user code can not easily do a try: ... except:
AttributeError, to test if the object supports these methods.  Instead
it would have to except on IOError, and have no way of knowing if it was
a real file error. (other than the kludge of examing the error string)

Therefore, I believe it would be more correct if these methods were
removed entirely, or at least replace the exception with AttributeError
instead of IOError.

Oh, and if they aren't removed, the seek method should at least accept
an arg since as it is now it will never raise its desired exception
anyway.



----------------------------------------------------------------------

Comment By: Matt Mueller (donut)
Date: 2001-03-17 09:21

Message:
Logged In: YES 
user_id=65253

Arrg.. freaking sourceforge and its reloading=resubmitting thing.. sigh.  Why can't they just do the "thank you for submitting page that then redirects you back to the previous location" like everyone else? 


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409420&group_id=5470


From noreply@sourceforge.net  Sat Mar 17 17:55:29 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Mar 2001 09:55:29 -0800
Subject: [Python-bugs-list] [ python-Bugs-409230 ] Python 2.1b1 dumps core on list compr.
Message-ID: <E14eKvJ-00045u-00@usw-sf-web3.sourceforge.net>

Bugs item #409230, was updated on 2001-03-16 14:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409230&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Priority: 5
Submitted By: Viktor Ferenczi (complex)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.1b1 dumps core on list compr.

Initial Comment:
Hi!

Python 2.1b1 dumps core when executing the following
statement:

print [[y for y in [x,x+1]] for x in [1,3]]

(Should print: [[1,2],[3,4]])

The problem may be related to variable scope resolving
code, because python reports "unknown scope for _[2] in
?(0)" before dumping core. This bug makes impossible to
use a list comprehension as the expression field of
another one.


-Complex-

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2001-03-17 09:55

Message:
Logged In: YES 
user_id=6656

this is a dup of

[ #406049 ] crash on nested listcomps

so someone with appropriate privilege should mark it as such.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409230&group_id=5470


From noreply@sourceforge.net  Sat Mar 17 18:04:38 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Mar 2001 10:04:38 -0800
Subject: [Python-bugs-list] [ python-Bugs-409430 ] pydoc shouldn't use #!/usr/bin/env
Message-ID: <E14eL4A-00049Z-00@usw-sf-web3.sourceforge.net>

Bugs item #409430, was updated on 2001-03-17 10:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409430&group_id=5470

Category: Installation
Group: None
Status: Open
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Nobody/Anonymous (nobody)
Summary: pydoc shouldn't use #!/usr/bin/env

Initial Comment:
I've moaned about this on python-dev but I want to make
sure it doesn't get forgotten.

I've just built from CVS, installed in /usr/local, and:

$ pydoc -g
Traceback (most recent call last):
  File "/usr/local/bin/pydoc", line 3, in ?
    import pydoc
ImportError: No module named pydoc

because the /usr/bin/env python thing hits the older
python in /usr first.

Don't really know how best to implement this, not being
a distutils whiz.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409430&group_id=5470


From noreply@sourceforge.net  Sat Mar 17 19:47:18 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Mar 2001 11:47:18 -0800
Subject: [Python-bugs-list] [ python-Bugs-407019 ] Python-2.1 does not compile under cygwin
Message-ID: <E14eMfW-0004xF-00@usw-sf-web2.sourceforge.net>

Bugs item #407019, was updated on 2001-03-08 06:02
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407019&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Nobody/Anonymous (nobody)
Summary: Python-2.1 does not compile under cygwin

Initial Comment:
configure runs well.

I use:
> g++ --version
2.95.2

Errors are occuring in tokenizer.c. the pointer-variable new seems to be misinterpreted. After 
renaming it to newptr in line 192 ans subsequent lines, tokenizer.c.

The next errors occure in Parser/myreadline.c:

Parser/myreadline.c: In function `char * PyOS_StdioReadline(char *)':
Parser/myreadline.c:62: ANSI C++ forbids implicit conversion from `void *' in as
signment
Parser/myreadline.c:99: ANSI C++ forbids implicit conversion from `void *' in as
signment
Parser/myreadline.c:109: ANSI C++ forbids implicit conversion from `void *' in r
eturn
make: *** [Parser/myreadline.o] Error 1



----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-03-17 11:47

Message:
Logged In: YES 
user_id=31435

Try gcc?  Jason Tishler did the Cygwin port, and said it 
works fine.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-03-16 10:02

Message:
Logged In: YES 
user_id=31392

cygwin ends with "win." right, tim?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407019&group_id=5470


From noreply@sourceforge.net  Sat Mar 17 19:53:01 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Mar 2001 11:53:01 -0800
Subject: [Python-bugs-list] [ python-Bugs-232606 ] 2.1a2 _tkinter build may pick up wrong Tcl/Tk versions
Message-ID: <E14eMl3-0001WZ-00@usw-sf-web1.sourceforge.net>

Bugs item #232606, was updated on 2001-02-15 13:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=232606&group_id=5470

Category: Build
Group: None
>Status: Closed
Priority: 5
Submitted By: Mark Favas (mfavas)
Assigned to: A.M. Kuchling (akuchling)
Summary: 2.1a2 _tkinter build may pick up wrong Tcl/Tk versions

Initial Comment:
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.


----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2001-03-17 11:53

Message:
Logged In: YES 
user_id=11375

>From looking at the setup.py code, I believe this problem 
should also be fixed by the change  to put /usr/local first
in inc_dirs and lib_dirs.  

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2001-02-23 08:45

Message:
The handling of include and lib directories has changed a bit; does it still pick up the wrong versions?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=232606&group_id=5470


From noreply@sourceforge.net  Sat Mar 17 19:55:31 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Mar 2001 11:55:31 -0800
Subject: [Python-bugs-list] [ python-Bugs-404444 ] auto indent/parentheses
Message-ID: <E14eMnT-0004yK-00@usw-sf-web3.sourceforge.net>

Bugs item #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: Closed
Priority: 5
Submitted By: Charles Doutriaux (cdoutri)
>Assigned to: Barry Warsaw (bwarsaw)
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

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-03-17 11:55

Message:
Logged In: YES 
user_id=31435

Added to PEP 42 and marked Later/Closed.

Assigned to Barry in the hopes that he can clarify the TAB 
business (I don't understand what this is asking for -- 
doesn't a TAB key act like a TAB key <wink> in Emacs?  
maybe I always rebound it in my Emacs days).


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=404444&group_id=5470


From noreply@sourceforge.net  Sat Mar 17 20:03:52 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Mar 2001 12:03:52 -0800
Subject: [Python-bugs-list] [ python-Bugs-409403 ] Require version in setup.py
Message-ID: <E14eMvY-00052A-00@usw-sf-web3.sourceforge.net>

Bugs item #409403, was updated on 2001-03-17 08:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409403&group_id=5470

Category: Distutils
Group: None
>Status: Closed
Priority: 5
Submitted By: A.M. Kuchling (akuchling)
Assigned to: A.M. Kuchling (akuchling)
Summary: Require version in setup.py

Initial Comment:
It should be an error to *not* have a version number
in the setup() call.

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2001-03-17 12:03

Message:
Logged In: YES 
user_id=11375

Fixed in revision 1.44 of distutils/dist.py


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409403&group_id=5470


From noreply@sourceforge.net  Sat Mar 17 20:15:51 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Mar 2001 12:15:51 -0800
Subject: [Python-bugs-list] [ python-Bugs-233253 ] build_ext: --define option doesn't work
Message-ID: <E14eN79-0001n8-00@usw-sf-web1.sourceforge.net>

Bugs item #233253, was updated on 2001-02-20 07:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=233253&group_id=5470

Category: Distutils
Group: None
>Status: Closed
Priority: 5
Submitted By: A.M. Kuchling (akuchling)
Assigned to: Greg Ward (gward)
Summary: build_ext: --define option doesn't work

Initial Comment:
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                                       

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2001-03-17 12:15

Message:
Logged In: YES 
user_id=11375

Fixed in revision 1.74 of distutils/commands/build_ext.py.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=233253&group_id=5470


From noreply@sourceforge.net  Sat Mar 17 21:45:13 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Mar 2001 13:45:13 -0800
Subject: [Python-bugs-list] [ python-Bugs-409448 ] Complex division is braindead
Message-ID: <E14eOVd-0002pL-00@usw-sf-web1.sourceforge.net>

Bugs item #409448, was updated on 2001-03-17 13:45
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409448&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Tim Peters (tim_one)
Summary: Complex division is braindead

Initial Comment:
>>> x = complex(1e200, 1e200)
>>> x/x
0j
>>> x = complex(1e-200, 1e-200)
>>> x/x
(1.#INF-1.#INDj)
>>> 

This is nothing new; it's always been this way; the 
algorithm we use is numerically naive, ignoring the 
possibility for overflow and underflow in internal 
intermediate results.  The results will vary across 
platforms in such cases, in unpredictable ways (the 
above was run on a WinTel box).


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409448&group_id=5470


From noreply@sourceforge.net  Sun Mar 18 01:40:50 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Mar 2001 17:40:50 -0800
Subject: [Python-bugs-list] [ python-Bugs-232606 ] 2.1a2 _tkinter build may pick up wrong Tcl/Tk versions
Message-ID: <E14eSBe-0007QC-00@usw-sf-web3.sourceforge.net>

Bugs item #232606, was updated on 2001-02-15 13:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=232606&group_id=5470

Category: Build
Group: None
Status: Closed
Priority: 5
Submitted By: Mark Favas (mfavas)
Assigned to: A.M. Kuchling (akuchling)
Summary: 2.1a2 _tkinter build may pick up wrong Tcl/Tk versions

Initial Comment:
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.


----------------------------------------------------------------------

>Comment By: Mark Favas (mfavas)
Date: 2001-03-17 17:40

Message:
Logged In: YES 
user_id=44979

Unfortunately, no - the _tkinter compile command is still
generated as:
cc -O -Olimit 1500 -DWITH_APPINIT=1 -I/usr/X11/include -I.
-I/blah/./Include -I/usr/local/include -IInclude/ -c
/blah/Modules/_tkinter.c -o
build/temp.osf1-V4.0-alpha-2.1/_tkinter.o

so a system with an earlier version of Tcl/Tk installed in
/usr/X11/include will pick up the includes (Tcl.h and Tk.h)
from there, rather than the later versions installed in
/usr/local/include. The link phase has a similar order, and,
since it looks for specific versions (-ltk8.0, for example)
is likely to pick up a library that doesn't match the
includes.

The other changes to setup.py to put
/usr/local/{include,lib} first in the search path are good
ones - they just don't apply to _tkinter. 



----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2001-03-17 11:53

Message:
Logged In: YES 
user_id=11375

>From looking at the setup.py code, I believe this problem 
should also be fixed by the change  to put /usr/local first
in inc_dirs and lib_dirs.  

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2001-02-23 08:45

Message:
The handling of include and lib directories has changed a bit; does it still pick up the wrong versions?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=232606&group_id=5470


From noreply@sourceforge.net  Sun Mar 18 05:29:22 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Mar 2001 21:29:22 -0800
Subject: [Python-bugs-list] [ python-Bugs-409355 ] Meta-class inheritance problem
Message-ID: <E14eVko-0000Uy-00@usw-sf-web3.sourceforge.net>

Bugs item #409355, was updated on 2001-03-17 02:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409355&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Priority: 5
Submitted By: Lorien Dunn (loriend)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: Meta-class inheritance problem

Initial Comment:
I've run into a bug in python 2.0. The real code that
the following pseudo code represents throws a
TypeError.

class MyDerivedClass(MyPurePythonClass,MyBoostClass):
        def __init__(self):
                MyPurePythonClass.__init__(self)
                MyBoostClass.__init__(self)

The problem occurs in MyPurePythonClass- Python says
"unbound method must be called with class instance 1st
argument". This makes sense: I'm passing a meta-class
instead of a class. David Abrahams (the main author of
boost::python) agrees that this is a Python problem,
and that it should affect Zope as well.

I think I've found the point in the python 2.0 sorce
where it occurs:


ceval.c, line 1816 (reformatted for clarity):

/*              BEGIN CODE SAMPLE               */

else
{
/* Unbound methods must be called with an instance of
the class (or a derived class) as first argument */

     if (na > 0 && (self = stack_pointer[-n]) != NULL
                && PyInstance_Check(self)
                && PyClass_IsSubclass((PyObject
*) 		 		   (((PyInstanceObject*)  self)->in_class),
class))
                  /* Handy-dandy */ ;
      else
      {
        PyErr_SetString(PyExc_TypeError, "unbound
method must be 		called with class instance 1st
argument");
        x = NULL;
        break;
      }
}

/*              END CODE SAMPLE         */


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-03-17 21:29

Message:
Logged In: YES 
user_id=31435

Assigned to Guido, because I bet JimF would refuse to take 
blame for this <wink>.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409355&group_id=5470


From noreply@sourceforge.net  Sun Mar 18 05:36:09 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Mar 2001 21:36:09 -0800
Subject: [Python-bugs-list] [ python-Bugs-409354 ] Meta-class inheritance problem
Message-ID: <E14eVrN-0000Xs-00@usw-sf-web3.sourceforge.net>

Bugs item #409354, was updated on 2001-03-17 02:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409354&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Closed
Priority: 5
Submitted By: Lorien Dunn (loriend)
Assigned to: Nobody/Anonymous (nobody)
Summary: Meta-class inheritance problem

Initial Comment:
I've run into a bug in python 2.0. The real code that
the following pseudo code represents throws a
TypeError.

class MyDerivedClass(MyPurePythonClass,MyBoostClass):
        def __init__(self):
                MyPurePythonClass.__init__(self)
                MyBoostClass.__init__(self)

The problem occurs in MyPurePythonClass- Python says
"unbound method must be called with class instance 1st
argument". This makes sense: I'm passing a meta-class
instead of a class. David Abrahams (the main author of
boost::python) agrees that this is a Python problem,
and that it should affect Zope as well.

I think I've found the point in the python 2.0 sorce
where it occurs:


ceval.c, line 1816 (reformatted for clarity):

/*              BEGIN CODE SAMPLE               */

else
{
/* Unbound methods must be called with an instance of
the class (or a derived class) as first argument */

     if (na > 0 && (self = stack_pointer[-n]) != NULL
                && PyInstance_Check(self)
                && PyClass_IsSubclass((PyObject
*) 		 		   (((PyInstanceObject*)  self)->in_class),
class))
                  /* Handy-dandy */ ;
      else
      {
        PyErr_SetString(PyExc_TypeError, "unbound
method must be 		called with class instance 1st
argument");
        x = NULL;
        break;
      }
}

/*              END CODE SAMPLE         */


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-03-17 21:36

Message:
Logged In: YES 
user_id=31435

Closed; it's a duplicate of 409355.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409354&group_id=5470


From noreply@sourceforge.net  Sun Mar 18 05:44:08 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Mar 2001 21:44:08 -0800
Subject: [Python-bugs-list] [ python-Bugs-408884 ] File not closed
Message-ID: <E14eVz6-0007hl-00@usw-sf-web1.sourceforge.net>

Bugs item #408884, was updated on 2001-03-15 11:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408884&group_id=5470

>Category: Windows
>Group: Platform-specific
>Status: Closed
Priority: 5
Submitted By: Charles Hixson (quixo)
Assigned to: Nobody/Anonymous (nobody)
Summary: File not closed

Initial Comment:
Python 2.1a2 (#10, Feb 2 2001, 16:01:03) [MSC 32 bit
(Intel)] on win32

OS Win95 4.00.950 B

In IDLE 0.6 I execute a script that is intended to
create a file.  An indexing error occurs (I used a
paren instead of a square bracket to access a
dictionary).  The program aborts:
Traceback (most recent call last):
  File "C:\Docs\TIP html\tipRec2Html.py", line 509, in ?
    test()
  File "C:\Docs\TIP html\tipRec2Html.py", line 439, in test
    laTitle = leadAgencies(leadAgncy)
TypeError: object is not callable: {'sonco': 'Son Co
Transit', 'santro ....

Rerunning the program yields:

Traceback (most recent call last):
  File "C:\Docs\TIP html\tipRec2Html.py", line 509, in ?
    test()
  File "C:\Docs\TIP html\tipRec2Html.py", line 415, in test
    os.unlink(here + '\html\' + fl)
OSError: [Errno 13] Permission denied: 'C:\Docs\TIP
html\html\hson.htm'

This is the file that was being created when the prior
error occured.  It appears that the file hasn't been
released.  This can be worked around by quitting IDLE
and re-executing it.

If you look at the code you'll probably see that I'm
new to Python.  I made some obvious silly decisions,
just to keep the code easier to think about.  The html1
file mainly declares a couple of methods for writing
out descriptions of HTML table cells, either with or
without titles.  (Sorry there was only room to include
one file... if I'd thought ahead I would have zipped them.)

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-03-17 21:44

Message:
Logged In: YES 
user_id=31435

Sorry, but I'm just closing this with a WontFix, and 
setting other fields to Windows and Platform-specific.

There are unbounded ways you can get yourself in trouble by 
writing scripts that don't work, and since IDLE is not an 
operating system it can't go cleaning up OS resources for 
you (IDLE has no idea which files you left open).

Restarting IDLE is the *proper* thing to do here.  Note 
that this is a Windows-specific problem because it's 
Windows that insists you can't unlink an open file; if you 
had done this under Linux instead, no problem.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408884&group_id=5470


From noreply@sourceforge.net  Sun Mar 18 05:48:06 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Mar 2001 21:48:06 -0800
Subject: [Python-bugs-list] [ python-Bugs-406563 ] test_long loops openbsd2.8 i386
Message-ID: <E14eW2w-0007kC-00@usw-sf-web1.sourceforge.net>

Bugs item #406563, was updated on 2001-03-06 19:16
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406563&group_id=5470

Category: Build
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Tim Peters (tim_one)
Summary: test_long loops openbsd2.8 i386

Initial Comment:
processor is a pentium 120.

build of python 2-1b1 on openbsd apparently works fine,
only hitch so far is test_long apparently looping
during make test, compiled using GCC 2.95.3 19991030
(prerelease).
I used the standard issue Openbsd 2.8 download
components.


No problems using python so far. 



----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-03-17 21:48

Message:
Logged In: YES 
user_id=31435

Assigned to me.  mwh asked for the right additional info on 
7 March.  If none is forthcoming by 21 March (two weeks 
from then), I'm simply going to close this.  Sounds like a 
compiler optimization bug (neither test_long nor the 
longint implementation code have changed recently, and 
there are no other reports of test_long failures).

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2001-03-07 04:23

Message:
Logged In: YES 
user_id=6656

can you 
(a) log in!
(b) try rebuilding without optimizations (things like
"compiled using GCC 2.95.3 19991030 (prerelease)" don't
really inspire confidence)
(c) gdb it and send a stack trace of where it hangs.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406563&group_id=5470


From noreply@sourceforge.net  Sun Mar 18 05:49:07 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Mar 2001 21:49:07 -0800
Subject: [Python-bugs-list] [ python-Bugs-406705 ] imaplib search() quoting search criteria
Message-ID: <E14eW3v-0007kl-00@usw-sf-web1.sourceforge.net>

Bugs item #406705, was updated on 2001-03-07 07:05
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406705&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Christian Kissner (b7kich)
>Assigned to: Skip Montanaro (montanaro)
Summary: imaplib search() quoting search criteria

Initial Comment:
Imaplib IMAP4.search() contains a bug in criteria
handling: when
sending a single word criterium it gets written to the
stream well: 
	M.search(None, 'ALL')
produces:
	GINH16 SEARCH
ALL                                         

But a criterium with a white space will be quoted:

	M.search(None,'TEXT Hello')
produces in the tcp stream:
	GINH17 SEARCH "TEXT Hello"

which gets rejected because quotes are only allowed
around
the string, not the criterium:
	GINH17 SEARCH TEXT "Hello"



----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-03-17 21:49

Message:
Logged In: YES 
user_id=31435

Assigned to Skip at random.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406705&group_id=5470


From noreply@sourceforge.net  Sun Mar 18 05:50:34 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Mar 2001 21:50:34 -0800
Subject: [Python-bugs-list] [ python-Bugs-406191 ] Mac OS X installation notes
Message-ID: <E14eW5K-0007m0-00@usw-sf-web1.sourceforge.net>

Bugs item #406191, was updated on 2001-03-05 19:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406191&group_id=5470

Category: Installation
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Mac OS X installation notes

Initial Comment:
I'm running a very recent Mac OS X build ("4K78"); here is 
what I found necessary in order to get 2.1b1 to build on that 
system.  It might be best to add notes about these things to 
the platform-specific part of the README.

First, though, please correct the spelling in the README
of "Mac OS X" -- the name has *two* spaces in it.  Spelling
it in a way inconsistent with Apple's intent makes it
harder (mac *os *x)  to find out where in the configure/
makefile it's mentioned.

Notes:


 - configure:
  OPT="-g -traditional-cpp"  ./configure --with-suffix=.exe --with-dyld


 - limit stacksize 2m
     (It defaults to a half-meg, and then one of the regular 
expression tests fails.)

 - disable the test_largefile test (I moved its source aside).
     This test should be enabled only on a Unix UFS filesystem.
 
- termios.h tries to define a bunch of things that do not exist 
on Mac OS X.

*** Modules/termios.c   Thu Mar  1 22:50:58 2001
--- ../Python-2.1b1-fixed/Modules/termios.c   Mon Mar  5 
15:43:05 2001
***************
*** 358,364 ****
        {"INLCR", INLCR},
        {"IGNCR", IGNCR},
        {"ICRNL", ICRNL},
!       {"IUCLC", IUCLC},
        {"IXON", IXON},
        {"IXANY", IXANY},
        {"IXOFF", IXOFF},
--- 358,364 ----
        {"INLCR", INLCR},
        {"IGNCR", IGNCR},
        {"ICRNL", ICRNL},
!       /* {"IUCLC", IUCLC}, No such thing on Mac OS X. */
        {"IXON", IXON},
        {"IXANY", IXANY},
        {"IXOFF", IXOFF},
***************
*** 366,405 ****
  
        /* struct termios.c_oflag constants */
        {"OPOST", OPOST},
!       {"OLCUC", OLCUC},
        {"ONLCR", ONLCR},
!       {"OCRNL", OCRNL},
!       {"ONOCR", ONOCR},
!       {"ONLRET", ONLRET},
!       {"OFILL", OFILL},
!       {"OFDEL", OFDEL},
!       {"NLDLY", NLDLY},
!       {"CRDLY", CRDLY},
!       {"TABDLY", TABDLY},
!       {"BSDLY", BSDLY},
!       {"VTDLY", VTDLY},
!       {"FFDLY", FFDLY},
  
        /* struct termios.c_oflag-related values (delay mask) */
!       {"NL0", NL0},
!       {"NL1", NL1},
!       {"CR0", CR0},
!       {"CR1", CR1},
!       {"CR2", CR2},
!       {"CR3", CR3},
!       {"TAB0", TAB0},
!       {"TAB1", TAB1},
!       {"TAB2", TAB2},
!       {"TAB3", TAB3},
  #ifdef XTABS
        {"XTABS", XTABS},
  #endif
!       {"BS0", BS0},
!       {"BS1", BS1},
!       {"VT0", VT0},
!       {"VT1", VT1},
!       {"FF0", FF0},
!       {"FF1", FF1},
  
        /* struct termios.c_cflag constants */
        {"CSIZE", CSIZE},
--- 366,405 ----
  
        /* struct termios.c_oflag constants */
        {"OPOST", OPOST},
!       /* {"OLCUC", OLCUC}, No such thing on Mac OS X. */
        {"ONLCR", ONLCR},
!       /* {"OCRNL", OCRNL}, No such thing on Mac OS X. */
!       /* {"ONOCR", ONOCR}, */
!       /* {"ONLRET", ONLRET}, */
!       /* {"OFILL", OFILL}, */
!       /* {"OFDEL", OFDEL}, */
!       /* {"NLDLY", NLDLY}, */
!       /* {"CRDLY", CRDLY}, */
!       /* {"TABDLY", TABDLY}, */
!       /* {"BSDLY", BSDLY}, */
!       /* {"VTDLY", VTDLY}, */
!       /* {"FFDLY", FFDLY}, */
  
        /* struct termios.c_oflag-related values (delay mask) */
!       /* {"NL0", NL0},
!           {"NL1", NL1},
!           {"CR0", CR0},
!           {"CR1", CR1},
!           {"CR2", CR2},
!           {"CR3", CR3},
!           {"TAB0", TAB0},
!           {"TAB1", TAB1},
!           {"TAB2", TAB2},
!           {"TAB3", TAB3}, */
  #ifdef XTABS
        {"XTABS", XTABS},
  #endif
!       /* {"BS0", BS0},
!          {"BS1", BS1},
!          {"VT0", VT0},
!          {"VT1", VT1},
!          {"FF0", FF0},
!          {"FF1", FF1}, */
  
        /* struct termios.c_cflag constants */
        {"CSIZE", CSIZE},


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-03-17 21:50

Message:
Logged In: YES 
user_id=31435

Assigned to Fred since he replied last.  I'd close it if 
you don't get a response soon.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-03-10 19:18

Message:
Logged In: YES 
user_id=3066

The version of termios in CVS already makes the right tests for all the definitions your patch affects, so the
termios module from CVS should work without further changes.  Please let us know if you have any further problems with termios.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-03-05 23:06

Message:
Logged In: YES 
user_id=21627

Can you produce a patch that does most of this
automatically? Ideally, such a patch would work so that no
other system is affected. E.g. instead of commenting-out
certain constants, an #ifdef would be more desirable.
Likewise, the compiler options are best put into
configure.in, in a way that they are used on all systems
requiring these settings, and ignored on all other systems.
That,of course, requires that a test is introduced to find
out whether you've got the right kind of system.

In addition, I'd prefer if the number of settings needed is
reduced to the absolute minimum. E.g. why is it *necessary*
to compiler Python with -g on Mac OS X? Also, if --with-dyld
is *mandatory* on Mac OS X, why can you specify it as an
option? On all other systems, not using dynamic loading is
not an option. OTOH, if the LDSHARED case of -nostdlib -r
(which you get when you omit --with-dyld) works fine on your
system, why is it necessary to specify --with-dyld.

In short, instead of giving long instructions how to do it
right, I'd prefer if Python configuration did it right on
its own. If you are unsure how to achieve this effect, I
suggest you ask on the pythonmac list. Please upload any
patch you come up with into the patch manager, adding a
comment here that a patch is available.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406191&group_id=5470


From noreply@sourceforge.net  Sun Mar 18 05:53:40 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Mar 2001 21:53:40 -0800
Subject: [Python-bugs-list] [ python-Bugs-407019 ] Python-2.1 does not compile under cygwin
Message-ID: <E14eW8K-0007nO-00@usw-sf-web1.sourceforge.net>

Bugs item #407019, was updated on 2001-03-08 06:02
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407019&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Tim Peters (tim_one)
Summary: Python-2.1 does not compile under cygwin

Initial Comment:
configure runs well.

I use:
> g++ --version
2.95.2

Errors are occuring in tokenizer.c. the pointer-variable new seems to be misinterpreted. After 
renaming it to newptr in line 192 ans subsequent lines, tokenizer.c.

The next errors occure in Parser/myreadline.c:

Parser/myreadline.c: In function `char * PyOS_StdioReadline(char *)':
Parser/myreadline.c:62: ANSI C++ forbids implicit conversion from `void *' in as
signment
Parser/myreadline.c:99: ANSI C++ forbids implicit conversion from `void *' in as
signment
Parser/myreadline.c:109: ANSI C++ forbids implicit conversion from `void *' in r
eturn
make: *** [Parser/myreadline.o] Error 1



----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-03-17 21:53

Message:
Logged In: YES 
user_id=31435

Sent email to Jason asking him to look at this.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-03-17 11:47

Message:
Logged In: YES 
user_id=31435

Try gcc?  Jason Tishler did the Cygwin port, and said it 
works fine.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-03-16 10:02

Message:
Logged In: YES 
user_id=31392

cygwin ends with "win." right, tim?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407019&group_id=5470


From noreply@sourceforge.net  Sun Mar 18 06:03:17 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Mar 2001 22:03:17 -0800
Subject: [Python-bugs-list] [ python-Bugs-408271 ] crash in shelve module
Message-ID: <E14eWHd-0000k5-00@usw-sf-web3.sourceforge.net>

Bugs item #408271, was updated on 2001-03-13 10:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408271&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Barry Warsaw (bwarsaw)
Summary: crash in shelve module

Initial Comment:
While using shelve module on SGI
sloth 271> uname -a
IRIX64 sloth 6.5 04191225 IP27

my python program crashes and
I am getting following error message:

  File "/usr/local/lib/python1.5/shelve.py", line 71,
in __setitem__
    self.dict[key] = f.getvalue()
bsddb.error: (0, 'Error')

At the time the size of the "shelve" file was quite big
(maybe this is a problem ?)
sloth 267> ls -lt *shelve
-rw-r--r--    1 ryszard  cdiApps   85778432 Mar 13
12:27 recap_mddr.shelve


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-03-17 22:03

Message:
Logged In: YES 
user_id=31435

Assigned to Barry because there's not enough info here to 
do anything about it <wink>.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408271&group_id=5470


From noreply@sourceforge.net  Sun Mar 18 06:04:14 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Mar 2001 22:04:14 -0800
Subject: [Python-bugs-list] [ python-Bugs-408820 ] 'install -d' fails on BSDI systems.
Message-ID: <E14eWIY-0000kW-00@usw-sf-web3.sourceforge.net>

Bugs item #408820, was updated on 2001-03-15 08:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408820&group_id=5470

Category: Installation
Group: Platform-specific
Status: Open
Priority: 6
Submitted By: Thomas Wouters (twouters)
>Assigned to: A.M. Kuchling (akuchling)
Summary: 'install -d' fails on BSDI systems.

Initial Comment:
Apparently the Makefile was changed to use 'install -d'
to create directories. This does not work on BSDI. It
seems to be an autoconf failure (since configure.in
just contains 'AC_PROG_INSTALL' but I haven't
experienced this before, with other software or with
Python.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-03-17 22:04

Message:
Logged In: YES 
user_id=31435

Assigned to Andrew because he's been known to succeed when 
installing things <ahem>.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408820&group_id=5470


From noreply@sourceforge.net  Sun Mar 18 06:14:01 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Mar 2001 22:14:01 -0800
Subject: [Python-bugs-list] [ python-Bugs-409230 ] Python 2.1b1 dumps core on list compr.
Message-ID: <E14eWS1-0007zs-00@usw-sf-web1.sourceforge.net>

Bugs item #409230, was updated on 2001-03-16 14:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409230&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
>Priority: 7
Submitted By: Viktor Ferenczi (complex)
>Assigned to: Jeremy Hylton (jhylton)
Summary: Python 2.1b1 dumps core on list compr.

Initial Comment:
Hi!

Python 2.1b1 dumps core when executing the following
statement:

print [[y for y in [x,x+1]] for x in [1,3]]

(Should print: [[1,2],[3,4]])

The problem may be related to variable scope resolving
code, because python reports "unknown scope for _[2] in
?(0)" before dumping core. This bug makes impossible to
use a list comprehension as the expression field of
another one.


-Complex-

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-03-17 22:14

Message:
Logged In: YES 
user_id=31435

Assigned to Jeremy.  Boosted priority.  Note that mwh says 
this is a dup of 406049 (but this is clearly not the same 
test case).  Whatever, I confirmed that this specific case 
still crashes.

Fatal Python error: unknown scope for _[2] in ?(0) in 
<stdin>


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2001-03-17 09:55

Message:
Logged In: YES 
user_id=6656

this is a dup of

[ #406049 ] crash on nested listcomps

so someone with appropriate privilege should mark it as such.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409230&group_id=5470


From noreply@sourceforge.net  Sun Mar 18 06:20:19 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Mar 2001 22:20:19 -0800
Subject: [Python-bugs-list] [ python-Bugs-409311 ] Python 2.1b1 re module is broken!
Message-ID: <E14eWY7-000840-00@usw-sf-web1.sourceforge.net>

Bugs item #409311, was updated on 2001-03-16 19:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409311&group_id=5470

Category: Regular Expressions
Group: None
Status: Open
Priority: 5
Submitted By: Gregory P. Smith (greg)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.1b1 re module is broken!

Initial Comment:
the following should -not- match:

$ python
Python 2.1b1 (#1, Mar 12 2001, 18:20:53) 
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> reg = r"(?im)<dtml-var\s+([a-z_0-9]+?)\s*>"
>>> str = '<dtml-var
expr="Presentation.show(\'start\')">'
>>> import re                                
>>> re.match(reg, str)                       
<SRE_Match object at 0x810d9d0>


In python 1.5.2 and 2.0 this works fine.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-03-17 22:20

Message:
Logged In: YES 
user_id=31435

Just adding a comment to force SF to send this as email (so 
I can read it).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409311&group_id=5470


From noreply@sourceforge.net  Sun Mar 18 06:21:14 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Mar 2001 22:21:14 -0800
Subject: [Python-bugs-list] [ python-Bugs-409331 ] distutils does not support ObjC
Message-ID: <E14eWZ0-00084S-00@usw-sf-web1.sourceforge.net>

Bugs item #409331, was updated on 2001-03-16 22:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409331&group_id=5470

>Category: Distutils
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Greg Ward (gward)
Summary: distutils does not support ObjC

Initial Comment:
Via this patch....

Index: unixccompiler.py
=======================================
============================
RCS file: /cvsroot/python/python/dist/src/Lib/
distutils/unixccompiler.py,v
retrieving revision 1.32
diff -r1.32 unixccompiler.py
70c70
<     src_extensions = [".c",".C",".cc",".cxx",".cpp"]
---
>     src_extensions = 
[".c",".C",".cc",".cxx",".cpp",".m"]


... I added ".m" as the list of suffixes to compile as 
C source on Mac OS X.  This worked just fine and 
allowed the PyObjC module to compile via a 
normal distutils based setup.py script.

I suspect that there may need to be flags?

In general, the whole makesetup mechanism 
should be coupled with distutils because 
makesetup has a bunch more knowledge about 
the specifics of dealing with certain source file 
types!???!!

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-03-17 22:21

Message:
Logged In: YES 
user_id=31435

Assigned to Greg Ward and changed Category to Distutils.

----------------------------------------------------------------------

Comment By: Bill Bumgarner (bbum)
Date: 2001-03-16 23:00

Message:
Logged In: YES 
user_id=103811

That  was submitted by me [bbum@codefab.com] in 
case anywhere needs to followup.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409331&group_id=5470


From noreply@sourceforge.net  Sun Mar 18 06:21:56 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Mar 2001 22:21:56 -0800
Subject: [Python-bugs-list] [ python-Bugs-409419 ] gzip.py seek and tell methods are counter-productive (and seek is broken anyway)
Message-ID: <E14eWZg-00084j-00@usw-sf-web1.sourceforge.net>

Bugs item #409419, was updated on 2001-03-17 09:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409419&group_id=5470

>Category: Extension Modules
Group: None
Status: Open
Priority: 5
Submitted By: Matthew Mueller (donut)
>Assigned to: A.M. Kuchling (akuchling)
Summary: gzip.py seek and tell methods are counter-productive (and seek is broken anyway)

Initial Comment:
gzip.open returns an object that emulates a file type.  However, it does
not support seeking or telling.  That is not the problem, what is the
problem is that even though it does not support them, it has the methods
there anyway.  This means user code can not easily do a try: ... except:
AttributeError, to test if the object supports these methods.  Instead
it would have to except on IOError, and have no way of knowing if it was
a real file error. (other than the kludge of examing the error string)

Therefore, I believe it would be more correct if these methods were
removed entirely, or at least replace the exception with AttributeError
instead of IOError.

Oh, and if they aren't removed, the seek method should at least accept
an arg since as it is now it will never raise its desired exception
anyway.



----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-03-17 22:21

Message:
Logged In: YES 
user_id=31435

Assigned to Andrew, our resident gzip fan.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409419&group_id=5470


From noreply@sourceforge.net  Sun Mar 18 06:23:31 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Mar 2001 22:23:31 -0800
Subject: [Python-bugs-list] [ python-Bugs-409430 ] pydoc shouldn't use #!/usr/bin/env
Message-ID: <E14eWbD-00085a-00@usw-sf-web1.sourceforge.net>

Bugs item #409430, was updated on 2001-03-17 10:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409430&group_id=5470

Category: Installation
Group: None
Status: Open
Priority: 5
Submitted By: Michael Hudson (mwh)
>Assigned to: A.M. Kuchling (akuchling)
Summary: pydoc shouldn't use #!/usr/bin/env

Initial Comment:
I've moaned about this on python-dev but I want to make
sure it doesn't get forgotten.

I've just built from CVS, installed in /usr/local, and:

$ pydoc -g
Traceback (most recent call last):
  File "/usr/local/bin/pydoc", line 3, in ?
    import pydoc
ImportError: No module named pydoc

because the /usr/bin/env python thing hits the older
python in /usr first.

Don't really know how best to implement this, not being
a distutils whiz.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-03-17 22:23

Message:
Logged In: YES 
user_id=31435

Assigned to Andrew because I seem to recall he wrote the 
pydoc script.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409430&group_id=5470


From noreply@sourceforge.net  Sun Mar 18 06:33:20 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Mar 2001 22:33:20 -0800
Subject: [Python-bugs-list] [ python-Bugs-409311 ] Python 2.1b1 re module is broken!
Message-ID: <E14eWki-0008BG-00@usw-sf-web1.sourceforge.net>

Bugs item #409311, was updated on 2001-03-16 19:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409311&group_id=5470

Category: Regular Expressions
Group: None
Status: Open
>Priority: 7
Submitted By: Gregory P. Smith (greg)
>Assigned to: Fredrik Lundh (effbot)
Summary: Python 2.1b1 re module is broken!

Initial Comment:
the following should -not- match:

$ python
Python 2.1b1 (#1, Mar 12 2001, 18:20:53) 
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> reg = r"(?im)<dtml-var\s+([a-z_0-9]+?)\s*>"
>>> str = '<dtml-var
expr="Presentation.show(\'start\')">'
>>> import re                                
>>> re.match(reg, str)                       
<SRE_Match object at 0x810d9d0>


In python 1.5.2 and 2.0 this works fine.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-03-17 22:33

Message:
Logged In: YES 
user_id=31435

Assigned to Fredrik and boosted priority.

Gregory, it's hard to see exactly what your str vrbl 
contains because there appears to be an embedded newline in 
it.  Whatever, if I change your

    +?

to the semantically equivalent

    *

then the problem goes away for what *I* guessed you 
intended str to contain.  The

    [a-z_0-9]

part is also better written as

    \w

(since you're using the ?i flag, same thing).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-03-17 22:20

Message:
Logged In: YES 
user_id=31435

Just adding a comment to force SF to send this as email (so 
I can read it).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409311&group_id=5470


From noreply@sourceforge.net  Sun Mar 18 08:24:48 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Mar 2001 00:24:48 -0800
Subject: [Python-bugs-list] [ python-Bugs-409448 ] Complex division is braindead
Message-ID: <E14eYUa-0001eG-00@usw-sf-web2.sourceforge.net>

Bugs item #409448, was updated on 2001-03-17 13:45
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409448&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Closed
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Tim Peters (tim_one)
Summary: Complex division is braindead

Initial Comment:
>>> x = complex(1e200, 1e200)
>>> x/x
0j
>>> x = complex(1e-200, 1e-200)
>>> x/x
(1.#INF-1.#INDj)
>>> 

This is nothing new; it's always been this way; the 
algorithm we use is numerically naive, ignoring the 
possibility for overflow and underflow in internal 
intermediate results.  The results will vary across 
platforms in such cases, in unpredictable ways (the 
above was run on a WinTel box).


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-03-18 00:24

Message:
Logged In: YES 
user_id=31435

Now less braindead.

Lib/test/test_complex.py: initial revision: 1.1
Lib/test/output/test_complex: initial revision: 1.1
Objects/complexobject.c: new revision: 2.35


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409448&group_id=5470


From noreply@sourceforge.net  Sun Mar 18 09:13:09 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Mar 2001 01:13:09 -0800
Subject: [Python-bugs-list] [ python-Bugs-408085 ] urllib.py https redirect-302 bug
Message-ID: <E14eZFN-0001KA-00@usw-sf-web1.sourceforge.net>

Bugs item #408085, was updated on 2001-03-12 17:05
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408085&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Dustin Boswell (boswell)
Assigned to: Moshe Zadka (moshez)
Summary: urllib.py https redirect-302 bug

Initial Comment:
Using urllib.urlopen("https://...") seems 
to hang because of a redirect problem. Looks 
like its trying to follow the redirect with 
http not https. 

>>> import urllib 
>>> params = ... 
>>> f = urllib.urlopen("https://...", params) 
connect: (securesite.com, 80) 
#a printout from httplib, line 354 

Traceback (most recent call last): 
File "<stdin>", line 1, in ? 
File "/usr/local/lib/python2.0/urllib.py", line 63, in
urlopen 
return _urlopener.open(url, data) 
File "/usr/local/lib/python2.0/urllib.py", line 168, in
open 
return getattr(self, name)(url, data) 
File "/usr/local/lib/python2.0/urllib.py", line 367, in
open_https 
data) 
File "/usr/local/lib/python2.0/urllib.py", line 301, in
http_error 
result = method(url, fp, errcode, errmsg, headers,
data) 
File "/usr/local/lib/python2.0/urllib.py", line 537, in
http_error_302 
return self.open(newurl, data) 
File "/usr/local/lib/python2.0/urllib.py", line 168, in
open 
return getattr(self, name)(url, data) 
File "/usr/local/lib/python2.0/urllib.py", line 269, in
open_http 
h.putrequest('POST', selector) 
File "/usr/local/lib/python2.0/httplib.py", line 428,
in putrequest 
self.send(str) 
File "/usr/local/lib/python2.0/httplib.py", line 370,
in send 
self.connect() 
File "/usr/local/lib/python2.0/httplib.py", line 354,
in connect 
self.sock.connect((self.host, self.port)) 
KeyboardInterrupt 
>>> 

----------------------------------------------------------------------

>Comment By: Moshe Zadka (moshez)
Date: 2001-03-18 01:13

Message:
Logged In: YES 
user_id=11645

Errr....I'm not sure I see the bug. Perhaps the "Location"
header actually contained an "http://" URL? If you can give
me the site or more information (like a printout of newurl),
I can probably be of more help.

In testing (sadly, against a server inside a firewall, so I
cannot give the URL) I have found that it seems to work.

One thing, that may or may not have to do with your problem:
when POSTing, a 302 means "POST to that other URL", not
"GET that other URL". Many webserver writers seem to ignore
this, and many browsers compensate for that server bug.
urllib2 does *not* compensate for that bug -- I haven't
thought through whether *that* may be the explanation.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408085&group_id=5470


From noreply@sourceforge.net  Sun Mar 18 09:14:00 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Mar 2001 01:14:00 -0800
Subject: [Python-bugs-list] [ python-Bugs-406683 ] typos in urllib2 ( cvs )
Message-ID: <E14eZGC-0001Km-00@usw-sf-web1.sourceforge.net>

Bugs item #406683, was updated on 2001-03-07 05:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406683&group_id=5470

Category: Python Library
Group: None
>Status: Closed
Priority: 5
Submitted By: Bernd S. Brentrup (winnegan)
Assigned to: Moshe Zadka (moshez)
Summary: typos in urllib2 ( cvs )

Initial Comment:
urllib2.ProxyHandler fails due to typos when using proxy 
autthentication, patch included.


----------------------------------------------------------------------

>Comment By: Moshe Zadka (moshez)
Date: 2001-03-18 01:14

Message:
Logged In: YES 
user_id=11645

Fixed. (Did not use the patch -- fixed it myself)


----------------------------------------------------------------------

Comment By: Eduardo Fernandez Corrales (ejfc)
Date: 2001-03-08 09:59

Message:
Logged In: YES 
user_id=169128

I have corrected the patch to reflect proper Basic 
Authentication:

--- /var/local/cvs/python/dist/src/Lib/urllib2.py	Thu 
Mar  1 09:46:07 2001
+++ /usr/local/lib/python2.1/urllib2.py	Thu Mar  8 17:23:31 
2001
@@ -477,8 +477,8 @@
         host, XXX = splithost(r_type)
         if '@' in host:
             user_pass, host = host.split('@', 1)
-            user_pass = base64.encode_string(unquote
(user_passw)).strip()
-            req.addheader('Proxy-Authorization', user_pass)
+            user_pass = "Basic " + base64.encodestring
(unquote(user_pass)).strip()
+            req.add_header('Proxy-Authorization', 
user_pass)
         host = unquote(host)
         req.set_proxy(host, type)
         if orig_type == type:

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406683&group_id=5470


From noreply@sourceforge.net  Sun Mar 18 09:22:20 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Mar 2001 01:22:20 -0800
Subject: [Python-bugs-list] [ python-Bugs-407783 ] urllib2: AbstractHTTPHandler limits flexible client implementations
Message-ID: <E14eZOG-0001xn-00@usw-sf-web3.sourceforge.net>

Bugs item #407783, was updated on 2001-03-11 16:43
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407783&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 4
Submitted By: Bill Bumgarner (bbum)
Assigned to: Moshe Zadka (moshez)
Summary: urllib2: AbstractHTTPHandler limits flexible client implementations

Initial Comment:
The implementation of the do_open() method on the AbstractHTTPHandler class contains a couple of "features" that could be considered to be "bugs".  In any case, each time I have wanted to use urllib2 for relatively straightforward development of an HTTP client, I have had to effectively replace the HTTPHandler with one that reimplements do_open() (or http_open() in 2.0).  Maybe my usage is not the norm-- in any case, the more information, the better...

Specifics (all names in context of Python 2.1):

- AbstractHTTPHandler does not allow for anything but GET or POST requests.   GET is the default and POST happens anytime the request object contains data to be passed to the server.

This limitation is the only thing that stands in the way of using the AbstractHTTPHandler *directly* to implement, say, a WebDAV client or to do something like a site sucker that uses the HEAD method to determine if content has changed.

- [this is likely a bug]  the method will throw an exception if *any* response is received from the server other than 200.   However, HTTP defines that all 2XX responses should be treated as successful. 

In any case, there are *a lot* of contexts within which a non-200 response may be treated as a 'success' of some sort or another.  Regardless, it is really outside of the scope of the AbstractHTTPHandler's implementation to make the success/failure decision-- it should simply return  the same thing regardless of the response status.

- [a bug?] Whenever an exception is raised (a non-200 code is received), the status code and reason (as provided by the server) are both lost. 

I see that moshez has been primarily responsible for recent changes surrounding this code.  I would be happy to contribute to the evolution of the code;  please feel free to contact me directly.


----------------------------------------------------------------------

>Comment By: Moshe Zadka (moshez)
Date: 2001-03-18 01:22

Message:
Logged In: YES 
user_id=11645

None of these can really be classified as "bugs" rather then
functionality enhancement requests, and this is something
I'm not sure I want to do this close to the second beta.

BTW, one thing I'm sure I *don't* want to change -- handling
of 20x codes. If you want to handle 201/206/whatever, then
just handle them. With some __getattr__ trickery, you can
have a class that handles all http_error_20x errors, so this
is *easy* for 3rd party urllib2 extensions to add.

Regarding explicitly determining the command: just put the
command inside the request object, and use it in your
own HTTPHandler/HTTPSHandler. This may be done in the next
version of urllib2 (for 2.2). At that time I might also add
the feature that other encodings (not just
application/x-www-form-urlencoded, but also
multipart/form-data) will be supported.



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-03-16 10:43

Message:
Logged In: YES 
user_id=31392

I haven't had any spare cycles to devote to urllib2 this
year.  Perhaps Moshe can be of more help in the near term. 
Following the 2.1 release, I may have more time.

I never used urllib2 it a situation that produced anything
other than vanilla responses -- 200, 401, etc.  I'm not to
surprised to hear that there are problems with 2XX cases.

Can you post some examples of the sorts of things you want
to do?  It sounds reasonable in the abstract, but some code
would help.  If not in this patch archive, perhaps on
comp.lang.python?


----------------------------------------------------------------------

Comment By: Bill Bumgarner (bbum)
Date: 2001-03-11 19:59

Message:
Logged In: YES 
user_id=103811

I realized that the exception throw behaviour is more fundamental to the underlying implementation than may have been indicated in the above description.  In particular, throwing an HTTP exception when handling a 401 is key to making the various Authentication Handlers work.

I still feel that the behaviour should be normalized across all requests such that the callee is responsible for determining error conditions or, at the lest, has access to the same data in a relatively similar format upon success or failure.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407783&group_id=5470


From noreply@sourceforge.net  Sun Mar 18 09:24:03 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Mar 2001 01:24:03 -0800
Subject: [Python-bugs-list] [ python-Bugs-225217 ] urllib2.py and proxies (Python 2.0)
Message-ID: <E14eZPv-0001yZ-00@usw-sf-web3.sourceforge.net>

Bugs item #225217, was updated on 2000-12-09 22:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=225217&group_id=5470

Category: Python Library
Group: None
>Status: Closed
Priority: 5
Submitted By: The Written Word (china) (tww-china)
Assigned to: Moshe Zadka (moshez)
Summary: urllib2.py and proxies (Python 2.0)

Initial Comment:
Consider the following program:

  import os, sys, urllib2
  from urllib2 import urlopen
        
  os.environ['http_proxy'] = 'http://[HOST]:5865'
   
  authinfo = urllib2.HTTPBasicAuthHandler ()
  authinfo.add_password ('[REALM]', 'http://[URL]', '[login]', 
  '[password]')
        
  opener = urllib2.build_opener (authinfo)
  urllib2.install_opener (opener)

  url = urlopen ('http://[URL]/')
  print url.info ()
  url.close ()

Urllib2.py does not work if we wish to do BASIC authentication to a URL through a proxy. Chances are it also will not work if the proxy requires BASIC authentication too and the URL requires BASIC authentication. Here's the error I receive (Solaris 7/SPARC but platform does not matter):

    File "/tmp/a.py", line 15, in ?                          
      url = urlopen ('http://updates.thewrittenword.com/')
    File "/opt/TWWfsw/pkgutils12/lib/python20/lib/python2.0/urllib2.py",
  line 137, in urlopen
      return _opener.open(url, data)
    File "/opt/TWWfsw/pkgutils12/lib/python20/lib/python2.0/urllib2.py",
  line 325, in open
      '_open', req)
    File "/opt/TWWfsw/pkgutils12/lib/python20/lib/python2.0/urllib2.py",
  line 304, in _call_chain
      result = func(*args)
    File "/opt/TWWfsw/pkgutils12/lib/python20/lib/python2.0/urllib2.py",
  line 764, in http_open
      return self.parent.error('http', req, fp, code, msg, hdrs)
    File "/opt/TWWfsw/pkgutils12/lib/python20/lib/python2.0/urllib2.py",
  line 351, in error
      return self._call_chain(*args)
    File "/opt/TWWfsw/pkgutils12/lib/python20/lib/python2.0/urllib2.py",
  line 304, in _call_chain
      result = func(*args)
    File "/opt/TWWfsw/pkgutils12/lib/python20/lib/python2.0/urllib2.py",
  line 430, in http_error_default
      raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
  urllib2.HTTPError: HTTP Error 401: Authorization Required


----------------------------------------------------------------------

>Comment By: Moshe Zadka (moshez)
Date: 2001-03-18 01:24

Message:
Logged In: YES 
user_id=11645

Fixed in 2.1b1

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-03-06 03:24

Message:
Logged In: NO 

alike for $ftp_proxy:
  File "/usr/local/lib/python2.0/urllib.py", line 61, in
urlopen
    return _urlopener.open(url)
  File "/usr/local/lib/python2.0/urllib.py", line 166, in
open
    return getattr(self, name)(url)
  File "/usr/local/lib/python2.0/urllib.py", line 416, in
open_ftp
    host, path = splithost(url)
  File "/usr/local/lib/python2.0/urllib.py", line 885, in
splithost
    match = _hostprog.match(url)
TypeError: expected string or buffer


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=225217&group_id=5470


From noreply@sourceforge.net  Sun Mar 18 10:30:03 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Mar 2001 02:30:03 -0800
Subject: [Python-bugs-list] [ python-Bugs-232460 ] SSL Support (Apparently) Broken on Solaris
Message-ID: <E14eaRn-0002PF-00@usw-sf-web2.sourceforge.net>

Bugs item #232460, was updated on 2001-02-14 19:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=232460&group_id=5470

Category: Extension Modules
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: David M. Beazley (beazley)
Assigned to: A.M. Kuchling (akuchling)
Summary: SSL Support (Apparently) Broken on Solaris

Initial Comment:
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.

----------------------------------------------------------------------

>Comment By: Moshe Zadka (moshez)
Date: 2001-03-18 02:30

Message:
Logged In: YES 
user_id=11645

I just want to me-too Neil, since I submitted the original
patch. I think it *did* fix problems on Solaris, as long
as the user is running EGD and set up RANDFILE env. variable
properly. Otherwise, you won't be getting connect errors,
but a warning from Python about using a non-secure way to
generate seed.
(For the record, the problem is that Solaris doesn't have a
/dev/urandom like Linux does)

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2001-03-02 07:49

Message:
Logged In: YES 
user_id=35752

It looks like patch "[ #405101 ] Add Random Seeding to
OpenSSL" might fix this.  Assigning to Andrew since he
is assigned that patch too.


----------------------------------------------------------------------

Comment By: David M. Beazley (beazley)
Date: 2001-02-15 06:12

Message:
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


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=232460&group_id=5470


From noreply@sourceforge.net  Sun Mar 18 10:34:55 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Mar 2001 02:34:55 -0800
Subject: [Python-bugs-list] [ python-Bugs-215026 ] SSL features undocumented
Message-ID: <E14eaWV-0002Qu-00@usw-sf-web2.sourceforge.net>

Bugs item #215026, was updated on 2000-09-21 15:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=215026&group_id=5470

Category: Documentation
Group: None
Status: Open
Priority: 3
Submitted By: Martin v. Löwis (loewis)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: SSL features undocumented

Initial Comment:
The socket.ssl function, and the SSL objects, are not documented.

----------------------------------------------------------------------

>Comment By: Moshe Zadka (moshez)
Date: 2001-03-18 02:34

Message:
Logged In: YES 
user_id=11645

Fred, if any of the guys in PythonLabs has some spare times
and a windows machine, then inside the RAND_status() line,
you should put right after the USE_EGD #endif something like

#ifdef <whatever says it's windows>
RAND_screen()
#endif

I don't want to make this a formal patch submission because
I don't have any windows machine to test it on...

(And if we make an ssl module, it should just have a
RAND_* functions wrapped up and have all the smarts in
socket.py/ssl.py/<whatever>.

I don't have cycles to work on this, but this seemed like
a good place to braindump

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2000-10-12 19:41

Message:
I should note that the SSL support in the socket module was discussed briefly at a PythonLabs meeting a few weeks ago in the context of a bug report complaining that the SSL code here wasn't portable to Windows.

We decided that SSL support probably belonged in a separate module in the first place, so all this might change in some future release.  Especially if anyone would like to fund some work on getting SSL support working across platforms.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2000-09-21 20:46

Message:
Low priority for 2.0, but reasonable patches will be considered.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=215026&group_id=5470


From noreply@sourceforge.net  Sun Mar 18 10:34:54 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Mar 2001 02:34:54 -0800
Subject: [Python-bugs-list] [ python-Bugs-409230 ] Python 2.1b1 dumps core on list compr.
Message-ID: <E14eaWU-000286-00@usw-sf-web1.sourceforge.net>

Bugs item #409230, was updated on 2001-03-16 14:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409230&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Priority: 7
Submitted By: Viktor Ferenczi (complex)
Assigned to: Jeremy Hylton (jhylton)
Summary: Python 2.1b1 dumps core on list compr.

Initial Comment:
Hi!

Python 2.1b1 dumps core when executing the following
statement:

print [[y for y in [x,x+1]] for x in [1,3]]

(Should print: [[1,2],[3,4]])

The problem may be related to variable scope resolving
code, because python reports "unknown scope for _[2] in
?(0)" before dumping core. This bug makes impossible to
use a list comprehension as the expression field of
another one.


-Complex-

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2001-03-18 02:34

Message:
Logged In: YES 
user_id=6656

Well, no, it's not the same test case, but it is the same
problem.  It also doesn't crash if you apply patch #406076,
which I wrote to fix #406049.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-03-17 22:14

Message:
Logged In: YES 
user_id=31435

Assigned to Jeremy.  Boosted priority.  Note that mwh says 
this is a dup of 406049 (but this is clearly not the same 
test case).  Whatever, I confirmed that this specific case 
still crashes.

Fatal Python error: unknown scope for _[2] in ?(0) in 
<stdin>


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2001-03-17 09:55

Message:
Logged In: YES 
user_id=6656

this is a dup of

[ #406049 ] crash on nested listcomps

so someone with appropriate privilege should mark it as such.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409230&group_id=5470


From noreply@sourceforge.net  Sun Mar 18 11:15:59 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Mar 2001 03:15:59 -0800
Subject: [Python-bugs-list] [ python-Bugs-409230 ] Python 2.1b1 dumps core on list compr.
Message-ID: <E14ebAF-0002aA-00@usw-sf-web1.sourceforge.net>

Bugs item #409230, was updated on 2001-03-16 14:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409230&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Priority: 7
Submitted By: Viktor Ferenczi (complex)
Assigned to: Jeremy Hylton (jhylton)
Summary: Python 2.1b1 dumps core on list compr.

Initial Comment:
Hi!

Python 2.1b1 dumps core when executing the following
statement:

print [[y for y in [x,x+1]] for x in [1,3]]

(Should print: [[1,2],[3,4]])

The problem may be related to variable scope resolving
code, because python reports "unknown scope for _[2] in
?(0)" before dumping core. This bug makes impossible to
use a list comprehension as the expression field of
another one.


-Complex-

----------------------------------------------------------------------

>Comment By: Moshe Zadka (moshez)
Date: 2001-03-18 03:15

Message:
Logged In: YES 
user_id=11645

Here is a patch to fix the problem.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2001-03-18 02:34

Message:
Logged In: YES 
user_id=6656

Well, no, it's not the same test case, but it is the same
problem.  It also doesn't crash if you apply patch #406076,
which I wrote to fix #406049.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-03-17 22:14

Message:
Logged In: YES 
user_id=31435

Assigned to Jeremy.  Boosted priority.  Note that mwh says 
this is a dup of 406049 (but this is clearly not the same 
test case).  Whatever, I confirmed that this specific case 
still crashes.

Fatal Python error: unknown scope for _[2] in ?(0) in 
<stdin>


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2001-03-17 09:55

Message:
Logged In: YES 
user_id=6656

this is a dup of

[ #406049 ] crash on nested listcomps

so someone with appropriate privilege should mark it as such.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409230&group_id=5470


From noreply@sourceforge.net  Sun Mar 18 11:38:29 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Mar 2001 03:38:29 -0800
Subject: [Python-bugs-list] [ python-Bugs-409311 ] Python 2.1b1 re module is broken!
Message-ID: <E14ebW1-0002qz-00@usw-sf-web2.sourceforge.net>

Bugs item #409311, was updated on 2001-03-16 19:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409311&group_id=5470

Category: Regular Expressions
Group: None
Status: Open
Priority: 7
Submitted By: Gregory P. Smith (greg)
Assigned to: Fredrik Lundh (effbot)
Summary: Python 2.1b1 re module is broken!

Initial Comment:
the following should -not- match:

$ python
Python 2.1b1 (#1, Mar 12 2001, 18:20:53) 
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> reg = r"(?im)<dtml-var\s+([a-z_0-9]+?)\s*>"
>>> str = '<dtml-var
expr="Presentation.show(\'start\')">'
>>> import re                                
>>> re.match(reg, str)                       
<SRE_Match object at 0x810d9d0>


In python 1.5.2 and 2.0 this works fine.


----------------------------------------------------------------------

>Comment By: Moshe Zadka (moshez)
Date: 2001-03-18 03:38

Message:
Logged In: YES 
user_id=11645

Here is a simpler test case which shows the same
problem:

>>> str, r
('e=>', '(e+?)>')
>>> re.match(r, str)
<SRE_Match object at 0x4015f2e0>
>>> pre.match(r, str)
>>> 

If we lose the laziness (make the pattern "(e+)>") then it
works OK.

So the crucial problem seems to be the compilation/execution
of the lazy patterns, *not* the compilation/execution of
character classes.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-03-17 22:33

Message:
Logged In: YES 
user_id=31435

Assigned to Fredrik and boosted priority.

Gregory, it's hard to see exactly what your str vrbl 
contains because there appears to be an embedded newline in 
it.  Whatever, if I change your

    +?

to the semantically equivalent

    *

then the problem goes away for what *I* guessed you 
intended str to contain.  The

    [a-z_0-9]

part is also better written as

    \w

(since you're using the ?i flag, same thing).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-03-17 22:20

Message:
Logged In: YES 
user_id=31435

Just adding a comment to force SF to send this as email (so 
I can read it).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409311&group_id=5470


From noreply@sourceforge.net  Sun Mar 18 11:46:11 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Mar 2001 03:46:11 -0800
Subject: [Python-bugs-list] [ python-Bugs-405999 ] getopt: extra args behavior wrong
Message-ID: <E14ebdT-0002uH-00@usw-sf-web2.sourceforge.net>

Bugs item #405999, was updated on 2001-03-05 03:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405999&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Gregor Hoffleit (flight)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: getopt: extra args behavior wrong

Initial Comment:
[Forwarded from the Debian bug tracking system,
Bug#87722]
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=87722&repeatmerged=yes

Sender: Wichert Akkerman <wichert@cistron.nl>

getopt claims to behave just like GNU getopt, but it
does not. If I use
this code snippet:

------------------------------------------------------------------------------
(opt,args) = getopt.getopt(sys.argv[1:], 'ab')

print "Options decoded: " + string.join(map(lambda x:
x[0], opt), ', ')
print "Extra arguments: " +  string.join(args, ', ')
------------------------------------------------------------------------------

Then this result is correct:

[fog;/tmp]-26> ./x.py -a -b bla
Options decoded: -a, -b
Extra arguments: bla

But this is wrong:

[fog;/tmp]-27> ./x.py -a bla -b 
Options decoded: -a
Extra arguments: bla, -b

That should give the exact same result, but doesn't.
The problem seems
to be that the while loop used to iterate over the
arguments aborts
at the first non-option argument, while it should
continue to check
all arguments for possible options.

This problem persist in python2-base.

Wichert.


----------------------------------------------------------------------

>Comment By: Moshe Zadka (moshez)
Date: 2001-03-18 03:46

Message:
Logged In: YES 
user_id=11645

This patches clarifies the documentation, that the "GNU
behaviour" comment only holds for interpretation of --
options and *not* to the ordering problem.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405999&group_id=5470


From noreply@sourceforge.net  Sun Mar 18 11:57:59 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Mar 2001 03:57:59 -0800
Subject: [Python-bugs-list] [ python-Bugs-406642 ] 2.1b1 from socket import* omits errorTab
Message-ID: <E14ebot-0002yk-00@usw-sf-web2.sourceforge.net>

Bugs item #406642, was updated on 2001-03-07 01:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406642&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Priority: 5
Submitted By: Ernie Sasaki (esasaki)
Assigned to: Skip Montanaro (montanaro)
Summary: 2.1b1 from socket import* omits errorTab

Initial Comment:
Under Win98SE, if you say "from socket import *" at an 
interactive python 2.0 prompt, you can see errorTab in 
what dir() returns. 

With a 2.1b1 interactive prompt, if you do the same 
exact thing no errorTab is in the list. However, if 
instead you say import socket and then dir(socket), 
errorTab appears.

Not sure if this is a bug but it sure sent me on a 
wild goose chase for a while. I don't think this is 
correct Nested Scopes related behavior but I admit I 
haven't fully understood this new feature.

This came up because I've been using the 
timeoutsocket.py module from the Vaults of Parnassus 
for a few weeks. It imports from socket. In a 
different module I (very non-portably), then format an 
nice error message based on the contents of errorTab. 
This code now is broken under 2.1b1.


----------------------------------------------------------------------

>Comment By: Moshe Zadka (moshez)
Date: 2001-03-18 03:57

Message:
Logged In: YES 
user_id=11645

For the record, it seems to me that he's right. errorTab
is *not* used inside socket.py, so it *must* be defined
so that other people can use it, whether it is documented or
not.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406642&group_id=5470


From noreply@sourceforge.net  Sun Mar 18 12:15:15 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Mar 2001 04:15:15 -0800
Subject: [Python-bugs-list] [ python-Bugs-406049 ] crash on nested listcomps
Message-ID: <E14ec5b-00036a-00@usw-sf-web2.sourceforge.net>

Bugs item #406049, was updated on 2001-03-05 08:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406049&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Priority: 7
Submitted By: David Goodger (goodger)
Assigned to: Jeremy Hylton (jhylton)
Summary: crash on nested listcomps

Initial Comment:
(if you need to contact me: dgoodger@atsautomation.com)

I got an aborted interpreter under both QNX 4.25 and 
Windows NT 4.0:

Python 2.1b1 (#2, Mar 05 2001, 11:19:23) [C] on qnxJ
Type "copyright", "credits" or "license" for more 
information.
>>> l=[[[0,0,0] for i in range(3)] for j in range(3)]
Fatal Python error: unknown scope for _[2] in ?(0) in 
<stdin>
symbols: {'i': 2, 'l': 2, 'j': 2, 'range': 8, '_[1]': 
2}
locals: {'l': 1, 'j': 2, '_[1]': 3, 'i': 0}
globals: {'range': 1}

%1 - 32637 Abort                python


----------------------------------------------------------------------

>Comment By: Moshe Zadka (moshez)
Date: 2001-03-18 04:15

Message:
Logged In: YES 
user_id=11645

My patch attached to 409230 solves this problem too.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2001-03-05 10:36

Message:
Logged In: YES 
user_id=6656

tee hee.  fun one.

see patch #406076 for a fix & test case.  not sure the fix
is exactly what's wanted though.  the problem is that
--st->st_tmpname is called before symtable_node is called on
the first node in the listcomp. this patch gets rid of the
decrement and resets st_tmpname in symtable_enter_scope.

and doesn't pass make test.  hang on...

I want to rewrite Python/compile.c in OCaml one of these days...

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406049&group_id=5470


From noreply@sourceforge.net  Sun Mar 18 13:03:27 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Mar 2001 05:03:27 -0800
Subject: [Python-bugs-list] [ python-Bugs-409355 ] Meta-class inheritance problem
Message-ID: <E14ecqF-0003JL-00@usw-sf-web3.sourceforge.net>

Bugs item #409355, was updated on 2001-03-17 02:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409355&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Priority: 5
Submitted By: Lorien Dunn (loriend)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Meta-class inheritance problem

Initial Comment:
I've run into a bug in python 2.0. The real code that
the following pseudo code represents throws a
TypeError.

class MyDerivedClass(MyPurePythonClass,MyBoostClass):
        def __init__(self):
                MyPurePythonClass.__init__(self)
                MyBoostClass.__init__(self)

The problem occurs in MyPurePythonClass- Python says
"unbound method must be called with class instance 1st
argument". This makes sense: I'm passing a meta-class
instead of a class. David Abrahams (the main author of
boost::python) agrees that this is a Python problem,
and that it should affect Zope as well.

I think I've found the point in the python 2.0 sorce
where it occurs:


ceval.c, line 1816 (reformatted for clarity):

/*              BEGIN CODE SAMPLE               */

else
{
/* Unbound methods must be called with an instance of
the class (or a derived class) as first argument */

     if (na > 0 && (self = stack_pointer[-n]) != NULL
                && PyInstance_Check(self)
                && PyClass_IsSubclass((PyObject
*) 		 		   (((PyInstanceObject*)  self)->in_class),
class))
                  /* Handy-dandy */ ;
      else
      {
        PyErr_SetString(PyExc_TypeError, "unbound
method must be 		called with class instance 1st
argument");
        x = NULL;
        break;
      }
}

/*              END CODE SAMPLE         */


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-03-18 05:03

Message:
Logged In: NO 

I was a bit surprised to learn that this check was still in 
the code after issubclass and isinstance had been fixed to 
work with extension classes. Suppose you checked for a 
__class__ attribute on the first argument instead (or 
additionally)?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-03-17 21:29

Message:
Logged In: YES 
user_id=31435

Assigned to Guido, because I bet JimF would refuse to take 
blame for this <wink>.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409355&group_id=5470


From noreply@sourceforge.net  Sun Mar 18 13:30:26 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Mar 2001 05:30:26 -0800
Subject: [Python-bugs-list] [ python-Bugs-409355 ] Meta-class inheritance problem
Message-ID: <E14edGM-0003zX-00@usw-sf-web1.sourceforge.net>

Bugs item #409355, was updated on 2001-03-17 02:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409355&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Priority: 5
Submitted By: Lorien Dunn (loriend)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Meta-class inheritance problem

Initial Comment:
I've run into a bug in python 2.0. The real code that
the following pseudo code represents throws a
TypeError.

class MyDerivedClass(MyPurePythonClass,MyBoostClass):
        def __init__(self):
                MyPurePythonClass.__init__(self)
                MyBoostClass.__init__(self)

The problem occurs in MyPurePythonClass- Python says
"unbound method must be called with class instance 1st
argument". This makes sense: I'm passing a meta-class
instead of a class. David Abrahams (the main author of
boost::python) agrees that this is a Python problem,
and that it should affect Zope as well.

I think I've found the point in the python 2.0 sorce
where it occurs:


ceval.c, line 1816 (reformatted for clarity):

/*              BEGIN CODE SAMPLE               */

else
{
/* Unbound methods must be called with an instance of
the class (or a derived class) as first argument */

     if (na > 0 && (self = stack_pointer[-n]) != NULL
                && PyInstance_Check(self)
                && PyClass_IsSubclass((PyObject
*) 		 		   (((PyInstanceObject*)  self)->in_class),
class))
                  /* Handy-dandy */ ;
      else
      {
        PyErr_SetString(PyExc_TypeError, "unbound
method must be 		called with class instance 1st
argument");
        x = NULL;
        break;
      }
}

/*              END CODE SAMPLE         */


----------------------------------------------------------------------

Comment By: David Abrahams (david_abrahams)
Date: 2001-03-18 05:30

Message:
Logged In: YES 
user_id=52572

Sorry, that anonymous comment is mine. I'm still a bit 
clumsy with SourceForge.

-Dve

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-03-18 05:03

Message:
Logged In: NO 

I was a bit surprised to learn that this check was still in 
the code after issubclass and isinstance had been fixed to 
work with extension classes. Suppose you checked for a 
__class__ attribute on the first argument instead (or 
additionally)?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-03-17 21:29

Message:
Logged In: YES 
user_id=31435

Assigned to Guido, because I bet JimF would refuse to take 
blame for this <wink>.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409355&group_id=5470


From noreply@sourceforge.net  Sun Mar 18 16:10:23 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Mar 2001 08:10:23 -0800
Subject: [Python-bugs-list] [ python-Bugs-408271 ] crash in shelve module
Message-ID: <E14efl9-0006xd-00@usw-sf-web1.sourceforge.net>

Bugs item #408271, was updated on 2001-03-13 10:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408271&group_id=5470

Category: Python Library
>Group: Irreproducible
>Status: Closed
>Priority: 3
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Barry Warsaw (bwarsaw)
Summary: crash in shelve module

Initial Comment:
While using shelve module on SGI
sloth 271> uname -a
IRIX64 sloth 6.5 04191225 IP27

my python program crashes and
I am getting following error message:

  File "/usr/local/lib/python1.5/shelve.py", line 71,
in __setitem__
    self.dict[key] = f.getvalue()
bsddb.error: (0, 'Error')

At the time the size of the "shelve" file was quite big
(maybe this is a problem ?)
sloth 267> ls -lt *shelve
-rw-r--r--    1 ryszard  cdiApps   85778432 Mar 13
12:27 recap_mddr.shelve


----------------------------------------------------------------------

>Comment By: Barry Warsaw (bwarsaw)
Date: 2001-03-18 08:10

Message:
Logged In: YES 
user_id=12800

Besides, this was submitted by "anonymous" and the only clue
to the identity of the original poster is in the ls output. 
Unfortunately, I'm not prepared to spam all the Ryszard's in
my name database. :)

I'm closing this report until/unless we get more
information.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-03-17 22:03

Message:
Logged In: YES 
user_id=31435

Assigned to Barry because there's not enough info here to 
do anything about it <wink>.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408271&group_id=5470


From noreply@sourceforge.net  Sun Mar 18 16:27:19 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Mar 2001 08:27:19 -0800
Subject: [Python-bugs-list] [ python-Bugs-405999 ] getopt: extra args behavior wrong
Message-ID: <E14eg1X-00064o-00@usw-sf-web2.sourceforge.net>

Bugs item #405999, was updated on 2001-03-05 03:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405999&group_id=5470

>Category: Documentation
Group: None
Status: Open
Priority: 5
Submitted By: Gregor Hoffleit (flight)
>Assigned to: Moshe Zadka (moshez)
Summary: getopt: extra args behavior wrong

Initial Comment:
[Forwarded from the Debian bug tracking system,
Bug#87722]
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=87722&repeatmerged=yes

Sender: Wichert Akkerman <wichert@cistron.nl>

getopt claims to behave just like GNU getopt, but it
does not. If I use
this code snippet:

------------------------------------------------------------------------------
(opt,args) = getopt.getopt(sys.argv[1:], 'ab')

print "Options decoded: " + string.join(map(lambda x:
x[0], opt), ', ')
print "Extra arguments: " +  string.join(args, ', ')
------------------------------------------------------------------------------

Then this result is correct:

[fog;/tmp]-26> ./x.py -a -b bla
Options decoded: -a, -b
Extra arguments: bla

But this is wrong:

[fog;/tmp]-27> ./x.py -a bla -b 
Options decoded: -a
Extra arguments: bla, -b

That should give the exact same result, but doesn't.
The problem seems
to be that the while loop used to iterate over the
arguments aborts
at the first non-option argument, while it should
continue to check
all arguments for possible options.

This problem persist in python2-base.

Wichert.


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-03-18 08:27

Message:
Logged In: YES 
user_id=3066

Moshe:  Your documentation update is correct; please check it in.

----------------------------------------------------------------------

Comment By: Moshe Zadka (moshez)
Date: 2001-03-18 03:46

Message:
Logged In: YES 
user_id=11645

This patches clarifies the documentation, that the "GNU
behaviour" comment only holds for interpretation of --
options and *not* to the ordering problem.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405999&group_id=5470


From noreply@sourceforge.net  Sun Mar 18 16:28:57 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Mar 2001 08:28:57 -0800
Subject: [Python-bugs-list] [ python-Bugs-215026 ] SSL features undocumented
Message-ID: <E14eg37-00065U-00@usw-sf-web2.sourceforge.net>

Bugs item #215026, was updated on 2000-09-21 15:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=215026&group_id=5470

Category: Documentation
Group: None
Status: Open
>Priority: 4
Submitted By: Martin v. Löwis (loewis)
>Assigned to: Tim Peters (tim_one)
Summary: SSL features undocumented

Initial Comment:
The socket.ssl function, and the SSL objects, are not documented.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-03-18 08:28

Message:
Logged In: YES 
user_id=3066

Tim:  Can you look at Moshe's suggestion for the SSL on Windows?  Please assign back to me for the documentation issue afterwards.  Thanks!

----------------------------------------------------------------------

Comment By: Moshe Zadka (moshez)
Date: 2001-03-18 02:34

Message:
Logged In: YES 
user_id=11645

Fred, if any of the guys in PythonLabs has some spare times
and a windows machine, then inside the RAND_status() line,
you should put right after the USE_EGD #endif something like

#ifdef <whatever says it's windows>
RAND_screen()
#endif

I don't want to make this a formal patch submission because
I don't have any windows machine to test it on...

(And if we make an ssl module, it should just have a
RAND_* functions wrapped up and have all the smarts in
socket.py/ssl.py/<whatever>.

I don't have cycles to work on this, but this seemed like
a good place to braindump

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2000-10-12 19:41

Message:
I should note that the SSL support in the socket module was discussed briefly at a PythonLabs meeting a few weeks ago in the context of a bug report complaining that the SSL code here wasn't portable to Windows.

We decided that SSL support probably belonged in a separate module in the first place, so all this might change in some future release.  Especially if anyone would like to fund some work on getting SSL support working across platforms.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2000-09-21 20:46

Message:
Low priority for 2.0, but reasonable patches will be considered.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=215026&group_id=5470


From noreply@sourceforge.net  Sun Mar 18 18:56:26 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Mar 2001 10:56:26 -0800
Subject: [Python-bugs-list] [ python-Bugs-215026 ] SSL features undocumented
Message-ID: <E14eiLq-0007Dq-00@usw-sf-web2.sourceforge.net>

Bugs item #215026, was updated on 2000-09-21 15:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=215026&group_id=5470

Category: Documentation
Group: None
Status: Open
Priority: 4
Submitted By: Martin v. Löwis (loewis)
>Assigned to: Moshe Zadka (moshez)
Summary: SSL features undocumented

Initial Comment:
The socket.ssl function, and the SSL objects, are not documented.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-03-18 10:56

Message:
Logged In: YES 
user_id=31435

Sorry, Fred, I not only know nothing about SSL, I've never 
even used a socket!  I don't have a clue.  Maybe after the 
docs are written, I'll know how to test it <wink>.

Assigning back to Moshe, in the hope that he can at least 
attach a teensy test case I can run to let me know whether 
or not his suggestion works on Windows.  But someone will 
also have to tell me how to *compile* with SSL support on 
Windows -- e.g., I sure don't have any of the #include 
files it's looking for when USE_SSL is #define'd.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-03-18 08:28

Message:
Logged In: YES 
user_id=3066

Tim:  Can you look at Moshe's suggestion for the SSL on Windows?  Please assign back to me for the documentation issue afterwards.  Thanks!

----------------------------------------------------------------------

Comment By: Moshe Zadka (moshez)
Date: 2001-03-18 02:34

Message:
Logged In: YES 
user_id=11645

Fred, if any of the guys in PythonLabs has some spare times
and a windows machine, then inside the RAND_status() line,
you should put right after the USE_EGD #endif something like

#ifdef <whatever says it's windows>
RAND_screen()
#endif

I don't want to make this a formal patch submission because
I don't have any windows machine to test it on...

(And if we make an ssl module, it should just have a
RAND_* functions wrapped up and have all the smarts in
socket.py/ssl.py/<whatever>.

I don't have cycles to work on this, but this seemed like
a good place to braindump

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2000-10-12 19:41

Message:
I should note that the SSL support in the socket module was discussed briefly at a PythonLabs meeting a few weeks ago in the context of a bug report complaining that the SSL code here wasn't portable to Windows.

We decided that SSL support probably belonged in a separate module in the first place, so all this might change in some future release.  Especially if anyone would like to fund some work on getting SSL support working across platforms.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2000-09-21 20:46

Message:
Low priority for 2.0, but reasonable patches will be considered.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=215026&group_id=5470


From noreply@sourceforge.net  Sun Mar 18 18:58:10 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Mar 2001 10:58:10 -0800
Subject: [Python-bugs-list] [ python-Bugs-409311 ] Python 2.1b1 re module is broken!
Message-ID: <E14eiNW-0007Ee-00@usw-sf-web2.sourceforge.net>

Bugs item #409311, was updated on 2001-03-16 19:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409311&group_id=5470

Category: Regular Expressions
Group: None
Status: Open
Priority: 7
Submitted By: Gregory P. Smith (greg)
Assigned to: Fredrik Lundh (effbot)
Summary: Python 2.1b1 re module is broken!

Initial Comment:
the following should -not- match:

$ python
Python 2.1b1 (#1, Mar 12 2001, 18:20:53) 
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> reg = r"(?im)<dtml-var\s+([a-z_0-9]+?)\s*>"
>>> str = '<dtml-var
expr="Presentation.show(\'start\')">'
>>> import re                                
>>> re.match(reg, str)                       
<SRE_Match object at 0x810d9d0>


In python 1.5.2 and 2.0 this works fine.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-03-18 10:58

Message:
Logged In: YES 
user_id=31435

So, Moshe, what's worse:  floating-point or regexps <2/3 
wink>?  For the life of me, I'll never be able to read +? 
as a minimal match -- it's so clearly "match one or more, 
but optionally"!

----------------------------------------------------------------------

Comment By: Moshe Zadka (moshez)
Date: 2001-03-18 03:38

Message:
Logged In: YES 
user_id=11645

Here is a simpler test case which shows the same
problem:

>>> str, r
('e=>', '(e+?)>')
>>> re.match(r, str)
<SRE_Match object at 0x4015f2e0>
>>> pre.match(r, str)
>>> 

If we lose the laziness (make the pattern "(e+)>") then it
works OK.

So the crucial problem seems to be the compilation/execution
of the lazy patterns, *not* the compilation/execution of
character classes.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-03-17 22:33

Message:
Logged In: YES 
user_id=31435

Assigned to Fredrik and boosted priority.

Gregory, it's hard to see exactly what your str vrbl 
contains because there appears to be an embedded newline in 
it.  Whatever, if I change your

    +?

to the semantically equivalent

    *

then the problem goes away for what *I* guessed you 
intended str to contain.  The

    [a-z_0-9]

part is also better written as

    \w

(since you're using the ?i flag, same thing).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-03-17 22:20

Message:
Logged In: YES 
user_id=31435

Just adding a comment to force SF to send this as email (so 
I can read it).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409311&group_id=5470


From noreply@sourceforge.net  Sun Mar 18 19:54:11 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Mar 2001 11:54:11 -0800
Subject: [Python-bugs-list] [ python-Bugs-406642 ] 2.1b1 from socket import* omits errorTab
Message-ID: <E14ejFj-0000xO-00@usw-sf-web1.sourceforge.net>

Bugs item #406642, was updated on 2001-03-07 01:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406642&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Closed
Priority: 5
Submitted By: Ernie Sasaki (esasaki)
Assigned to: Skip Montanaro (montanaro)
Summary: 2.1b1 from socket import* omits errorTab

Initial Comment:
Under Win98SE, if you say "from socket import *" at an 
interactive python 2.0 prompt, you can see errorTab in 
what dir() returns. 

With a 2.1b1 interactive prompt, if you do the same 
exact thing no errorTab is in the list. However, if 
instead you say import socket and then dir(socket), 
errorTab appears.

Not sure if this is a bug but it sure sent me on a 
wild goose chase for a while. I don't think this is 
correct Nested Scopes related behavior but I admit I 
haven't fully understood this new feature.

This came up because I've been using the 
timeoutsocket.py module from the Vaults of Parnassus 
for a few weeks. It imports from socket. In a 
different module I (very non-portably), then format an 
nice error message based on the contents of errorTab. 
This code now is broken under 2.1b1.


----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2001-03-18 11:54

Message:
Logged In: YES 
user_id=44345

taken care of.  just an oversight on my part.


----------------------------------------------------------------------

Comment By: Moshe Zadka (moshez)
Date: 2001-03-18 03:57

Message:
Logged In: YES 
user_id=11645

For the record, it seems to me that he's right. errorTab
is *not* used inside socket.py, so it *must* be defined
so that other people can use it, whether it is documented or
not.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406642&group_id=5470


From noreply@sourceforge.net  Sun Mar 18 20:01:53 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Mar 2001 12:01:53 -0800
Subject: [Python-bugs-list] [ python-Bugs-406705 ] imaplib search() quoting search criteria
Message-ID: <E14ejNB-00012k-00@usw-sf-web1.sourceforge.net>

Bugs item #406705, was updated on 2001-03-07 07:05
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406705&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Christian Kissner (b7kich)
Assigned to: Skip Montanaro (montanaro)
Summary: imaplib search() quoting search criteria

Initial Comment:
Imaplib IMAP4.search() contains a bug in criteria
handling: when
sending a single word criterium it gets written to the
stream well: 
	M.search(None, 'ALL')
produces:
	GINH16 SEARCH
ALL                                         

But a criterium with a white space will be quoted:

	M.search(None,'TEXT Hello')
produces in the tcp stream:
	GINH17 SEARCH "TEXT Hello"

which gets rejected because quotes are only allowed
around
the string, not the criterium:
	GINH17 SEARCH TEXT "Hello"



----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2001-03-18 12:01

Message:
Logged In: YES 
user_id=44345

This doesn't look like a bug to me.  Looks like the search
call is incorrect.  I think it should be called as

    M.search(None, "TEXT", "Hello")

I've never used the imaplib stuff before, however.  I'd
welcome some input from someone who has.

Skip


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-03-17 21:49

Message:
Logged In: YES 
user_id=31435

Assigned to Skip at random.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406705&group_id=5470


From noreply@sourceforge.net  Sun Mar 18 21:05:53 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Mar 2001 13:05:53 -0800
Subject: [Python-bugs-list] [ python-Bugs-409587 ] Tools/compiler loses linenos
Message-ID: <E14ekN7-0008HB-00@usw-sf-web2.sourceforge.net>

Bugs item #409587, was updated on 2001-03-18 13:05
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409587&group_id=5470

Category: demos and tools
Group: None
Status: Open
Priority: 5
Submitted By: Paul Prescod (prescod)
Assigned to: Jeremy Hylton (jhylton)
Summary: Tools/compiler loses linenos

Initial Comment:
You can see the problem with this simple program:

def foo():
    pass

1/0

Standard Python compiler:

>python -c "import test"
Traceback (most recent call last):
  File "<string>", line 1, in ?
  File "test.py", line 4, in ?
    1/0
ZeroDivisionError: integer division or modulo

>del test.pyc

Tools/compile.py : 

>python compile.py test.py

>python -c "import test"
Traceback (most recent call last):
  File "<string>", line 1, in ?
  File "test.py", line 1, in <module>
    def foo():
ZeroDivisionError: integer division or modulo


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409587&group_id=5470


From noreply@sourceforge.net  Sun Mar 18 22:22:59 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Mar 2001 14:22:59 -0800
Subject: [Python-bugs-list] [ python-Bugs-409355 ] Meta-class inheritance problem
Message-ID: <E14elZj-0002c2-00@usw-sf-web1.sourceforge.net>

Bugs item #409355, was updated on 2001-03-17 02:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409355&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Priority: 5
Submitted By: Lorien Dunn (loriend)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Meta-class inheritance problem

Initial Comment:
I've run into a bug in python 2.0. The real code that
the following pseudo code represents throws a
TypeError.

class MyDerivedClass(MyPurePythonClass,MyBoostClass):
        def __init__(self):
                MyPurePythonClass.__init__(self)
                MyBoostClass.__init__(self)

The problem occurs in MyPurePythonClass- Python says
"unbound method must be called with class instance 1st
argument". This makes sense: I'm passing a meta-class
instead of a class. David Abrahams (the main author of
boost::python) agrees that this is a Python problem,
and that it should affect Zope as well.

I think I've found the point in the python 2.0 sorce
where it occurs:


ceval.c, line 1816 (reformatted for clarity):

/*              BEGIN CODE SAMPLE               */

else
{
/* Unbound methods must be called with an instance of
the class (or a derived class) as first argument */

     if (na > 0 && (self = stack_pointer[-n]) != NULL
                && PyInstance_Check(self)
                && PyClass_IsSubclass((PyObject
*) 		 		   (((PyInstanceObject*)  self)->in_class),
class))
                  /* Handy-dandy */ ;
      else
      {
        PyErr_SetString(PyExc_TypeError, "unbound
method must be 		called with class instance 1st
argument");
        x = NULL;
        break;
      }
}

/*              END CODE SAMPLE         */


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-18 14:22

Message:
Logged In: YES 
user_id=6380

Zope has several workarounds, so isn't affected.

But I agree it could be fixed.  The test is there because it wants to enforce a concept: 'self' should be an instance 
of the class that defines the method (where a subclass instance is fine too).

But the implementation of the test is based too much on the default implementation of classes.

Could someone please submit a patch that replaces the concrete isinstance() test with an isinstance() test similar 
to that in bltinmodule.c?  (Maybe we need to add a new C API, PyObject_IsInstance().)

If someone could come up with a check that conve

----------------------------------------------------------------------

Comment By: David Abrahams (david_abrahams)
Date: 2001-03-18 05:30

Message:
Logged In: YES 
user_id=52572

Sorry, that anonymous comment is mine. I'm still a bit 
clumsy with SourceForge.

-Dve

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-03-18 05:03

Message:
Logged In: NO 

I was a bit surprised to learn that this check was still in 
the code after issubclass and isinstance had been fixed to 
work with extension classes. Suppose you checked for a 
__class__ attribute on the first argument instead (or 
additionally)?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-03-17 21:29

Message:
Logged In: YES 
user_id=31435

Assigned to Guido, because I bet JimF would refuse to take 
blame for this <wink>.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409355&group_id=5470


From noreply@sourceforge.net  Mon Mar 19 05:07:01 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Mar 2001 21:07:01 -0800
Subject: [Python-bugs-list] [ python-Bugs-409651 ] fnmatch doesn't escape '\' between [...]
Message-ID: <E14ersj-0006y3-00@usw-sf-web1.sourceforge.net>

Bugs item #409651, was updated on 2001-03-18 21:07
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409651&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Donovan Baarda (abo)
Assigned to: Nobody/Anonymous (nobody)
Summary: fnmatch doesn't escape '\' between [...]

Initial Comment:
The translate() function inside fnmatch doesn't 
escape '\' chars between '[' and ']' brackets when 
converting unix filename wildcards to a regular 
expression.

This means the '\' character behaves strangely when 
inside '['...']' or '[^'...']'. Depending on the 
character that follows, it can be interpreted in a 
wild variety of ways, including escaping the 
closing ']' and failing the re.compile. This was 
encountered when using fnmatch on windoze where 
os.sep='\'. Note that the docs say os.sep is not 
treated specially by fnmatch.

The fix required is to escape '\' in 'stuff' inside 
translate(). This is easiest done using stuff.replace
('\','\\'). A patch is attached...

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409651&group_id=5470


From noreply@sourceforge.net  Mon Mar 19 05:21:22 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Mar 2001 21:21:22 -0800
Subject: [Python-bugs-list] [ python-Bugs-409651 ] fnmatch doesn't escape '\' between [...]
Message-ID: <E14es6c-0003Qn-00@usw-sf-web2.sourceforge.net>

Bugs item #409651, was updated on 2001-03-18 21:07
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409651&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Donovan Baarda (abo)
Assigned to: Nobody/Anonymous (nobody)
Summary: fnmatch doesn't escape '\' between [...]

Initial Comment:
The translate() function inside fnmatch doesn't 
escape '\' chars between '[' and ']' brackets when 
converting unix filename wildcards to a regular 
expression.

This means the '\' character behaves strangely when 
inside '['...']' or '[^'...']'. Depending on the 
character that follows, it can be interpreted in a 
wild variety of ways, including escaping the 
closing ']' and failing the re.compile. This was 
encountered when using fnmatch on windoze where 
os.sep='\'. Note that the docs say os.sep is not 
treated specially by fnmatch.

The fix required is to escape '\' in 'stuff' inside 
translate(). This is easiest done using stuff.replace
('\','\\'). A patch is attached...

----------------------------------------------------------------------

>Comment By: Donovan Baarda (abo)
Date: 2001-03-18 21:21

Message:
Logged In: YES 
user_id=10273

No sooner did I submit this, than I saw a neat way to make 
this small portion of code even neater and faster... new 
patch attached.

This patch trims 4 redundant lines and should be a fraction 
faster.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409651&group_id=5470


From noreply@sourceforge.net  Mon Mar 19 05:23:20 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Mar 2001 21:23:20 -0800
Subject: [Python-bugs-list] [ python-Bugs-409651 ] fnmatch doesn't escape '\' between [...]
Message-ID: <E14es8W-0003A3-00@usw-sf-web3.sourceforge.net>

Bugs item #409651, was updated on 2001-03-18 21:07
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409651&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Donovan Baarda (abo)
Assigned to: Nobody/Anonymous (nobody)
Summary: fnmatch doesn't escape '\' between [...]

Initial Comment:
The translate() function inside fnmatch doesn't 
escape '\' chars between '[' and ']' brackets when 
converting unix filename wildcards to a regular 
expression.

This means the '\' character behaves strangely when 
inside '['...']' or '[^'...']'. Depending on the 
character that follows, it can be interpreted in a 
wild variety of ways, including escaping the 
closing ']' and failing the re.compile. This was 
encountered when using fnmatch on windoze where 
os.sep='\'. Note that the docs say os.sep is not 
treated specially by fnmatch.

The fix required is to escape '\' in 'stuff' inside 
translate(). This is easiest done using stuff.replace
('\','\\'). A patch is attached...

----------------------------------------------------------------------

>Comment By: Donovan Baarda (abo)
Date: 2001-03-18 21:23

Message:
Logged In: YES 
user_id=10273

Due to potential confusion over which patch is the new one, 
I've deleted the old patch...

----------------------------------------------------------------------

Comment By: Donovan Baarda (abo)
Date: 2001-03-18 21:21

Message:
Logged In: YES 
user_id=10273

No sooner did I submit this, than I saw a neat way to make 
this small portion of code even neater and faster... new 
patch attached.

This patch trims 4 redundant lines and should be a fraction 
faster.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409651&group_id=5470


From noreply@sourceforge.net  Mon Mar 19 05:26:27 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Mar 2001 21:26:27 -0800
Subject: [Python-bugs-list] [ python-Bugs-409651 ] fnmatch doesn't escape '\' between [...]
Message-ID: <E14esBX-0003TI-00@usw-sf-web2.sourceforge.net>

Bugs item #409651, was updated on 2001-03-18 21:07
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409651&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Donovan Baarda (abo)
Assigned to: Nobody/Anonymous (nobody)
Summary: fnmatch doesn't escape '\' between [...]

Initial Comment:
The translate() function inside fnmatch doesn't 
escape '\' chars between '[' and ']' brackets when 
converting unix filename wildcards to a regular 
expression.

This means the '\' character behaves strangely when 
inside '['...']' or '[^'...']'. Depending on the 
character that follows, it can be interpreted in a 
wild variety of ways, including escaping the 
closing ']' and failing the re.compile. This was 
encountered when using fnmatch on windoze where 
os.sep='\'. Note that the docs say os.sep is not 
treated specially by fnmatch.

The fix required is to escape '\' in 'stuff' inside 
translate(). This is easiest done using stuff.replace
('\','\\'). A patch is attached...

----------------------------------------------------------------------

>Comment By: Donovan Baarda (abo)
Date: 2001-03-18 21:26

Message:
Logged In: YES 
user_id=10273

Hmmm. that didn't work... I'll try again, but if it still 
doesn't work, use the one discribed as "fnmatch patch 
for '\' in '[...]'".

----------------------------------------------------------------------

Comment By: Donovan Baarda (abo)
Date: 2001-03-18 21:23

Message:
Logged In: YES 
user_id=10273

Due to potential confusion over which patch is the new one, 
I've deleted the old patch...

----------------------------------------------------------------------

Comment By: Donovan Baarda (abo)
Date: 2001-03-18 21:21

Message:
Logged In: YES 
user_id=10273

No sooner did I submit this, than I saw a neat way to make 
this small portion of code even neater and faster... new 
patch attached.

This patch trims 4 redundant lines and should be a fraction 
faster.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409651&group_id=5470


From noreply@sourceforge.net  Mon Mar 19 09:39:12 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Mar 2001 01:39:12 -0800
Subject: [Python-bugs-list] [ python-Bugs-408173 ] re.py comments refer to old versions
Message-ID: <E14ew88-0004wH-00@usw-sf-web3.sourceforge.net>

Bugs item #408173, was updated on 2001-03-13 02:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408173&group_id=5470

Category: Regular Expressions
Group: None
>Status: Closed
Priority: 5
Submitted By: Rob W.W. Hooft (hooft)
Assigned to: Fredrik Lundh (effbot)
Summary: re.py comments refer to old versions

Initial Comment:
re.py comments say that "this is for 2.0b1" and "this
will be removed in version 2.0".

----------------------------------------------------------------------

>Comment By: Fredrik Lundh (effbot)
Date: 2001-03-19 01:39

Message:
Logged In: YES 
user_id=38376

fixed in 2.1 alphas.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408173&group_id=5470


From noreply@sourceforge.net  Mon Mar 19 09:50:42 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Mar 2001 01:50:42 -0800
Subject: [Python-bugs-list] [ python-Bugs-408958 ] pydoc fails on exceptions.html (win2K)
Message-ID: <E14ewJG-00052C-00@usw-sf-web3.sourceforge.net>

Bugs item #408958, was updated on 2001-03-15 15:13
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408958&group_id=5470

Category: Python Library
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Hernan Martinez Foffani (hfoffani)
Assigned to: Ka-Ping Yee (ping)
Summary: pydoc fails on exceptions.html (win2K)

Initial Comment:
Pydoc fails to show exceptions.html
Windows 2000, python 2.1b1
(FYI, I've got python 2.0 installed on the same 
machine)


----------------------------------------------------------------------

>Comment By: Hernan Martinez Foffani (hfoffani)
Date: 2001-03-19 01:50

Message:
Logged In: YES 
user_id=112690

These messages, that i grab when trying to access to 
exceptions.html, may help (both in python 2.1b1 and python 
2.0):


C:\Python20\Lib>python pydoc.py
----------------------------------------
Exception happened during processing of request from 
('127.0.0.1', 1642)
Traceback (most recent call last):
  File "c:\python20\lib\SocketServer.py", line 221, in 
handle_request
    self.process_request(request, client_address)
  File "c:\python20\lib\SocketServer.py", line 247, in 
process_request
    self.finish_request(request, client_address)
  File "c:\python20\lib\SocketServer.py", line 251, in 
finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "c:\python20\lib\SocketServer.py", line 385, in 
__init__
    self.handle()
  File "c:\python20\lib\BaseHTTPServer.py", line 266, in 
handle
    method()
  File "pydoc.py", line 1116, in do_GET
    p, x = locate(path)
  File "pydoc.py", line 927, in locate
    filename = sys.modules[path].__file__
AttributeError: __file__
----------------------------------------


C:\Python21\Lib>python
Python 2.1b1 (#11, Mar  2 2001, 11:23:29) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
>>> ^Z


C:\Python21\Lib>python pydoc.py
----------------------------------------
Exception happened during processing of request from 
('127.0.0.1', 1651)
Traceback (most recent call last):
  File "c:\python21\lib\SocketServer.py", line 214, in 
handle_request
    self.process_request(request, client_address)
  File "c:\python21\lib\SocketServer.py", line 232, in 
process_request
    self.finish_request(request, client_address)
  File "c:\python21\lib\SocketServer.py", line 244, in 
finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "c:\python21\lib\SocketServer.py", line 481, in 
__init__
    self.handle()
  File "c:\python21\lib\BaseHTTPServer.py", line 266, in 
handle
    method()
  File "pydoc.py", line 1112, in do_GET
    p, x = locate(path)
  File "pydoc.py", line 923, in locate
    filename = sys.modules[path].__file__
AttributeError: 'exceptions' module has no 
attribute '__file__'
----------------------------------------



----------------------------------------------------------------------

Comment By: Hernan Martinez Foffani (hfoffani)
Date: 2001-03-16 02:27

Message:
Logged In: YES 
user_id=112690

Aditional Info:
Windows 2000 and IE 5.5 SP1 both Spanish version.

IExplorer error is "Can't find server or DNS error"
(translated by me)

(sorry for the 2nd bug report, but sourceforge keeps 
fighting me)



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408958&group_id=5470


From noreply@sourceforge.net  Mon Mar 19 10:01:28 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Mar 2001 02:01:28 -0800
Subject: [Python-bugs-list] [ python-Bugs-408958 ] pydoc fails on exceptions.html (win2K)
Message-ID: <E14ewTg-00057Y-00@usw-sf-web3.sourceforge.net>

Bugs item #408958, was updated on 2001-03-15 15:13
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408958&group_id=5470

Category: Python Library
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Hernan Martinez Foffani (hfoffani)
Assigned to: Ka-Ping Yee (ping)
Summary: pydoc fails on exceptions.html (win2K)

Initial Comment:
Pydoc fails to show exceptions.html
Windows 2000, python 2.1b1
(FYI, I've got python 2.0 installed on the same 
machine)


----------------------------------------------------------------------

>Comment By: Hernan Martinez Foffani (hfoffani)
Date: 2001-03-19 02:01

Message:
Logged In: YES 
user_id=112690

These messages, that i grab when trying to access to 
exceptions.html, may help (both in python 2.1b1 and python 
2.0):


C:\Python20\Lib>python pydoc.py
----------------------------------------
Exception happened during processing of request from 
('127.0.0.1', 1642)
Traceback (most recent call last):
  File "c:\python20\lib\SocketServer.py", line 221, in 
handle_request
    self.process_request(request, client_address)
  File "c:\python20\lib\SocketServer.py", line 247, in 
process_request
    self.finish_request(request, client_address)
  File "c:\python20\lib\SocketServer.py", line 251, in 
finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "c:\python20\lib\SocketServer.py", line 385, in 
__init__
    self.handle()
  File "c:\python20\lib\BaseHTTPServer.py", line 266, in 
handle
    method()
  File "pydoc.py", line 1116, in do_GET
    p, x = locate(path)
  File "pydoc.py", line 927, in locate
    filename = sys.modules[path].__file__
AttributeError: __file__
----------------------------------------


C:\Python21\Lib>python
Python 2.1b1 (#11, Mar  2 2001, 11:23:29) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
>>> ^Z


C:\Python21\Lib>python pydoc.py
----------------------------------------
Exception happened during processing of request from 
('127.0.0.1', 1651)
Traceback (most recent call last):
  File "c:\python21\lib\SocketServer.py", line 214, in 
handle_request
    self.process_request(request, client_address)
  File "c:\python21\lib\SocketServer.py", line 232, in 
process_request
    self.finish_request(request, client_address)
  File "c:\python21\lib\SocketServer.py", line 244, in 
finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "c:\python21\lib\SocketServer.py", line 481, in 
__init__
    self.handle()
  File "c:\python21\lib\BaseHTTPServer.py", line 266, in 
handle
    method()
  File "pydoc.py", line 1112, in do_GET
    p, x = locate(path)
  File "pydoc.py", line 923, in locate
    filename = sys.modules[path].__file__
AttributeError: 'exceptions' module has no 
attribute '__file__'
----------------------------------------



----------------------------------------------------------------------

Comment By: Hernan Martinez Foffani (hfoffani)
Date: 2001-03-19 01:50

Message:
Logged In: YES 
user_id=112690

These messages, that i grab when trying to access to 
exceptions.html, may help (both in python 2.1b1 and python 
2.0):


C:\Python20\Lib>python pydoc.py
----------------------------------------
Exception happened during processing of request from 
('127.0.0.1', 1642)
Traceback (most recent call last):
  File "c:\python20\lib\SocketServer.py", line 221, in 
handle_request
    self.process_request(request, client_address)
  File "c:\python20\lib\SocketServer.py", line 247, in 
process_request
    self.finish_request(request, client_address)
  File "c:\python20\lib\SocketServer.py", line 251, in 
finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "c:\python20\lib\SocketServer.py", line 385, in 
__init__
    self.handle()
  File "c:\python20\lib\BaseHTTPServer.py", line 266, in 
handle
    method()
  File "pydoc.py", line 1116, in do_GET
    p, x = locate(path)
  File "pydoc.py", line 927, in locate
    filename = sys.modules[path].__file__
AttributeError: __file__
----------------------------------------


C:\Python21\Lib>python
Python 2.1b1 (#11, Mar  2 2001, 11:23:29) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
>>> ^Z


C:\Python21\Lib>python pydoc.py
----------------------------------------
Exception happened during processing of request from 
('127.0.0.1', 1651)
Traceback (most recent call last):
  File "c:\python21\lib\SocketServer.py", line 214, in 
handle_request
    self.process_request(request, client_address)
  File "c:\python21\lib\SocketServer.py", line 232, in 
process_request
    self.finish_request(request, client_address)
  File "c:\python21\lib\SocketServer.py", line 244, in 
finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "c:\python21\lib\SocketServer.py", line 481, in 
__init__
    self.handle()
  File "c:\python21\lib\BaseHTTPServer.py", line 266, in 
handle
    method()
  File "pydoc.py", line 1112, in do_GET
    p, x = locate(path)
  File "pydoc.py", line 923, in locate
    filename = sys.modules[path].__file__
AttributeError: 'exceptions' module has no 
attribute '__file__'
----------------------------------------



----------------------------------------------------------------------

Comment By: Hernan Martinez Foffani (hfoffani)
Date: 2001-03-16 02:27

Message:
Logged In: YES 
user_id=112690

Aditional Info:
Windows 2000 and IE 5.5 SP1 both Spanish version.

IExplorer error is "Can't find server or DNS error"
(translated by me)

(sorry for the 2nd bug report, but sourceforge keeps 
fighting me)



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408958&group_id=5470


From noreply@sourceforge.net  Mon Mar 19 10:41:44 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Mar 2001 02:41:44 -0800
Subject: [Python-bugs-list] [ python-Bugs-409683 ] import tzparse --> fails
Message-ID: <E14ex6e-0005Qi-00@usw-sf-web3.sourceforge.net>

Bugs item #409683, was updated on 2001-03-19 02:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409683&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Hernan Martinez Foffani (hfoffani)
Assigned to: Nobody/Anonymous (nobody)
Summary: import tzparse --> fails

Initial Comment:
In Windows OS, an import tzparse fails. May be 
See below:

Python 2.1b1 (#11, Mar  2 2001, 11:23:29) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
>>> import tzparse
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "c:\python21\lib\tzparse.py", line 67, in ?
    tzset()
  File "c:\python21\lib\tzparse.py", line 50, in tzset
    tzstr = os.environ['TZ']
  File "C:\Python21\lib\os.py", line 371, in 
__getitem__
    return self.data[key.upper()]
KeyError: TZ
>>>

At line 67 there is a call to tzset() which fails if:
- TZ environment variable is not set
- TZ is set but with an unrecognized format

Commenting such line works for me. I don't need 
tzparse, just was get the docs thru pydoc the utility. 
But that's just me, I don't know about other guys.
(BTW, the module is said to be obsolote)

I don't know if this is really a bug... I read GvR 
that Ping is going to change pydoc from "import" 
to "parse source"...




----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409683&group_id=5470


From noreply@sourceforge.net  Mon Mar 19 10:59:14 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Mar 2001 02:59:14 -0800
Subject: [Python-bugs-list] [ python-Bugs-409684 ] pydoc htmls pages that fails or no-info
Message-ID: <E14exNa-0005vC-00@usw-sf-web2.sourceforge.net>

Bugs item #409684, was updated on 2001-03-19 02:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409684&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Hernan Martinez Foffani (hfoffani)
Assigned to: Nobody/Anonymous (nobody)
Summary: pydoc htmls pages that fails or no-info

Initial Comment:
python 2.1b1, windows 2000 spanish version.
using pydoc webserver capability.

The following pages don't show info or fails.
Builtins:
- exceptions.html (already reported in Bugs item 
#408958)

DLLs:
- xmlparse.html
- xmltok.html
- tcl83.html (i guess that's very hard to get python 
doc info from this, right? :-)
- tk83.html (ditto?)

Library:
- tzparse.html (i posted a bug report on this)
- rlcompleter.html (a un*x capability)
- pty.html (ditto)





----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409684&group_id=5470


From noreply@sourceforge.net  Mon Mar 19 13:12:18 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Mar 2001 05:12:18 -0800
Subject: [Python-bugs-list] [ python-Bugs-408085 ] urllib.py https redirect-302 bug
Message-ID: <E14ezSM-0006YK-00@usw-sf-web3.sourceforge.net>

Bugs item #408085, was updated on 2001-03-12 17:05
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408085&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Dustin Boswell (boswell)
Assigned to: Moshe Zadka (moshez)
Summary: urllib.py https redirect-302 bug

Initial Comment:
Using urllib.urlopen("https://...") seems 
to hang because of a redirect problem. Looks 
like its trying to follow the redirect with 
http not https. 

>>> import urllib 
>>> params = ... 
>>> f = urllib.urlopen("https://...", params) 
connect: (securesite.com, 80) 
#a printout from httplib, line 354 

Traceback (most recent call last): 
File "<stdin>", line 1, in ? 
File "/usr/local/lib/python2.0/urllib.py", line 63, in
urlopen 
return _urlopener.open(url, data) 
File "/usr/local/lib/python2.0/urllib.py", line 168, in
open 
return getattr(self, name)(url, data) 
File "/usr/local/lib/python2.0/urllib.py", line 367, in
open_https 
data) 
File "/usr/local/lib/python2.0/urllib.py", line 301, in
http_error 
result = method(url, fp, errcode, errmsg, headers,
data) 
File "/usr/local/lib/python2.0/urllib.py", line 537, in
http_error_302 
return self.open(newurl, data) 
File "/usr/local/lib/python2.0/urllib.py", line 168, in
open 
return getattr(self, name)(url, data) 
File "/usr/local/lib/python2.0/urllib.py", line 269, in
open_http 
h.putrequest('POST', selector) 
File "/usr/local/lib/python2.0/httplib.py", line 428,
in putrequest 
self.send(str) 
File "/usr/local/lib/python2.0/httplib.py", line 370,
in send 
self.connect() 
File "/usr/local/lib/python2.0/httplib.py", line 354,
in connect 
self.sock.connect((self.host, self.port)) 
KeyboardInterrupt 
>>> 

----------------------------------------------------------------------

>Comment By: Dustin Boswell (boswell)
Date: 2001-03-19 05:12

Message:
Logged In: YES 
user_id=153527

The server is https://trading.etrade.com

Unless you have an account there to try it yourself,
there's not much else specific information I can give you.

I know for sure that the redirection is to another
https url.  The "Location" header is actually a relative
one, which is where the bug in urllib.py is.  The problem
is that when open_https is called, if an error is
encountered, it calls http_error, which assumes the
url was an http, and so when a relative url is encountered,
just prepends a http:// to the front.  I can't think
of an elegant fix to this.  Maybe when http_error realizes
it's a relative location, it should prepend "proto" (some
argument to the function that doesn't exist yet) and
prepend THAT one to it...

def open_https(self, url, data=None):
  if errcode == 200:
     return addinfourl(fp, headers, url)
  else:
     if data is None:
        return self.http_error(url, fp, errcode, errmsg,
headers)
     else:
        return self.http_error(url, fp, errcode, errmsg,
headers, data)

... and here's the function called after the error is
realized...

  def http_error_302(self, url, fp, errcode, errmsg,
headers, data=None):
        """Error 302 -- relocated (temporarily)."""
        ######Here's the problem#############
        # In case the server sent a relative URL, join with
original:
        newurl = basejoin("http:" + url, newurl)
	#uh, what if it isn't http? we seem to have lost that
information...
        if data is None:
            return self.open(newurl)
        else:
            return self.open(newurl, data)

I originally was developing my project in JAVA and
had it working, but was realizing that I was re-inventing
the wheel (i.e. redirection handling). So I switched to
Python (for other reasons too).  But I went back and
placed a POST instead of GET in the redirection handling
and everything still worked, so as for the possible GET vs.
POST redirect server bug, it wasn't that (although that's
very interesting to know...).

Am I making any sense?

----------------------------------------------------------------------

Comment By: Moshe Zadka (moshez)
Date: 2001-03-18 01:13

Message:
Logged In: YES 
user_id=11645

Errr....I'm not sure I see the bug. Perhaps the "Location"
header actually contained an "http://" URL? If you can give
me the site or more information (like a printout of newurl),
I can probably be of more help.

In testing (sadly, against a server inside a firewall, so I
cannot give the URL) I have found that it seems to work.

One thing, that may or may not have to do with your problem:
when POSTing, a 302 means "POST to that other URL", not
"GET that other URL". Many webserver writers seem to ignore
this, and many browsers compensate for that server bug.
urllib2 does *not* compensate for that bug -- I haven't
thought through whether *that* may be the explanation.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408085&group_id=5470


From noreply@sourceforge.net  Mon Mar 19 13:57:35 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Mar 2001 05:57:35 -0800
Subject: [Python-bugs-list] [ python-Bugs-407019 ] Python-2.1 does not compile under cygwin
Message-ID: <E14f0AB-0006xB-00@usw-sf-web3.sourceforge.net>

Bugs item #407019, was updated on 2001-03-08 06:02
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407019&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Tim Peters (tim_one)
Summary: Python-2.1 does not compile under cygwin

Initial Comment:
configure runs well.

I use:
> g++ --version
2.95.2

Errors are occuring in tokenizer.c. the pointer-variable new seems to be misinterpreted. After 
renaming it to newptr in line 192 ans subsequent lines, tokenizer.c.

The next errors occure in Parser/myreadline.c:

Parser/myreadline.c: In function `char * PyOS_StdioReadline(char *)':
Parser/myreadline.c:62: ANSI C++ forbids implicit conversion from `void *' in as
signment
Parser/myreadline.c:99: ANSI C++ forbids implicit conversion from `void *' in as
signment
Parser/myreadline.c:109: ANSI C++ forbids implicit conversion from `void *' in r
eturn
make: *** [Parser/myreadline.o] Error 1



----------------------------------------------------------------------

Comment By: Jason Tishler (jlt63)
Date: 2001-03-19 05:57

Message:
Logged In: YES 
user_id=86216

I haven't played "hot potato" since I was a kid...

More information than the above is necessary in order for me to help you such as
your exact configure command line, Cygwin version, etc..  Anyway I can make the
following suggestions:

    1. Your version of gcc (and most likely binutils) is really old.  My WAG is that you
        are still using gcc 2.95.2-2 -- you should be using 2.95.2-6 or later.  Please
        update your Cygwin installation by running http://www.cygwin.com/setup.exe

    2. You should use gcc not g++ to build Cygwin Python

Cygwin Python builds OOTB, please see the following for instructions:

    http://sources.redhat.com/ml/cygwin-apps/2001-03/msg00003.html

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-03-17 21:53

Message:
Logged In: YES 
user_id=31435

Sent email to Jason asking him to look at this.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-03-17 11:47

Message:
Logged In: YES 
user_id=31435

Try gcc?  Jason Tishler did the Cygwin port, and said it 
works fine.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-03-16 10:02

Message:
Logged In: YES 
user_id=31392

cygwin ends with "win." right, tim?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407019&group_id=5470


From noreply@sourceforge.net  Mon Mar 19 15:36:09 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Mar 2001 07:36:09 -0800
Subject: [Python-bugs-list] [ python-Bugs-409755 ] Followup to Bug 233033 - 2.1 Builds Fail
Message-ID: <E14f1hZ-0008H0-00@usw-sf-web2.sourceforge.net>

Bugs item #409755, was updated on 2001-03-19 07:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409755&group_id=5470

Category: Build
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Followup to Bug 233033 - 2.1 Builds Fail

Initial Comment:
I am sorry it has taken me so long to follow up on my previous bug 
report but here it is.

I am attaching a file that shows the results of an attempted build. At
first, the build fails because setup.py cannot find the  os  module.
The file then shows the line I had to modify in the Makefile. I then 
continue the build with the modified Makefile - and it succeeds.

Even with the added line,  "make test" and "make install" will still fail.

I've seen the same results with Python 2.1a and 2.1b on both Redhat
6.2 and 7.0.

Contact me by email if I can be of further help. I promise to be more
prompt this time.

...Bob     ryodlowski@pirus.com

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409755&group_id=5470


From noreply@sourceforge.net  Mon Mar 19 17:08:12 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Mar 2001 09:08:12 -0800
Subject: [Python-bugs-list] [ python-Bugs-409773 ] Bug Fix In dircmp class
Message-ID: <E14f38e-0000ig-00@usw-sf-web2.sourceforge.net>

Bugs item #409773, was updated on 2001-03-19 09:08
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409773&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bug Fix In dircmp class

Initial Comment:
Hello, I tried to diff two directories, using
filecmp.dircmp class.

I have Python2.0 installed from source in Debian
(Potato).

The code is the following:
#!/tmp/bin/python
import filecmp
from filecmp import dircmp
a = dircmp('lala','loulou')

b = a.report_full_closure()

print b

It yields:

	hargikas@simula:~/src/mydiff$ ./mydiff.py
	diff lala loulou
	Only in loulou : ['kiko']	
	Traceback (most recent call last):
	  File "./mydiff.py", line 6, in ?
	    b = a.report_full_closure()
	  File "/tmp/lib/python2.0/filecmp.py", line 264,
in 			report_full_closure
	    self.report()
	  File "/tmp/lib/python2.0/filecmp.py", line 241, in
report
	    if self.same_files:
	  File "/tmp/lib/python2.0/filecmp.py", line 147, in
__getattr__
	    self.phase3()
	  File "/tmp/lib/python2.0/filecmp.py", line 214, in
phase3
	    xx = cmpfiles(self.left, self.right,
self.common_files)
	  File "/tmp/lib/python2.0/filecmp.py", line 288, in
cmpfiles
	    res[_cmp(ax, bx, shallow,
use_statcache)].append(x)
	TypeError: too many arguments; expected 2, got 4

Actually the 288 line of filecmp.py is:
	res[_cmp(ax, bx, shallow, use_statcache)].append(x)
and it should be:
	res[cmp(ax, bx, shallow, use_statcache)].append(x)

NOTE the missing undescore, in the correct version.

With that changed it worked ok:
	hargikas@simula:~/src/mydiff$ ./mydiff.py
	diff lala loulou
	Only in loulou : ['kiko']
	Identical files : ['loulou']
	Differing files : ['lala']
	None

Any Ideas???

Best Regards,
Charalampos Gikas,
Virtual Trip LTD
http://www.vtrip-ltd.com

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409773&group_id=5470


From noreply@sourceforge.net  Mon Mar 19 19:49:02 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Mar 2001 11:49:02 -0800
Subject: [Python-bugs-list] [ python-Bugs-409230 ] Python 2.1b1 dumps core on list compr.
Message-ID: <E14f5eI-0001V2-00@usw-sf-web3.sourceforge.net>

Bugs item #409230, was updated on 2001-03-16 14:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409230&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Priority: 7
Submitted By: Viktor Ferenczi (complex)
Assigned to: Jeremy Hylton (jhylton)
Summary: Python 2.1b1 dumps core on list compr.

Initial Comment:
Hi!

Python 2.1b1 dumps core when executing the following
statement:

print [[y for y in [x,x+1]] for x in [1,3]]

(Should print: [[1,2],[3,4]])

The problem may be related to variable scope resolving
code, because python reports "unknown scope for _[2] in
?(0)" before dumping core. This bug makes impossible to
use a list comprehension as the expression field of
another one.


-Complex-

----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-03-19 11:49

Message:
Logged In: YES 
user_id=31392

This patch is incorrect.  The root of the problem is that
the symbol table does not have the correct entry for the
nested list comp.  The solution must address the symbol
table problem.


----------------------------------------------------------------------

Comment By: Moshe Zadka (moshez)
Date: 2001-03-18 03:15

Message:
Logged In: YES 
user_id=11645

Here is a patch to fix the problem.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2001-03-18 02:34

Message:
Logged In: YES 
user_id=6656

Well, no, it's not the same test case, but it is the same
problem.  It also doesn't crash if you apply patch #406076,
which I wrote to fix #406049.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-03-17 22:14

Message:
Logged In: YES 
user_id=31435

Assigned to Jeremy.  Boosted priority.  Note that mwh says 
this is a dup of 406049 (but this is clearly not the same 
test case).  Whatever, I confirmed that this specific case 
still crashes.

Fatal Python error: unknown scope for _[2] in ?(0) in 
<stdin>


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2001-03-17 09:55

Message:
Logged In: YES 
user_id=6656

this is a dup of

[ #406049 ] crash on nested listcomps

so someone with appropriate privilege should mark it as such.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409230&group_id=5470


From noreply@sourceforge.net  Mon Mar 19 20:43:04 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Mar 2001 12:43:04 -0800
Subject: [Python-bugs-list] [ python-Bugs-409230 ] Python 2.1b1 dumps core on list compr.
Message-ID: <E14f6Ua-00019m-00@usw-sf-web1.sourceforge.net>

Bugs item #409230, was updated on 2001-03-16 14:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409230&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Closed
Priority: 7
Submitted By: Viktor Ferenczi (complex)
Assigned to: Jeremy Hylton (jhylton)
Summary: Python 2.1b1 dumps core on list compr.

Initial Comment:
Hi!

Python 2.1b1 dumps core when executing the following
statement:

print [[y for y in [x,x+1]] for x in [1,3]]

(Should print: [[1,2],[3,4]])

The problem may be related to variable scope resolving
code, because python reports "unknown scope for _[2] in
?(0)" before dumping core. This bug makes impossible to
use a list comprehension as the expression field of
another one.


-Complex-

----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-03-19 12:43

Message:
Logged In: YES 
user_id=31392

Fixed in rev. 2.187 of compile.c


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-03-19 11:49

Message:
Logged In: YES 
user_id=31392

This patch is incorrect.  The root of the problem is that
the symbol table does not have the correct entry for the
nested list comp.  The solution must address the symbol
table problem.


----------------------------------------------------------------------

Comment By: Moshe Zadka (moshez)
Date: 2001-03-18 03:15

Message:
Logged In: YES 
user_id=11645

Here is a patch to fix the problem.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2001-03-18 02:34

Message:
Logged In: YES 
user_id=6656

Well, no, it's not the same test case, but it is the same
problem.  It also doesn't crash if you apply patch #406076,
which I wrote to fix #406049.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-03-17 22:14

Message:
Logged In: YES 
user_id=31435

Assigned to Jeremy.  Boosted priority.  Note that mwh says 
this is a dup of 406049 (but this is clearly not the same 
test case).  Whatever, I confirmed that this specific case 
still crashes.

Fatal Python error: unknown scope for _[2] in ?(0) in 
<stdin>


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2001-03-17 09:55

Message:
Logged In: YES 
user_id=6656

this is a dup of

[ #406049 ] crash on nested listcomps

so someone with appropriate privilege should mark it as such.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409230&group_id=5470


From noreply@sourceforge.net  Mon Mar 19 20:43:34 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Mar 2001 12:43:34 -0800
Subject: [Python-bugs-list] [ python-Bugs-407800 ] global in classdef affect nested scope!?
Message-ID: <E14f6V4-0001Ad-00@usw-sf-web1.sourceforge.net>

Bugs item #407800, was updated on 2001-03-11 18:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407800&group_id=5470

Category: Parser/Compiler
Group: None
>Status: Closed
Priority: 7
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Jeremy Hylton (jhylton)
Summary: global in classdef affect nested scope!?

Initial Comment:
[pedroni]
> (II)
> from __future__ import nested_scopes

> x='top'
> def ta():
>     x='ta'
>     class A:
>         global x
>         def tata(self):
>             return x # LOAD_GLOBAL
>     return A
>
> print ta()().tata() # -> 'top'
>
> should not the global decl in class scope be ignored 
and so x be
> bound to x in ta, resulting in 'ta' as output?

[Tim Peters]
Yes, this one is clearly a bug.  Good catch!



----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-03-19 12:43

Message:
Logged In: YES 
user_id=31392

Fixed in rev. 2.187 of compile.c


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407800&group_id=5470


From noreply@sourceforge.net  Mon Mar 19 20:44:21 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Mar 2001 12:44:21 -0800
Subject: [Python-bugs-list] [ python-Bugs-407800 ] global in classdef affect nested scope!?
Message-ID: <E14f6Vp-0001B5-00@usw-sf-web1.sourceforge.net>

Bugs item #407800, was updated on 2001-03-11 18:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407800&group_id=5470

Category: Parser/Compiler
Group: None
>Status: Open
Priority: 7
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Jeremy Hylton (jhylton)
Summary: global in classdef affect nested scope!?

Initial Comment:
[pedroni]
> (II)
> from __future__ import nested_scopes

> x='top'
> def ta():
>     x='ta'
>     class A:
>         global x
>         def tata(self):
>             return x # LOAD_GLOBAL
>     return A
>
> print ta()().tata() # -> 'top'
>
> should not the global decl in class scope be ignored 
and so x be
> bound to x in ta, resulting in 'ta' as output?

[Tim Peters]
Yes, this one is clearly a bug.  Good catch!



----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-03-19 12:44

Message:
Logged In: YES 
user_id=31392

Oops!  Didn't mean to close this one.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-03-19 12:43

Message:
Logged In: YES 
user_id=31392

Fixed in rev. 2.187 of compile.c


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407800&group_id=5470


From noreply@sourceforge.net  Mon Mar 19 20:44:52 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Mar 2001 12:44:52 -0800
Subject: [Python-bugs-list] [ python-Bugs-406049 ] crash on nested listcomps
Message-ID: <E14f6WK-0001BT-00@usw-sf-web1.sourceforge.net>

Bugs item #406049, was updated on 2001-03-05 08:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406049&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Closed
Priority: 7
Submitted By: David Goodger (goodger)
Assigned to: Jeremy Hylton (jhylton)
Summary: crash on nested listcomps

Initial Comment:
(if you need to contact me: dgoodger@atsautomation.com)

I got an aborted interpreter under both QNX 4.25 and 
Windows NT 4.0:

Python 2.1b1 (#2, Mar 05 2001, 11:19:23) [C] on qnxJ
Type "copyright", "credits" or "license" for more 
information.
>>> l=[[[0,0,0] for i in range(3)] for j in range(3)]
Fatal Python error: unknown scope for _[2] in ?(0) in 
<stdin>
symbols: {'i': 2, 'l': 2, 'j': 2, 'range': 8, '_[1]': 
2}
locals: {'l': 1, 'j': 2, '_[1]': 3, 'i': 0}
globals: {'range': 1}

%1 - 32637 Abort                python


----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-03-19 12:44

Message:
Logged In: YES 
user_id=31392

Fixed in rev. 2.187 of compile.c


----------------------------------------------------------------------

Comment By: Moshe Zadka (moshez)
Date: 2001-03-18 04:15

Message:
Logged In: YES 
user_id=11645

My patch attached to 409230 solves this problem too.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2001-03-05 10:36

Message:
Logged In: YES 
user_id=6656

tee hee.  fun one.

see patch #406076 for a fix & test case.  not sure the fix
is exactly what's wanted though.  the problem is that
--st->st_tmpname is called before symtable_node is called on
the first node in the listcomp. this patch gets rid of the
decrement and resets st_tmpname in symtable_enter_scope.

and doesn't pass make test.  hang on...

I want to rewrite Python/compile.c in OCaml one of these days...

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406049&group_id=5470


From noreply@sourceforge.net  Mon Mar 19 21:28:32 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Mar 2001 13:28:32 -0800
Subject: [Python-bugs-list] [ python-Bugs-409838 ] Error in httplib post example
Message-ID: <E14f7Ca-0001iA-00@usw-sf-web1.sourceforge.net>

Bugs item #409838, was updated on 2001-03-19 13:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409838&group_id=5470

Category: Documentation
Group: None
Status: Open
Priority: 5
Submitted By: Fredrik Borg (jenzjenz)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Error in httplib post example

Initial Comment:
The 'post' example has errors:

"paramstring" on line 9 should be "params"

and

"errcode" on line 11 should be "reply"

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409838&group_id=5470


From noreply@sourceforge.net  Mon Mar 19 21:52:45 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Mar 2001 13:52:45 -0800
Subject: [Python-bugs-list] [ python-Bugs-405341 ] Reminder -- nested scopes TO DO list
Message-ID: <E14f7a1-00022D-00@usw-sf-web1.sourceforge.net>

Bugs item #405341, was updated on 2001-03-01 18:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405341&group_id=5470

Category: None
Group: None
Status: Open
>Priority: 7
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Jeremy Hylton (jhylton)
Summary: Reminder -- nested scopes TO DO list

Initial Comment:
Subject: [Python-Dev] nested scopes and future status
From: Jeremy Hylton <jeremy@alum.mit.edu>
To: python-dev@python.org
Date: Thu, 1 Mar 2001 18:34:44 -0500 (EST)

There are several loose ends in the nested scopes
changes that I won't
have time to fix before the beta.  Here's a laundry
list of tasks that
remain.  I don't think any of these is crucial for the
release.
Holler if there's something you'd like me to fix
tonight.

- Integrate the parsing of future statements into the
_symtable
  module's interface.  This interface is new with 2.1
and
  undocumented, so it's deficiency here will not affect
any code.

- Update traceback.py to understand SyntaxErrors that
have a text
  attribute and an offset of None.  It should not print
the caret.

- PyErr_ProgramText() should be called when an
exception is printed
  rather than when it is raised.

- Fix pdb to support nested scopes.

- Produce a better error message/warning for code like
this:
  def f(x):
      def g():
          exec ...
          print x
  The warning message should say that exec is not
allowed in a nested
  function with free variables.  It currently says that
g *contains* a
  nested function with free variables.

- Update the documentation.

Jeremy


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405341&group_id=5470


From noreply@sourceforge.net  Mon Mar 19 23:27:38 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Mar 2001 15:27:38 -0800
Subject: [Python-bugs-list] [ python-Bugs-409684 ] pydoc htmls pages that fails or no-info
Message-ID: <E14f93q-0004En-00@usw-sf-web2.sourceforge.net>

Bugs item #409684, was updated on 2001-03-19 02:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409684&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Hernan Martinez Foffani (hfoffani)
>Assigned to: Ka-Ping Yee (ping)
Summary: pydoc htmls pages that fails or no-info

Initial Comment:
python 2.1b1, windows 2000 spanish version.
using pydoc webserver capability.

The following pages don't show info or fails.
Builtins:
- exceptions.html (already reported in Bugs item 
#408958)

DLLs:
- xmlparse.html
- xmltok.html
- tcl83.html (i guess that's very hard to get python 
doc info from this, right? :-)
- tk83.html (ditto?)

Library:
- tzparse.html (i posted a bug report on this)
- rlcompleter.html (a un*x capability)
- pty.html (ditto)





----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409684&group_id=5470


From noreply@sourceforge.net  Mon Mar 19 23:35:28 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Mar 2001 15:35:28 -0800
Subject: [Python-bugs-list] [ python-Bugs-409651 ] fnmatch doesn't escape '\' between [...]
Message-ID: <E14f9BQ-0003N6-00@usw-sf-web3.sourceforge.net>

Bugs item #409651, was updated on 2001-03-18 21:07
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409651&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Donovan Baarda (abo)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: fnmatch doesn't escape '\' between [...]

Initial Comment:
The translate() function inside fnmatch doesn't 
escape '\' chars between '[' and ']' brackets when 
converting unix filename wildcards to a regular 
expression.

This means the '\' character behaves strangely when 
inside '['...']' or '[^'...']'. Depending on the 
character that follows, it can be interpreted in a 
wild variety of ways, including escaping the 
closing ']' and failing the re.compile. This was 
encountered when using fnmatch on windoze where 
os.sep='\'. Note that the docs say os.sep is not 
treated specially by fnmatch.

The fix required is to escape '\' in 'stuff' inside 
translate(). This is easiest done using stuff.replace
('\','\\'). A patch is attached...

----------------------------------------------------------------------

Comment By: Donovan Baarda (abo)
Date: 2001-03-18 21:26

Message:
Logged In: YES 
user_id=10273

Hmmm. that didn't work... I'll try again, but if it still 
doesn't work, use the one discribed as "fnmatch patch 
for '\' in '[...]'".

----------------------------------------------------------------------

Comment By: Donovan Baarda (abo)
Date: 2001-03-18 21:23

Message:
Logged In: YES 
user_id=10273

Due to potential confusion over which patch is the new one, 
I've deleted the old patch...

----------------------------------------------------------------------

Comment By: Donovan Baarda (abo)
Date: 2001-03-18 21:21

Message:
Logged In: YES 
user_id=10273

No sooner did I submit this, than I saw a neat way to make 
this small portion of code even neater and faster... new 
patch attached.

This patch trims 4 redundant lines and should be a fraction 
faster.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409651&group_id=5470


From noreply@sourceforge.net  Mon Mar 19 23:37:57 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Mar 2001 15:37:57 -0800
Subject: [Python-bugs-list] [ python-Bugs-409683 ] import tzparse --> fails
Message-ID: <E14f9Dp-0003OB-00@usw-sf-web3.sourceforge.net>

Bugs item #409683, was updated on 2001-03-19 02:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409683&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Hernan Martinez Foffani (hfoffani)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: import tzparse --> fails

Initial Comment:
In Windows OS, an import tzparse fails. May be 
See below:

Python 2.1b1 (#11, Mar  2 2001, 11:23:29) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
>>> import tzparse
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "c:\python21\lib\tzparse.py", line 67, in ?
    tzset()
  File "c:\python21\lib\tzparse.py", line 50, in tzset
    tzstr = os.environ['TZ']
  File "C:\Python21\lib\os.py", line 371, in 
__getitem__
    return self.data[key.upper()]
KeyError: TZ
>>>

At line 67 there is a call to tzset() which fails if:
- TZ environment variable is not set
- TZ is set but with an unrecognized format

Commenting such line works for me. I don't need 
tzparse, just was get the docs thru pydoc the utility. 
But that's just me, I don't know about other guys.
(BTW, the module is said to be obsolote)

I don't know if this is really a bug... I read GvR 
that Ping is going to change pydoc from "import" 
to "parse source"...




----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-03-19 15:37

Message:
Logged In: YES 
user_id=31392

I also find it annoying that this module can't be imported
if there isn't a valid TZ environment variable.  

I also noticed in the CVS log that tzparse.py was labelled
"no longer necessary" in June 1993.  Is it still useful?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409683&group_id=5470


From noreply@sourceforge.net  Tue Mar 20 00:26:00 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Mar 2001 16:26:00 -0800
Subject: [Python-bugs-list] [ python-Bugs-407800 ] global in classdef affect nested scope!?
Message-ID: <E14f9yK-0003tB-00@usw-sf-web1.sourceforge.net>

Bugs item #407800, was updated on 2001-03-11 18:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407800&group_id=5470

Category: Parser/Compiler
Group: None
>Status: Closed
Priority: 7
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Jeremy Hylton (jhylton)
Summary: global in classdef affect nested scope!?

Initial Comment:
[pedroni]
> (II)
> from __future__ import nested_scopes

> x='top'
> def ta():
>     x='ta'
>     class A:
>         global x
>         def tata(self):
>             return x # LOAD_GLOBAL
>     return A
>
> print ta()().tata() # -> 'top'
>
> should not the global decl in class scope be ignored 
and so x be
> bound to x in ta, resulting in 'ta' as output?

[Tim Peters]
Yes, this one is clearly a bug.  Good catch!



----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-03-19 16:26

Message:
Logged In: YES 
user_id=31392

Fix in rev 2.188 of compile.c


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-03-19 12:44

Message:
Logged In: YES 
user_id=31392

Oops!  Didn't mean to close this one.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-03-19 12:43

Message:
Logged In: YES 
user_id=31392

Fixed in rev. 2.187 of compile.c


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407800&group_id=5470


From noreply@sourceforge.net  Tue Mar 20 00:37:17 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Mar 2001 16:37:17 -0800
Subject: [Python-bugs-list] [ python-Bugs-407783 ] urllib2: AbstractHTTPHandler limits flexible client implemen
Message-ID: <E14fA9F-00040p-00@usw-sf-web1.sourceforge.net>

Bugs item #407783, was updated on 2001-03-11 16:43
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407783&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 4
Submitted By: Bill Bumgarner (bbum)
Assigned to: Moshe Zadka (moshez)
>Summary: urllib2: AbstractHTTPHandler limits flexible client implemen

Initial Comment:
The implementation of the do_open() method on the AbstractHTTPHandler class contains a couple of "features" that could be considered to be "bugs".  In any case, each time I have wanted to use urllib2 for relatively straightforward development of an HTTP client, I have had to effectively replace the HTTPHandler with one that reimplements do_open() (or http_open() in 2.0).  Maybe my usage is not the norm-- in any case, the more information, the better...

Specifics (all names in context of Python 2.1):

- AbstractHTTPHandler does not allow for anything but GET or POST requests.   GET is the default and POST happens anytime the request object contains data to be passed to the server.

This limitation is the only thing that stands in the way of using the AbstractHTTPHandler *directly* to implement, say, a WebDAV client or to do something like a site sucker that uses the HEAD method to determine if content has changed.

- [this is likely a bug]  the method will throw an exception if *any* response is received from the server other than 200.   However, HTTP defines that all 2XX responses should be treated as successful. 

In any case, there are *a lot* of contexts within which a non-200 response may be treated as a 'success' of some sort or another.  Regardless, it is really outside of the scope of the AbstractHTTPHandler's implementation to make the success/failure decision-- it should simply return  the same thing regardless of the response status.

- [a bug?] Whenever an exception is raised (a non-200 code is received), the status code and reason (as provided by the server) are both lost. 

I see that moshez has been primarily responsible for recent changes surrounding this code.  I would be happy to contribute to the evolution of the code;  please feel free to contact me directly.


----------------------------------------------------------------------

>Comment By: Bill Bumgarner (bbum)
Date: 2001-03-19 16:37

Message:
Logged In: YES 
user_id=103811

OK-- I can understand that logic (close to beta, etc).

Given the prominence of Python in the WebDav 
community combined with the increasing use of 2xx 
(and 1xx) codes, it would be extremely useful to 
include-- at the least-- examples of handling such via 
the urllib2 modules.   

Beyond that, it would be quite helpful to the developers 
to expend some amount of engineering effort such that 
handling 2xx response codes doesn't require 
__getattr__ trickery! 

Similarly, breaking out the HTTP raw connection setup 
from the method that actually composes and sends the 
HTTP request would be helpful in that it would greatly 
reduce the amount of code that has to be duplicated 
when subclassing the handler to customize handling of 
2xx or when specifying methods other than GET/POST.

I.e. most developers will be confused to the point of 
being overwhelmed if "how do I customize responses 
such that they don't raise" or "how do I send an 
OPTIONS or HEAD request" requires figuring out how 
to deal with setting up and sending a request via the 
much-lower-level-than-urllib2 HTTP API.


----------------------------------------------------------------------

Comment By: Moshe Zadka (moshez)
Date: 2001-03-18 01:22

Message:
Logged In: YES 
user_id=11645

None of these can really be classified as "bugs" rather then
functionality enhancement requests, and this is something
I'm not sure I want to do this close to the second beta.

BTW, one thing I'm sure I *don't* want to change -- handling
of 20x codes. If you want to handle 201/206/whatever, then
just handle them. With some __getattr__ trickery, you can
have a class that handles all http_error_20x errors, so this
is *easy* for 3rd party urllib2 extensions to add.

Regarding explicitly determining the command: just put the
command inside the request object, and use it in your
own HTTPHandler/HTTPSHandler. This may be done in the next
version of urllib2 (for 2.2). At that time I might also add
the feature that other encodings (not just
application/x-www-form-urlencoded, but also
multipart/form-data) will be supported.



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-03-16 10:43

Message:
Logged In: YES 
user_id=31392

I haven't had any spare cycles to devote to urllib2 this
year.  Perhaps Moshe can be of more help in the near term. 
Following the 2.1 release, I may have more time.

I never used urllib2 it a situation that produced anything
other than vanilla responses -- 200, 401, etc.  I'm not to
surprised to hear that there are problems with 2XX cases.

Can you post some examples of the sorts of things you want
to do?  It sounds reasonable in the abstract, but some code
would help.  If not in this patch archive, perhaps on
comp.lang.python?


----------------------------------------------------------------------

Comment By: Bill Bumgarner (bbum)
Date: 2001-03-11 19:59

Message:
Logged In: YES 
user_id=103811

I realized that the exception throw behaviour is more fundamental to the underlying implementation than may have been indicated in the above description.  In particular, throwing an HTTP exception when handling a 401 is key to making the various Authentication Handlers work.

I still feel that the behaviour should be normalized across all requests such that the callee is responsible for determining error conditions or, at the lest, has access to the same data in a relatively similar format upon success or failure.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407783&group_id=5470


From noreply@sourceforge.net  Tue Mar 20 03:03:05 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Mar 2001 19:03:05 -0800
Subject: [Python-bugs-list] [ python-Bugs-409911 ] cPickle holds GIL during I/O
Message-ID: <E14fCQL-0005ss-00@usw-sf-web2.sourceforge.net>

Bugs item #409911, was updated on 2001-03-19 19:03
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409911&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: cPickle holds GIL during I/O

Initial Comment:
The cPickle module does not release the global
interpreter lock during I/O operations. In my
ThreadingTCPServer, this prevents other threads from
working until the connection thread doing
cPickle.load(mysocket) goes away.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409911&group_id=5470


From noreply@sourceforge.net  Tue Mar 20 03:43:15 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Mar 2001 19:43:15 -0800
Subject: [Python-bugs-list] [ python-Bugs-409911 ] cPickle holds GIL during I/O
Message-ID: <E14fD3D-00069n-00@usw-sf-web1.sourceforge.net>

Bugs item #409911, was updated on 2001-03-19 19:03
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409911&group_id=5470

Category: Extension Modules
Group: None
>Status: Closed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: cPickle holds GIL during I/O

Initial Comment:
The cPickle module does not release the global
interpreter lock during I/O operations. In my
ThreadingTCPServer, this prevents other threads from
working until the connection thread doing
cPickle.load(mysocket) goes away.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-03-19 19:43

Message:
Logged In: YES 
user_id=31435

Please try again under current CVS; this was changed a few 
days ago; you can reopen the bug if it still doesn't work.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409911&group_id=5470


From noreply@sourceforge.net  Tue Mar 20 14:29:19 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Mar 2001 06:29:19 -0800
Subject: [Python-bugs-list] [ python-Bugs-410008 ] cannot use crypt module
Message-ID: <E14fN8R-0004uw-00@usw-sf-web1.sourceforge.net>

Bugs item #410008, was updated on 2001-03-20 06:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410008&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Priority: 5
Submitted By: Joseph Kuan (jkuan)
Assigned to: Nobody/Anonymous (nobody)
Summary: cannot use crypt module

Initial Comment:
I have downloaded the BeOpen-Python-2.0-1.i386.rpm from
www.python.org and installed fine. 

However, I cannot use the crypt module which is
described in the documentation.

>>> import crypt
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError: No module named crypt

Also if I do rpm -qpl on BeOpen-Python-2.0-1.i386.rpm,
there is crypt.py in the whole rpm file.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410008&group_id=5470


From noreply@sourceforge.net  Tue Mar 20 15:47:56 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Mar 2001 07:47:56 -0800
Subject: [Python-bugs-list] [ python-Bugs-405341 ] Reminder -- nested scopes TO DO list
Message-ID: <E14fOMW-0002Fa-00@usw-sf-web3.sourceforge.net>

Bugs item #405341, was updated on 2001-03-01 18:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405341&group_id=5470

Category: None
Group: None
Status: Open
Priority: 7
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Jeremy Hylton (jhylton)
Summary: Reminder -- nested scopes TO DO list

Initial Comment:
Subject: [Python-Dev] nested scopes and future status
From: Jeremy Hylton <jeremy@alum.mit.edu>
To: python-dev@python.org
Date: Thu, 1 Mar 2001 18:34:44 -0500 (EST)

There are several loose ends in the nested scopes
changes that I won't
have time to fix before the beta.  Here's a laundry
list of tasks that
remain.  I don't think any of these is crucial for the
release.
Holler if there's something you'd like me to fix
tonight.

- Integrate the parsing of future statements into the
_symtable
  module's interface.  This interface is new with 2.1
and
  undocumented, so it's deficiency here will not affect
any code.

- Update traceback.py to understand SyntaxErrors that
have a text
  attribute and an offset of None.  It should not print
the caret.

- PyErr_ProgramText() should be called when an
exception is printed
  rather than when it is raised.

- Fix pdb to support nested scopes.

- Produce a better error message/warning for code like
this:
  def f(x):
      def g():
          exec ...
          print x
  The warning message should say that exec is not
allowed in a nested
  function with free variables.  It currently says that
g *contains* a
  nested function with free variables.

- Update the documentation.

Jeremy


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-20 07:47

Message:
Logged In: YES 
user_id=6380

Jeremy, what's up with these?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405341&group_id=5470


From noreply@sourceforge.net  Tue Mar 20 15:48:22 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Mar 2001 07:48:22 -0800
Subject: [Python-bugs-list] [ python-Bugs-409419 ] gzip.py seek and tell methods are counter-productive (and seek is broken anyway)
Message-ID: <E14fOMw-0005vI-00@usw-sf-web1.sourceforge.net>

Bugs item #409419, was updated on 2001-03-17 09:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409419&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Priority: 5
Submitted By: Matthew Mueller (donut)
Assigned to: A.M. Kuchling (akuchling)
Summary: gzip.py seek and tell methods are counter-productive (and seek is broken anyway)

Initial Comment:
gzip.open returns an object that emulates a file type.  However, it does
not support seeking or telling.  That is not the problem, what is the
problem is that even though it does not support them, it has the methods
there anyway.  This means user code can not easily do a try: ... except:
AttributeError, to test if the object supports these methods.  Instead
it would have to except on IOError, and have no way of knowing if it was
a real file error. (other than the kludge of examing the error string)

Therefore, I believe it would be more correct if these methods were
removed entirely, or at least replace the exception with AttributeError
instead of IOError.

Oh, and if they aren't removed, the seek method should at least accept
an arg since as it is now it will never raise its desired exception
anyway.



----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2001-03-20 07:48

Message:
Logged In: YES 
user_id=11375

Good point; I'll resolve this.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-03-17 22:21

Message:
Logged In: YES 
user_id=31435

Assigned to Andrew, our resident gzip fan.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409419&group_id=5470


From noreply@sourceforge.net  Tue Mar 20 15:53:00 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Mar 2001 07:53:00 -0800
Subject: [Python-bugs-list] [ python-Bugs-409419 ] gzip.py seek and tell methods are counter-productive (and seek is broken anyway)
Message-ID: <E14fORQ-0003cs-00@usw-sf-web2.sourceforge.net>

Bugs item #409419, was updated on 2001-03-17 09:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409419&group_id=5470

Category: Extension Modules
Group: None
>Status: Closed
Priority: 5
Submitted By: Matthew Mueller (donut)
Assigned to: A.M. Kuchling (akuchling)
Summary: gzip.py seek and tell methods are counter-productive (and seek is broken anyway)

Initial Comment:
gzip.open returns an object that emulates a file type.  However, it does
not support seeking or telling.  That is not the problem, what is the
problem is that even though it does not support them, it has the methods
there anyway.  This means user code can not easily do a try: ... except:
AttributeError, to test if the object supports these methods.  Instead
it would have to except on IOError, and have no way of knowing if it was
a real file error. (other than the kludge of examing the error string)

Therefore, I believe it would be more correct if these methods were
removed entirely, or at least replace the exception with AttributeError
instead of IOError.

Oh, and if they aren't removed, the seek method should at least accept
an arg since as it is now it will never raise its desired exception
anyway.



----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2001-03-20 07:52

Message:
Logged In: YES 
user_id=11375

I've deleted the seek() and tell() methods as suggested.


----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2001-03-20 07:48

Message:
Logged In: YES 
user_id=11375

Good point; I'll resolve this.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-03-17 22:21

Message:
Logged In: YES 
user_id=31435

Assigned to Andrew, our resident gzip fan.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409419&group_id=5470


From noreply@sourceforge.net  Tue Mar 20 15:53:34 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Mar 2001 07:53:34 -0800
Subject: [Python-bugs-list] [ python-Bugs-408820 ] 'install -d' fails on BSDI systems.
Message-ID: <E14fORy-0003dK-00@usw-sf-web2.sourceforge.net>

Bugs item #408820, was updated on 2001-03-15 08:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408820&group_id=5470

Category: Installation
Group: Platform-specific
Status: Open
Priority: 6
Submitted By: Thomas Wouters (twouters)
>Assigned to: Neil Schemenauer (nascheme)
Summary: 'install -d' fails on BSDI systems.

Initial Comment:
Apparently the Makefile was changed to use 'install -d'
to create directories. This does not work on BSDI. It
seems to be an autoconf failure (since configure.in
just contains 'AC_PROG_INSTALL' but I haven't
experienced this before, with other software or with
Python.


----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2001-03-20 07:53

Message:
Logged In: YES 
user_id=11375

Makefile stuff is Neil's province.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-03-17 22:04

Message:
Logged In: YES 
user_id=31435

Assigned to Andrew because he's been known to succeed when 
installing things <ahem>.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408820&group_id=5470


From noreply@sourceforge.net  Tue Mar 20 15:58:57 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Mar 2001 07:58:57 -0800
Subject: [Python-bugs-list] [ python-Bugs-232460 ] SSL Support (Apparently) Broken on Solaris
Message-ID: <E14fOXB-00063c-00@usw-sf-web1.sourceforge.net>

Bugs item #232460, was updated on 2001-02-14 19:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=232460&group_id=5470

Category: Extension Modules
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: David M. Beazley (beazley)
Assigned to: A.M. Kuchling (akuchling)
Summary: SSL Support (Apparently) Broken on Solaris

Initial Comment:
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.

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2001-03-20 07:58

Message:
Logged In: YES 
user_id=11375

Moshe checked in patch #405101 to the CVS tree.  David, can
you update and see if it fixed the problem for you?


----------------------------------------------------------------------

Comment By: Moshe Zadka (moshez)
Date: 2001-03-18 02:30

Message:
Logged In: YES 
user_id=11645

I just want to me-too Neil, since I submitted the original
patch. I think it *did* fix problems on Solaris, as long
as the user is running EGD and set up RANDFILE env. variable
properly. Otherwise, you won't be getting connect errors,
but a warning from Python about using a non-secure way to
generate seed.
(For the record, the problem is that Solaris doesn't have a
/dev/urandom like Linux does)

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2001-03-02 07:49

Message:
Logged In: YES 
user_id=35752

It looks like patch "[ #405101 ] Add Random Seeding to
OpenSSL" might fix this.  Assigning to Andrew since he
is assigned that patch too.


----------------------------------------------------------------------

Comment By: David M. Beazley (beazley)
Date: 2001-02-15 06:12

Message:
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


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=232460&group_id=5470


From noreply@sourceforge.net  Tue Mar 20 16:06:29 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Mar 2001 08:06:29 -0800
Subject: [Python-bugs-list] [ python-Bugs-410008 ] cannot use crypt module
Message-ID: <E14fOeT-0006A3-00@usw-sf-web1.sourceforge.net>

Bugs item #410008, was updated on 2001-03-20 06:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410008&group_id=5470

>Category: Installation
>Group: Platform-specific
>Status: Closed
Priority: 5
Submitted By: eXom (jkuan)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: cannot use crypt module

Initial Comment:
I have downloaded the BeOpen-Python-2.0-1.i386.rpm from
www.python.org and installed fine. 

However, I cannot use the crypt module which is
described in the documentation.

>>> import crypt
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError: No module named crypt

Also if I do rpm -qpl on BeOpen-Python-2.0-1.i386.rpm,
there is crypt.py in the whole rpm file.


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-20 08:06

Message:
Logged In: YES 
user_id=6380

Crypt is a built-in that must be enabled at compile time.

Apparently we forgot about this when building the RPMs.

You can build from source though -- download the source code
tarball from python.org/2.0/.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410008&group_id=5470


From noreply@sourceforge.net  Tue Mar 20 16:13:27 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Mar 2001 08:13:27 -0800
Subject: [Python-bugs-list] [ python-Bugs-409773 ] Bug Fix In dircmp class
Message-ID: <E14fOlD-0006GY-00@usw-sf-web1.sourceforge.net>

Bugs item #409773, was updated on 2001-03-19 09:08
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409773&group_id=5470

Category: Python Library
Group: None
>Status: Closed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: Bug Fix In dircmp class

Initial Comment:
Hello, I tried to diff two directories, using
filecmp.dircmp class.

I have Python2.0 installed from source in Debian
(Potato).

The code is the following:
#!/tmp/bin/python
import filecmp
from filecmp import dircmp
a = dircmp('lala','loulou')

b = a.report_full_closure()

print b

It yields:

	hargikas@simula:~/src/mydiff$ ./mydiff.py
	diff lala loulou
	Only in loulou : ['kiko']	
	Traceback (most recent call last):
	  File "./mydiff.py", line 6, in ?
	    b = a.report_full_closure()
	  File "/tmp/lib/python2.0/filecmp.py", line 264,
in 			report_full_closure
	    self.report()
	  File "/tmp/lib/python2.0/filecmp.py", line 241, in
report
	    if self.same_files:
	  File "/tmp/lib/python2.0/filecmp.py", line 147, in
__getattr__
	    self.phase3()
	  File "/tmp/lib/python2.0/filecmp.py", line 214, in
phase3
	    xx = cmpfiles(self.left, self.right,
self.common_files)
	  File "/tmp/lib/python2.0/filecmp.py", line 288, in
cmpfiles
	    res[_cmp(ax, bx, shallow,
use_statcache)].append(x)
	TypeError: too many arguments; expected 2, got 4

Actually the 288 line of filecmp.py is:
	res[_cmp(ax, bx, shallow, use_statcache)].append(x)
and it should be:
	res[cmp(ax, bx, shallow, use_statcache)].append(x)

NOTE the missing undescore, in the correct version.

With that changed it worked ok:
	hargikas@simula:~/src/mydiff$ ./mydiff.py
	diff lala loulou
	Only in loulou : ['kiko']
	Identical files : ['loulou']
	Differing files : ['lala']
	None

Any Ideas???

Best Regards,
Charalampos Gikas,
Virtual Trip LTD
http://www.vtrip-ltd.com

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-20 08:13

Message:
Logged In: YES 
user_id=6380

This was fixed in Python 2.1.

The fix you suggest is wrong -- it really needs to call
_cmp().
Here's the proper fix:

*** filecmp.py	2000/07/03 08:18:47	1.6
--- filecmp.py	2000/12/03 20:48:07	1.7
***************
*** 295,303 ****
  #	1 for different
  #	2 for funny cases (can't stat, etc.)
  #
! def _cmp(a, b):
      try:
!         return not abs(cmp(a, b))
      except os.error:
          return 2
  
--- 295,303 ----
  #	1 for different
  #	2 for funny cases (can't stat, etc.)
  #
! def _cmp(a, b, sh, st):
      try:
!         return not abs(cmp(a, b, sh, st))
      except os.error:
          return 2
  


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409773&group_id=5470


From noreply@sourceforge.net  Tue Mar 20 16:27:23 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Mar 2001 08:27:23 -0800
Subject: [Python-bugs-list] [ python-Bugs-409755 ] Followup to Bug 233033 - 2.1 Builds Fail
Message-ID: <E14fOyh-0003xL-00@usw-sf-web2.sourceforge.net>

Bugs item #409755, was updated on 2001-03-19 07:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409755&group_id=5470

Category: Build
Group: None
Status: Open
>Priority: 3
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Followup to Bug 233033 - 2.1 Builds Fail

Initial Comment:
I am sorry it has taken me so long to follow up on my previous bug 
report but here it is.

I am attaching a file that shows the results of an attempted build. At
first, the build fails because setup.py cannot find the  os  module.
The file then shows the line I had to modify in the Makefile. I then 
continue the build with the modified Makefile - and it succeeds.

Even with the added line,  "make test" and "make install" will still fail.

I've seen the same results with Python 2.1a and 2.1b on both Redhat
6.2 and 7.0.

Contact me by email if I can be of further help. I promise to be more
prompt this time.

...Bob     ryodlowski@pirus.com

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-20 08:27

Message:
Logged In: YES 
user_id=6380

Where is the attached file?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409755&group_id=5470


From noreply@sourceforge.net  Tue Mar 20 17:09:00 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Mar 2001 09:09:00 -0800
Subject: [Python-bugs-list] [ python-Bugs-406792 ] python2.1b1 core dumps --with-pymalloc
Message-ID: <E14fPcy-0002zh-00@usw-sf-web3.sourceforge.net>

Bugs item #406792, was updated on 2001-03-07 11:08
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406792&group_id=5470

>Category: Build
Group: Platform-specific
Status: Open
>Priority: 3
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Nobody/Anonymous (nobody)
Summary: python2.1b1 core dumps --with-pymalloc 

Initial Comment:
% ./configure --without-threads --with-pymalloc
% gmake
...

./python setup.py
...
Then it dumps core. Removing the  --with-pymalloc and
it runs just fine.
[281] % uname -a
HP-UX wssgped B.10.20 A 9000/782 2001125167 two-user
license
[282] % gcc --version
2.95.1


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-20 09:08

Message:
Logged In: YES 
user_id=6380

Alas, I can't reproduce this on Linux.

I'm afraid building Python on HP-UX is braindead, and I
don't know wht the problem is.  No two HP-UX users ever seem
to run in the same problem, nor do I ever seem to get help
from folks with HP-UX machines in debugging those
problems...

So, while I am sympathetic, I can't help.  Somebody else
please help!


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406792&group_id=5470


From noreply@sourceforge.net  Tue Mar 20 17:11:17 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Mar 2001 09:11:17 -0800
Subject: [Python-bugs-list] [ python-Bugs-230029 ] [HP-UX] Python chokes on pthread_mutex_init
Message-ID: <E14fPfB-00030r-00@usw-sf-web3.sourceforge.net>

Bugs item #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: 3
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Guido van Rossum (gvanrossum)
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 (toddw)
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 (tim_one)
Date: 2001-02-09 15:29

Message:
Assigned to our resident HP-UX fan <wink>.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
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 noreply@sourceforge.net  Tue Mar 20 17:11:20 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Mar 2001 09:11:20 -0800
Subject: [Python-bugs-list] [ python-Bugs-210665 ] Compiling python on hpux 11.00 with threads (PR#360)
Message-ID: <E14fPfE-00031H-00@usw-sf-web3.sourceforge.net>

Bugs item #210665, was updated on 2000-07-31 14:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210665&group_id=5470

>Category: Threads
Group: Platform-specific
Status: Open
Priority: 3
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Compiling python on hpux 11.00 with threads (PR#360)

Initial Comment:
Jitterbug-Id: 360
Submitted-By: philipp.jocham@salomon.at
Date: Fri, 16 Jun 2000 08:47:06 -0400 (EDT)
Version: 1.5.2
OS: HP-UX 11.00


There are two missing details in the configure process to make this work
out of the box.

First: The function 
	pthread_create
isn't found in library libpthread.a but in libcma.a, because
pthread_create is just a macro in sys/pthread.h pointing to 
	__pthread_create_system

After patching ./configure directly and running 
	./configure --with-thread
(now detecting the correct library /usr/lib/libpthread.a) I also
added -lcl to Modules/Makefile at
	LIBS=           -lnet -lnsl -ldld  -lpthread -lcl

otherwise importing of modules with threads didn't work 
(in this case oci_.sl from DCOracle). 

I'm not sure about the correct syntax or wether it's the correct
place and method, but I would suggest a solution like the following
code snippet.

[...]
AC_MSG_CHECKING(for --with-thread)
[...]
AC_DEFINE(_POSIX_THREADS)
LIBS="$LIBS -lpthread -lcl"
LIBOBJS="$LIBOBJS thread.o"], [
AC_CHECK_LIB(pthread, __pthread_create_system, [AC_DEFINE(WITH_THREAD)
[...]

I hope this helps to make installation process smoother.
Fell free to contact me, if there are further questions.
Philipp
-- 
I confirm that, to the best of my knowledge and belief, this
contribution is free of any claims of third parties under
copyright, patent or other rights or interests ("claims").  To
the extent that I have any such claims, I hereby grant to CNRI a
nonexclusive, irrevocable, royalty-free, worldwide license to
reproduce, distribute, perform and/or display publicly, prepare
derivative versions, and otherwise use this contribution as part
of the Python software and its related documentation, or any
derivative versions thereof, at no cost to CNRI or its licensed
users, and to authorize others to do so.

I acknowledge that CNRI may, at its sole discretion, decide
whether or not to incorporate this contribution in the Python
software and its related documentation.  I further grant CNRI
permission to use my name and other identifying information
provided to CNRI by me for use in connection with the Python
software and its related documentation.



====================================================================
Audit trail:
Tue Jul 11 08:26:01 2000	guido	moved from incoming to open

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-11-02 08:38

Message:
Reopened because there's a dissenting opinion.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2000-11-02 07:25

Message:
Ok, check out the configure.in patch I created against Python 2.0:
  ftp://ftp.thewrittenword.com/outgoing/pub/python-2.0.patch

I tested it under HP-UX 11.00 and it works just fine. The thread test worked too.

-- 
albert chin (china@thewrittenword.com)

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2000-11-01 09:18

Message:
Ick! Why check for anything with __ prepended to the name? Isn't that like checking for a "hidden" function, which might not be there in a followup version?

On HP-UX 11.00, pthread_create is in /usr/lib/libc.sl anyway. The proper way to check for pthread_create is:
  AC_TRY_LINK([#include <pthread.h>

  void * start_routine (void *arg) { exit (0); }], [
  pthread_create (NULL, NULL, start_routine, NULL)], [
    AC_MSG_RESULT(yes)], [
    AC_MSG_RESULT(no)])

I modified configure.in in 2.0 to remove the patch you included in CVS 1.175 and added a test to include <pthread.h> similar to the above (linked without -lpthread and with -lpthread). I'm testing now. Will provide a patch when things are tested.

Also, I don't think threads on HP-UX 10.20 will work unless you have the DCE libraries installed. Anyhow, I'd probably avoid threads on 10.20.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-30 09:48

Message:
Philipp submitted a patch to configure.in that fixes the problem for him and doesn't look like it would break things for others.  configure.in, CVS revision 1.175.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-13 07:45

Message:
OK, so the correct thing to do seems to be to somehow add #include <pthread.h> to the tests for thread libraries. I'm afraid I won't be able to fix this in 2.0final, but I'll think about fixing it in 2.1 (or 2.0.1, whichever comes first :-).

----------------------------------------------------------------------

Comment By: Eddy De Greef (edg)
Date: 2000-10-10 04:55

Message:
I can confirm that the bug still exists in 2.0c1.
It works fine on HP-UX 10.20 (which only has libcma),
but not on HP-UX 11 (which both has libcma and libpthread).
The pthread_create function is not defined as a macro though,
but as a static function:

static int pthread_create(pthread_t *tid, const pthread_attr_t *attr, void *(*start_routine)(void *), void *arg)
   { return(__pthread_create_system(tid, attr, start_routine, arg)); }

I don't see an easy way to work around this.
I'm not a configure expert, but perhaps the script should
first check whether this code compiles and links:

#include <pthread.h>
int main()
{
   pthread_create(0,0,0,0);
   return 0;
}

and if not, fall back on the other tests ?


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-06 10:40

Message:
I have two reports from people for whom configure, build and run  with threads now works on HP-UX 10 and 11. I'm not sure what to do about this report... What's different on Philipp's system???

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-09-25 06:10

Message:
I'm hoping that this was fixed by recent changes. Sent an email to the original submittor to verify.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-09-22 02:56

Message:
Taking this because I'm considering to redesign the thread configuration section in configure.in anyway -- there's a similar bug report for Alpha OSF1.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2000-09-07 15:05

Message:
Please do triage on this bug.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210665&group_id=5470


From noreply@sourceforge.net  Tue Mar 20 17:11:18 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Mar 2001 09:11:18 -0800
Subject: [Python-bugs-list] [ python-Bugs-231377 ] [HP-UX] Python chokes on pthread_mutex_init
Message-ID: <E14fPfC-000319-00@usw-sf-web3.sourceforge.net>

Bugs item #231377, was updated on 2001-02-07 01:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=231377&group_id=5470

Category: Threads
Group: Platform-specific
Status: Open
>Priority: 3
Submitted By: Thomas Wallgram (twallgram)
Assigned to: Guido van Rossum (gvanrossum)
Summary: [HP-UX] Python chokes on pthread_mutex_init

Initial Comment:
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


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-02-09 15:50

Message:
Another for the eternal HP-UX pile.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=231377&group_id=5470


From noreply@sourceforge.net  Tue Mar 20 18:30:07 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Mar 2001 10:30:07 -0800
Subject: [Python-bugs-list] [ python-Bugs-405553 ] pydoc.help broken in IDLE
Message-ID: <E14fQtT-00081a-00@usw-sf-web1.sourceforge.net>

Bugs item #405553, was updated on 2001-03-02 15:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405553&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 7
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Ka-Ping Yee (ping)
Summary: pydoc.help broken in IDLE

Initial Comment:
pydoc has an (undocumented?) feature that after "from
pydoc import help" in an interactive interpreter,
help(object) or help("modulename") gives help.

This doesn't work right in IDLE:

On Unix, it brings up a pager in the terminal window
where IDLE was started.  That's not what you want!!!

On Windows, where IDLE is normally started from the
Start menu, it gives an error, complaining about an
invalid file descriptor.

Perhaps it should invoke a stupid internal pager, like
the one used by the license() built-in command?  That
"just works" in IDLE!


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-20 10:30

Message:
Logged In: YES 
user_id=6380

Hi Ping, the attached files never showed up on SF.

I think the SF problems have been fixed now, but I recommend
that you just check the patch in.  pydoc is your code -- you
can make it and break it!

----------------------------------------------------------------------

Comment By: Ka-Ping Yee (ping)
Date: 2001-03-03 18:35

Message:
Logged In: YES 
user_id=45338

Here's a little patch.  It just looks for __file__.

I tried help('sys') and all was well.

----------------------------------------------------------------------

Comment By: Ka-Ping Yee (ping)
Date: 2001-03-03 18:32

Message:
Logged In: YES 
user_id=45338

The pydoc.getpager() routine was written to try to take
care of this case by making sure that sys.stdout is a real
file and sys.stdin is a tty before launching an interactive
pager.  I just tried it now in IDLE with

Python 2.1a2 (#1, Mar  1 2001, 00:10:25) 
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on
linux2
Type "copyright", "credits" or "license" for more
information.
IDLE 0.6 -- press F1 for help
>>> from pydoc import help
>>> help('atexit')
Help on module atexit:

NAME
    atexit

...

and it worked fine.

I bet you tried "help('sys')", didn't you?  That clobbers
sys.stdin and sys.stdout by reloading 'sys'.  Not sure what
to do about that.  I suppose i could just add a special case
to never reload built-in modules.


-- ?!ng

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405553&group_id=5470


From noreply@sourceforge.net  Tue Mar 20 18:32:41 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Mar 2001 10:32:41 -0800
Subject: [Python-bugs-list] [ python-Bugs-409683 ] import tzparse --> fails
Message-ID: <E14fQvx-00082m-00@usw-sf-web1.sourceforge.net>

Bugs item #409683, was updated on 2001-03-19 02:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409683&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Hernan Martinez Foffani (hfoffani)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: import tzparse --> fails

Initial Comment:
In Windows OS, an import tzparse fails. May be 
See below:

Python 2.1b1 (#11, Mar  2 2001, 11:23:29) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
>>> import tzparse
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "c:\python21\lib\tzparse.py", line 67, in ?
    tzset()
  File "c:\python21\lib\tzparse.py", line 50, in tzset
    tzstr = os.environ['TZ']
  File "C:\Python21\lib\os.py", line 371, in 
__getitem__
    return self.data[key.upper()]
KeyError: TZ
>>>

At line 67 there is a call to tzset() which fails if:
- TZ environment variable is not set
- TZ is set but with an unrecognized format

Commenting such line works for me. I don't need 
tzparse, just was get the docs thru pydoc the utility. 
But that's just me, I don't know about other guys.
(BTW, the module is said to be obsolote)

I don't know if this is really a bug... I read GvR 
that Ping is going to change pydoc from "import" 
to "parse source"...




----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-20 10:32

Message:
Logged In: YES 
user_id=6380

I propose to make tzparse obsolete.  It clearly doesn't work
right, and doesn't seem to be neede.

Assigning to Fred to implement the necessary doc changes.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-03-19 15:37

Message:
Logged In: YES 
user_id=31392

I also find it annoying that this module can't be imported
if there isn't a valid TZ environment variable.  

I also noticed in the CVS log that tzparse.py was labelled
"no longer necessary" in June 1993.  Is it still useful?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409683&group_id=5470


From noreply@sourceforge.net  Tue Mar 20 18:39:16 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Mar 2001 10:39:16 -0800
Subject: [Python-bugs-list] [ python-Bugs-409355 ] Meta-class inheritance problem
Message-ID: <E14fR2K-0003lW-00@usw-sf-web3.sourceforge.net>

Bugs item #409355, was updated on 2001-03-17 02:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409355&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
>Priority: 7
Submitted By: Lorien Dunn (loriend)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Meta-class inheritance problem

Initial Comment:
I've run into a bug in python 2.0. The real code that
the following pseudo code represents throws a
TypeError.

class MyDerivedClass(MyPurePythonClass,MyBoostClass):
        def __init__(self):
                MyPurePythonClass.__init__(self)
                MyBoostClass.__init__(self)

The problem occurs in MyPurePythonClass- Python says
"unbound method must be called with class instance 1st
argument". This makes sense: I'm passing a meta-class
instead of a class. David Abrahams (the main author of
boost::python) agrees that this is a Python problem,
and that it should affect Zope as well.

I think I've found the point in the python 2.0 sorce
where it occurs:


ceval.c, line 1816 (reformatted for clarity):

/*              BEGIN CODE SAMPLE               */

else
{
/* Unbound methods must be called with an instance of
the class (or a derived class) as first argument */

     if (na > 0 && (self = stack_pointer[-n]) != NULL
                && PyInstance_Check(self)
                && PyClass_IsSubclass((PyObject
*) 		 		   (((PyInstanceObject*)  self)->in_class),
class))
                  /* Handy-dandy */ ;
      else
      {
        PyErr_SetString(PyExc_TypeError, "unbound
method must be 		called with class instance 1st
argument");
        x = NULL;
        break;
      }
}

/*              END CODE SAMPLE         */


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-18 14:22

Message:
Logged In: YES 
user_id=6380

Zope has several workarounds, so isn't affected.

But I agree it could be fixed.  The test is there because it wants to enforce a concept: 'self' should be an instance 
of the class that defines the method (where a subclass instance is fine too).

But the implementation of the test is based too much on the default implementation of classes.

Could someone please submit a patch that replaces the concrete isinstance() test with an isinstance() test similar 
to that in bltinmodule.c?  (Maybe we need to add a new C API, PyObject_IsInstance().)

If someone could come up with a check that conve

----------------------------------------------------------------------

Comment By: David Abrahams (david_abrahams)
Date: 2001-03-18 05:30

Message:
Logged In: YES 
user_id=52572

Sorry, that anonymous comment is mine. I'm still a bit 
clumsy with SourceForge.

-Dve

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-03-18 05:03

Message:
Logged In: NO 

I was a bit surprised to learn that this check was still in 
the code after issubclass and isinstance had been fixed to 
work with extension classes. Suppose you checked for a 
__class__ attribute on the first argument instead (or 
additionally)?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-03-17 21:29

Message:
Logged In: YES 
user_id=31435

Assigned to Guido, because I bet JimF would refuse to take 
blame for this <wink>.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409355&group_id=5470


From noreply@sourceforge.net  Tue Mar 20 18:45:34 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Mar 2001 10:45:34 -0800
Subject: [Python-bugs-list] [ python-Bugs-407915 ] largefile support under Linux
Message-ID: <E14fR8Q-0008E2-00@usw-sf-web1.sourceforge.net>

Bugs item #407915, was updated on 2001-03-12 06:43
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407915&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
>Priority: 7
Submitted By: Hans-Joachim Widmaier (hjwidmai)
Assigned to: Guido van Rossum (gvanrossum)
Summary: largefile support under Linux

Initial Comment:
While trying to build 2.1b1 with support for large
files under Linux (2.4, glibc 2.2),
Objects/fileobject.c didn't compile:

gcc -D_FILE_OFFSET_BITS=64 -c -g -O2 -Wall
-Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H  -o
Objects/fileobject.o Objects/fileobject.c
Objects/fileobject.c: In function `_portable_ftell':
Objects/fileobject.c:267: incompatible types in return
Objects/fileobject.c:275: warning: control reaches end
of non-void function

This is because fpos_t is a structure holding 2 long
longs. After changing

    return pos
to
    return pos.__pos

I got it to compile and it seems to work ok.
This is, of course, not a portable solution.

Alas, I don't really understand why there are 3 Methods
of getting largefile support (/usr/include/feature.h)
in glibc, even less why I'm bothered with defining
CFLAGS to get it; but configure seems unable to figure
out that itself. But this is not Python's fault.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-20 10:45

Message:
Logged In: YES 
user_id=6380

Sigh.  You can't win with this stuff!

Try this for now:

http://python.sourceforge.net/devel-docs/lib/posix-large-files.html

It suggests to add -D_LARGEFILE64_SOURCE which makes fpos a
long long.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407915&group_id=5470


From noreply@sourceforge.net  Tue Mar 20 18:49:10 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Mar 2001 10:49:10 -0800
Subject: [Python-bugs-list] [ python-Bugs-405837 ] getting PyRun_String() true result
Message-ID: <E14fRBu-0005Gd-00@usw-sf-web2.sourceforge.net>

Bugs item #405837, was updated on 2001-03-04 06:53
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405837&group_id=5470

Category: Python Interpreter Core
>Group: Not a Bug
>Status: Closed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Guido van Rossum (gvanrossum)
Summary: getting PyRun_String() true result

Initial Comment:
It seems impossible to build am embedded Python
interpreter extension which actually allows getting
the result of the evaluation of a string from the
interpreter, as it is done in interactive mode, as in
the following:
  def f: pass
  f
prints:
  <function f at 0x8069694>

But in C (called twice with the 2 above strings):
  PyRun_String(string, Py_file_input, globals, globals)
returns None.

I found a workaround by patching the core in ceval.c,
eval_code2() (inspired by the PRINT_EXPR case):

...
case POP_TOP:
  v = POP();
PyDict_SetItemString(f->f_globals, "_", v); /* added */
  Py_DECREF(v);
  continue;
...

and then:
  PyRun_String(string, Py_file_input, globals, globals)
  result =PyDict_GetItemString(globals, "_")
returns the '<function f at 0x8069694>' correct result.


My goal is to allow the tclpython extension (at
http://jfontain.free.fr/) to work without having to
insert print statements on the Python side to be able
to pass data to the Tcl interpreter.

Please forgive me if there is an obvious way to do the
above without patching the core, but I am new to Python
(I like it already though :-)

Jean-Luc Fontaine

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-20 10:49

Message:
Logged In: YES 
user_id=6380

This is not a bug.   Closing the bug report now.

If you need more help still, wrote help@python.org.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-03-05 10:51

Message:
Logged In: NO 

> To evaluate a string, use Py_RunString with Py_eval_input,
> or perhaps Py_single_input.

Py_eval_input is for "isolated expressions", and
Py_single_input "for a single statement", so how do I
execute whole modules except by using Py_file_input, the
only remaining option?

I actually tested all the above options thoroughly and found
that only Py_file_input did the job, but without a way to
get at the result.

Please let me know whether there is something that I missed,
as I am stuck at the moment. If needed, I will be happy to
send you sample code that illustrates the problem.

Thank you very much for your prompt response.

Jean-Luc

PS: passing "def f(): pass\n" to Py_eval_input returns a
"SyntaxError: invalid syntax"


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-03-04 10:22

Message:
Logged In: YES 
user_id=21627

Sure there is. PyRun_SimpleString executes a string in "file
mode"; this has no result. The interactive interpreter, when
it prints a result, runs the string in "eval mode" - only
evaluation gives a result.

To evaluate a string, use Py_RunString with Py_eval_input,
or perhaps Py_single_input.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405837&group_id=5470


From noreply@sourceforge.net  Tue Mar 20 19:43:05 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Mar 2001 11:43:05 -0800
Subject: [Python-bugs-list] [ python-Bugs-404545 ] frozen package import uses wrong files
Message-ID: <E14fS25-0004ML-00@usw-sf-web3.sourceforge.net>

Bugs item #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: 2
Submitted By: Toby Dickenson (htrd)
Assigned to: Guido van Rossum (gvanrossum)
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.



----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-20 11:43

Message:
Logged In: YES 
user_id=6380

I agree this is a bug.

I think there are lots of other ways to break frozen
programs, so I don't think this is a high priority security
bug.

I wish I had more time to research this, but I don't, so
I'll give this a low priority.  If someone submits a patch,
I'd be grateful!

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=404545&group_id=5470


From noreply@sourceforge.net  Tue Mar 20 19:46:16 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Mar 2001 11:46:16 -0800
Subject: [Python-bugs-list] [ python-Bugs-232136 ] traceback module gets out of sync source lines
Message-ID: <E14fS5A-0005mh-00@usw-sf-web2.sourceforge.net>

Bugs item #232136, was updated on 2001-02-12 21:19
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=232136&group_id=5470

Category: Python Library
Group: None
Status: Open
>Priority: 2
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Guido van Rossum (gvanrossum)
Summary: traceback module gets out of sync source lines

Initial Comment:
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


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-20 11:46

Message:
Logged In: YES 
user_id=6380

Lowering priority -- I don't have time to fix this before
2.1b2.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-02-13 05:49

Message:
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?


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-02-13 02:48

Message:
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 ...

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=232136&group_id=5470


From noreply@sourceforge.net  Tue Mar 20 19:56:36 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Mar 2001 11:56:36 -0800
Subject: [Python-bugs-list] [ python-Bugs-231189 ] Crash when Python Re-Initialized with Daemon Threads
Message-ID: <E14fSFA-0004Tz-00@usw-sf-web3.sourceforge.net>

Bugs item #231189, was updated on 2001-02-05 15:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=231189&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Closed
Priority: 5
Submitted By: Justin D. Pettit (jpettit)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Crash when Python Re-Initialized with Daemon Threads

Initial Comment:
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 ---------

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-20 11:56

Message:
Logged In: YES 
user_id=6380

It's not really possible to do something about this.  There
is no way to kill a thread (for very good reasons having to
do with releasing resources such as locks) if there are
threads running (daemon or otherwise) when Py_Finalize() is
called.  I agree that it's a pain that this can crash, but,
alas, I can't fix it.

So I'm closing this bug report. :-(

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-02-09 15:33

Message:
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).

----------------------------------------------------------------------

Comment By: Justin D. Pettit (jpettit)
Date: 2001-02-05 15:08

Message:
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?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=231189&group_id=5470


From noreply@sourceforge.net  Tue Mar 20 20:06:31 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Mar 2001 12:06:31 -0800
Subject: [Python-bugs-list] [ python-Bugs-230359 ] Run script should not appear in shell window
Message-ID: <E14fSOl-0000mW-00@usw-sf-web1.sourceforge.net>

Bugs item #230359, was updated on 2001-01-28 15:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=230359&group_id=5470

Category: IDLE
Group: None
Status: Open
>Priority: 2
Submitted By: Martin v. Löwis (loewis)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Run script should not appear in shell window

Initial Comment:
When selecting "Run module" in the shell window, an error message
"The buffer Python Shell is not saved..." is produced.

Since running the shell window will fail in any case, these menu items should be removed from the shell window.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-20 12:06

Message:
Logged In: YES 
user_id=6380

Good suggestion.  A revamping of the entire IDLE "run
program" interface is planned, but won't be ready in time
for 2.1.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=230359&group_id=5470


From noreply@sourceforge.net  Tue Mar 20 20:11:55 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Mar 2001 12:11:55 -0800
Subject: [Python-bugs-list] [ python-Bugs-229840 ] IDLE needs to print !
Message-ID: <E14fSTz-0004cX-00@usw-sf-web3.sourceforge.net>

Bugs item #229840, was updated on 2001-01-23 10:52
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=229840&group_id=5470

Category: IDLE
Group: Feature Request
Status: Open
>Priority: 1
Submitted By: Charles Doutriaux (cdoutri)
Assigned to: Guido van Rossum (gvanrossum)
Summary: IDLE needs to print !

Initial Comment:
It'd be really nice if idle had a print function, all these nice colors got to be printed ! or at least a postscript output would be nice.

Thanks,

C.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-01-23 18:40

Message:
The kind folks from reportlab.com once contributed a printing function.  it was kind of slow though.  But maybe it should still be added.  I think I have it somewhere still.  The problem is the licensing (it's not relesed under the same license as Python itself).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=229840&group_id=5470


From noreply@sourceforge.net  Tue Mar 20 20:22:11 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Mar 2001 12:22:11 -0800
Subject: [Python-bugs-list] [ python-Bugs-229843 ] MacOSX  case insensitivity bug resurfaces
Message-ID: <E14fSdv-0004hw-00@usw-sf-web3.sourceforge.net>

Bugs item #229843, was updated on 2001-01-23 11:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=229843&group_id=5470

Category: Build
Group: Platform-specific
>Status: Closed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Guido van Rossum (gvanrossum)
Summary: MacOSX  case insensitivity bug resurfaces

Initial Comment:
The case insensitivity with HFS+ MacOSX bug has 
resurfaced with the 2.1a1 release. 

import FCNTL; import fcntl

or 

import termios; import TERMIOS

(and maybe others) 

will crash due to duplicate symbols as it tries to import
the same shared libraries twice instead ot importing
the .py file for one of them. 

This was handled in 2.0 by building those modules as
built-in, not shared.  ( I haven't yet figured out the new
setup.py system.  Maybe it should be fixed in import. ) 

-- Steve M.  <sdm7g>



----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-20 12:22

Message:
Logged In: YES 
user_id=6380

This was fixed in 2.1b1.

----------------------------------------------------------------------

Comment By: Steven D. Majewski (sdm7g)
Date: 2001-01-29 16:01

Message:
[Patch #103495] case sensitive import for case insensitive  FileSystem

I submitted a patch that fixes the problem.
(#ifdefs around the code probably ought to
  be changed to also test __APPLE__ )

- Steve Majewski

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-01-23 22:13

Message:
There is also a  clash between:
lib/plat-Darwin1.2/SOCKET.py
& lib/socket.py
which can't be fixed by building one
builtin. ( The .so is _socketmodule.so,
so it doesn't clash. ) 

- sdm7g

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-01-23 18:46

Message:
You can make them built-in by adding them to the Modules/Setup file -- that file still exists and works as before, it's just that most modules aren't listed there any more.  See also the discussion at this patch:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102409&group_id=5470

The long-term solution is to get rid of the FCNTL and TERMIOS modules and include the symbols in the extension -- as has been done for e.g. the socket module.  (Some of the symbols of FCNTL are already exported by fcntl or os.)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=229843&group_id=5470


From noreply@sourceforge.net  Tue Mar 20 20:27:38 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Mar 2001 12:27:38 -0800
Subject: [Python-bugs-list] [ python-Bugs-410146 ] python 2.1b shelve is broken
Message-ID: <E14fSjC-00015N-00@usw-sf-web1.sourceforge.net>

Bugs item #410146, was updated on 2001-03-20 12:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410146&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Robert Drach (drach)
Assigned to: Nobody/Anonymous (nobody)
Summary: python 2.1b shelve is broken

Initial Comment:
python 2.1b shelve module is broken, on Redhat Linux
6.2:

% python
Python 2.1b1 (#1, Mar 19 2001, 15:18:14)
[GCC 2.95.2 19991024 (release)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import shelve
>>> f = shelve.open('testshelve')
>>> f.keys()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/cdat/alpha/lib/python2.1/shelve.py",
line 56, in keys
    return self.dict.keys()
MemoryError 

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410146&group_id=5470


From noreply@sourceforge.net  Tue Mar 20 21:03:34 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Mar 2001 13:03:34 -0800
Subject: [Python-bugs-list] [ python-Bugs-409755 ] Followup to Bug 233033 - 2.1 Builds Fail
Message-ID: <E14fTHy-0001X5-00@usw-sf-web1.sourceforge.net>

Bugs item #409755, was updated on 2001-03-19 07:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409755&group_id=5470

Category: Build
Group: None
Status: Open
Priority: 3
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Followup to Bug 233033 - 2.1 Builds Fail

Initial Comment:
I am sorry it has taken me so long to follow up on my previous bug 
report but here it is.

I am attaching a file that shows the results of an attempted build. At
first, the build fails because setup.py cannot find the  os  module.
The file then shows the line I had to modify in the Makefile. I then 
continue the build with the modified Makefile - and it succeeds.

Even with the added line,  "make test" and "make install" will still fail.

I've seen the same results with Python 2.1a and 2.1b on both Redhat
6.2 and 7.0.

Contact me by email if I can be of further help. I promise to be more
prompt this time.

...Bob     ryodlowski@pirus.com

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-03-20 13:03

Message:
Logged In: NO 

Here (finally) is the log file.



{/home/ryodlowski/Linux/Python-2.1b1} make clean
find . -name '*.o' -exec rm -f {} ';'
find . -name '*.py[co]' -exec rm -f {} ';'
{/home/ryodlowski/Linux/Python-2.1b1} mv Makefile 
Makefile_MODIFIED
{/home/ryodlowski/Linux/Python-2.1b1} mv Makefile~ Makefile


{/home/ryodlowski/Linux/Python-2.1b1} make
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Modules/python.o Modules/python.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Parser/acceler.o Parser/acceler.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Parser/grammar1.o Parser/grammar1.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Parser/listnode.o Parser/listnode.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Parser/node.o Parser/node.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Parser/parser.o Parser/parser.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Parser/parsetok.o Parser/parsetok.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Parser/tokenizer.o Parser/tokenizer.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Parser/bitset.o Parser/bitset.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Parser/metagrammar.o Parser/metagrammar.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Parser/myreadline.o Parser/myreadline.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Objects/abstract.o Objects/abstract.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Objects/bufferobject.o 
Objects/bufferobject.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Objects/cellobject.o Objects/cellobject.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Objects/classobject.o 
Objects/classobject.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Objects/cobject.o Objects/cobject.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Objects/complexobject.o 
Objects/complexobject.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Objects/fileobject.o Objects/fileobject.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Objects/floatobject.o 
Objects/floatobject.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Objects/frameobject.o 
Objects/frameobject.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Objects/funcobject.o Objects/funcobject.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Objects/intobject.o Objects/intobject.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Objects/listobject.o Objects/listobject.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Objects/longobject.o Objects/longobject.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Objects/dictobject.o Objects/dictobject.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Objects/methodobject.o 
Objects/methodobject.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Objects/moduleobject.o 
Objects/moduleobject.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Objects/object.o Objects/object.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Objects/rangeobject.o 
Objects/rangeobject.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Objects/sliceobject.o 
Objects/sliceobject.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Objects/stringobject.o 
Objects/stringobject.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Objects/tupleobject.o 
Objects/tupleobject.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Objects/typeobject.o Objects/typeobject.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Objects/unicodeobject.o 
Objects/unicodeobject.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Objects/unicodectype.o 
Objects/unicodectype.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Python/bltinmodule.o Python/bltinmodule.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Python/exceptions.o Python/exceptions.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Python/ceval.o Python/ceval.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Parser/firstsets.o Parser/firstsets.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Parser/grammar.o Parser/grammar.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Parser/pgen.o Parser/pgen.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Parser/printgrammar.o 
Parser/printgrammar.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Parser/pgenmain.o Parser/pgenmain.c
gcc -g -O2 -Wall -Wstrict-prototypes  Parser/acceler.o 
Parser/grammar1.o Parser/listnode.o Parser/node.o 
Parser/parser.o Parser/parsetok.o Parser/tokenizer.o 
Parser/bitset.o Parser/metagrammar.o Parser/firstsets.o 
Parser/grammar.o Parser/pgen.o Parser/printgrammar.o 
Parser/pgenmain.o -lpthread -ldl  -lutil -o Parser/pgen
Parser/pgen ./Grammar/Grammar ./Include/graminit.h ./Python/
graminit.c
Compiling (meta-) parse tree into NFA grammar
Making DFA for 'single_input' ...
Making DFA for 'file_input' ...
Making DFA for 'eval_input' ...
Making DFA for 'funcdef' ...
Making DFA for 'parameters' ...
Making DFA for 'varargslist' ...
Making DFA for 'fpdef' ...
Making DFA for 'fplist' ...
Making DFA for 'stmt' ...
Making DFA for 'simple_stmt' ...
Making DFA for 'small_stmt' ...
Making DFA for 'expr_stmt' ...
Making DFA for 'augassign' ...
Making DFA for 'print_stmt' ...
Making DFA for 'del_stmt' ...
Making DFA for 'pass_stmt' ...
Making DFA for 'flow_stmt' ...
Making DFA for 'break_stmt' ...
Making DFA for 'continue_stmt' ...
Making DFA for 'return_stmt' ...
Making DFA for 'raise_stmt' ...
Making DFA for 'import_stmt' ...
Making DFA for 'import_as_name' ...
Making DFA for 'dotted_as_name' ...
Making DFA for 'dotted_name' ...
Making DFA for 'global_stmt' ...
Making DFA for 'exec_stmt' ...
Making DFA for 'assert_stmt' ...
Making DFA for 'compound_stmt' ...
Making DFA for 'if_stmt' ...
Making DFA for 'while_stmt' ...
Making DFA for 'for_stmt' ...
Making DFA for 'try_stmt' ...
Making DFA for 'except_clause' ...
Making DFA for 'suite' ...
Making DFA for 'test' ...
Making DFA for 'and_test' ...
Making DFA for 'not_test' ...
Making DFA for 'comparison' ...
Making DFA for 'comp_op' ...
Making DFA for 'expr' ...
Making DFA for 'xor_expr' ...
Making DFA for 'and_expr' ...
Making DFA for 'shift_expr' ...
Making DFA for 'arith_expr' ...
Making DFA for 'term' ...
Making DFA for 'factor' ...
Making DFA for 'power' ...
Making DFA for 'atom' ...
Making DFA for 'listmaker' ...
Making DFA for 'lambdef' ...
Making DFA for 'trailer' ...
Making DFA for 'subscriptlist' ...
Making DFA for 'subscript' ...
Making DFA for 'sliceop' ...
Making DFA for 'exprlist' ...
Making DFA for 'testlist' ...
Making DFA for 'dictmaker' ...
Making DFA for 'classdef' ...
Making DFA for 'arglist' ...
Making DFA for 'argument' ...
Making DFA for 'list_iter' ...
Making DFA for 'list_for' ...
Making DFA for 'list_if' ...
Adding FIRST sets ...
Writing ./Python/graminit.c ...
Writing ./Include/graminit.h ...
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Python/compile.o Python/compile.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Python/codecs.o Python/codecs.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Python/errors.o Python/errors.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Python/frozen.o Python/frozen.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Python/frozenmain.o Python/frozenmain.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Python/future.o Python/future.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Python/getargs.o Python/getargs.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Python/getcompiler.o Python/getcompiler.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Python/getcopyright.o 
Python/getcopyright.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Python/getmtime.o Python/getmtime.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H -DPLATFORM='"linux2"' -o 
Python/getplatform.o ./Python/getplatform.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Python/getversion.o Python/getversion.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Python/graminit.o Python/graminit.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Python/import.o Python/import.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H -I/ -o Python/importdl.o ./Python/importdl.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Python/marshal.o Python/marshal.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Python/modsupport.o Python/modsupport.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Python/mystrtoul.o Python/mystrtoul.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Python/pyfpe.o Python/pyfpe.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Python/pystate.o Python/pystate.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Python/pythonrun.o Python/pythonrun.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Python/structmember.o 
Python/structmember.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Python/symtable.o Python/symtable.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Python/sysmodule.o Python/sysmodule.c
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_shlib.o 
Python/dynload_shlib.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Python/thread.o Python/thread.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Modules/config.o Modules/config.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -DPYTHONPATH='":plat-linux2:lib-tk"' \
	-DPREFIX='"/home/ryodlowski/Linux/Installations"' \
	-
DEXEC_PREFIX='"/home/ryodlowski/Linux/Installations"' \
	-DVERSION='"2.1"' \
	-DVPATH='""' \
	-o Modules/getpath.o ./Modules/getpath.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Modules/main.o Modules/main.c
gcc -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H   -c ./Modules/gcmodule.c -o 
Modules/gcmodule.o
gcc -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H   -c ./Modules/threadmodule.c -o 
Modules/threadmodule.o
gcc -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H   -c ./Modules/signalmodule.c -o 
Modules/signalmodule.o
gcc -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H   -c ./Modules/posixmodule.c -o 
Modules/posixmodule.o
gcc -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H   -c ./Modules/_sre.c -o Modules/_sre.o
if test -f buildno; then \
	expr `cat buildno` + 1 >buildno1; \
	mv -f buildno1 buildno; \
else echo 1 >buildno; fi
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -DBUILD=`cat buildno` -o 
Modules/getbuildinfo.o ./Modules/getbuildinfo.c
rm -f libpython2.1.a
# avoid long command lines, same as LIBRARY_OBJS
ar cr libpython2.1.a Modules/getbuildinfo.o
ar cr libpython2.1.a Parser/acceler.o Parser/grammar1.o 
Parser/listnode.o Parser/node.o Parser/parser.o 
Parser/parsetok.o Parser/tokenizer.o Parser/bitset.o 
Parser/metagrammar.o Parser/myreadline.o
ar cr libpython2.1.a Objects/abstract.o 
Objects/bufferobject.o Objects/cellobject.o 
Objects/classobject.o Objects/cobject.o 
Objects/complexobject.o Objects/fileobject.o 
Objects/floatobject.o Objects/frameobject.o 
Objects/funcobject.o Objects/intobject.o 
Objects/listobject.o Objects/longobject.o 
Objects/dictobject.o Objects/methodobject.o 
Objects/moduleobject.o Objects/object.o 
Objects/rangeobject.o Objects/sliceobject.o 
Objects/stringobject.o Objects/tupleobject.o 
Objects/typeobject.o Objects/unicodeobject.o 
Objects/unicodectype.o
ar cr libpython2.1.a Python/bltinmodule.o 
Python/exceptions.o Python/ceval.o Python/compile.o 
Python/codecs.o Python/errors.o Python/frozen.o 
Python/frozenmain.o Python/future.o Python/getargs.o 
Python/getcompiler.o Python/getcopyright.o 
Python/getmtime.o Python/getplatform.o Python/getversion.o 
Python/graminit.o Python/import.o Python/importdl.o 
Python/marshal.o Python/modsupport.o Python/mystrtoul.o 
Python/pyfpe.o Python/pystate.o Python/pythonrun.o 
Python/structmember.o Python/symtable.o Python/sysmodule.o 
Python/traceback.o Python/getopt.o Python/dynload_shlib.o 
Python/thread.o
ar cr libpython2.1.a Modules/config.o Modules/getpath.o 
Modules/main.o 
ar cr libpython2.1.a Modules/gcmodule.o  
Modules/threadmodule.o  Modules/signalmodule.o  
Modules/posixmodule.o  Modules/_sre.o
ranlib libpython2.1.a
gcc  -Xlinker -export-dynamic -o python Modules/python.o \
		libpython2.1.a -lpthread -ldl  -lutil   -
lm  
PYTHONPATH= ./python ./setup.py build
'import site' failed; use -v for traceback
Traceback (most recent call last):
  File "./setup.py", line 9, in ?
    import sys, os, getopt
ImportError: No module named os
make: *** [sharedmods] Error 1




{/home/ryodlowski/Linux/Python-2.1b1} mv Makefile 
Makefile_ORG
{/home/ryodlowski/Linux/Python-2.1b1} cp Makefile_MODIFIED 
Makefile
{/home/ryodlowski/Linux/Python-2.1b1} diff Makefile_ORG 
Makefile_MODIFIED 
155c155
< SITEPATH=
---
> SITEPATH=/home/ryodlowski/Linux/Python-2.1b1/Lib




{/home/ryodlowski/Linux/Python-2.1b1} make
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -
DPYTHONPATH='"/home/ryodlowski/Linux/Python-2.1b1/Lib:plat-
linux2:lib-tk"' \
	-DPREFIX='"/home/ryodlowski/Linux/Installations"' \
	-
DEXEC_PREFIX='"/home/ryodlowski/Linux/Installations"' \
	-DVERSION='"2.1"' \
	-DVPATH='""' \
	-o Modules/getpath.o ./Modules/getpath.c
if test -f buildno; then \
	expr `cat buildno` + 1 >buildno1; \
	mv -f buildno1 buildno; \
else echo 1 >buildno; fi
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -DBUILD=`cat buildno` -o 
Modules/getbuildinfo.o ./Modules/getbuildinfo.c
rm -f libpython2.1.a
# avoid long command lines, same as LIBRARY_OBJS
ar cr libpython2.1.a Modules/getbuildinfo.o
ar cr libpython2.1.a Parser/acceler.o Parser/grammar1.o 
Parser/listnode.o Parser/node.o Parser/parser.o 
Parser/parsetok.o Parser/tokenizer.o Parser/bitset.o 
Parser/metagrammar.o Parser/myreadline.o
ar cr libpython2.1.a Objects/abstract.o 
Objects/bufferobject.o Objects/cellobject.o 
Objects/classobject.o Objects/cobject.o 
Objects/complexobject.o Objects/fileobject.o 
Objects/floatobject.o Objects/frameobject.o 
Objects/funcobject.o Objects/intobject.o 
Objects/listobject.o Objects/longobject.o 
Objects/dictobject.o Objects/methodobject.o 
Objects/moduleobject.o Objects/object.o 
Objects/rangeobject.o Objects/sliceobject.o 
Objects/stringobject.o Objects/tupleobject.o 
Objects/typeobject.o Objects/unicodeobject.o 
Objects/unicodectype.o
ar cr libpython2.1.a Python/bltinmodule.o 
Python/exceptions.o Python/ceval.o Python/compile.o 
Python/codecs.o Python/errors.o Python/frozen.o 
Python/frozenmain.o Python/future.o Python/getargs.o 
Python/getcompiler.o Python/getcopyright.o 
Python/getmtime.o Python/getplatform.o Python/getversion.o 
Python/graminit.o Python/import.o Python/importdl.o 
Python/marshal.o Python/modsupport.o Python/mystrtoul.o 
Python/pyfpe.o Python/pystate.o Python/pythonrun.o 
Python/structmember.o Python/symtable.o Python/sysmodule.o 
Python/traceback.o Python/getopt.o Python/dynload_shlib.o 
Python/thread.o
ar cr libpython2.1.a Modules/config.o Modules/getpath.o 
Modules/main.o 
ar cr libpython2.1.a Modules/gcmodule.o  
Modules/threadmodule.o  Modules/signalmodule.o  
Modules/posixmodule.o  Modules/_sre.o
ranlib libpython2.1.a
gcc  -Xlinker -export-dynamic -o python Modules/python.o \
		libpython2.1.a -lpthread -ldl  -lutil   -
lm  
PYTHONPATH= ./python ./setup.py build
running build
running build_ext
skipping 'struct' extension (up-to-date)
skipping 'regex' extension (up-to-date)
skipping 'pcre' extension (up-to-date)
skipping '_weakref' extension (up-to-date)
skipping '_symtable' extension (up-to-date)
skipping 'xreadlines' extension (up-to-date)
skipping 'array' extension (up-to-date)
skipping 'cmath' extension (up-to-date)
skipping 'math' extension (up-to-date)
skipping 'strop' extension (up-to-date)
skipping 'time' extension (up-to-date)
skipping 'operator' extension (up-to-date)
skipping '_codecs' extension (up-to-date)
skipping '_testcapi' extension (up-to-date)
skipping 'unicodedata' extension (up-to-date)
skipping '_locale' extension (up-to-date)
skipping 'fcntl' extension (up-to-date)
skipping 'pwd' extension (up-to-date)
skipping 'grp' extension (up-to-date)
skipping 'errno' extension (up-to-date)
skipping 'select' extension (up-to-date)
skipping 'md5' extension (up-to-date)
skipping 'sha' extension (up-to-date)
skipping 'new' extension (up-to-date)
skipping 'binascii' extension (up-to-date)
skipping 'parser' extension (up-to-date)
skipping 'cStringIO' extension (up-to-date)
skipping 'cPickle' extension (up-to-date)
skipping 'mmap' extension (up-to-date)
skipping 'rotor' extension (up-to-date)
skipping 'syslog' extension (up-to-date)
skipping 'timing' extension (up-to-date)
skipping 'audioop' extension (up-to-date)
skipping 'imageop' extension (up-to-date)
skipping 'rgbimg' extension (up-to-date)
skipping 'readline' extension (up-to-date)
skipping 'crypt' extension (up-to-date)
skipping '_socket' extension (up-to-date)
skipping 'dbm' extension (up-to-date)
skipping 'gdbm' extension (up-to-date)
skipping 'bsddb' extension (up-to-date)
skipping 'termios' extension (up-to-date)
skipping 'resource' extension (up-to-date)
skipping 'nis' extension (up-to-date)
skipping '_curses' extension (up-to-date)
skipping '_curses_panel' extension (up-to-date)
skipping 'fpectl' extension (up-to-date)
skipping 'zlib' extension (up-to-date)
skipping 'linuxaudiodev' extension (up-to-date)
skipping '_tkinter' extension (up-to-date)
running build_scripts
not copying /home/ryodlowski/Linux/Python-
2.1b1/Tools/scripts/pydoc (up-to-date)
{/home/ryodlowski/Linux/Python-2.1b1} 
{/home/ryodlowski/Linux/Python-2.1b1} make clean
/home/ryodlowski/Linux/Python-2.1b1: Permission denied.
{/home/ryodlowski/Linux/Python-2.1b1} 


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-20 08:27

Message:
Logged In: YES 
user_id=6380

Where is the attached file?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409755&group_id=5470


From noreply@sourceforge.net  Tue Mar 20 21:28:14 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Mar 2001 13:28:14 -0800
Subject: [Python-bugs-list] [ python-Bugs-410155 ] tokenize.NL missing
Message-ID: <E14fTfq-0005Ly-00@usw-sf-web3.sourceforge.net>

Bugs item #410155, was updated on 2001-03-20 13:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410155&group_id=5470

Category: Documentation
Group: None
Status: Open
Priority: 5
Submitted By: Jürgen Hermann (jhermann)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: tokenize.NL missing

Initial Comment:
In section 17.5 of the Python 2.0 Library Reference, 
the constant "NL" is not documented.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410155&group_id=5470


From noreply@sourceforge.net  Tue Mar 20 21:34:05 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Mar 2001 13:34:05 -0800
Subject: [Python-bugs-list] [ python-Bugs-406705 ] imaplib search() quoting search criteria
Message-ID: <E14fTlV-0006lw-00@usw-sf-web2.sourceforge.net>

Bugs item #406705, was updated on 2001-03-07 07:05
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406705&group_id=5470

Category: Python Library
Group: None
>Status: Closed
Priority: 5
Submitted By: Christian Kissner (b7kich)
Assigned to: Skip Montanaro (montanaro)
Summary: imaplib search() quoting search criteria

Initial Comment:
Imaplib IMAP4.search() contains a bug in criteria
handling: when
sending a single word criterium it gets written to the
stream well: 
	M.search(None, 'ALL')
produces:
	GINH16 SEARCH
ALL                                         

But a criterium with a white space will be quoted:

	M.search(None,'TEXT Hello')
produces in the tcp stream:
	GINH17 SEARCH "TEXT Hello"

which gets rejected because quotes are only allowed
around
the string, not the criterium:
	GINH17 SEARCH TEXT "Hello"



----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2001-03-20 13:34

Message:
Logged In: YES 
user_id=44345

Having heard nothing else on this, I'm going to conclude my
reading of the code was correct and am closing it

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2001-03-18 12:01

Message:
Logged In: YES 
user_id=44345

This doesn't look like a bug to me.  Looks like the search
call is incorrect.  I think it should be called as

    M.search(None, "TEXT", "Hello")

I've never used the imaplib stuff before, however.  I'd
welcome some input from someone who has.

Skip


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-03-17 21:49

Message:
Logged In: YES 
user_id=31435

Assigned to Skip at random.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406705&group_id=5470


From noreply@sourceforge.net  Tue Mar 20 21:34:23 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Mar 2001 13:34:23 -0800
Subject: [Python-bugs-list] [ python-Bugs-405837 ] getting PyRun_String() true result
Message-ID: <E14fTln-0005Pw-00@usw-sf-web3.sourceforge.net>

Bugs item #405837, was updated on 2001-03-04 06:53
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405837&group_id=5470

Category: Python Interpreter Core
Group: Not a Bug
Status: Closed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Guido van Rossum (gvanrossum)
Summary: getting PyRun_String() true result

Initial Comment:
It seems impossible to build am embedded Python
interpreter extension which actually allows getting
the result of the evaluation of a string from the
interpreter, as it is done in interactive mode, as in
the following:
  def f: pass
  f
prints:
  <function f at 0x8069694>

But in C (called twice with the 2 above strings):
  PyRun_String(string, Py_file_input, globals, globals)
returns None.

I found a workaround by patching the core in ceval.c,
eval_code2() (inspired by the PRINT_EXPR case):

...
case POP_TOP:
  v = POP();
PyDict_SetItemString(f->f_globals, "_", v); /* added */
  Py_DECREF(v);
  continue;
...

and then:
  PyRun_String(string, Py_file_input, globals, globals)
  result =PyDict_GetItemString(globals, "_")
returns the '<function f at 0x8069694>' correct result.


My goal is to allow the tclpython extension (at
http://jfontain.free.fr/) to work without having to
insert print statements on the Python side to be able
to pass data to the Tcl interpreter.

Please forgive me if there is an obvious way to do the
above without patching the core, but I am new to Python
(I like it already though :-)

Jean-Luc Fontaine

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-03-20 13:34

Message:
Logged In: NO 

I agree that this is not a bug per se.
I am puzzled though, that other scripting languages, such as
Perl and Tcl can readily do this.
I still have no answer to my request, so I guess I will try
help@python.org as you recommend.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-20 10:49

Message:
Logged In: YES 
user_id=6380

This is not a bug.   Closing the bug report now.

If you need more help still, wrote help@python.org.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-03-05 10:51

Message:
Logged In: NO 

> To evaluate a string, use Py_RunString with Py_eval_input,
> or perhaps Py_single_input.

Py_eval_input is for "isolated expressions", and
Py_single_input "for a single statement", so how do I
execute whole modules except by using Py_file_input, the
only remaining option?

I actually tested all the above options thoroughly and found
that only Py_file_input did the job, but without a way to
get at the result.

Please let me know whether there is something that I missed,
as I am stuck at the moment. If needed, I will be happy to
send you sample code that illustrates the problem.

Thank you very much for your prompt response.

Jean-Luc

PS: passing "def f(): pass\n" to Py_eval_input returns a
"SyntaxError: invalid syntax"


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-03-04 10:22

Message:
Logged In: YES 
user_id=21627

Sure there is. PyRun_SimpleString executes a string in "file
mode"; this has no result. The interactive interpreter, when
it prints a result, runs the string in "eval mode" - only
evaluation gives a result.

To evaluate a string, use Py_RunString with Py_eval_input,
or perhaps Py_single_input.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405837&group_id=5470


From noreply@sourceforge.net  Tue Mar 20 21:40:27 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Mar 2001 13:40:27 -0800
Subject: [Python-bugs-list] [ python-Bugs-405837 ] getting PyRun_String() true result
Message-ID: <E14fTrf-0006qJ-00@usw-sf-web2.sourceforge.net>

Bugs item #405837, was updated on 2001-03-04 06:53
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405837&group_id=5470

Category: Python Interpreter Core
Group: Not a Bug
Status: Closed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Guido van Rossum (gvanrossum)
Summary: getting PyRun_String() true result

Initial Comment:
It seems impossible to build am embedded Python
interpreter extension which actually allows getting
the result of the evaluation of a string from the
interpreter, as it is done in interactive mode, as in
the following:
  def f: pass
  f
prints:
  <function f at 0x8069694>

But in C (called twice with the 2 above strings):
  PyRun_String(string, Py_file_input, globals, globals)
returns None.

I found a workaround by patching the core in ceval.c,
eval_code2() (inspired by the PRINT_EXPR case):

...
case POP_TOP:
  v = POP();
PyDict_SetItemString(f->f_globals, "_", v); /* added */
  Py_DECREF(v);
  continue;
...

and then:
  PyRun_String(string, Py_file_input, globals, globals)
  result =PyDict_GetItemString(globals, "_")
returns the '<function f at 0x8069694>' correct result.


My goal is to allow the tclpython extension (at
http://jfontain.free.fr/) to work without having to
insert print statements on the Python side to be able
to pass data to the Tcl interpreter.

Please forgive me if there is an obvious way to do the
above without patching the core, but I am new to Python
(I like it already though :-)

Jean-Luc Fontaine

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2001-03-20 13:40

Message:
Logged In: YES 
user_id=21627

What kind of result would you expect from evaluating a
file_input? E.g. given

i = 1
def foo():
  return i
class C:
  pass

What should be the result of executing this statement list
(i.e. suite)? IMO, there is no meaningful result except for
"success or exception".

You may also consider discussing this on
python-list@python.org.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-03-20 13:34

Message:
Logged In: NO 

I agree that this is not a bug per se.
I am puzzled though, that other scripting languages, such as
Perl and Tcl can readily do this.
I still have no answer to my request, so I guess I will try
help@python.org as you recommend.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-20 10:49

Message:
Logged In: YES 
user_id=6380

This is not a bug.   Closing the bug report now.

If you need more help still, wrote help@python.org.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-03-05 10:51

Message:
Logged In: NO 

> To evaluate a string, use Py_RunString with Py_eval_input,
> or perhaps Py_single_input.

Py_eval_input is for "isolated expressions", and
Py_single_input "for a single statement", so how do I
execute whole modules except by using Py_file_input, the
only remaining option?

I actually tested all the above options thoroughly and found
that only Py_file_input did the job, but without a way to
get at the result.

Please let me know whether there is something that I missed,
as I am stuck at the moment. If needed, I will be happy to
send you sample code that illustrates the problem.

Thank you very much for your prompt response.

Jean-Luc

PS: passing "def f(): pass\n" to Py_eval_input returns a
"SyntaxError: invalid syntax"


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-03-04 10:22

Message:
Logged In: YES 
user_id=21627

Sure there is. PyRun_SimpleString executes a string in "file
mode"; this has no result. The interactive interpreter, when
it prints a result, runs the string in "eval mode" - only
evaluation gives a result.

To evaluate a string, use Py_RunString with Py_eval_input,
or perhaps Py_single_input.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405837&group_id=5470


From noreply@sourceforge.net  Tue Mar 20 21:42:39 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Mar 2001 13:42:39 -0800
Subject: [Python-bugs-list] [ python-Bugs-410164 ] pydoc can't find module in current dir
Message-ID: <E14fTtn-0005Ug-00@usw-sf-web3.sourceforge.net>

Bugs item #410164, was updated on 2001-03-20 13:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410164&group_id=5470

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: pydoc can't find module in current dir

Initial Comment:
On my linux system pydoc doesn't seem able to find
modules in the current directory unless I set the
PYTHONPATH environment variable, including ".":

    % pydoc OO_Model
    No Python documentation found for 'OO_Model'.
    beluga:lib% PYTHONPATH=. pydoc OO_Model

    Python Library Documentation: module OO_Model
    ...

I examined the output of pydoc.pathdirs().  Even
without setting PYTHONPATH the directory containing the
OO_Model module is in the output (second directory):

    % python
    Python 2.1b1 (#1, Mar 12 2001, 16:13:37) 
    [GCC 2.95.3 19991030 (prerelease)] on linux2
    Type "copyright", "credits" or "license" for more
    information.
    >>> import pydoc
    >>> pydoc.pathdirs()
    ['/usr/local/lib/automatrix/python',
     '/home/skip/src/tttech/lib',
     '/usr/local/lib/python2.1',
     '/usr/local/lib/python2.1/plat-linux2',
     '/usr/local/lib/python2.1/lib-tk',
     '/usr/local/lib/python2.1/lib-dynload',
     '/usr/local/lib/python2.1/site-packages',
     '/home/skip/src/Zope/lib/python']

Seems like a bug to me.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410164&group_id=5470


From noreply@sourceforge.net  Tue Mar 20 22:58:21 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Mar 2001 14:58:21 -0800
Subject: [Python-bugs-list] [ python-Bugs-410155 ] tokenize.NL undocumented
Message-ID: <E14fV53-00030N-00@usw-sf-web1.sourceforge.net>

Bugs item #410155, was updated on 2001-03-20 13:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410155&group_id=5470

Category: Documentation
Group: None
Status: Open
Priority: 5
Submitted By: Jürgen Hermann (jhermann)
>Assigned to: Ka-Ping Yee (ping)
>Summary: tokenize.NL undocumented

Initial Comment:
In section 17.5 of the Python 2.0 Library Reference, 
the constant "NL" is not documented.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-03-20 14:58

Message:
Logged In: YES 
user_id=3066

Ping, should NL be documented?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410155&group_id=5470


From noreply@sourceforge.net  Tue Mar 20 23:06:43 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Mar 2001 15:06:43 -0800
Subject: [Python-bugs-list] [ python-Bugs-409838 ] Error in httplib post example
Message-ID: <E14fVD9-0006Hb-00@usw-sf-web3.sourceforge.net>

Bugs item #409838, was updated on 2001-03-19 13:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409838&group_id=5470

Category: Documentation
Group: None
>Status: Closed
Priority: 5
Submitted By: Fredrik Borg (jenzjenz)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Error in httplib post example

Initial Comment:
The 'post' example has errors:

"paramstring" on line 9 should be "params"

and

"errcode" on line 11 should be "reply"

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-03-20 15:06

Message:
Logged In: YES 
user_id=3066

Already fixed in the Python 2.1 development documentation.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409838&group_id=5470


From noreply@sourceforge.net  Tue Mar 20 23:15:56 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Mar 2001 15:15:56 -0800
Subject: [Python-bugs-list] [ python-Bugs-409683 ] import tzparse --> fails
Message-ID: <E14fVM4-0006M6-00@usw-sf-web3.sourceforge.net>

Bugs item #409683, was updated on 2001-03-19 02:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409683&group_id=5470

Category: Python Library
Group: None
>Status: Closed
Priority: 5
Submitted By: Hernan Martinez Foffani (hfoffani)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: import tzparse --> fails

Initial Comment:
In Windows OS, an import tzparse fails. May be 
See below:

Python 2.1b1 (#11, Mar  2 2001, 11:23:29) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
>>> import tzparse
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "c:\python21\lib\tzparse.py", line 67, in ?
    tzset()
  File "c:\python21\lib\tzparse.py", line 50, in tzset
    tzstr = os.environ['TZ']
  File "C:\Python21\lib\os.py", line 371, in 
__getitem__
    return self.data[key.upper()]
KeyError: TZ
>>>

At line 67 there is a call to tzset() which fails if:
- TZ environment variable is not set
- TZ is set but with an unrecognized format

Commenting such line works for me. I don't need 
tzparse, just was get the docs thru pydoc the utility. 
But that's just me, I don't know about other guys.
(BTW, the module is said to be obsolote)

I don't know if this is really a bug... I read GvR 
that Ping is going to change pydoc from "import" 
to "parse source"...




----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-03-20 15:15

Message:
Logged In: YES 
user_id=3066

Updated the documentation to indicate that this module is obsolete and that it doesn't work in some circumstances.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-20 10:32

Message:
Logged In: YES 
user_id=6380

I propose to make tzparse obsolete.  It clearly doesn't work
right, and doesn't seem to be neede.

Assigning to Fred to implement the necessary doc changes.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-03-19 15:37

Message:
Logged In: YES 
user_id=31392

I also find it annoying that this module can't be imported
if there isn't a valid TZ environment variable.  

I also noticed in the CVS log that tzparse.py was labelled
"no longer necessary" in June 1993.  Is it still useful?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409683&group_id=5470


From noreply@sourceforge.net  Tue Mar 20 23:52:12 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Mar 2001 15:52:12 -0800
Subject: [Python-bugs-list] [ python-Bugs-409755 ] Followup to Bug 233033 - 2.1 Builds Fail
Message-ID: <E14fVvA-000821-00@usw-sf-web2.sourceforge.net>

Bugs item #409755, was updated on 2001-03-19 07:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409755&group_id=5470

Category: Build
Group: None
>Status: Closed
>Priority: 1
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: Followup to Bug 233033 - 2.1 Builds Fail

Initial Comment:
I am sorry it has taken me so long to follow up on my previous bug 
report but here it is.

I am attaching a file that shows the results of an attempted build. At
first, the build fails because setup.py cannot find the  os  module.
The file then shows the line I had to modify in the Makefile. I then 
continue the build with the modified Makefile - and it succeeds.

Even with the added line,  "make test" and "make install" will still fail.

I've seen the same results with Python 2.1a and 2.1b on both Redhat
6.2 and 7.0.

Contact me by email if I can be of further help. I promise to be more
prompt this time.

...Bob     ryodlowski@pirus.com

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-20 15:52

Message:
Logged In: YES 
user_id=6380

This was a user error.

Subject: RE: bug 409755  Found the problem (mine), ok to
close the bug. 
From: "Yodlowski, Robert" <RYodlowski@Pirus.com> 
To: "'Guido van Rossum'" <guido@digicool.com> 
Date: Tue, 20 Mar 2001 18:30:50 -0500 
 
Guido, I found the problem. I had an old value set for
PYTHONHOME that was 
pointing to a now non-existant directory. I removed the
obsolete env 
variable and everything in 2.1b1 ran beautifully! 
 
Thanks for your help. 
 
...Bob 
 


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-03-20 13:03

Message:
Logged In: NO 

Here (finally) is the log file.



{/home/ryodlowski/Linux/Python-2.1b1} make clean
find . -name '*.o' -exec rm -f {} ';'
find . -name '*.py[co]' -exec rm -f {} ';'
{/home/ryodlowski/Linux/Python-2.1b1} mv Makefile 
Makefile_MODIFIED
{/home/ryodlowski/Linux/Python-2.1b1} mv Makefile~ Makefile


{/home/ryodlowski/Linux/Python-2.1b1} make
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Modules/python.o Modules/python.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Parser/acceler.o Parser/acceler.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Parser/grammar1.o Parser/grammar1.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Parser/listnode.o Parser/listnode.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Parser/node.o Parser/node.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Parser/parser.o Parser/parser.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Parser/parsetok.o Parser/parsetok.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Parser/tokenizer.o Parser/tokenizer.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Parser/bitset.o Parser/bitset.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Parser/metagrammar.o Parser/metagrammar.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Parser/myreadline.o Parser/myreadline.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Objects/abstract.o Objects/abstract.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Objects/bufferobject.o 
Objects/bufferobject.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Objects/cellobject.o Objects/cellobject.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Objects/classobject.o 
Objects/classobject.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Objects/cobject.o Objects/cobject.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Objects/complexobject.o 
Objects/complexobject.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Objects/fileobject.o Objects/fileobject.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Objects/floatobject.o 
Objects/floatobject.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Objects/frameobject.o 
Objects/frameobject.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Objects/funcobject.o Objects/funcobject.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Objects/intobject.o Objects/intobject.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Objects/listobject.o Objects/listobject.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Objects/longobject.o Objects/longobject.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Objects/dictobject.o Objects/dictobject.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Objects/methodobject.o 
Objects/methodobject.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Objects/moduleobject.o 
Objects/moduleobject.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Objects/object.o Objects/object.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Objects/rangeobject.o 
Objects/rangeobject.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Objects/sliceobject.o 
Objects/sliceobject.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Objects/stringobject.o 
Objects/stringobject.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Objects/tupleobject.o 
Objects/tupleobject.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Objects/typeobject.o Objects/typeobject.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Objects/unicodeobject.o 
Objects/unicodeobject.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Objects/unicodectype.o 
Objects/unicodectype.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Python/bltinmodule.o Python/bltinmodule.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Python/exceptions.o Python/exceptions.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Python/ceval.o Python/ceval.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Parser/firstsets.o Parser/firstsets.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Parser/grammar.o Parser/grammar.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Parser/pgen.o Parser/pgen.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Parser/printgrammar.o 
Parser/printgrammar.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Parser/pgenmain.o Parser/pgenmain.c
gcc -g -O2 -Wall -Wstrict-prototypes  Parser/acceler.o 
Parser/grammar1.o Parser/listnode.o Parser/node.o 
Parser/parser.o Parser/parsetok.o Parser/tokenizer.o 
Parser/bitset.o Parser/metagrammar.o Parser/firstsets.o 
Parser/grammar.o Parser/pgen.o Parser/printgrammar.o 
Parser/pgenmain.o -lpthread -ldl  -lutil -o Parser/pgen
Parser/pgen ./Grammar/Grammar ./Include/graminit.h ./Python/
graminit.c
Compiling (meta-) parse tree into NFA grammar
Making DFA for 'single_input' ...
Making DFA for 'file_input' ...
Making DFA for 'eval_input' ...
Making DFA for 'funcdef' ...
Making DFA for 'parameters' ...
Making DFA for 'varargslist' ...
Making DFA for 'fpdef' ...
Making DFA for 'fplist' ...
Making DFA for 'stmt' ...
Making DFA for 'simple_stmt' ...
Making DFA for 'small_stmt' ...
Making DFA for 'expr_stmt' ...
Making DFA for 'augassign' ...
Making DFA for 'print_stmt' ...
Making DFA for 'del_stmt' ...
Making DFA for 'pass_stmt' ...
Making DFA for 'flow_stmt' ...
Making DFA for 'break_stmt' ...
Making DFA for 'continue_stmt' ...
Making DFA for 'return_stmt' ...
Making DFA for 'raise_stmt' ...
Making DFA for 'import_stmt' ...
Making DFA for 'import_as_name' ...
Making DFA for 'dotted_as_name' ...
Making DFA for 'dotted_name' ...
Making DFA for 'global_stmt' ...
Making DFA for 'exec_stmt' ...
Making DFA for 'assert_stmt' ...
Making DFA for 'compound_stmt' ...
Making DFA for 'if_stmt' ...
Making DFA for 'while_stmt' ...
Making DFA for 'for_stmt' ...
Making DFA for 'try_stmt' ...
Making DFA for 'except_clause' ...
Making DFA for 'suite' ...
Making DFA for 'test' ...
Making DFA for 'and_test' ...
Making DFA for 'not_test' ...
Making DFA for 'comparison' ...
Making DFA for 'comp_op' ...
Making DFA for 'expr' ...
Making DFA for 'xor_expr' ...
Making DFA for 'and_expr' ...
Making DFA for 'shift_expr' ...
Making DFA for 'arith_expr' ...
Making DFA for 'term' ...
Making DFA for 'factor' ...
Making DFA for 'power' ...
Making DFA for 'atom' ...
Making DFA for 'listmaker' ...
Making DFA for 'lambdef' ...
Making DFA for 'trailer' ...
Making DFA for 'subscriptlist' ...
Making DFA for 'subscript' ...
Making DFA for 'sliceop' ...
Making DFA for 'exprlist' ...
Making DFA for 'testlist' ...
Making DFA for 'dictmaker' ...
Making DFA for 'classdef' ...
Making DFA for 'arglist' ...
Making DFA for 'argument' ...
Making DFA for 'list_iter' ...
Making DFA for 'list_for' ...
Making DFA for 'list_if' ...
Adding FIRST sets ...
Writing ./Python/graminit.c ...
Writing ./Include/graminit.h ...
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Python/compile.o Python/compile.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Python/codecs.o Python/codecs.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Python/errors.o Python/errors.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Python/frozen.o Python/frozen.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Python/frozenmain.o Python/frozenmain.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Python/future.o Python/future.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Python/getargs.o Python/getargs.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Python/getcompiler.o Python/getcompiler.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Python/getcopyright.o 
Python/getcopyright.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Python/getmtime.o Python/getmtime.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H -DPLATFORM='"linux2"' -o 
Python/getplatform.o ./Python/getplatform.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Python/getversion.o Python/getversion.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Python/graminit.o Python/graminit.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Python/import.o Python/import.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H -I/ -o Python/importdl.o ./Python/importdl.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Python/marshal.o Python/marshal.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Python/modsupport.o Python/modsupport.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Python/mystrtoul.o Python/mystrtoul.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Python/pyfpe.o Python/pyfpe.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Python/pystate.o Python/pystate.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Python/pythonrun.o Python/pythonrun.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Python/structmember.o 
Python/structmember.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Python/symtable.o Python/symtable.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Python/sysmodule.o Python/sysmodule.c
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_shlib.o 
Python/dynload_shlib.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Python/thread.o Python/thread.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Modules/config.o Modules/config.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -DPYTHONPATH='":plat-linux2:lib-tk"' \
	-DPREFIX='"/home/ryodlowski/Linux/Installations"' \
	-
DEXEC_PREFIX='"/home/ryodlowski/Linux/Installations"' \
	-DVERSION='"2.1"' \
	-DVPATH='""' \
	-o Modules/getpath.o ./Modules/getpath.c
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -o Modules/main.o Modules/main.c
gcc -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H   -c ./Modules/gcmodule.c -o 
Modules/gcmodule.o
gcc -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H   -c ./Modules/threadmodule.c -o 
Modules/threadmodule.o
gcc -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H   -c ./Modules/signalmodule.c -o 
Modules/signalmodule.o
gcc -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H   -c ./Modules/posixmodule.c -o 
Modules/posixmodule.o
gcc -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H   -c ./Modules/_sre.c -o Modules/_sre.o
if test -f buildno; then \
	expr `cat buildno` + 1 >buildno1; \
	mv -f buildno1 buildno; \
else echo 1 >buildno; fi
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -DBUILD=`cat buildno` -o 
Modules/getbuildinfo.o ./Modules/getbuildinfo.c
rm -f libpython2.1.a
# avoid long command lines, same as LIBRARY_OBJS
ar cr libpython2.1.a Modules/getbuildinfo.o
ar cr libpython2.1.a Parser/acceler.o Parser/grammar1.o 
Parser/listnode.o Parser/node.o Parser/parser.o 
Parser/parsetok.o Parser/tokenizer.o Parser/bitset.o 
Parser/metagrammar.o Parser/myreadline.o
ar cr libpython2.1.a Objects/abstract.o 
Objects/bufferobject.o Objects/cellobject.o 
Objects/classobject.o Objects/cobject.o 
Objects/complexobject.o Objects/fileobject.o 
Objects/floatobject.o Objects/frameobject.o 
Objects/funcobject.o Objects/intobject.o 
Objects/listobject.o Objects/longobject.o 
Objects/dictobject.o Objects/methodobject.o 
Objects/moduleobject.o Objects/object.o 
Objects/rangeobject.o Objects/sliceobject.o 
Objects/stringobject.o Objects/tupleobject.o 
Objects/typeobject.o Objects/unicodeobject.o 
Objects/unicodectype.o
ar cr libpython2.1.a Python/bltinmodule.o 
Python/exceptions.o Python/ceval.o Python/compile.o 
Python/codecs.o Python/errors.o Python/frozen.o 
Python/frozenmain.o Python/future.o Python/getargs.o 
Python/getcompiler.o Python/getcopyright.o 
Python/getmtime.o Python/getplatform.o Python/getversion.o 
Python/graminit.o Python/import.o Python/importdl.o 
Python/marshal.o Python/modsupport.o Python/mystrtoul.o 
Python/pyfpe.o Python/pystate.o Python/pythonrun.o 
Python/structmember.o Python/symtable.o Python/sysmodule.o 
Python/traceback.o Python/getopt.o Python/dynload_shlib.o 
Python/thread.o
ar cr libpython2.1.a Modules/config.o Modules/getpath.o 
Modules/main.o 
ar cr libpython2.1.a Modules/gcmodule.o  
Modules/threadmodule.o  Modules/signalmodule.o  
Modules/posixmodule.o  Modules/_sre.o
ranlib libpython2.1.a
gcc  -Xlinker -export-dynamic -o python Modules/python.o \
		libpython2.1.a -lpthread -ldl  -lutil   -
lm  
PYTHONPATH= ./python ./setup.py build
'import site' failed; use -v for traceback
Traceback (most recent call last):
  File "./setup.py", line 9, in ?
    import sys, os, getopt
ImportError: No module named os
make: *** [sharedmods] Error 1




{/home/ryodlowski/Linux/Python-2.1b1} mv Makefile 
Makefile_ORG
{/home/ryodlowski/Linux/Python-2.1b1} cp Makefile_MODIFIED 
Makefile
{/home/ryodlowski/Linux/Python-2.1b1} diff Makefile_ORG 
Makefile_MODIFIED 
155c155
< SITEPATH=
---
> SITEPATH=/home/ryodlowski/Linux/Python-2.1b1/Lib




{/home/ryodlowski/Linux/Python-2.1b1} make
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -
DPYTHONPATH='"/home/ryodlowski/Linux/Python-2.1b1/Lib:plat-
linux2:lib-tk"' \
	-DPREFIX='"/home/ryodlowski/Linux/Installations"' \
	-
DEXEC_PREFIX='"/home/ryodlowski/Linux/Installations"' \
	-DVERSION='"2.1"' \
	-DVPATH='""' \
	-o Modules/getpath.o ./Modules/getpath.c
if test -f buildno; then \
	expr `cat buildno` + 1 >buildno1; \
	mv -f buildno1 buildno; \
else echo 1 >buildno; fi
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H  -DBUILD=`cat buildno` -o 
Modules/getbuildinfo.o ./Modules/getbuildinfo.c
rm -f libpython2.1.a
# avoid long command lines, same as LIBRARY_OBJS
ar cr libpython2.1.a Modules/getbuildinfo.o
ar cr libpython2.1.a Parser/acceler.o Parser/grammar1.o 
Parser/listnode.o Parser/node.o Parser/parser.o 
Parser/parsetok.o Parser/tokenizer.o Parser/bitset.o 
Parser/metagrammar.o Parser/myreadline.o
ar cr libpython2.1.a Objects/abstract.o 
Objects/bufferobject.o Objects/cellobject.o 
Objects/classobject.o Objects/cobject.o 
Objects/complexobject.o Objects/fileobject.o 
Objects/floatobject.o Objects/frameobject.o 
Objects/funcobject.o Objects/intobject.o 
Objects/listobject.o Objects/longobject.o 
Objects/dictobject.o Objects/methodobject.o 
Objects/moduleobject.o Objects/object.o 
Objects/rangeobject.o Objects/sliceobject.o 
Objects/stringobject.o Objects/tupleobject.o 
Objects/typeobject.o Objects/unicodeobject.o 
Objects/unicodectype.o
ar cr libpython2.1.a Python/bltinmodule.o 
Python/exceptions.o Python/ceval.o Python/compile.o 
Python/codecs.o Python/errors.o Python/frozen.o 
Python/frozenmain.o Python/future.o Python/getargs.o 
Python/getcompiler.o Python/getcopyright.o 
Python/getmtime.o Python/getplatform.o Python/getversion.o 
Python/graminit.o Python/import.o Python/importdl.o 
Python/marshal.o Python/modsupport.o Python/mystrtoul.o 
Python/pyfpe.o Python/pystate.o Python/pythonrun.o 
Python/structmember.o Python/symtable.o Python/sysmodule.o 
Python/traceback.o Python/getopt.o Python/dynload_shlib.o 
Python/thread.o
ar cr libpython2.1.a Modules/config.o Modules/getpath.o 
Modules/main.o 
ar cr libpython2.1.a Modules/gcmodule.o  
Modules/threadmodule.o  Modules/signalmodule.o  
Modules/posixmodule.o  Modules/_sre.o
ranlib libpython2.1.a
gcc  -Xlinker -export-dynamic -o python Modules/python.o \
		libpython2.1.a -lpthread -ldl  -lutil   -
lm  
PYTHONPATH= ./python ./setup.py build
running build
running build_ext
skipping 'struct' extension (up-to-date)
skipping 'regex' extension (up-to-date)
skipping 'pcre' extension (up-to-date)
skipping '_weakref' extension (up-to-date)
skipping '_symtable' extension (up-to-date)
skipping 'xreadlines' extension (up-to-date)
skipping 'array' extension (up-to-date)
skipping 'cmath' extension (up-to-date)
skipping 'math' extension (up-to-date)
skipping 'strop' extension (up-to-date)
skipping 'time' extension (up-to-date)
skipping 'operator' extension (up-to-date)
skipping '_codecs' extension (up-to-date)
skipping '_testcapi' extension (up-to-date)
skipping 'unicodedata' extension (up-to-date)
skipping '_locale' extension (up-to-date)
skipping 'fcntl' extension (up-to-date)
skipping 'pwd' extension (up-to-date)
skipping 'grp' extension (up-to-date)
skipping 'errno' extension (up-to-date)
skipping 'select' extension (up-to-date)
skipping 'md5' extension (up-to-date)
skipping 'sha' extension (up-to-date)
skipping 'new' extension (up-to-date)
skipping 'binascii' extension (up-to-date)
skipping 'parser' extension (up-to-date)
skipping 'cStringIO' extension (up-to-date)
skipping 'cPickle' extension (up-to-date)
skipping 'mmap' extension (up-to-date)
skipping 'rotor' extension (up-to-date)
skipping 'syslog' extension (up-to-date)
skipping 'timing' extension (up-to-date)
skipping 'audioop' extension (up-to-date)
skipping 'imageop' extension (up-to-date)
skipping 'rgbimg' extension (up-to-date)
skipping 'readline' extension (up-to-date)
skipping 'crypt' extension (up-to-date)
skipping '_socket' extension (up-to-date)
skipping 'dbm' extension (up-to-date)
skipping 'gdbm' extension (up-to-date)
skipping 'bsddb' extension (up-to-date)
skipping 'termios' extension (up-to-date)
skipping 'resource' extension (up-to-date)
skipping 'nis' extension (up-to-date)
skipping '_curses' extension (up-to-date)
skipping '_curses_panel' extension (up-to-date)
skipping 'fpectl' extension (up-to-date)
skipping 'zlib' extension (up-to-date)
skipping 'linuxaudiodev' extension (up-to-date)
skipping '_tkinter' extension (up-to-date)
running build_scripts
not copying /home/ryodlowski/Linux/Python-
2.1b1/Tools/scripts/pydoc (up-to-date)
{/home/ryodlowski/Linux/Python-2.1b1} 
{/home/ryodlowski/Linux/Python-2.1b1} make clean
/home/ryodlowski/Linux/Python-2.1b1: Permission denied.
{/home/ryodlowski/Linux/Python-2.1b1} 


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-20 08:27

Message:
Logged In: YES 
user_id=6380

Where is the attached file?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409755&group_id=5470


From noreply@sourceforge.net  Wed Mar 21 01:10:43 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Mar 2001 17:10:43 -0800
Subject: [Python-bugs-list] [ python-Bugs-410207 ] correction to section 2.3: 'apply'
Message-ID: <E14fX99-0000DI-00@usw-sf-web2.sourceforge.net>

Bugs item #410207, was updated on 2001-03-20 17:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410207&group_id=5470

Category: Documentation
Group: None
Status: Open
Priority: 5
Submitted By: John Cook (johncook)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: correction to section 2.3: 'apply'

Initial Comment:
In section 2.3, 'Built-in Functions', I think the 
following description for 'apply' is incorrect:

"The function argument must be a callable object (a 
user-defined or built-in function or method, or a 
class object) and the args argument must be a sequence 
(if it is not a tuple, the sequence is first converted 
to a tuple). "

I suggest the following:

"The function argument must be a callable object (a 
user-defined or built-in function or method, or a 
class object) and the args argument must be a tuple 
(if it is a sequence, the sequence is first converted 
to a tuple)."

I found this in the Release 2.1 beta 1 version of the 
Python documentation at:
http://python.sourceforge.net/devel-docs/

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410207&group_id=5470


From noreply@sourceforge.net  Wed Mar 21 01:33:38 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Mar 2001 17:33:38 -0800
Subject: [Python-bugs-list] [ python-Bugs-410207 ] correction to section 2.3: 'apply'
Message-ID: <E14fXVK-0000O0-00@usw-sf-web2.sourceforge.net>

Bugs item #410207, was updated on 2001-03-20 17:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410207&group_id=5470

Category: Documentation
Group: None
Status: Open
Priority: 5
Submitted By: John Cook (johncook)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: correction to section 2.3: 'apply'

Initial Comment:
In section 2.3, 'Built-in Functions', I think the 
following description for 'apply' is incorrect:

"The function argument must be a callable object (a 
user-defined or built-in function or method, or a 
class object) and the args argument must be a sequence 
(if it is not a tuple, the sequence is first converted 
to a tuple). "

I suggest the following:

"The function argument must be a callable object (a 
user-defined or built-in function or method, or a 
class object) and the args argument must be a tuple 
(if it is a sequence, the sequence is first converted 
to a tuple)."

I found this in the Release 2.1 beta 1 version of the 
Python documentation at:
http://python.sourceforge.net/devel-docs/

----------------------------------------------------------------------

>Comment By: John Cook (johncook)
Date: 2001-03-20 17:33

Message:
Logged In: YES 
user_id=178427

On further review, this is better:

"The function argument must be a callable object (a 
user-defined or built-in function or method, or a 
class object) and the args argument must be a tuple or a 
sequence (if args is a sequence, apply converts the 
sequence to a tuple)."

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410207&group_id=5470


From noreply@sourceforge.net  Wed Mar 21 02:22:58 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Mar 2001 18:22:58 -0800
Subject: [Python-bugs-list] [ python-Bugs-410155 ] tokenize.NL undocumented
Message-ID: <E14fYH4-0005FT-00@usw-sf-web1.sourceforge.net>

Bugs item #410155, was updated on 2001-03-20 13:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410155&group_id=5470

Category: Documentation
Group: None
Status: Open
Priority: 5
Submitted By: Jürgen Hermann (jhermann)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: tokenize.NL undocumented

Initial Comment:
In section 17.5 of the Python 2.0 Library Reference, 
the constant "NL" is not documented.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-03-20 18:22

Message:
Logged In: YES 
user_id=31435

Yes, it should be, but Ping doesn't know about NL:  Guido 
added that one.  Python's real tokenizer has no such token 
type.  It was added because-- unlike Python's real 
tokenizer --tokenizer.py passes *everything* on to the 
client, including blank lines and comments, so passes on 
newlines that aren't NEWLINEs too.  Reassigned to Guido in 
case he remembers more about the details ...

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-03-20 14:58

Message:
Logged In: YES 
user_id=3066

Ping, should NL be documented?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410155&group_id=5470


From noreply@sourceforge.net  Wed Mar 21 03:21:12 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Mar 2001 19:21:12 -0800
Subject: [Python-bugs-list] [ python-Bugs-410155 ] tokenize.NL undocumented
Message-ID: <E14fZBQ-0005s8-00@usw-sf-web1.sourceforge.net>

Bugs item #410155, was updated on 2001-03-20 13:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410155&group_id=5470

Category: Documentation
Group: None
Status: Open
Priority: 5
Submitted By: Jürgen Hermann (jhermann)
Assigned to: Guido van Rossum (gvanrossum)
Summary: tokenize.NL undocumented

Initial Comment:
In section 17.5 of the Python 2.0 Library Reference, 
the constant "NL" is not documented.

----------------------------------------------------------------------

>Comment By: Jürgen Hermann (jhermann)
Date: 2001-03-20 19:21

Message:
Logged In: YES 
user_id=39128

tokenize.NL seems to be an empty line, as opposed to 
token.NEWLINE which is a logical line end. Insofar NL is 
comparable to COMMENT, since it has no semantic content and 
is ignorable by a parser.

1 a = \
2 2
3
4 b=4

emits these tokens:

1,0-1,1:        NAME    'a'
1,2-1,3:        OP      '='
2,0-2,1:        NUMBER  '2'
2,1-2,2:        NEWLINE '\012'
3,0-3,1:        NL      '\012'
4,0-4,1:        NAME    'b'
4,1-4,2:        OP      '='
4,2-4,3:        NUMBER  '4'
4,3-4,4:        NEWLINE '\012'
5,0-5,0:        ENDMARKER       ''

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-03-20 18:22

Message:
Logged In: YES 
user_id=31435

Yes, it should be, but Ping doesn't know about NL:  Guido 
added that one.  Python's real tokenizer has no such token 
type.  It was added because-- unlike Python's real 
tokenizer --tokenizer.py passes *everything* on to the 
client, including blank lines and comments, so passes on 
newlines that aren't NEWLINEs too.  Reassigned to Guido in 
case he remembers more about the details ...

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-03-20 14:58

Message:
Logged In: YES 
user_id=3066

Ping, should NL be documented?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410155&group_id=5470


From noreply@sourceforge.net  Wed Mar 21 05:33:54 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Mar 2001 21:33:54 -0800
Subject: [Python-bugs-list] [ python-Bugs-410207 ] correction to section 2.3: 'apply'
Message-ID: <E14fbFq-0002Iv-00@usw-sf-web2.sourceforge.net>

Bugs item #410207, was updated on 2001-03-20 17:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410207&group_id=5470

Category: Documentation
Group: None
>Status: Closed
Priority: 5
Submitted By: John Cook (johncook)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: correction to section 2.3: 'apply'

Initial Comment:
In section 2.3, 'Built-in Functions', I think the 
following description for 'apply' is incorrect:

"The function argument must be a callable object (a 
user-defined or built-in function or method, or a 
class object) and the args argument must be a sequence 
(if it is not a tuple, the sequence is first converted 
to a tuple). "

I suggest the following:

"The function argument must be a callable object (a 
user-defined or built-in function or method, or a 
class object) and the args argument must be a tuple 
(if it is a sequence, the sequence is first converted 
to a tuple)."

I found this in the Release 2.1 beta 1 version of the 
Python documentation at:
http://python.sourceforge.net/devel-docs/

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-03-20 21:33

Message:
Logged In: YES 
user_id=3066

Suggestion declined:  because non-tuple sequences are
automatically converted to tuples, it makes no sense to say
that 'args' must be a tuple -- any sequence will do.

----------------------------------------------------------------------

Comment By: John Cook (johncook)
Date: 2001-03-20 17:33

Message:
Logged In: YES 
user_id=178427

On further review, this is better:

"The function argument must be a callable object (a 
user-defined or built-in function or method, or a 
class object) and the args argument must be a tuple or a 
sequence (if args is a sequence, apply converts the 
sequence to a tuple)."

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410207&group_id=5470


From noreply@sourceforge.net  Wed Mar 21 06:00:21 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Mar 2001 22:00:21 -0800
Subject: [Python-bugs-list] [ python-Bugs-410164 ] pydoc can't find module in current dir
Message-ID: <E14fbfR-0000uG-00@usw-sf-web3.sourceforge.net>

Bugs item #410164, was updated on 2001-03-20 13:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410164&group_id=5470

>Category: demos and tools
>Group: Feature Request
Status: Open
Priority: 5
Submitted By: Skip Montanaro (montanaro)
>Assigned to: Ka-Ping Yee (ping)
Summary: pydoc can't find module in current dir

Initial Comment:
On my linux system pydoc doesn't seem able to find
modules in the current directory unless I set the
PYTHONPATH environment variable, including ".":

    % pydoc OO_Model
    No Python documentation found for 'OO_Model'.
    beluga:lib% PYTHONPATH=. pydoc OO_Model

    Python Library Documentation: module OO_Model
    ...

I examined the output of pydoc.pathdirs().  Even
without setting PYTHONPATH the directory containing the
OO_Model module is in the output (second directory):

    % python
    Python 2.1b1 (#1, Mar 12 2001, 16:13:37) 
    [GCC 2.95.3 19991030 (prerelease)] on linux2
    Type "copyright", "credits" or "license" for more
    information.
    >>> import pydoc
    >>> pydoc.pathdirs()
    ['/usr/local/lib/automatrix/python',
     '/home/skip/src/tttech/lib',
     '/usr/local/lib/python2.1',
     '/usr/local/lib/python2.1/plat-linux2',
     '/usr/local/lib/python2.1/lib-tk',
     '/usr/local/lib/python2.1/lib-dynload',
     '/usr/local/lib/python2.1/site-packages',
     '/home/skip/src/Zope/lib/python']

Seems like a bug to me.



----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-03-20 22:00

Message:
Logged In: YES 
user_id=3066

This ia a pydoc issue; sys.path for a script includes the
script dir but not (necessarily) the current dir.

Assigned to Ping.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410164&group_id=5470


From noreply@sourceforge.net  Wed Mar 21 09:52:15 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 21 Mar 2001 01:52:15 -0800
Subject: [Python-bugs-list] [ python-Bugs-410271 ] SRE: word-based anchors ignore locale
Message-ID: <E14ffHr-0002Xq-00@usw-sf-web3.sourceforge.net>

Bugs item #410271, was updated on 2001-03-21 01:52
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410271&group_id=5470

Category: Regular Expressions
Group: None
Status: Open
Priority: 7
Submitted By: Fredrik Lundh (effbot)
Assigned to: Fredrik Lundh (effbot)
Summary: SRE: word-based anchors ignore locale

Initial Comment:
the \b and \B anchors don't take the locale
settings into account.

import locale, re
locale.setlocale(locale.LC_ALL, "")

# should print ["egg", "and"]
print re.findall(r"\b...\b", "spam, egg, bacon, and 
åäö")

# should print ["egg", "and", "åäö"]
print re.findall(r"(?L)\b...\b", "spam, egg, bacon, 
and åäö")


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410271&group_id=5470


From noreply@sourceforge.net  Wed Mar 21 09:58:44 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 21 Mar 2001 01:58:44 -0800
Subject: [Python-bugs-list] [ python-Bugs-410274 ] sys.prefix isn't always set
Message-ID: <E14ffO8-0002b3-00@usw-sf-web3.sourceforge.net>

Bugs item #410274, was updated on 2001-03-21 01:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410274&group_id=5470

Category: Python Interpreter Core
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Fredrik Lundh (effbot)
Assigned to: Nobody/Anonymous (nobody)
Summary: sys.prefix isn't always set

Initial Comment:
(2.0 and earlier, Windows only)

it looks like sys.prefix isn't set unless

1) PYTHONHOME is set (either via an environment 
variable, or via a call to Py_SetPythonHome), or

2) lib/os.py (or lib/string.py, in 1.5.2) can be found 
somewhere between the directory your executable is 
found in, and the root.

if neither is set, the path is taken from the 
registry, but sys.prefix is left blank, and code 
depending on sys.prefix (e.g. FixTk.py) no longer 
works.

</F>


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410274&group_id=5470


From noreply@sourceforge.net  Wed Mar 21 15:59:26 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 21 Mar 2001 07:59:26 -0800
Subject: [Python-bugs-list] [ python-Bugs-231439 ] python and Python interfaces should use cc -G for so's
Message-ID: <E14fl1C-0006kd-00@usw-sf-web2.sourceforge.net>

Bugs item #231439, was updated on 2001-02-07 10:52
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=231439&group_id=5470

Category: Build
Group: Platform-specific
>Status: Closed
Priority: 5
Submitted By: Larry Rosenman (ler)
>Assigned to: Nobody/Anonymous (nobody)
Summary: python and Python interfaces should use cc -G for so's

Initial Comment:
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


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2001-03-21 07:59

Message:
Logged In: YES 
user_id=21627

A fix was committed as configure.in 1.212 and configure
1.204.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-03-05 02:14

Message:
Logged In: YES 
user_id=21627

Can you please try adding -Wl,-Bexport into LINKFORSHARED?
This is essentially the same as SCO_SV, except that
-Bdynamic -dy appear to be the default on Unixware.

This option will cause symbols in the python executable to
be exported to shared libraries. By default, only shared
libraries export all their symbols; for executables, -Bhide
is the default. That should cause _PyObject_New to be
available.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2001-03-03 23:37

Message:
Logged In: YES 
user_id=35752

Martin, with your patch I get:

ImportError: Python 2.1b1 (#1, Mar  4 2001, 01:30:18) [C] on
unixware5
Type "copyright", "credits" or "license" for more
information.
>>> import zlib
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
dynamic linker: ./python: relocation error: symbol not
found: _PyObject_New; referenced from:
/home/nas/Python-2.1b1/build/lib.unixware-5-i386-2.1/zlib.so

----------------------------------------------------------------------

Comment By: Larry Rosenman (ler)
Date: 2001-03-02 18:00

Message:
Logged In: YES 
user_id=36452

What about -KPIC -Ki486 -belf -Wl,-Bexport? This is what is
                                currently used on SCO_SV

I'd lose the -Ki486 -belf as they are not needed for 
UnixWare. 

You can look at man pages at:

http://uw7doc.sco.com

or my site at:
http://www.lerctr.org:457

I also gave neil (nas) a login, and can do the same for you. 

LER


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-03-02 15:40

Message:
Logged In: YES 
user_id=21627

OK, upload fails, so try this inline. You may succeed with
cut-n-paste from the HTML source

Index: configure.in
===================================================================
RCS file: /cvsroot/python/python/dist/src/configure.in,v
retrieving revision 1.207
diff -u -r1.207 configure.in
--- configure.in	2001/02/27 04:45:05	1.207
+++ configure.in	2001/03/02 23:36:10
@@ -576,6 +576,11 @@
 		else
 			LDSHARED="ld -Bshareable ${LDFLAGS}"
 		fi;;
+	UnixWare*)
+		if test "$GCC" = "yes"
+		then LDSHARED='$(CC) -shared'
+		else LDSHARED="cc -G";
+		fi ;;
 	SCO_SV*) LDSHARED="cc -G -KPIC -Ki486 -belf
-Wl,-Bexport";;
 	Monterey*) LDSHARED="cc -G -dy -Bdynamic -Bexport
-L/usr/lib/ia64l64";;
 	CYGWIN*) LDSHARED="gcc -shared
-Wl,--enable-auto-image-base";;
@@ -601,6 +606,11 @@
 	BSD/OS*/4*) CCSHARED="-fpic";;
 	OpenBSD*) CCSHARED="-fpic";;
 	FreeBSD*|NetBSD*) CCSHARED="-fPIC";;
+	UnixWare*)
+		if test "$GCC" = "yes"
+		then LDSHARED='$(CC) -fPIC'
+		else LDSHARED="cc -KPIC";
+		fi ;;
 	SCO_SV*) CCSHARED="-KPIC -dy -Bdynamic";;
 	Monterey*) CCSHARED="-G";;
 	IRIX*/6*)  case $CC in


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-03-02 15:38

Message:
Logged In: YES 
user_id=21627

Can you provide an example compiler invocation to see what
options are actually used? One -c invocation and one linker
invocation would be good.

What about -KPIC -Ki486 -belf -Wl,-Bexport? This is what is
currently used on SCO_SV.

Can you please try the attached patch (patch1 if upload
succeeds)?

----------------------------------------------------------------------

Comment By: Larry Rosenman (ler)
Date: 2001-02-10 16:41

Message:
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
$ 


----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2001-02-10 12:46

Message:
What does "uname -u" say for UnixWare?

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2001-02-08 09:23

Message:
Assigning to Neil.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=231439&group_id=5470


From noreply@sourceforge.net  Wed Mar 21 18:07:56 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 21 Mar 2001 10:07:56 -0800
Subject: [Python-bugs-list] [ python-Bugs-410274 ] sys.prefix isn't always set
Message-ID: <E14fn1Y-0006Ci-00@usw-sf-web3.sourceforge.net>

Bugs item #410274, was updated on 2001-03-21 01:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410274&group_id=5470

Category: Python Interpreter Core
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Fredrik Lundh (effbot)
>Assigned to: Mark Hammond (mhammond)
Summary: sys.prefix isn't always set

Initial Comment:
(2.0 and earlier, Windows only)

it looks like sys.prefix isn't set unless

1) PYTHONHOME is set (either via an environment 
variable, or via a call to Py_SetPythonHome), or

2) lib/os.py (or lib/string.py, in 1.5.2) can be found 
somewhere between the directory your executable is 
found in, and the root.

if neither is set, the path is taken from the 
registry, but sys.prefix is left blank, and code 
depending on sys.prefix (e.g. FixTk.py) no longer 
works.

</F>


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410274&group_id=5470


From noreply@sourceforge.net  Wed Mar 21 18:07:40 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 21 Mar 2001 10:07:40 -0800
Subject: [Python-bugs-list] [ python-Bugs-409651 ] fnmatch doesn't escape '\' between [...]
Message-ID: <E14fn1I-0006Ca-00@usw-sf-web3.sourceforge.net>

Bugs item #409651, was updated on 2001-03-18 21:07
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409651&group_id=5470

Category: Python Library
Group: None
>Status: Closed
Priority: 5
Submitted By: Donovan Baarda (abo)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: fnmatch doesn't escape '\' between [...]

Initial Comment:
The translate() function inside fnmatch doesn't 
escape '\' chars between '[' and ']' brackets when 
converting unix filename wildcards to a regular 
expression.

This means the '\' character behaves strangely when 
inside '['...']' or '[^'...']'. Depending on the 
character that follows, it can be interpreted in a 
wild variety of ways, including escaping the 
closing ']' and failing the re.compile. This was 
encountered when using fnmatch on windoze where 
os.sep='\'. Note that the docs say os.sep is not 
treated specially by fnmatch.

The fix required is to escape '\' in 'stuff' inside 
translate(). This is easiest done using stuff.replace
('\','\\'). A patch is attached...

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-03-21 10:07

Message:
Logged In: YES 
user_id=3066

Fixed in Lib/fnmatch.py revision 1.11 using a slightly
modified version of the provided patch.

----------------------------------------------------------------------

Comment By: Donovan Baarda (abo)
Date: 2001-03-18 21:26

Message:
Logged In: YES 
user_id=10273

Hmmm. that didn't work... I'll try again, but if it still 
doesn't work, use the one discribed as "fnmatch patch 
for '\' in '[...]'".

----------------------------------------------------------------------

Comment By: Donovan Baarda (abo)
Date: 2001-03-18 21:23

Message:
Logged In: YES 
user_id=10273

Due to potential confusion over which patch is the new one, 
I've deleted the old patch...

----------------------------------------------------------------------

Comment By: Donovan Baarda (abo)
Date: 2001-03-18 21:21

Message:
Logged In: YES 
user_id=10273

No sooner did I submit this, than I saw a neat way to make 
this small portion of code even neater and faster... new 
patch attached.

This patch trims 4 redundant lines and should be a fraction 
faster.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409651&group_id=5470


From noreply@sourceforge.net  Wed Mar 21 18:19:30 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 21 Mar 2001 10:19:30 -0800
Subject: [Python-bugs-list] [ python-Bugs-410274 ] sys.prefix isn't always set
Message-ID: <E14fnCk-0007RY-00@usw-sf-web1.sourceforge.net>

Bugs item #410274, was updated on 2001-03-21 01:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410274&group_id=5470

Category: Python Interpreter Core
Group: Platform-specific
Status: Open
>Priority: 6
Submitted By: Fredrik Lundh (effbot)
Assigned to: Mark Hammond (mhammond)
Summary: sys.prefix isn't always set

Initial Comment:
(2.0 and earlier, Windows only)

it looks like sys.prefix isn't set unless

1) PYTHONHOME is set (either via an environment 
variable, or via a call to Py_SetPythonHome), or

2) lib/os.py (or lib/string.py, in 1.5.2) can be found 
somewhere between the directory your executable is 
found in, and the root.

if neither is set, the path is taken from the 
registry, but sys.prefix is left blank, and code 
depending on sys.prefix (e.g. FixTk.py) no longer 
works.

</F>


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-03-21 10:19

Message:
Logged In: YES 
user_id=31435

Boosted priority a notch.  Mark, is this intentional or a 
bug?  You're a bit overdue in writing up the intended rules 
for Windows, and I'm very reluctant to go changing things 
like this myself in the absence of clarity.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410274&group_id=5470


From noreply@sourceforge.net  Wed Mar 21 19:03:52 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 21 Mar 2001 11:03:52 -0800
Subject: [Python-bugs-list] [ python-Bugs-409311 ] Python 2.1b1 re module is broken!
Message-ID: <E14fntg-0000oR-00@usw-sf-web2.sourceforge.net>

Bugs item #409311, was updated on 2001-03-16 19:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409311&group_id=5470

Category: Regular Expressions
Group: None
Status: Open
Priority: 7
Submitted By: Gregory P. Smith (greg)
Assigned to: Fredrik Lundh (effbot)
Summary: Python 2.1b1 re module is broken!

Initial Comment:
the following should -not- match:

$ python
Python 2.1b1 (#1, Mar 12 2001, 18:20:53) 
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> reg = r"(?im)<dtml-var\s+([a-z_0-9]+?)\s*>"
>>> str = '<dtml-var
expr="Presentation.show(\'start\')">'
>>> import re                                
>>> re.match(reg, str)                       
<SRE_Match object at 0x810d9d0>


In python 1.5.2 and 2.0 this works fine.


----------------------------------------------------------------------

>Comment By: Fredrik Lundh (effbot)
Date: 2001-03-21 11:03

Message:
Logged In: YES 
user_id=38376

same as #233283

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-03-18 10:58

Message:
Logged In: YES 
user_id=31435

So, Moshe, what's worse:  floating-point or regexps <2/3 
wink>?  For the life of me, I'll never be able to read +? 
as a minimal match -- it's so clearly "match one or more, 
but optionally"!

----------------------------------------------------------------------

Comment By: Moshe Zadka (moshez)
Date: 2001-03-18 03:38

Message:
Logged In: YES 
user_id=11645

Here is a simpler test case which shows the same
problem:

>>> str, r
('e=>', '(e+?)>')
>>> re.match(r, str)
<SRE_Match object at 0x4015f2e0>
>>> pre.match(r, str)
>>> 

If we lose the laziness (make the pattern "(e+)>") then it
works OK.

So the crucial problem seems to be the compilation/execution
of the lazy patterns, *not* the compilation/execution of
character classes.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-03-17 22:33

Message:
Logged In: YES 
user_id=31435

Assigned to Fredrik and boosted priority.

Gregory, it's hard to see exactly what your str vrbl 
contains because there appears to be an embedded newline in 
it.  Whatever, if I change your

    +?

to the semantically equivalent

    *

then the problem goes away for what *I* guessed you 
intended str to contain.  The

    [a-z_0-9]

part is also better written as

    \w

(since you're using the ?i flag, same thing).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-03-17 22:20

Message:
Logged In: YES 
user_id=31435

Just adding a comment to force SF to send this as email (so 
I can read it).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409311&group_id=5470


From noreply@sourceforge.net  Wed Mar 21 19:18:06 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 21 Mar 2001 11:18:06 -0800
Subject: [Python-bugs-list] [ python-Bugs-409355 ] Meta-class inheritance problem
Message-ID: <E14fo7S-0000vq-00@usw-sf-web2.sourceforge.net>

Bugs item #409355, was updated on 2001-03-17 02:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409355&group_id=5470

Category: Python Interpreter Core
>Group: Feature Request
>Status: Closed
Priority: 7
Submitted By: Lorien Dunn (loriend)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Meta-class inheritance problem

Initial Comment:
I've run into a bug in python 2.0. The real code that
the following pseudo code represents throws a
TypeError.

class MyDerivedClass(MyPurePythonClass,MyBoostClass):
        def __init__(self):
                MyPurePythonClass.__init__(self)
                MyBoostClass.__init__(self)

The problem occurs in MyPurePythonClass- Python says
"unbound method must be called with class instance 1st
argument". This makes sense: I'm passing a meta-class
instead of a class. David Abrahams (the main author of
boost::python) agrees that this is a Python problem,
and that it should affect Zope as well.

I think I've found the point in the python 2.0 sorce
where it occurs:


ceval.c, line 1816 (reformatted for clarity):

/*              BEGIN CODE SAMPLE               */

else
{
/* Unbound methods must be called with an instance of
the class (or a derived class) as first argument */

     if (na > 0 && (self = stack_pointer[-n]) != NULL
                && PyInstance_Check(self)
                && PyClass_IsSubclass((PyObject
*) 		 		   (((PyInstanceObject*)  self)->in_class),
class))
                  /* Handy-dandy */ ;
      else
      {
        PyErr_SetString(PyExc_TypeError, "unbound
method must be 		called with class instance 1st
argument");
        x = NULL;
        break;
      }
}

/*              END CODE SAMPLE         */


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-21 11:18

Message:
Logged In: YES 
user_id=6380

I *think* I've fixed this now -- please test with the
current CVS.

Please let me know if I goofed up, and I'll reopen the bug
report.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-18 14:22

Message:
Logged In: YES 
user_id=6380

Zope has several workarounds, so isn't affected.

But I agree it could be fixed.  The test is there because it wants to enforce a concept: 'self' should be an instance 
of the class that defines the method (where a subclass instance is fine too).

But the implementation of the test is based too much on the default implementation of classes.

Could someone please submit a patch that replaces the concrete isinstance() test with an isinstance() test similar 
to that in bltinmodule.c?  (Maybe we need to add a new C API, PyObject_IsInstance().)

If someone could come up with a check that conve

----------------------------------------------------------------------

Comment By: David Abrahams (david_abrahams)
Date: 2001-03-18 05:30

Message:
Logged In: YES 
user_id=52572

Sorry, that anonymous comment is mine. I'm still a bit 
clumsy with SourceForge.

-Dve

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-03-18 05:03

Message:
Logged In: NO 

I was a bit surprised to learn that this check was still in 
the code after issubclass and isinstance had been fixed to 
work with extension classes. Suppose you checked for a 
__class__ attribute on the first argument instead (or 
additionally)?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-03-17 21:29

Message:
Logged In: YES 
user_id=31435

Assigned to Guido, because I bet JimF would refuse to take 
blame for this <wink>.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409355&group_id=5470


From noreply@sourceforge.net  Wed Mar 21 21:44:08 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 21 Mar 2001 13:44:08 -0800
Subject: [Python-bugs-list] [ python-Bugs-410274 ] sys.prefix isn't always set
Message-ID: <E14fqOm-0001X4-00@usw-sf-web1.sourceforge.net>

Bugs item #410274, was updated on 2001-03-21 01:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410274&group_id=5470

Category: Python Interpreter Core
Group: Platform-specific
Status: Open
Priority: 6
Submitted By: Fredrik Lundh (effbot)
Assigned to: Mark Hammond (mhammond)
Summary: sys.prefix isn't always set

Initial Comment:
(2.0 and earlier, Windows only)

it looks like sys.prefix isn't set unless

1) PYTHONHOME is set (either via an environment 
variable, or via a call to Py_SetPythonHome), or

2) lib/os.py (or lib/string.py, in 1.5.2) can be found 
somewhere between the directory your executable is 
found in, and the root.

if neither is set, the path is taken from the 
registry, but sys.prefix is left blank, and code 
depending on sys.prefix (e.g. FixTk.py) no longer 
works.

</F>


----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2001-03-21 13:44

Message:
Logged In: YES 
user_id=14198

The main problem here is exactly how to detect it.

If the executable is not in the Python directory there are 
no reasonable hints.  The DLL is always in the system 
directory.  The core path entries may not may not be in the 
home.

But 228685 depends on this too.

The only solution I can come up with is to use the core 
sys.path entries, and one at a time try and see if the root 
could be the parent of one of them.  Any other ideas?  I 
would prefer to not assume another registry entry is 
written by installers.

I will try and write registry docs soon, but this isn't 
really relevant - I agree that sys.prefix should always be 
set, but just not sure how.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-03-21 10:19

Message:
Logged In: YES 
user_id=31435

Boosted priority a notch.  Mark, is this intentional or a 
bug?  You're a bit overdue in writing up the intended rules 
for Windows, and I'm very reluctant to go changing things 
like this myself in the absence of clarity.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410274&group_id=5470


From noreply@sourceforge.net  Wed Mar 21 23:44:19 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 21 Mar 2001 15:44:19 -0800
Subject: [Python-bugs-list] [ python-Bugs-408820 ] 'install -d' fails on BSDI systems.
Message-ID: <E14fsH5-0003Cv-00@usw-sf-web2.sourceforge.net>

Bugs item #408820, was updated on 2001-03-15 08:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408820&group_id=5470

Category: Installation
Group: Platform-specific
Status: Open
Priority: 6
Submitted By: Thomas Wouters (twouters)
>Assigned to: Thomas Wouters (twouters)
Summary: 'install -d' fails on BSDI systems.

Initial Comment:
Apparently the Makefile was changed to use 'install -d'
to create directories. This does not work on BSDI. It
seems to be an autoconf failure (since configure.in
just contains 'AC_PROG_INSTALL' but I haven't
experienced this before, with other software or with
Python.


----------------------------------------------------------------------

>Comment By: Neil Schemenauer (nascheme)
Date: 2001-03-21 15:44

Message:
Logged In: YES 
user_id=35752

Thomas, can you give this patch a go?

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2001-03-20 07:53

Message:
Logged In: YES 
user_id=11375

Makefile stuff is Neil's province.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-03-17 22:04

Message:
Logged In: YES 
user_id=31435

Assigned to Andrew because he's been known to succeed when 
installing things <ahem>.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408820&group_id=5470


From noreply@sourceforge.net  Wed Mar 21 23:50:29 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 21 Mar 2001 15:50:29 -0800
Subject: [Python-bugs-list] [ python-Bugs-231222 ] Python-2.1a2: HP make continiously runs the configure script
Message-ID: <E14fsN3-0003G4-00@usw-sf-web2.sourceforge.net>

Bugs item #231222, was updated on 2001-02-05 23:50
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=231222&group_id=5470

Category: Build
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Neil Schemenauer (nascheme)
Summary: Python-2.1a2: HP make continiously runs the configure script

Initial Comment:
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++

....


----------------------------------------------------------------------

>Comment By: Neil Schemenauer (nascheme)
Date: 2001-03-21 15:50

Message:
Logged In: YES 
user_id=35752

I think patch 405792 will fix this bug.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2001-02-10 13:07

Message:
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.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2001-02-08 09:22

Message:
Reassigning to Neil, and reclassifying as a build problem.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=231222&group_id=5470


From noreply@sourceforge.net  Wed Mar 21 23:58:33 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 21 Mar 2001 15:58:33 -0800
Subject: [Python-bugs-list] [ python-Bugs-232637 ] can't compile modules on AIX 4.2.1 (for real this time)
Message-ID: <E14fsUr-0003Ji-00@usw-sf-web2.sourceforge.net>

Bugs item #232637, was updated on 2001-02-15 15:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=232637&group_id=5470

Category: Build
Group: None
Status: Open
Priority: 5
Submitted By: Benjamin Collar (bcollar)
Assigned to: Neil Schemenauer (nascheme)
Summary: can't compile modules on AIX 4.2.1 (for real this time)

Initial Comment:
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...


----------------------------------------------------------------------

>Comment By: Neil Schemenauer (nascheme)
Date: 2001-03-21 15:58

Message:
Logged In: YES 
user_id=35752

What are the values of CC and LINKCC in Makefile?

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2001-03-17 09:17

Message:
Logged In: YES 
user_id=11375

Reassigning to Neil; I don't know why the value of CC
changes depending on the version of make.  setup.py looks at
the CC environment variable; perhaps AIX make doesn't 
pass its variables to subprocesses correctly?



----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-02-28 20:52

Message:
Logged In: YES 
user_id=3066

This relates to the move to distutils, but may have already been fixed.  Andrew?

----------------------------------------------------------------------

Comment By: Benjamin Collar (bcollar)
Date: 2001-02-22 11:47

Message:
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"?

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-02-16 01:51

Message:
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 ?!

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-02-16 01:45

Message:
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)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=232637&group_id=5470


From noreply@sourceforge.net  Thu Mar 22 00:08:42 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 21 Mar 2001 16:08:42 -0800
Subject: [Python-bugs-list] [ python-Bugs-407915 ] largefile support under Linux
Message-ID: <E14fseg-00038U-00@usw-sf-web1.sourceforge.net>

Bugs item #407915, was updated on 2001-03-12 06:43
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407915&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
>Priority: 3
Submitted By: Hans-Joachim Widmaier (hjwidmai)
Assigned to: Guido van Rossum (gvanrossum)
Summary: largefile support under Linux

Initial Comment:
While trying to build 2.1b1 with support for large
files under Linux (2.4, glibc 2.2),
Objects/fileobject.c didn't compile:

gcc -D_FILE_OFFSET_BITS=64 -c -g -O2 -Wall
-Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H  -o
Objects/fileobject.o Objects/fileobject.c
Objects/fileobject.c: In function `_portable_ftell':
Objects/fileobject.c:267: incompatible types in return
Objects/fileobject.c:275: warning: control reaches end
of non-void function

This is because fpos_t is a structure holding 2 long
longs. After changing

    return pos
to
    return pos.__pos

I got it to compile and it seems to work ok.
This is, of course, not a portable solution.

Alas, I don't really understand why there are 3 Methods
of getting largefile support (/usr/include/feature.h)
in glibc, even less why I'm bothered with defining
CFLAGS to get it; but configure seems unable to figure
out that itself. But this is not Python's fault.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-20 10:45

Message:
Logged In: YES 
user_id=6380

Sigh.  You can't win with this stuff!

Try this for now:

http://python.sourceforge.net/devel-docs/lib/posix-large-files.html

It suggests to add -D_LARGEFILE64_SOURCE which makes fpos a
long long.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407915&group_id=5470


From noreply@sourceforge.net  Thu Mar 22 00:20:16 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 21 Mar 2001 16:20:16 -0800
Subject: [Python-bugs-list] [ python-Bugs-410146 ] python 2.1b shelve is broken
Message-ID: <E14fsps-0003Gu-00@usw-sf-web1.sourceforge.net>

Bugs item #410146, was updated on 2001-03-20 12:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410146&group_id=5470

>Category: Extension Modules
Group: None
>Status: Closed
Priority: 5
Submitted By: Robert Drach (drach)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: python 2.1b shelve is broken

Initial Comment:
python 2.1b shelve module is broken, on Redhat Linux
6.2:

% python
Python 2.1b1 (#1, Mar 19 2001, 15:18:14)
[GCC 2.95.2 19991024 (release)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import shelve
>>> f = shelve.open('testshelve')
>>> f.keys()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/cdat/alpha/lib/python2.1/shelve.py",
line 56, in keys
    return self.dict.keys()
MemoryError 

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-21 16:20

Message:
Logged In: YES 
user_id=6380

This was actually a bug introduced recently in the bsddb
module.  Thanks for reporting this!  It's now fixed in the
CVS tree, just in time for the 2.1b2 release.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410146&group_id=5470


From noreply@sourceforge.net  Thu Mar 22 00:24:16 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 21 Mar 2001 16:24:16 -0800
Subject: [Python-bugs-list] [ python-Bugs-410155 ] tokenize.NL undocumented
Message-ID: <E14fstk-0003Ig-00@usw-sf-web1.sourceforge.net>

Bugs item #410155, was updated on 2001-03-20 13:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410155&group_id=5470

Category: Documentation
Group: None
>Status: Closed
Priority: 5
Submitted By: Jürgen Hermann (jhermann)
Assigned to: Guido van Rossum (gvanrossum)
Summary: tokenize.NL undocumented

Initial Comment:
In section 17.5 of the Python 2.0 Library Reference, 
the constant "NL" is not documented.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-21 16:24

Message:
Logged In: YES 
user_id=6380

The time machne strikes again.  Skip Montanaro added docs
for NL in February.  For proof, see:

http://python.sourceforge.net/devel-docs/lib/module-tokenize.html

----------------------------------------------------------------------

Comment By: Jürgen Hermann (jhermann)
Date: 2001-03-20 19:21

Message:
Logged In: YES 
user_id=39128

tokenize.NL seems to be an empty line, as opposed to 
token.NEWLINE which is a logical line end. Insofar NL is 
comparable to COMMENT, since it has no semantic content and 
is ignorable by a parser.

1 a = \
2 2
3
4 b=4

emits these tokens:

1,0-1,1:        NAME    'a'
1,2-1,3:        OP      '='
2,0-2,1:        NUMBER  '2'
2,1-2,2:        NEWLINE '\012'
3,0-3,1:        NL      '\012'
4,0-4,1:        NAME    'b'
4,1-4,2:        OP      '='
4,2-4,3:        NUMBER  '4'
4,3-4,4:        NEWLINE '\012'
5,0-5,0:        ENDMARKER       ''

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-03-20 18:22

Message:
Logged In: YES 
user_id=31435

Yes, it should be, but Ping doesn't know about NL:  Guido 
added that one.  Python's real tokenizer has no such token 
type.  It was added because-- unlike Python's real 
tokenizer --tokenizer.py passes *everything* on to the 
client, including blank lines and comments, so passes on 
newlines that aren't NEWLINEs too.  Reassigned to Guido in 
case he remembers more about the details ...

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-03-20 14:58

Message:
Logged In: YES 
user_id=3066

Ping, should NL be documented?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410155&group_id=5470


From noreply@sourceforge.net  Thu Mar 22 00:33:06 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 21 Mar 2001 16:33:06 -0800
Subject: [Python-bugs-list] [ python-Bugs-407180 ] proposal: allow years before 1900
Message-ID: <E14ft2I-0000mf-00@usw-sf-web3.sourceforge.net>

Bugs item #407180, was updated on 2001-03-08 13:55
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407180&group_id=5470

Category: Python Library
Group: Feature Request
>Status: Closed
Priority: 4
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Guido van Rossum (gvanrossum)
Summary: proposal: allow years before 1900

Initial Comment:
Handling of years before 1900: proposed change for 
python 1.5.2-2.1

from http://www.python.org/doc/current/lib/module-
time.html:

>Values 100-1899 are always
>illegal. Note that this is new as of Python 1.5.2
(a2); earlier
>versions, up to Python 1.5.1 and 1.5.2a1, would add 
1900 to year
>values below 1900.

Wouldn't the correct behaviour be just to store years 
before 1900 into
tm_year as any other year in timemodule.c gettmarg()?  
They get stored
as negative values, but there shouldn't be any 
problems with that,
judging from glibc 2.2 behaviour, documentation for 
other libc's, and
the following quote from 
http://www.platinum.com/products/wp/wp_epmdt.htm:

"While tm_year is based on 1900, the full range of 
positive and
negative values are allowed. For 32-bit integers this 
allows for dates
from 2147481748 BCE to 2147485548 CE. "


Proposed patch for python 1.5.2:

*** timemodule.c.origi  Tue Apr  6 00:54:14 1999
--- timemodule.c        Thu Mar  8 23:32:55 2001
***************
*** 345,355 ****
                        y += 1900;
                else if (0 <= y && y <= 68)
                        y += 2000;
-               else {
-                       PyErr_SetString
(PyExc_ValueError,
-                                       "year out of 
range (00-99, 1900-*)");
-                       return 0;
-               }
        }
        p->tm_year = y - 1900;
        p->tm_mon--;
--- 345,350 ----



----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-21 16:33

Message:
Logged In: YES 
user_id=6380

I question the wisdom of this change.  It suggests that the
time module would support old dates, while in fact it has
almost no support for dates before 1970. The only thing it
would add is that you can use asctime() and strftime() for
dates before 1900, but I doubt that that is very useful
without full support. (E.g. you can't calculate what day of
the week 1/1/1800 is even with this change.)

So I'm rejecting this -- better catch bogus inputs early.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407180&group_id=5470


From noreply@sourceforge.net  Thu Mar 22 02:49:30 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 21 Mar 2001 18:49:30 -0800
Subject: [Python-bugs-list] [ python-Bugs-408098 ] python -i loses __future__
Message-ID: <E14fvAI-0004tr-00@usw-sf-web1.sourceforge.net>

Bugs item #408098, was updated on 2001-03-12 17:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408098&group_id=5470

Category: Parser/Compiler
Group: None
>Status: Closed
Priority: 5
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Jeremy Hylton (jhylton)
Summary: python -i loses __future__

Initial Comment:
If you run a Python script that has a "from __future__
import nested_scopes" and pass the -i flag, the
interactive interpreter should have the nested_scopes
compiler flag set.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408098&group_id=5470


From noreply@sourceforge.net  Thu Mar 22 03:58:53 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 21 Mar 2001 19:58:53 -0800
Subject: [Python-bugs-list] [ python-Bugs-405341 ] Reminder -- nested scopes TO DO list
Message-ID: <E14fwFR-0005cP-00@usw-sf-web1.sourceforge.net>

Bugs item #405341, was updated on 2001-03-01 18:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405341&group_id=5470

>Category: Parser/Compiler
Group: None
Status: Open
>Priority: 6
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Jeremy Hylton (jhylton)
Summary: Reminder -- nested scopes TO DO list

Initial Comment:
Subject: [Python-Dev] nested scopes and future status
From: Jeremy Hylton <jeremy@alum.mit.edu>
To: python-dev@python.org
Date: Thu, 1 Mar 2001 18:34:44 -0500 (EST)

There are several loose ends in the nested scopes
changes that I won't
have time to fix before the beta.  Here's a laundry
list of tasks that
remain.  I don't think any of these is crucial for the
release.
Holler if there's something you'd like me to fix
tonight.

- Integrate the parsing of future statements into the
_symtable
  module's interface.  This interface is new with 2.1
and
  undocumented, so it's deficiency here will not affect
any code.

- Update traceback.py to understand SyntaxErrors that
have a text
  attribute and an offset of None.  It should not print
the caret.

- PyErr_ProgramText() should be called when an
exception is printed
  rather than when it is raised.

- Fix pdb to support nested scopes.

- Produce a better error message/warning for code like
this:
  def f(x):
      def g():
          exec ...
          print x
  The warning message should say that exec is not
allowed in a nested
  function with free variables.  It currently says that
g *contains* a
  nested function with free variables.

- Update the documentation.

Jeremy


----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-03-21 19:58

Message:
Logged In: YES 
user_id=31392

Only two things left to do:

1. Documentation
2. The PyErr_ProgramText() item (perhaps optional)


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-20 07:47

Message:
Logged In: YES 
user_id=6380

Jeremy, what's up with these?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405341&group_id=5470


From noreply@sourceforge.net  Thu Mar 22 06:23:21 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 21 Mar 2001 22:23:21 -0800
Subject: [Python-bugs-list] [ python-Bugs-410471 ] linuxaudiodev lacket Py_BEGIN/END_THREAD
Message-ID: <E14fyVF-00026N-00@usw-sf-web2.sourceforge.net>

Bugs item #410471, was updated on 2001-03-21 22:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410471&group_id=5470

Category: Python Library
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: linuxaudiodev lacket Py_BEGIN/END_THREAD

Initial Comment:
The system calls in the linuxaudiodev module need to
be wrapped with:

  Py_BEGIN_ALLOW_THREADS
  Py_END_ALLOW_THREADS

so that audio I/O can occur async/multithreaded.

I'm including a patch to fix this, for Python 2.0.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410471&group_id=5470


From noreply@sourceforge.net  Thu Mar 22 06:29:28 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 21 Mar 2001 22:29:28 -0800
Subject: [Python-bugs-list] [ python-Bugs-410473 ] Python docs contain refs to v1.7
Message-ID: <E14fybA-00028H-00@usw-sf-web2.sourceforge.net>

Bugs item #410473, was updated on 2001-03-21 22:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410473&group_id=5470

Category: Documentation
Group: Trash
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Python docs contain refs to v1.7

Initial Comment:
Mention of a non-existent Python version 1.7 appear
in a few places in the official docs.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410473&group_id=5470


From noreply@sourceforge.net  Thu Mar 22 15:29:54 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 22 Mar 2001 07:29:54 -0800
Subject: [Python-bugs-list] [ python-Bugs-410271 ] SRE: word-based anchors ignore locale
Message-ID: <E14g72A-0006i0-00@usw-sf-web3.sourceforge.net>

Bugs item #410271, was updated on 2001-03-21 01:52
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410271&group_id=5470

Category: Regular Expressions
Group: None
Status: Open
Priority: 7
Submitted By: Fredrik Lundh (effbot)
Assigned to: Fredrik Lundh (effbot)
Summary: SRE: word-based anchors ignore locale

Initial Comment:
the \b and \B anchors don't take the locale
settings into account.

import locale, re
locale.setlocale(locale.LC_ALL, "")

# should print ["egg", "and"]
print re.findall(r"\b...\b", "spam, egg, bacon, and 
åäö")

# should print ["egg", "and", "åäö"]
print re.findall(r"(?L)\b...\b", "spam, egg, bacon, 
and åäö")


----------------------------------------------------------------------

>Comment By: Fredrik Lundh (effbot)
Date: 2001-03-22 07:29

Message:
Logged In: YES 
user_id=38376

fixed in 2.1b2

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410271&group_id=5470


From noreply@sourceforge.net  Thu Mar 22 15:36:18 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 22 Mar 2001 07:36:18 -0800
Subject: [Python-bugs-list] [ python-Bugs-406792 ] python2.1b1 core dumps --with-pymalloc
Message-ID: <E14g78M-0005wR-00@usw-sf-web2.sourceforge.net>

Bugs item #406792, was updated on 2001-03-07 11:08
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406792&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Priority: 3
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: python2.1b1 core dumps --with-pymalloc 

Initial Comment:
% ./configure --without-threads --with-pymalloc
% gmake
...

./python setup.py
...
Then it dumps core. Removing the  --with-pymalloc and
it runs just fine.
[281] % uname -a
HP-UX wssgped B.10.20 A 9000/782 2001125167 two-user
license
[282] % gcc --version
2.95.1


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-03-22 07:36

Message:
Logged In: NO 

[213] % gcc --version
2.95.1
[214] % uname -a
HP-UX wvenus B.10.20 A 9000/782 2009382447 two-user license


If I build Objects/obmalloc.w WITHOUT the -O2 option then
./python works.
If I build Objects/obmalloc.w WITH the -O1 option then
./python works.

If I build Objects/obmalloc.w WITH the -O2 (the default)
option then ./python
fails as seen below. Using -O3 and -O4 also causes ./python
to crash.


[212] % gdb ./python ./setup.py build
Excess command line arguments ignored. (build)
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public
License, and you are
welcome to change it and/or distribute copies of it under
certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show
warranty" for details.
This GDB was configured as "hppa2.0-hp-hpux10.20"...
"/tmp_mnt/net/roti/wssg/hpux10x/usrlocal/packages/python2.1/Python-2.1b1/./setup.py"
is not a core dump: File format not recognized
(gdb) run
Starting program:
/tmp_mnt/net/roti/wssg/hpux10x/usrlocal/packages/python2.1/Python-2.1b1/./python 
warning: Unable to find __d_pid symbol in object file.
warning: Suggest linking with /opt/langtools/lib/end.o.
warning: GDB will be unable to track shl_load/shl_unload
calls

Program received signal SIGBUS, Bus error.
_PyCore_ObjectMalloc (nbytes=28) at Objects/obmalloc.c:417
417                             if ((pool->freeblock =
*(block **)bp) != NULL) {


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-20 09:08

Message:
Logged In: YES 
user_id=6380

Alas, I can't reproduce this on Linux.

I'm afraid building Python on HP-UX is braindead, and I
don't know wht the problem is.  No two HP-UX users ever seem
to run in the same problem, nor do I ever seem to get help
from folks with HP-UX machines in debugging those
problems...

So, while I am sympathetic, I can't help.  Somebody else
please help!


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406792&group_id=5470


From noreply@sourceforge.net  Thu Mar 22 15:52:58 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 22 Mar 2001 07:52:58 -0800
Subject: [Python-bugs-list] [ python-Bugs-410271 ] SRE: word-based anchors ignore locale
Message-ID: <E14g7OU-00065y-00@usw-sf-web2.sourceforge.net>

Bugs item #410271, was updated on 2001-03-21 01:52
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410271&group_id=5470

Category: Regular Expressions
Group: None
>Status: Closed
Priority: 7
Submitted By: Fredrik Lundh (effbot)
Assigned to: Fredrik Lundh (effbot)
Summary: SRE: word-based anchors ignore locale

Initial Comment:
the \b and \B anchors don't take the locale
settings into account.

import locale, re
locale.setlocale(locale.LC_ALL, "")

# should print ["egg", "and"]
print re.findall(r"\b...\b", "spam, egg, bacon, and 
åäö")

# should print ["egg", "and", "åäö"]
print re.findall(r"(?L)\b...\b", "spam, egg, bacon, 
and åäö")


----------------------------------------------------------------------

Comment By: Fredrik Lundh (effbot)
Date: 2001-03-22 07:29

Message:
Logged In: YES 
user_id=38376

fixed in 2.1b2

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410271&group_id=5470


From noreply@sourceforge.net  Thu Mar 22 16:31:21 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 22 Mar 2001 08:31:21 -0800
Subject: [Python-bugs-list] [ python-Bugs-410541 ] bdist builds bogus .zips
Message-ID: <E14g7zd-0006Rq-00@usw-sf-web2.sourceforge.net>

Bugs item #410541, was updated on 2001-03-22 08:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410541&group_id=5470

Category: Distutils
Group: None
Status: Open
Priority: 5
Submitted By: A.M. Kuchling (akuchling)
Assigned to: A.M. Kuchling (akuchling)
Summary: bdist builds bogus .zips

Initial Comment:
According to Thomas Heller: "... the resulting zip-file
from
'bdist --formats=zip' is unusable because it contains
filenames relative to
the root directory)"

Such paths may be OK for Unix (cd / and unzip it,
perhaps?), 
but isn't much good for Windows, where Python might be
installed anywhere.  


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410541&group_id=5470


From noreply@sourceforge.net  Thu Mar 22 16:35:33 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 22 Mar 2001 08:35:33 -0800
Subject: [Python-bugs-list] [ python-Bugs-228591 ] C-level GC API is not documented
Message-ID: <E14g83h-00051N-00@usw-sf-web1.sourceforge.net>

Bugs item #228591, was updated on 2001-01-12 13:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=228591&group_id=5470

Category: Documentation
Group: Feature Request
>Status: Closed
Priority: 6
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: C-level GC API is not documented

Initial Comment:
The C macros and functions needed to interface with the garbage collector and used to implement GC-aware types are not documented.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-03-22 08:35

Message:
Logged In: YES 
user_id=3066

Integrated most of Neil's text and added more (with example code!) in Doc/api/api.tex revisions 1.110 and 1.111.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-02-28 20:50

Message:
Logged In: YES 
user_id=3066

Neil has sent me some text; it's up to me to integrate.  So this is back on my plate.

Thanks, Neil!

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=228591&group_id=5470


From noreply@sourceforge.net  Thu Mar 22 16:37:28 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 22 Mar 2001 08:37:28 -0800
Subject: [Python-bugs-list] [ python-Bugs-410473 ] Python docs contain refs to v1.7
Message-ID: <E14g85Y-00052p-00@usw-sf-web1.sourceforge.net>

Bugs item #410473, was updated on 2001-03-21 22:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410473&group_id=5470

Category: Documentation
Group: Trash
>Status: Closed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Python docs contain refs to v1.7

Initial Comment:
Mention of a non-existent Python version 1.7 appear
in a few places in the official docs.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-03-22 08:37

Message:
Logged In: YES 
user_id=3066

The current CVS version of the documentation does not have this.  This was an artefact of the 1.6 docs before it was public knowledge that the next version would be 2.0.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410473&group_id=5470


From noreply@sourceforge.net  Thu Mar 22 17:15:04 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 22 Mar 2001 09:15:04 -0800
Subject: [Python-bugs-list] [ python-Bugs-409311 ] Python 2.1b1 re module is broken!
Message-ID: <E14g8fw-0005Wr-00@usw-sf-web1.sourceforge.net>

Bugs item #409311, was updated on 2001-03-16 19:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409311&group_id=5470

Category: Regular Expressions
Group: None
>Status: Closed
Priority: 7
Submitted By: Gregory P. Smith (greg)
Assigned to: Fredrik Lundh (effbot)
Summary: Python 2.1b1 re module is broken!

Initial Comment:
the following should -not- match:

$ python
Python 2.1b1 (#1, Mar 12 2001, 18:20:53) 
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> reg = r"(?im)<dtml-var\s+([a-z_0-9]+?)\s*>"
>>> str = '<dtml-var
expr="Presentation.show(\'start\')">'
>>> import re                                
>>> re.match(reg, str)                       
<SRE_Match object at 0x810d9d0>


In python 1.5.2 and 2.0 this works fine.


----------------------------------------------------------------------

>Comment By: Fredrik Lundh (effbot)
Date: 2001-03-22 09:15

Message:
Logged In: YES 
user_id=38376

fixed in 2.1b2

----------------------------------------------------------------------

Comment By: Fredrik Lundh (effbot)
Date: 2001-03-21 11:03

Message:
Logged In: YES 
user_id=38376

same as #233283

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-03-18 10:58

Message:
Logged In: YES 
user_id=31435

So, Moshe, what's worse:  floating-point or regexps <2/3 
wink>?  For the life of me, I'll never be able to read +? 
as a minimal match -- it's so clearly "match one or more, 
but optionally"!

----------------------------------------------------------------------

Comment By: Moshe Zadka (moshez)
Date: 2001-03-18 03:38

Message:
Logged In: YES 
user_id=11645

Here is a simpler test case which shows the same
problem:

>>> str, r
('e=>', '(e+?)>')
>>> re.match(r, str)
<SRE_Match object at 0x4015f2e0>
>>> pre.match(r, str)
>>> 

If we lose the laziness (make the pattern "(e+)>") then it
works OK.

So the crucial problem seems to be the compilation/execution
of the lazy patterns, *not* the compilation/execution of
character classes.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-03-17 22:33

Message:
Logged In: YES 
user_id=31435

Assigned to Fredrik and boosted priority.

Gregory, it's hard to see exactly what your str vrbl 
contains because there appears to be an embedded newline in 
it.  Whatever, if I change your

    +?

to the semantically equivalent

    *

then the problem goes away for what *I* guessed you 
intended str to contain.  The

    [a-z_0-9]

part is also better written as

    \w

(since you're using the ?i flag, same thing).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-03-17 22:20

Message:
Logged In: YES 
user_id=31435

Just adding a comment to force SF to send this as email (so 
I can read it).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409311&group_id=5470


From noreply@sourceforge.net  Thu Mar 22 19:59:07 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 22 Mar 2001 11:59:07 -0800
Subject: [Python-bugs-list] [ python-Bugs-409355 ] Meta-class inheritance problem
Message-ID: <E14gBEh-0000ly-00@usw-sf-web3.sourceforge.net>

Bugs item #409355, was updated on 2001-03-17 02:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409355&group_id=5470

Category: Python Interpreter Core
Group: Feature Request
Status: Closed
Priority: 7
Submitted By: Lorien Dunn (loriend)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Meta-class inheritance problem

Initial Comment:
I've run into a bug in python 2.0. The real code that
the following pseudo code represents throws a
TypeError.

class MyDerivedClass(MyPurePythonClass,MyBoostClass):
        def __init__(self):
                MyPurePythonClass.__init__(self)
                MyBoostClass.__init__(self)

The problem occurs in MyPurePythonClass- Python says
"unbound method must be called with class instance 1st
argument". This makes sense: I'm passing a meta-class
instead of a class. David Abrahams (the main author of
boost::python) agrees that this is a Python problem,
and that it should affect Zope as well.

I think I've found the point in the python 2.0 sorce
where it occurs:


ceval.c, line 1816 (reformatted for clarity):

/*              BEGIN CODE SAMPLE               */

else
{
/* Unbound methods must be called with an instance of
the class (or a derived class) as first argument */

     if (na > 0 && (self = stack_pointer[-n]) != NULL
                && PyInstance_Check(self)
                && PyClass_IsSubclass((PyObject
*) 		 		   (((PyInstanceObject*)  self)->in_class),
class))
                  /* Handy-dandy */ ;
      else
      {
        PyErr_SetString(PyExc_TypeError, "unbound
method must be 		called with class instance 1st
argument");
        x = NULL;
        break;
      }
}

/*              END CODE SAMPLE         */


----------------------------------------------------------------------

>Comment By: Lorien Dunn (loriend)
Date: 2001-03-22 11:59

Message:
Logged In: YES 
user_id=175701

I'm afraid it still doesn't work :( 
	the line is (from cvs code):
		ok = PyObject_IsInstance(self, class)
	and the problem is that ok == 0.
Thank you for patching this- I've spent hours trying to
figure out enough about the python internals to do it
myself.

Lorien
	 

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-21 11:18

Message:
Logged In: YES 
user_id=6380

I *think* I've fixed this now -- please test with the
current CVS.

Please let me know if I goofed up, and I'll reopen the bug
report.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-18 14:22

Message:
Logged In: YES 
user_id=6380

Zope has several workarounds, so isn't affected.

But I agree it could be fixed.  The test is there because it wants to enforce a concept: 'self' should be an instance 
of the class that defines the method (where a subclass instance is fine too).

But the implementation of the test is based too much on the default implementation of classes.

Could someone please submit a patch that replaces the concrete isinstance() test with an isinstance() test similar 
to that in bltinmodule.c?  (Maybe we need to add a new C API, PyObject_IsInstance().)

If someone could come up with a check that conve

----------------------------------------------------------------------

Comment By: David Abrahams (david_abrahams)
Date: 2001-03-18 05:30

Message:
Logged In: YES 
user_id=52572

Sorry, that anonymous comment is mine. I'm still a bit 
clumsy with SourceForge.

-Dve

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-03-18 05:03

Message:
Logged In: NO 

I was a bit surprised to learn that this check was still in 
the code after issubclass and isinstance had been fixed to 
work with extension classes. Suppose you checked for a 
__class__ attribute on the first argument instead (or 
additionally)?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-03-17 21:29

Message:
Logged In: YES 
user_id=31435

Assigned to Guido, because I bet JimF would refuse to take 
blame for this <wink>.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409355&group_id=5470


From noreply@sourceforge.net  Thu Mar 22 20:03:40 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 22 Mar 2001 12:03:40 -0800
Subject: [Python-bugs-list] [ python-Bugs-409355 ] Meta-class inheritance problem
Message-ID: <E14gBJ6-0007Sn-00@usw-sf-web1.sourceforge.net>

Bugs item #409355, was updated on 2001-03-17 02:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409355&group_id=5470

Category: Python Interpreter Core
Group: Feature Request
>Status: Open
Priority: 7
Submitted By: Lorien Dunn (loriend)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Meta-class inheritance problem

Initial Comment:
I've run into a bug in python 2.0. The real code that
the following pseudo code represents throws a
TypeError.

class MyDerivedClass(MyPurePythonClass,MyBoostClass):
        def __init__(self):
                MyPurePythonClass.__init__(self)
                MyBoostClass.__init__(self)

The problem occurs in MyPurePythonClass- Python says
"unbound method must be called with class instance 1st
argument". This makes sense: I'm passing a meta-class
instead of a class. David Abrahams (the main author of
boost::python) agrees that this is a Python problem,
and that it should affect Zope as well.

I think I've found the point in the python 2.0 sorce
where it occurs:


ceval.c, line 1816 (reformatted for clarity):

/*              BEGIN CODE SAMPLE               */

else
{
/* Unbound methods must be called with an instance of
the class (or a derived class) as first argument */

     if (na > 0 && (self = stack_pointer[-n]) != NULL
                && PyInstance_Check(self)
                && PyClass_IsSubclass((PyObject
*) 		 		   (((PyInstanceObject*)  self)->in_class),
class))
                  /* Handy-dandy */ ;
      else
      {
        PyErr_SetString(PyExc_TypeError, "unbound
method must be 		called with class instance 1st
argument");
        x = NULL;
        break;
      }
}

/*              END CODE SAMPLE         */


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-22 12:03

Message:
Logged In: YES 
user_id=6380

OK, try this.  In your Python code, what does
isinstance(self, MyPurePythonClass) return?

----------------------------------------------------------------------

Comment By: Lorien Dunn (loriend)
Date: 2001-03-22 11:59

Message:
Logged In: YES 
user_id=175701

I'm afraid it still doesn't work :( 
	the line is (from cvs code):
		ok = PyObject_IsInstance(self, class)
	and the problem is that ok == 0.
Thank you for patching this- I've spent hours trying to
figure out enough about the python internals to do it
myself.

Lorien
	 

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-21 11:18

Message:
Logged In: YES 
user_id=6380

I *think* I've fixed this now -- please test with the
current CVS.

Please let me know if I goofed up, and I'll reopen the bug
report.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-18 14:22

Message:
Logged In: YES 
user_id=6380

Zope has several workarounds, so isn't affected.

But I agree it could be fixed.  The test is there because it wants to enforce a concept: 'self' should be an instance 
of the class that defines the method (where a subclass instance is fine too).

But the implementation of the test is based too much on the default implementation of classes.

Could someone please submit a patch that replaces the concrete isinstance() test with an isinstance() test similar 
to that in bltinmodule.c?  (Maybe we need to add a new C API, PyObject_IsInstance().)

If someone could come up with a check that conve

----------------------------------------------------------------------

Comment By: David Abrahams (david_abrahams)
Date: 2001-03-18 05:30

Message:
Logged In: YES 
user_id=52572

Sorry, that anonymous comment is mine. I'm still a bit 
clumsy with SourceForge.

-Dve

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-03-18 05:03

Message:
Logged In: NO 

I was a bit surprised to learn that this check was still in 
the code after issubclass and isinstance had been fixed to 
work with extension classes. Suppose you checked for a 
__class__ attribute on the first argument instead (or 
additionally)?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-03-17 21:29

Message:
Logged In: YES 
user_id=31435

Assigned to Guido, because I bet JimF would refuse to take 
blame for this <wink>.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409355&group_id=5470


From noreply@sourceforge.net  Thu Mar 22 20:33:17 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 22 Mar 2001 12:33:17 -0800
Subject: [Python-bugs-list] [ python-Bugs-406792 ] python2.1b1 core dumps --with-pymalloc
Message-ID: <E14gBll-0000Gg-00@usw-sf-web2.sourceforge.net>

Bugs item #406792, was updated on 2001-03-07 11:08
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406792&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
>Priority: 2
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: python2.1b1 core dumps --with-pymalloc 

Initial Comment:
% ./configure --without-threads --with-pymalloc
% gmake
...

./python setup.py
...
Then it dumps core. Removing the  --with-pymalloc and
it runs just fine.
[281] % uname -a
HP-UX wssgped B.10.20 A 9000/782 2001125167 two-user
license
[282] % gcc --version
2.95.1


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-03-22 07:36

Message:
Logged In: NO 

[213] % gcc --version
2.95.1
[214] % uname -a
HP-UX wvenus B.10.20 A 9000/782 2009382447 two-user license


If I build Objects/obmalloc.w WITHOUT the -O2 option then
./python works.
If I build Objects/obmalloc.w WITH the -O1 option then
./python works.

If I build Objects/obmalloc.w WITH the -O2 (the default)
option then ./python
fails as seen below. Using -O3 and -O4 also causes ./python
to crash.


[212] % gdb ./python ./setup.py build
Excess command line arguments ignored. (build)
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public
License, and you are
welcome to change it and/or distribute copies of it under
certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show
warranty" for details.
This GDB was configured as "hppa2.0-hp-hpux10.20"...
"/tmp_mnt/net/roti/wssg/hpux10x/usrlocal/packages/python2.1/Python-2.1b1/./setup.py"
is not a core dump: File format not recognized
(gdb) run
Starting program:
/tmp_mnt/net/roti/wssg/hpux10x/usrlocal/packages/python2.1/Python-2.1b1/./python 
warning: Unable to find __d_pid symbol in object file.
warning: Suggest linking with /opt/langtools/lib/end.o.
warning: GDB will be unable to track shl_load/shl_unload
calls

Program received signal SIGBUS, Bus error.
_PyCore_ObjectMalloc (nbytes=28) at Objects/obmalloc.c:417
417                             if ((pool->freeblock =
*(block **)bp) != NULL) {


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-20 09:08

Message:
Logged In: YES 
user_id=6380

Alas, I can't reproduce this on Linux.

I'm afraid building Python on HP-UX is braindead, and I
don't know wht the problem is.  No two HP-UX users ever seem
to run in the same problem, nor do I ever seem to get help
from folks with HP-UX machines in debugging those
problems...

So, while I am sympathetic, I can't help.  Somebody else
please help!


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406792&group_id=5470


From noreply@sourceforge.net  Thu Mar 22 21:46:39 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 22 Mar 2001 13:46:39 -0800
Subject: [Python-bugs-list] [ python-Bugs-410608 ] popen with threads
Message-ID: <E14gCul-0000HL-00@usw-sf-web1.sourceforge.net>

Bugs item #410608, was updated on 2001-03-22 13:46
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410608&group_id=5470

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: popen with threads

Initial Comment:
This code generate a error

##########################
import threading
import os

class TestPopen( threading.Thread ):

   def run( self ):
      while 1:
         f = os.popen( "ls -l /" )
         lines = f.read()
         f.close()

if __name__ == "__main__":
   for i in range(50):
      t = TestPopen()
      t.start()
###########################

it eventually dies w/ IOErrors in the f.close() calls.

My system is:
Linux RedHat 6.2
Python 1.5.2
I tested in Python 2.0 and the same error occur.




----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410608&group_id=5470


From noreply@sourceforge.net  Thu Mar 22 21:58:02 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 22 Mar 2001 13:58:02 -0800
Subject: [Python-bugs-list] [ python-Bugs-409355 ] Meta-class inheritance problem
Message-ID: <E14gD5m-0001n9-00@usw-sf-web3.sourceforge.net>

Bugs item #409355, was updated on 2001-03-17 02:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409355&group_id=5470

Category: Python Interpreter Core
Group: Feature Request
Status: Open
Priority: 7
Submitted By: Lorien Dunn (loriend)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Meta-class inheritance problem

Initial Comment:
I've run into a bug in python 2.0. The real code that
the following pseudo code represents throws a
TypeError.

class MyDerivedClass(MyPurePythonClass,MyBoostClass):
        def __init__(self):
                MyPurePythonClass.__init__(self)
                MyBoostClass.__init__(self)

The problem occurs in MyPurePythonClass- Python says
"unbound method must be called with class instance 1st
argument". This makes sense: I'm passing a meta-class
instead of a class. David Abrahams (the main author of
boost::python) agrees that this is a Python problem,
and that it should affect Zope as well.

I think I've found the point in the python 2.0 sorce
where it occurs:


ceval.c, line 1816 (reformatted for clarity):

/*              BEGIN CODE SAMPLE               */

else
{
/* Unbound methods must be called with an instance of
the class (or a derived class) as first argument */

     if (na > 0 && (self = stack_pointer[-n]) != NULL
                && PyInstance_Check(self)
                && PyClass_IsSubclass((PyObject
*) 		 		   (((PyInstanceObject*)  self)->in_class),
class))
                  /* Handy-dandy */ ;
      else
      {
        PyErr_SetString(PyExc_TypeError, "unbound
method must be 		called with class instance 1st
argument");
        x = NULL;
        break;
      }
}

/*              END CODE SAMPLE         */


----------------------------------------------------------------------

>Comment By: Lorien Dunn (loriend)
Date: 2001-03-22 13:58

Message:
Logged In: YES 
user_id=175701

In the following code it returns 0.

MyDerivedClass(MyPurePythonClass, MyBoostClass):
       def __init__(self):
            MyBoostClass.__init__(self)
            isinstance(self, MyPurePythonClass)




----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-22 12:03

Message:
Logged In: YES 
user_id=6380

OK, try this.  In your Python code, what does
isinstance(self, MyPurePythonClass) return?

----------------------------------------------------------------------

Comment By: Lorien Dunn (loriend)
Date: 2001-03-22 11:59

Message:
Logged In: YES 
user_id=175701

I'm afraid it still doesn't work :( 
	the line is (from cvs code):
		ok = PyObject_IsInstance(self, class)
	and the problem is that ok == 0.
Thank you for patching this- I've spent hours trying to
figure out enough about the python internals to do it
myself.

Lorien
	 

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-21 11:18

Message:
Logged In: YES 
user_id=6380

I *think* I've fixed this now -- please test with the
current CVS.

Please let me know if I goofed up, and I'll reopen the bug
report.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-18 14:22

Message:
Logged In: YES 
user_id=6380

Zope has several workarounds, so isn't affected.

But I agree it could be fixed.  The test is there because it wants to enforce a concept: 'self' should be an instance 
of the class that defines the method (where a subclass instance is fine too).

But the implementation of the test is based too much on the default implementation of classes.

Could someone please submit a patch that replaces the concrete isinstance() test with an isinstance() test similar 
to that in bltinmodule.c?  (Maybe we need to add a new C API, PyObject_IsInstance().)

If someone could come up with a check that conve

----------------------------------------------------------------------

Comment By: David Abrahams (david_abrahams)
Date: 2001-03-18 05:30

Message:
Logged In: YES 
user_id=52572

Sorry, that anonymous comment is mine. I'm still a bit 
clumsy with SourceForge.

-Dve

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-03-18 05:03

Message:
Logged In: NO 

I was a bit surprised to learn that this check was still in 
the code after issubclass and isinstance had been fixed to 
work with extension classes. Suppose you checked for a 
__class__ attribute on the first argument instead (or 
additionally)?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-03-17 21:29

Message:
Logged In: YES 
user_id=31435

Assigned to Guido, because I bet JimF would refuse to take 
blame for this <wink>.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409355&group_id=5470


From noreply@sourceforge.net  Thu Mar 22 23:20:01 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 22 Mar 2001 15:20:01 -0800
Subject: [Python-bugs-list] [ python-Bugs-410620 ] pydoc installation w.r.t. RPM.
Message-ID: <E14gEN7-0001Na-00@usw-sf-web1.sourceforge.net>

Bugs item #410620, was updated on 2001-03-22 15:20
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410620&group_id=5470

Category: Installation
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: pydoc installation w.r.t. RPM.

Initial Comment:
Overview:

When building an RPM the value for the --prefix
configure variable takes on double meaning.  Why?
Well --prefix tells the build system to "build python
so that if runs from --prefix at run time".  This
infers that during "make install" you want to install
python in the --prefix area.  The problem is when
building an RPM you need to build python for --prefix
but install into a temprory place (not indicated by
the --prefix variable).  This is done by overriding
the environment variable $prefix during "make install"
so rpm can install into a temprary location in order
to snarf up the files for packaging.

Python in general plays this game well however from
2.1a2 to 2.1b1 the pydoc stuff breaks this paradigm.

I'm using this patch in my 2.1b1 rpm specfile but I
would prefer the patch to be incorporated into the
base installation.

-res

Patch included below:

--------------------- snip -------------------

*** Python-2.1b1/Makefile.pre.in.ORIG   Wed Mar 21
13:24:09 2001
--- Python-2.1b1/Makefile.pre.in        Wed Mar 21
13:24:48 2001
***************
*** 694,700 ****
  # This goes into $(exec_prefix)
  sharedinstall:
        PYTHONPATH= ./$(PYTHON) $(srcdir)/setup.py
install \
!               --install-platlib=$(DESTSHARED)
  
  # Build the toplevel Makefile
  Makefile.pre: Makefile.pre.in config.status
--- 694,700 ----
  # This goes into $(exec_prefix)
  sharedinstall:
        PYTHONPATH= ./$(PYTHON) $(srcdir)/setup.py
install \
!               --install-platlib=$(DESTSHARED)
--prefix=${prefix}
  
  # Build the toplevel Makefile
  Makefile.pre: Makefile.pre.in config.status


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410620&group_id=5470


From noreply@sourceforge.net  Fri Mar 23 02:28:14 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 22 Mar 2001 18:28:14 -0800
Subject: [Python-bugs-list] [ python-Bugs-215076 ] threads of __del__
Message-ID: <E14gHJG-00039f-00@usw-sf-web2.sourceforge.net>

Bugs item #215076, was updated on 2000-09-22 02:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=215076&group_id=5470

Category: Threads
Group: None
Status: Open
Priority: 3
Submitted By: Toby Dickenson (htrd)
Assigned to: Tim Peters (tim_one)
Summary: threads of __del__

Initial Comment:
I suspect (but have not proved) that the support for destroying deeply recursive structures can allow for an instances __del__ method to get called in a thread other than the one in which it lost its last reference.

This can happen if it switches to a different thread during deletion of a deeply recursive structure (with _PyTrash_delete_later not empty). 

Should Python guarantee that this does not happen? (I say yes - it is important for COM clients)

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-03-22 18:28

Message:
Logged In: NO 

Im trying to learn the art of cracking


----------------------------------------------------------------------

Comment By: Toby Dickenson (htrd)
Date: 2000-09-25 02:04

Message:
Ive noticed that this patch also fixes a different problem that I hadnt realised was related....

We were observing that one thread occasionally became blocked for a few tens of seconds, and the profiler wasnt giving any hints.

It turns out that this thread was busy emptying the trashcan, and running the deallocator functions for the objects used and discardered by all the other threads.

The script below shows up this problem (on NT). It prints pairs of numbers; the first out of each pair will stay the same for 'a long time'.

Mark: I assume Python.net will print the 'Waaah' lines too?

import thread,time

class A:
    def __init__(self,other):
        self._other = other
        self._ident = thread.get_ident()

    def __del__(self):
        new_ident = thread.get_ident()
        if new_ident!=self._ident:
            print 'Waaaaaah', new_ident, self._ident

def work(size):
    ident = thread.get_ident()
    while 1:
        a=None
        for i in range(size):
            a = A(a)
            for i in range(10):
                a = (a,)
            


# Three few big ones
for i in range(3):
    thread.start_new_thread(work,(1000,))
# And one huge one
work(100000)


----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2000-09-22 16:57

Message:
I've got to side with Tim that "last thread with a reference" is not the correct semantic to be applied here.

On the other hand, I do agree that some determinism would be nice here.  The reporter is completely correct about, eg, COM rules.  If I was BDFL, I would probably go for something deterministic, and that probably is "last thread to release", as anything else is just unreasonable.

My understanding of .NET is that it does GC on a seperate GC thread!  So there you are guaranteed to not get the behaviour (but guaranteed not to get it ever ;-)

Sorry Tim - back at ya!

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2000-09-22 11:52

Message:
Assigned to MarkH, as I want his opinion on this.

I dislike it on principle:  it elevates an accident of refcount semantics into a design goal, and complicates the code to achieve that.

The Microsoft .NET implementation of Python doesn't do refcounting, so not even the pre-trashcan refcount semantics can be relied on there, and I don't want to add to users' difficulties in moving among Python implementations (despite that it may be in my immediate financial interest to lock people into CPython, I'll leave "embrace & extend" to MS <wink>).

If this sounds like a good idea to Mark anyway, fine, but I don't buy it otherwise.

----------------------------------------------------------------------

Comment By: Toby Dickenson (htrd)
Date: 2000-09-22 07:52

Message:
There is a patch to move the trashcan into the thread state. see http://sourceforge.net/patch/?func=detailpatch&patch_id=101606&group_id=5470

This uses PyThreadState_GET() once to avoid the extra function call in the normal path, and only uses the trashcan if the thread state is non NULL. (assuming we are never deleting deeply recursive objects with no thread state)

On performance, this gives me a 2% increase in pystones....


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-09-22 06:30

Message:
It sounds that it will be hard to enforce that __del__ is called in the constructing thread even without the complication of the trashcan code.

Explicitly referencing thread-specific data in a __del__ seems silly -- if the object is tied so closely to the thread, why not add a pointer to the thread to the object.

Nevertheless, especially the COM thing sounds like it would be a good thing to prevent this if it is possible, and your solution (make the trashcan state part of the thread state) sounds reasonable -- except that it means that every deallocation of a tuple, list, dict, frame or traceback needs yet another call to PyThreadState_Get(). And, most disturbing of all, we found before releasing 2.0b1 that there are situations where dictionaries (and possibly other objects) are used when there is no current thread state!!!

Replacing one theoretical problem with another not-so-theoretical one doesn't seem right. Perhaps we could invent a flag that prevents thread-switches while the trashcan dealloc code is running? This could be a simple global boolean that, when set, stops the ceval main loop (and the BEGIN/END ALLOW THREADS macros and related functions!) from ever yielding the interpreter loop. It would almost never be triggered in practice, but guarantee safety in worst cases -- if not efficiency (other threads would be completely blocked until the trashcan code is done).

Back to Tim...

----------------------------------------------------------------------

Comment By: Toby Dickenson (htrd)
Date: 2000-09-22 03:27

Message:
There are two cases that I have in mind:

First is that of a COM client.

It depends on the COM threading model in use, but this problem applies in the most common threading model which is also the default threading model using Mark Hammond's pythoncom.

It is only permitted to access a reference to a COM object from the thread in which it is created. This restiction applies to the Release() method that is used by pythoncom to release its reference to the COM server.


Secondly, it is common to use a dictionary keyed by thread.get_ident() to provide thread-local storage. This is used extensively in Zope. Any application that uses this type of thread-local storage in a __del__ is likely to be broken.




----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-09-22 03:08

Message:
And why, exactly, would it be a problem that the trash is deleted in the 'wrong" thread? It's just trash. Any thread can delete it.

Or am I missing something?

----------------------------------------------------------------------

Comment By: Toby Dickenson (htrd)
Date: 2000-09-22 03:05

Message:
I agree there is no self-consistency problem with the trashcan, however......

The code in _PyTrash_destroy_chain can call an objects __del__ method, which can release the interpreter lock.

A second thread may then reenter _PyTrash_destroy_chain and continue to clean up the first thread's garbage. (the first thread is safely blocked inside the Py_DECREF)

Yes the garbage gets cleaned up, however it happens in the wrong thread.

I suggest that _PyTrash_delete_later should be part of pyThreadState




----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-09-22 02:52

Message:
Agreed that this would be a problem if it could cause an inconsistent state of the trashcan (at the end of object.c) structure. However, since the "trash" code is all executed with the global interpreter lock held, I don't see that there can be a problem. Here's why:

The code in _PyTrash_deposit_object() doesn't make any calls that could invoke __del__, so it's safe. The code in _PyTrash_destroy_chain() makes exactly one call to Py_DECREF(), but it takes care that its global data structures are consistent at this point. For a second I thought that _PyTrash_delete_later would have to be declared volatile, but on second thought I don't: the Py_DECREF() macro expands to a possible (indirect) function call, signaling the compiler that the global _PyTrash_delete_later may be changed in arbitrary ways.

Assigned to Tim Peters to verify my reasoning, because of his superior mind in reasoning about threads and race conditions.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=215076&group_id=5470


From noreply@sourceforge.net  Fri Mar 23 03:09:25 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 22 Mar 2001 19:09:25 -0800
Subject: [Python-bugs-list] [ python-Bugs-409355 ] Meta-class inheritance problem
Message-ID: <E14gHx7-0003TI-00@usw-sf-web2.sourceforge.net>

Bugs item #409355, was updated on 2001-03-17 02:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409355&group_id=5470

Category: Python Interpreter Core
Group: Feature Request
Status: Open
Priority: 7
Submitted By: Lorien Dunn (loriend)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Meta-class inheritance problem

Initial Comment:
I've run into a bug in python 2.0. The real code that
the following pseudo code represents throws a
TypeError.

class MyDerivedClass(MyPurePythonClass,MyBoostClass):
        def __init__(self):
                MyPurePythonClass.__init__(self)
                MyBoostClass.__init__(self)

The problem occurs in MyPurePythonClass- Python says
"unbound method must be called with class instance 1st
argument". This makes sense: I'm passing a meta-class
instead of a class. David Abrahams (the main author of
boost::python) agrees that this is a Python problem,
and that it should affect Zope as well.

I think I've found the point in the python 2.0 sorce
where it occurs:


ceval.c, line 1816 (reformatted for clarity):

/*              BEGIN CODE SAMPLE               */

else
{
/* Unbound methods must be called with an instance of
the class (or a derived class) as first argument */

     if (na > 0 && (self = stack_pointer[-n]) != NULL
                && PyInstance_Check(self)
                && PyClass_IsSubclass((PyObject
*) 		 		   (((PyInstanceObject*)  self)->in_class),
class))
                  /* Handy-dandy */ ;
      else
      {
        PyErr_SetString(PyExc_TypeError, "unbound
method must be 		called with class instance 1st
argument");
        x = NULL;
        break;
      }
}

/*              END CODE SAMPLE         */


----------------------------------------------------------------------

Comment By: David Abrahams (david_abrahams)
Date: 2001-03-22 19:09

Message:
Logged In: YES 
user_id=52572

Though I haven't checked out the latest from CVS, I'm at a 
loss to explain the results Lorien is getting. In 
particular, Boost.Python class instances have a __class__ 
attribute, and Boost.Python classes have a __bases__ 
attribute that is a tuple. Isn't that all that should be 
needed for isinstance() to work properly?...

Aha, now I remember: The first base class in the list 
controls which metaclass object gets control when a derived 
class is created. So the declaration of MyDerivedClass 
below actually creates a regular Python class with a base 
that is a Boost.Python class. At that point, everything is 
beyond my control. To get it to work, at least begin by 
swapping the order of the base classes.

I wonder if it would make sense to always defer to the 
first extension type's type (if any) for subclass creation? 
It's not a general solution (i.e. what if you have multiple 
extension types in the __bases__ tuple?) but at least it 
would handle this case. Surely it's less likely that a 
regular Python class can make any sane use of methods from 
an extension class.

-Dave

----------------------------------------------------------------------

Comment By: Lorien Dunn (loriend)
Date: 2001-03-22 13:58

Message:
Logged In: YES 
user_id=175701

In the following code it returns 0.

MyDerivedClass(MyPurePythonClass, MyBoostClass):
       def __init__(self):
            MyBoostClass.__init__(self)
            isinstance(self, MyPurePythonClass)




----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-22 12:03

Message:
Logged In: YES 
user_id=6380

OK, try this.  In your Python code, what does
isinstance(self, MyPurePythonClass) return?

----------------------------------------------------------------------

Comment By: Lorien Dunn (loriend)
Date: 2001-03-22 11:59

Message:
Logged In: YES 
user_id=175701

I'm afraid it still doesn't work :( 
	the line is (from cvs code):
		ok = PyObject_IsInstance(self, class)
	and the problem is that ok == 0.
Thank you for patching this- I've spent hours trying to
figure out enough about the python internals to do it
myself.

Lorien
	 

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-21 11:18

Message:
Logged In: YES 
user_id=6380

I *think* I've fixed this now -- please test with the
current CVS.

Please let me know if I goofed up, and I'll reopen the bug
report.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-18 14:22

Message:
Logged In: YES 
user_id=6380

Zope has several workarounds, so isn't affected.

But I agree it could be fixed.  The test is there because it wants to enforce a concept: 'self' should be an instance 
of the class that defines the method (where a subclass instance is fine too).

But the implementation of the test is based too much on the default implementation of classes.

Could someone please submit a patch that replaces the concrete isinstance() test with an isinstance() test similar 
to that in bltinmodule.c?  (Maybe we need to add a new C API, PyObject_IsInstance().)

If someone could come up with a check that conve

----------------------------------------------------------------------

Comment By: David Abrahams (david_abrahams)
Date: 2001-03-18 05:30

Message:
Logged In: YES 
user_id=52572

Sorry, that anonymous comment is mine. I'm still a bit 
clumsy with SourceForge.

-Dve

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-03-18 05:03

Message:
Logged In: NO 

I was a bit surprised to learn that this check was still in 
the code after issubclass and isinstance had been fixed to 
work with extension classes. Suppose you checked for a 
__class__ attribute on the first argument instead (or 
additionally)?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-03-17 21:29

Message:
Logged In: YES 
user_id=31435

Assigned to Guido, because I bet JimF would refuse to take 
blame for this <wink>.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409355&group_id=5470


From noreply@sourceforge.net  Fri Mar 23 03:32:05 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 22 Mar 2001 19:32:05 -0800
Subject: [Python-bugs-list] [ python-Bugs-409355 ] Meta-class inheritance problem
Message-ID: <E14gIJ3-0004Y4-00@usw-sf-web3.sourceforge.net>

Bugs item #409355, was updated on 2001-03-17 02:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409355&group_id=5470

Category: Python Interpreter Core
Group: Feature Request
Status: Open
Priority: 7
Submitted By: Lorien Dunn (loriend)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Meta-class inheritance problem

Initial Comment:
I've run into a bug in python 2.0. The real code that
the following pseudo code represents throws a
TypeError.

class MyDerivedClass(MyPurePythonClass,MyBoostClass):
        def __init__(self):
                MyPurePythonClass.__init__(self)
                MyBoostClass.__init__(self)

The problem occurs in MyPurePythonClass- Python says
"unbound method must be called with class instance 1st
argument". This makes sense: I'm passing a meta-class
instead of a class. David Abrahams (the main author of
boost::python) agrees that this is a Python problem,
and that it should affect Zope as well.

I think I've found the point in the python 2.0 sorce
where it occurs:


ceval.c, line 1816 (reformatted for clarity):

/*              BEGIN CODE SAMPLE               */

else
{
/* Unbound methods must be called with an instance of
the class (or a derived class) as first argument */

     if (na > 0 && (self = stack_pointer[-n]) != NULL
                && PyInstance_Check(self)
                && PyClass_IsSubclass((PyObject
*) 		 		   (((PyInstanceObject*)  self)->in_class),
class))
                  /* Handy-dandy */ ;
      else
      {
        PyErr_SetString(PyExc_TypeError, "unbound
method must be 		called with class instance 1st
argument");
        x = NULL;
        break;
      }
}

/*              END CODE SAMPLE         */


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-22 19:32

Message:
Logged In: YES 
user_id=6380

David, I'm not sure I agree with your theory.  At Jim
Fulton's request, when creating a subclass, Python actually
looks through the base classes for one that's not a regular
class, and gives that one control of the subclass creation
process. So MyDerivedClass really should be a Boost.Python
class!  (Lorien can easily verify that by printing
self.__class__.)

Otherwise, if it was a regular class, the __init__ call
woudln't have failed in the first place!

Since I don't have Boost (yet), I can't look into this
further right now, and I fear it will have to remain
unresolved until after the 2.1b2 release.  But I'll try to
look into it again before the final 2.1 release.

----------------------------------------------------------------------

Comment By: David Abrahams (david_abrahams)
Date: 2001-03-22 19:09

Message:
Logged In: YES 
user_id=52572

Though I haven't checked out the latest from CVS, I'm at a 
loss to explain the results Lorien is getting. In 
particular, Boost.Python class instances have a __class__ 
attribute, and Boost.Python classes have a __bases__ 
attribute that is a tuple. Isn't that all that should be 
needed for isinstance() to work properly?...

Aha, now I remember: The first base class in the list 
controls which metaclass object gets control when a derived 
class is created. So the declaration of MyDerivedClass 
below actually creates a regular Python class with a base 
that is a Boost.Python class. At that point, everything is 
beyond my control. To get it to work, at least begin by 
swapping the order of the base classes.

I wonder if it would make sense to always defer to the 
first extension type's type (if any) for subclass creation? 
It's not a general solution (i.e. what if you have multiple 
extension types in the __bases__ tuple?) but at least it 
would handle this case. Surely it's less likely that a 
regular Python class can make any sane use of methods from 
an extension class.

-Dave

----------------------------------------------------------------------

Comment By: Lorien Dunn (loriend)
Date: 2001-03-22 13:58

Message:
Logged In: YES 
user_id=175701

In the following code it returns 0.

MyDerivedClass(MyPurePythonClass, MyBoostClass):
       def __init__(self):
            MyBoostClass.__init__(self)
            isinstance(self, MyPurePythonClass)




----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-22 12:03

Message:
Logged In: YES 
user_id=6380

OK, try this.  In your Python code, what does
isinstance(self, MyPurePythonClass) return?

----------------------------------------------------------------------

Comment By: Lorien Dunn (loriend)
Date: 2001-03-22 11:59

Message:
Logged In: YES 
user_id=175701

I'm afraid it still doesn't work :( 
	the line is (from cvs code):
		ok = PyObject_IsInstance(self, class)
	and the problem is that ok == 0.
Thank you for patching this- I've spent hours trying to
figure out enough about the python internals to do it
myself.

Lorien
	 

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-21 11:18

Message:
Logged In: YES 
user_id=6380

I *think* I've fixed this now -- please test with the
current CVS.

Please let me know if I goofed up, and I'll reopen the bug
report.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-18 14:22

Message:
Logged In: YES 
user_id=6380

Zope has several workarounds, so isn't affected.

But I agree it could be fixed.  The test is there because it wants to enforce a concept: 'self' should be an instance 
of the class that defines the method (where a subclass instance is fine too).

But the implementation of the test is based too much on the default implementation of classes.

Could someone please submit a patch that replaces the concrete isinstance() test with an isinstance() test similar 
to that in bltinmodule.c?  (Maybe we need to add a new C API, PyObject_IsInstance().)

If someone could come up with a check that conve

----------------------------------------------------------------------

Comment By: David Abrahams (david_abrahams)
Date: 2001-03-18 05:30

Message:
Logged In: YES 
user_id=52572

Sorry, that anonymous comment is mine. I'm still a bit 
clumsy with SourceForge.

-Dve

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-03-18 05:03

Message:
Logged In: NO 

I was a bit surprised to learn that this check was still in 
the code after issubclass and isinstance had been fixed to 
work with extension classes. Suppose you checked for a 
__class__ attribute on the first argument instead (or 
additionally)?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-03-17 21:29

Message:
Logged In: YES 
user_id=31435

Assigned to Guido, because I bet JimF would refuse to take 
blame for this <wink>.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409355&group_id=5470


From noreply@sourceforge.net  Fri Mar 23 03:38:18 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 22 Mar 2001 19:38:18 -0800
Subject: [Python-bugs-list] [ python-Bugs-409355 ] Meta-class inheritance problem
Message-ID: <E14gIP4-00049R-00@usw-sf-web1.sourceforge.net>

Bugs item #409355, was updated on 2001-03-17 02:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409355&group_id=5470

Category: Python Interpreter Core
Group: Feature Request
Status: Open
Priority: 7
Submitted By: Lorien Dunn (loriend)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Meta-class inheritance problem

Initial Comment:
I've run into a bug in python 2.0. The real code that
the following pseudo code represents throws a
TypeError.

class MyDerivedClass(MyPurePythonClass,MyBoostClass):
        def __init__(self):
                MyPurePythonClass.__init__(self)
                MyBoostClass.__init__(self)

The problem occurs in MyPurePythonClass- Python says
"unbound method must be called with class instance 1st
argument". This makes sense: I'm passing a meta-class
instead of a class. David Abrahams (the main author of
boost::python) agrees that this is a Python problem,
and that it should affect Zope as well.

I think I've found the point in the python 2.0 sorce
where it occurs:


ceval.c, line 1816 (reformatted for clarity):

/*              BEGIN CODE SAMPLE               */

else
{
/* Unbound methods must be called with an instance of
the class (or a derived class) as first argument */

     if (na > 0 && (self = stack_pointer[-n]) != NULL
                && PyInstance_Check(self)
                && PyClass_IsSubclass((PyObject
*) 		 		   (((PyInstanceObject*)  self)->in_class),
class))
                  /* Handy-dandy */ ;
      else
      {
        PyErr_SetString(PyExc_TypeError, "unbound
method must be 		called with class instance 1st
argument");
        x = NULL;
        break;
      }
}

/*              END CODE SAMPLE         */


----------------------------------------------------------------------

>Comment By: Lorien Dunn (loriend)
Date: 2001-03-22 19:38

Message:
Logged In: YES 
user_id=175701

Guido,
	printing self.__class__ results in the text "<extension
class> MyDerivedClass.MyDerivedClass  at 8121560"

David,
	swapping the order of the base classes makes no difference. 

Thanks.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-22 19:32

Message:
Logged In: YES 
user_id=6380

David, I'm not sure I agree with your theory.  At Jim
Fulton's request, when creating a subclass, Python actually
looks through the base classes for one that's not a regular
class, and gives that one control of the subclass creation
process. So MyDerivedClass really should be a Boost.Python
class!  (Lorien can easily verify that by printing
self.__class__.)

Otherwise, if it was a regular class, the __init__ call
woudln't have failed in the first place!

Since I don't have Boost (yet), I can't look into this
further right now, and I fear it will have to remain
unresolved until after the 2.1b2 release.  But I'll try to
look into it again before the final 2.1 release.

----------------------------------------------------------------------

Comment By: David Abrahams (david_abrahams)
Date: 2001-03-22 19:09

Message:
Logged In: YES 
user_id=52572

Though I haven't checked out the latest from CVS, I'm at a 
loss to explain the results Lorien is getting. In 
particular, Boost.Python class instances have a __class__ 
attribute, and Boost.Python classes have a __bases__ 
attribute that is a tuple. Isn't that all that should be 
needed for isinstance() to work properly?...

Aha, now I remember: The first base class in the list 
controls which metaclass object gets control when a derived 
class is created. So the declaration of MyDerivedClass 
below actually creates a regular Python class with a base 
that is a Boost.Python class. At that point, everything is 
beyond my control. To get it to work, at least begin by 
swapping the order of the base classes.

I wonder if it would make sense to always defer to the 
first extension type's type (if any) for subclass creation? 
It's not a general solution (i.e. what if you have multiple 
extension types in the __bases__ tuple?) but at least it 
would handle this case. Surely it's less likely that a 
regular Python class can make any sane use of methods from 
an extension class.

-Dave

----------------------------------------------------------------------

Comment By: Lorien Dunn (loriend)
Date: 2001-03-22 13:58

Message:
Logged In: YES 
user_id=175701

In the following code it returns 0.

MyDerivedClass(MyPurePythonClass, MyBoostClass):
       def __init__(self):
            MyBoostClass.__init__(self)
            isinstance(self, MyPurePythonClass)




----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-22 12:03

Message:
Logged In: YES 
user_id=6380

OK, try this.  In your Python code, what does
isinstance(self, MyPurePythonClass) return?

----------------------------------------------------------------------

Comment By: Lorien Dunn (loriend)
Date: 2001-03-22 11:59

Message:
Logged In: YES 
user_id=175701

I'm afraid it still doesn't work :( 
	the line is (from cvs code):
		ok = PyObject_IsInstance(self, class)
	and the problem is that ok == 0.
Thank you for patching this- I've spent hours trying to
figure out enough about the python internals to do it
myself.

Lorien
	 

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-21 11:18

Message:
Logged In: YES 
user_id=6380

I *think* I've fixed this now -- please test with the
current CVS.

Please let me know if I goofed up, and I'll reopen the bug
report.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-18 14:22

Message:
Logged In: YES 
user_id=6380

Zope has several workarounds, so isn't affected.

But I agree it could be fixed.  The test is there because it wants to enforce a concept: 'self' should be an instance 
of the class that defines the method (where a subclass instance is fine too).

But the implementation of the test is based too much on the default implementation of classes.

Could someone please submit a patch that replaces the concrete isinstance() test with an isinstance() test similar 
to that in bltinmodule.c?  (Maybe we need to add a new C API, PyObject_IsInstance().)

If someone could come up with a check that conve

----------------------------------------------------------------------

Comment By: David Abrahams (david_abrahams)
Date: 2001-03-18 05:30

Message:
Logged In: YES 
user_id=52572

Sorry, that anonymous comment is mine. I'm still a bit 
clumsy with SourceForge.

-Dve

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-03-18 05:03

Message:
Logged In: NO 

I was a bit surprised to learn that this check was still in 
the code after issubclass and isinstance had been fixed to 
work with extension classes. Suppose you checked for a 
__class__ attribute on the first argument instead (or 
additionally)?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-03-17 21:29

Message:
Logged In: YES 
user_id=31435

Assigned to Guido, because I bet JimF would refuse to take 
blame for this <wink>.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409355&group_id=5470


From noreply@sourceforge.net  Fri Mar 23 05:41:53 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 22 Mar 2001 21:41:53 -0800
Subject: [Python-bugs-list] [ python-Bugs-410708 ] Condition.wait() and KeyboardInterrupt
Message-ID: <E14gKKf-0004ZE-00@usw-sf-web2.sourceforge.net>

Bugs item #410708, was updated on 2001-03-22 21:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410708&group_id=5470

Category: Threads
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Condition.wait() and KeyboardInterrupt

Initial Comment:
>My problem is: Condition.wait() is not protected 
against
>KeyboardInterrupt. Fix is below.
>
>Regards,
>Oleg.
>
>-----------------------------
>#python 2.0, threading.py:
>
>...
>class _Condition(_Verbose):
>...
>    def wait(self, timeout=None):
>...
>        saved_state = self._release_save()
># line to be inserted
>        try:
>...
># line to be inserted
>        finally:
>            self._acquire_restore(saved_state)
>


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410708&group_id=5470


From noreply@sourceforge.net  Fri Mar 23 17:52:34 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 23 Mar 2001 09:52:34 -0800
Subject: [Python-bugs-list] [ python-Bugs-410878 ] Distutils should have a Setup parser
Message-ID: <E14gVjm-0002oG-00@usw-sf-web3.sourceforge.net>

Bugs item #410878, was updated on 2001-03-23 09:52
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410878&group_id=5470

Category: Distutils
Group: Feature Request
Status: Open
Priority: 5
Submitted By: A.M. Kuchling (akuchling)
Assigned to: A.M. Kuchling (akuchling)
Summary: Distutils should have a Setup parser

Initial Comment:
Setup files are handy for allowing user overrides.
I do a minimal parse in Python 2.1's setup.py, and Pete
Shinners wrote a more complete one for pygame's
config.py.  Support for
parsing Setup files should be added to the Distutils
API, so packagers can easily make overrides for 
C extension compile flags.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410878&group_id=5470


From noreply@sourceforge.net  Fri Mar 23 17:53:57 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 23 Mar 2001 09:53:57 -0800
Subject: [Python-bugs-list] [ python-Bugs-406191 ] Mac OS X installation notes
Message-ID: <E14gVl7-0002OE-00@usw-sf-web2.sourceforge.net>

Bugs item #406191, was updated on 2001-03-05 19:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406191&group_id=5470

Category: Installation
Group: Platform-specific
>Status: Closed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Mac OS X installation notes

Initial Comment:
I'm running a very recent Mac OS X build ("4K78"); here is 
what I found necessary in order to get 2.1b1 to build on that 
system.  It might be best to add notes about these things to 
the platform-specific part of the README.

First, though, please correct the spelling in the README
of "Mac OS X" -- the name has *two* spaces in it.  Spelling
it in a way inconsistent with Apple's intent makes it
harder (mac *os *x)  to find out where in the configure/
makefile it's mentioned.

Notes:


 - configure:
  OPT="-g -traditional-cpp"  ./configure --with-suffix=.exe --with-dyld


 - limit stacksize 2m
     (It defaults to a half-meg, and then one of the regular 
expression tests fails.)

 - disable the test_largefile test (I moved its source aside).
     This test should be enabled only on a Unix UFS filesystem.
 
- termios.h tries to define a bunch of things that do not exist 
on Mac OS X.

*** Modules/termios.c   Thu Mar  1 22:50:58 2001
--- ../Python-2.1b1-fixed/Modules/termios.c   Mon Mar  5 
15:43:05 2001
***************
*** 358,364 ****
        {"INLCR", INLCR},
        {"IGNCR", IGNCR},
        {"ICRNL", ICRNL},
!       {"IUCLC", IUCLC},
        {"IXON", IXON},
        {"IXANY", IXANY},
        {"IXOFF", IXOFF},
--- 358,364 ----
        {"INLCR", INLCR},
        {"IGNCR", IGNCR},
        {"ICRNL", ICRNL},
!       /* {"IUCLC", IUCLC}, No such thing on Mac OS X. */
        {"IXON", IXON},
        {"IXANY", IXANY},
        {"IXOFF", IXOFF},
***************
*** 366,405 ****
  
        /* struct termios.c_oflag constants */
        {"OPOST", OPOST},
!       {"OLCUC", OLCUC},
        {"ONLCR", ONLCR},
!       {"OCRNL", OCRNL},
!       {"ONOCR", ONOCR},
!       {"ONLRET", ONLRET},
!       {"OFILL", OFILL},
!       {"OFDEL", OFDEL},
!       {"NLDLY", NLDLY},
!       {"CRDLY", CRDLY},
!       {"TABDLY", TABDLY},
!       {"BSDLY", BSDLY},
!       {"VTDLY", VTDLY},
!       {"FFDLY", FFDLY},
  
        /* struct termios.c_oflag-related values (delay mask) */
!       {"NL0", NL0},
!       {"NL1", NL1},
!       {"CR0", CR0},
!       {"CR1", CR1},
!       {"CR2", CR2},
!       {"CR3", CR3},
!       {"TAB0", TAB0},
!       {"TAB1", TAB1},
!       {"TAB2", TAB2},
!       {"TAB3", TAB3},
  #ifdef XTABS
        {"XTABS", XTABS},
  #endif
!       {"BS0", BS0},
!       {"BS1", BS1},
!       {"VT0", VT0},
!       {"VT1", VT1},
!       {"FF0", FF0},
!       {"FF1", FF1},
  
        /* struct termios.c_cflag constants */
        {"CSIZE", CSIZE},
--- 366,405 ----
  
        /* struct termios.c_oflag constants */
        {"OPOST", OPOST},
!       /* {"OLCUC", OLCUC}, No such thing on Mac OS X. */
        {"ONLCR", ONLCR},
!       /* {"OCRNL", OCRNL}, No such thing on Mac OS X. */
!       /* {"ONOCR", ONOCR}, */
!       /* {"ONLRET", ONLRET}, */
!       /* {"OFILL", OFILL}, */
!       /* {"OFDEL", OFDEL}, */
!       /* {"NLDLY", NLDLY}, */
!       /* {"CRDLY", CRDLY}, */
!       /* {"TABDLY", TABDLY}, */
!       /* {"BSDLY", BSDLY}, */
!       /* {"VTDLY", VTDLY}, */
!       /* {"FFDLY", FFDLY}, */
  
        /* struct termios.c_oflag-related values (delay mask) */
!       /* {"NL0", NL0},
!           {"NL1", NL1},
!           {"CR0", CR0},
!           {"CR1", CR1},
!           {"CR2", CR2},
!           {"CR3", CR3},
!           {"TAB0", TAB0},
!           {"TAB1", TAB1},
!           {"TAB2", TAB2},
!           {"TAB3", TAB3}, */
  #ifdef XTABS
        {"XTABS", XTABS},
  #endif
!       /* {"BS0", BS0},
!          {"BS1", BS1},
!          {"VT0", VT0},
!          {"VT1", VT1},
!          {"FF0", FF0},
!          {"FF1", FF1}, */
  
        /* struct termios.c_cflag constants */
        {"CSIZE", CSIZE},


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-03-23 09:53

Message:
Logged In: YES 
user_id=3066

Added comments about the remaining issues to README revision 1.118.  Marked "Won't Fix" since we have no idea how to fix the remaining aspects of this report.  If anyone figures out how, please open a new bug report or patch and describe in detail what needs to change and how.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-03-17 21:50

Message:
Logged In: YES 
user_id=31435

Assigned to Fred since he replied last.  I'd close it if 
you don't get a response soon.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-03-10 19:18

Message:
Logged In: YES 
user_id=3066

The version of termios in CVS already makes the right tests for all the definitions your patch affects, so the
termios module from CVS should work without further changes.  Please let us know if you have any further problems with termios.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-03-05 23:06

Message:
Logged In: YES 
user_id=21627

Can you produce a patch that does most of this
automatically? Ideally, such a patch would work so that no
other system is affected. E.g. instead of commenting-out
certain constants, an #ifdef would be more desirable.
Likewise, the compiler options are best put into
configure.in, in a way that they are used on all systems
requiring these settings, and ignored on all other systems.
That,of course, requires that a test is introduced to find
out whether you've got the right kind of system.

In addition, I'd prefer if the number of settings needed is
reduced to the absolute minimum. E.g. why is it *necessary*
to compiler Python with -g on Mac OS X? Also, if --with-dyld
is *mandatory* on Mac OS X, why can you specify it as an
option? On all other systems, not using dynamic loading is
not an option. OTOH, if the LDSHARED case of -nostdlib -r
(which you get when you omit --with-dyld) works fine on your
system, why is it necessary to specify --with-dyld.

In short, instead of giving long instructions how to do it
right, I'd prefer if Python configuration did it right on
its own. If you are unsure how to achieve this effect, I
suggest you ask on the pythonmac list. Please upload any
patch you come up with into the patch manager, adding a
comment here that a patch is available.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406191&group_id=5470


From noreply@sourceforge.net  Fri Mar 23 18:09:33 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 23 Mar 2001 10:09:33 -0800
Subject: [Python-bugs-list] [ python-Bugs-404545 ] frozen package import uses wrong files
Message-ID: <E14gW0D-0002XE-00@usw-sf-web2.sourceforge.net>

Bugs item #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: 2
Submitted By: Toby Dickenson (htrd)
Assigned to: Guido van Rossum (gvanrossum)
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.



----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-23 10:09

Message:
Logged In: YES 
user_id=6380

Note, I tried this on Linux, and I couldn't reproduce it.  

What Python version were you using?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-20 11:43

Message:
Logged In: YES 
user_id=6380

I agree this is a bug.

I think there are lots of other ways to break frozen
programs, so I don't think this is a high priority security
bug.

I wish I had more time to research this, but I don't, so
I'll give this a low priority.  If someone submits a patch,
I'd be grateful!

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=404545&group_id=5470


From noreply@sourceforge.net  Fri Mar 23 18:15:38 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 23 Mar 2001 10:15:38 -0800
Subject: [Python-bugs-list] [ python-Bugs-406459 ] nested scopes opcodes not documented
Message-ID: <E14gW66-0002aH-00@usw-sf-web2.sourceforge.net>

Bugs item #406459, was updated on 2001-03-06 13:19
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406459&group_id=5470

Category: Documentation
Group: None
>Status: Closed
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Jeremy Hylton (jhylton)
Summary: nested scopes opcodes not documented

Initial Comment:
As in summary, the description of the opcodes added to
support nested scopes are not documented - and I want
to know how they work!

----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-03-23 10:15

Message:
Logged In: YES 
user_id=31392

terse description added to dis docs

more implementation stuff is deferred to final version of
PEP


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-03-08 07:58

Message:
Logged In: YES 
user_id=3066

Assigned to Jeremy since he knows what the new opcodes are and how things have changed in this arena.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406459&group_id=5470


From noreply@sourceforge.net  Fri Mar 23 18:16:15 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 23 Mar 2001 10:16:15 -0800
Subject: [Python-bugs-list] [ python-Bugs-405341 ] Reminder -- nested scopes TO DO list
Message-ID: <E14gW6h-0002af-00@usw-sf-web2.sourceforge.net>

Bugs item #405341, was updated on 2001-03-01 18:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405341&group_id=5470

Category: Parser/Compiler
Group: None
>Status: Closed
Priority: 6
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Jeremy Hylton (jhylton)
Summary: Reminder -- nested scopes TO DO list

Initial Comment:
Subject: [Python-Dev] nested scopes and future status
From: Jeremy Hylton <jeremy@alum.mit.edu>
To: python-dev@python.org
Date: Thu, 1 Mar 2001 18:34:44 -0500 (EST)

There are several loose ends in the nested scopes
changes that I won't
have time to fix before the beta.  Here's a laundry
list of tasks that
remain.  I don't think any of these is crucial for the
release.
Holler if there's something you'd like me to fix
tonight.

- Integrate the parsing of future statements into the
_symtable
  module's interface.  This interface is new with 2.1
and
  undocumented, so it's deficiency here will not affect
any code.

- Update traceback.py to understand SyntaxErrors that
have a text
  attribute and an offset of None.  It should not print
the caret.

- PyErr_ProgramText() should be called when an
exception is printed
  rather than when it is raised.

- Fix pdb to support nested scopes.

- Produce a better error message/warning for code like
this:
  def f(x):
      def g():
          exec ...
          print x
  The warning message should say that exec is not
allowed in a nested
  function with free variables.  It currently says that
g *contains* a
  nested function with free variables.

- Update the documentation.

Jeremy


----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-03-23 10:16

Message:
Logged In: YES 
user_id=31392

All done except for PyErr_ProgramText90


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-03-21 19:58

Message:
Logged In: YES 
user_id=31392

Only two things left to do:

1. Documentation
2. The PyErr_ProgramText() item (perhaps optional)


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-20 07:47

Message:
Logged In: YES 
user_id=6380

Jeremy, what's up with these?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405341&group_id=5470


From noreply@sourceforge.net  Sat Mar 24 05:39:34 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 23 Mar 2001 21:39:34 -0800
Subject: [Python-bugs-list] [ python-Bugs-410979 ] Python 2.1 breaks py-qt
Message-ID: <E14ggly-0008C5-00@usw-sf-web3.sourceforge.net>

Bugs item #410979, was updated on 2001-03-23 21:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410979&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.1 breaks py-qt

Initial Comment:
Py-Qt, which works fine with Python 2.0, complains 
fails with RuntimeError: Signal has wrong argument 
types for slot under Python 2.1b2 when attempting to 
run any program with QT that uses signals and slots.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410979&group_id=5470


From noreply@sourceforge.net  Sat Mar 24 10:39:46 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 24 Mar 2001 02:39:46 -0800
Subject: [Python-bugs-list] [ python-Bugs-410993 ] linuxaudiodev fails during "make test".
Message-ID: <E14glSU-0001Z1-00@usw-sf-web3.sourceforge.net>

Bugs item #410993, was updated on 2001-03-24 02:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410993&group_id=5470

Category: Python Library
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Sean Reifschneider (jafo)
Assigned to: Nobody/Anonymous (nobody)
Summary: linuxaudiodev fails during "make test".

Initial Comment:
Picked up 2.1b2 and did "./configure" and "make test"
on a RedHat 7.0-based system:

test test_linuxaudiodev crashed -- linuxaudiodev.error:
(11, 'Resource temporarily unavailable')

Was running build as root, and "mpg123" runs
successfully before and after.  This is on a ThinkPad
240 with esssolo1 driver with 2.2.18 kernel.

Sean

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410993&group_id=5470


From noreply@sourceforge.net  Sat Mar 24 16:20:53 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 24 Mar 2001 08:20:53 -0800
Subject: [Python-bugs-list] [ python-Bugs-405837 ] getting PyRun_String() true result
Message-ID: <E14gqmb-0003BQ-00@usw-sf-web1.sourceforge.net>

Bugs item #405837, was updated on 2001-03-04 06:53
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405837&group_id=5470

Category: Python Interpreter Core
Group: Not a Bug
Status: Closed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Guido van Rossum (gvanrossum)
Summary: getting PyRun_String() true result

Initial Comment:
It seems impossible to build am embedded Python
interpreter extension which actually allows getting
the result of the evaluation of a string from the
interpreter, as it is done in interactive mode, as in
the following:
  def f: pass
  f
prints:
  <function f at 0x8069694>

But in C (called twice with the 2 above strings):
  PyRun_String(string, Py_file_input, globals, globals)
returns None.

I found a workaround by patching the core in ceval.c,
eval_code2() (inspired by the PRINT_EXPR case):

...
case POP_TOP:
  v = POP();
PyDict_SetItemString(f->f_globals, "_", v); /* added */
  Py_DECREF(v);
  continue;
...

and then:
  PyRun_String(string, Py_file_input, globals, globals)
  result =PyDict_GetItemString(globals, "_")
returns the '<function f at 0x8069694>' correct result.


My goal is to allow the tclpython extension (at
http://jfontain.free.fr/) to work without having to
insert print statements on the Python side to be able
to pass data to the Tcl interpreter.

Please forgive me if there is an obvious way to do the
above without patching the core, but I am new to Python
(I like it already though :-)

Jean-Luc Fontaine

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-03-24 08:20

Message:
Logged In: NO 

>i = 1
>def foo():
>    return i
>class C:
>    pass
>What should be the result of executing this statement list
>(i.e. suite)? IMO, there is no meaningful result except for
>"success or exception".

True.
But you want to go further than that: actually calling a
function and getting its result, as it is done in
interactive mode.
Let us say that you have a nice library written in Python,
that you want to invoke from C. Once loaded in the embedded
interpreter, how do you get the result of the library Python
functions that you invoke?

Again, that is something that is readily done in other
interpreted languages. But maybe Python is not meant to be
also used as a C extension?

I think my very simple patch demonstrates otherwise, and
furthermore, that Python when run in interactive mode
behaves as I (and I guess most people) expect. For example,
when typing:
  i = 1
  def foo():
      return i
  foo()
one gets 1 as result.

Now if you pass the following C string to an embedded
interpreter:
char *code = "i = 1\ndef foo()\n    return i\nfoo()";
how to you get the result "1"?

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-03-20 13:40

Message:
Logged In: YES 
user_id=21627

What kind of result would you expect from evaluating a
file_input? E.g. given

i = 1
def foo():
  return i
class C:
  pass

What should be the result of executing this statement list
(i.e. suite)? IMO, there is no meaningful result except for
"success or exception".

You may also consider discussing this on
python-list@python.org.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-03-20 13:34

Message:
Logged In: NO 

I agree that this is not a bug per se.
I am puzzled though, that other scripting languages, such as
Perl and Tcl can readily do this.
I still have no answer to my request, so I guess I will try
help@python.org as you recommend.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-20 10:49

Message:
Logged In: YES 
user_id=6380

This is not a bug.   Closing the bug report now.

If you need more help still, wrote help@python.org.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-03-05 10:51

Message:
Logged In: NO 

> To evaluate a string, use Py_RunString with Py_eval_input,
> or perhaps Py_single_input.

Py_eval_input is for "isolated expressions", and
Py_single_input "for a single statement", so how do I
execute whole modules except by using Py_file_input, the
only remaining option?

I actually tested all the above options thoroughly and found
that only Py_file_input did the job, but without a way to
get at the result.

Please let me know whether there is something that I missed,
as I am stuck at the moment. If needed, I will be happy to
send you sample code that illustrates the problem.

Thank you very much for your prompt response.

Jean-Luc

PS: passing "def f(): pass\n" to Py_eval_input returns a
"SyntaxError: invalid syntax"


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-03-04 10:22

Message:
Logged In: YES 
user_id=21627

Sure there is. PyRun_SimpleString executes a string in "file
mode"; this has no result. The interactive interpreter, when
it prints a result, runs the string in "eval mode" - only
evaluation gives a result.

To evaluate a string, use Py_RunString with Py_eval_input,
or perhaps Py_single_input.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405837&group_id=5470


From noreply@sourceforge.net  Sat Mar 24 16:21:43 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 24 Mar 2001 08:21:43 -0800
Subject: [Python-bugs-list] [ python-Bugs-411060 ] pydoc helpe(help) fails
Message-ID: <E14gqnP-0004C5-00@usw-sf-web2.sourceforge.net>

Bugs item #411060, was updated on 2001-03-24 08:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411060&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Emile van Sebille (evansebille)
Assigned to: Nobody/Anonymous (nobody)
Summary: pydoc helpe(help) fails

Initial Comment:
from pydoc import help
help(help)
-->
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "c:\python21\lib\pydoc.py", line 1147, in 
__call__
    doc(args[0])
  File "c:\python21\lib\pydoc.py", line 1106, in doc
    pager('Help on %s:\n\n' % desc + text.document
(thing))
  File "c:\python21\lib\pydoc.py", line 196, in 
document
    return apply(self.docother, args)
  File "c:\python21\lib\pydoc.py", line 895, in 
docother
    line = self.bold(name) + ' = ' + repr
  File "c:\python21\lib\pydoc.py", line 700, in bold
    return join(map(lambda ch: ch + '\b' + ch, 
text), '')
TypeError: argument 2 to map() must be a sequence 
object

---------------------------

by changing Helper in pydoc.py and wrapping calls in 
try/except:

    def __call__(self, *args):
        try:
            doc(args[0])
        except:
            print repr(self)


you get:

>>> help(help)
To get help on a Python object, call help(object).
To get help on a module or package, either import it 
before calling
help(module) or call help('modulename').
>>> 

This is obviously not the place to change it, but it 
did help!  ;-)



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411060&group_id=5470


From noreply@sourceforge.net  Sat Mar 24 16:36:57 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 24 Mar 2001 08:36:57 -0800
Subject: [Python-bugs-list] [ python-Bugs-411063 ] Minor flaws in "Documenting Python"
Message-ID: <E14gr29-00049T-00@usw-sf-web3.sourceforge.net>

Bugs item #411063, was updated on 2001-03-24 08:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411063&group_id=5470

Category: Documentation
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Minor flaws in "Documenting Python"

Initial Comment:
Documenting Python , Section 3.1
3.1 Syntax
	"There are only a things that....

==> Perhaps: a few things?

...
Syntactically, groups are enclosed in braces:

	{text in a group}

An alternative syntax for a group using 
brackets ({...}) is used by...

==> maybe ([...])


...
environment: 
This example shows an environment which takes a single 
required parameter:

	\begin{datadesc}{datadesc}{controlnames}
          A 33-element ....

==> Is the 2nd {datadesc} above needed?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411063&group_id=5470


From noreply@sourceforge.net  Sat Mar 24 16:52:22 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 24 Mar 2001 08:52:22 -0800
Subject: [Python-bugs-list] [ python-Bugs-231207 ] Fatal Python Error during program shutdown
Message-ID: <E14grH4-0003Vv-00@usw-sf-web1.sourceforge.net>

Bugs item #231207, was updated on 2001-02-05 18:50
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=231207&group_id=5470

Category: Tkinter
Group: None
Status: Open
Priority: 5
Submitted By: Doug Henderson (djhender)
Assigned to: Fredrik Lundh (effbot)
Summary: Fatal Python Error during program shutdown

Initial Comment:
The windows builds of versions 2.0 and 2.1a2 contain an intermittent bug which often appears when a script using Tkinter stops by calling self.tk.quit() and sometimes (less often) appears following a <Destroy> event or call to a ?.destory() function.
Under Windows 98SE, this results in a GPF.
Under Windows 2000, a message to the console window shows "Fatal Python Error", "PyEval_RestoreThread NULL tstate".

The following script demonstrates the problem:
---------------------
# BugDemo.py

from Tkinter import *

class BugDemo(Frame):
    def __init__(self, parent):
        Frame.__init__(self, parent)
        Button(self, text='Hi', command=self.hi).pack()
        Button(self, text='Quit', command=self.tk.quit).pack()
    def hi(self):
        print "hi"

bd = BugDemo(Tk())
bd.pack()
bd.mainloop()
----------------------
Execute in console window: "c:> python BugDemo.py"
Test this by 1) clicking Quit button 2) clicking Hi button, then Quit button.
Test 1: The script runs successfully most of the time. I found I had to minimize and restore its window to make it fail regularly.
Test 2: I need to click Hi button before clicking the Quit button. Then it failed about half the time.

The problem appears to occur after the script has completed, during some kind of cleanup perhaps. The more useful error message on the Win2k machine may help to locate the problem.

Problem also manifests using the PythonWare 2.0 release on Win98.

----------------------------------------------------------------------

Comment By: Joel Gould (joelgould)
Date: 2001-03-24 08:52

Message:
Logged In: YES 
user_id=20954

I also see a GPF on shutdown under Windows 98 using 
Tkinter.  I tested this using the PythonWare 2.0 release as 
well.

I have attached a very simple Tkinter program.  When I run 
this on my Windows 98 SE machine, a crash occurs when the 
program exits.  Without the MainDialog class it works OK.  
Without the Pmw initialization call it works OK.  But as 
written it will crash around 75% of the time.

(1) run the program
(2) press the Test Button
(3) click Cancel in the file open dialog (you do not need 
to select a file)
(4) click the close button in the upper right corner
-->  Boom

--------------------

import Tkinter
import tkFileDialog
import Pmw

def action():
    tkFileDialog.askopenfilename(filetypes=[('All','*')])

class MainDialog:
    def __init__(self,parent):
        Tkinter.Button(parent,text='Test 
Button',command=action).pack()

root = Pmw.initialise()
dialog = MainDialog(root)
root.mainloop()

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-02-09 15:34

Message:
Assigned to /F, under the theory he can confirm that "this kind of thing" is still a general problem with Tk we can't do anything about.

----------------------------------------------------------------------

Comment By: Doug Henderson (djhender)
Date: 2001-02-05 21:30

Message:
See also #116289 (and my comment to it) which describes what often happened to my 'real' programs which lead to developing the above BugDemo script. My 'real' programs were developed over the last two years or so, and worked in Jan 2000 with 1.5.2. I upgraded the Python version recently, and then started working on these programs again. It was "WTF is wrong with my code", until I found the same problem showing up in the small test cases.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=231207&group_id=5470


From noreply@sourceforge.net  Sat Mar 24 17:51:43 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 24 Mar 2001 09:51:43 -0800
Subject: [Python-bugs-list] [ python-Bugs-405837 ] getting PyRun_String() true result
Message-ID: <E14gsCV-0004Db-00@usw-sf-web1.sourceforge.net>

Bugs item #405837, was updated on 2001-03-04 06:53
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405837&group_id=5470

Category: Python Interpreter Core
Group: Not a Bug
Status: Closed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Guido van Rossum (gvanrossum)
Summary: getting PyRun_String() true result

Initial Comment:
It seems impossible to build am embedded Python
interpreter extension which actually allows getting
the result of the evaluation of a string from the
interpreter, as it is done in interactive mode, as in
the following:
  def f: pass
  f
prints:
  <function f at 0x8069694>

But in C (called twice with the 2 above strings):
  PyRun_String(string, Py_file_input, globals, globals)
returns None.

I found a workaround by patching the core in ceval.c,
eval_code2() (inspired by the PRINT_EXPR case):

...
case POP_TOP:
  v = POP();
PyDict_SetItemString(f->f_globals, "_", v); /* added */
  Py_DECREF(v);
  continue;
...

and then:
  PyRun_String(string, Py_file_input, globals, globals)
  result =PyDict_GetItemString(globals, "_")
returns the '<function f at 0x8069694>' correct result.


My goal is to allow the tclpython extension (at
http://jfontain.free.fr/) to work without having to
insert print statements on the Python side to be able
to pass data to the Tcl interpreter.

Please forgive me if there is an obvious way to do the
above without patching the core, but I am new to Python
(I like it already though :-)

Jean-Luc Fontaine

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2001-03-24 09:51

Message:
Logged In: YES 
user_id=21627

> But maybe Python is not meant to be also used as a C
extension?

Nonsense. You just have to use it properly.

> Once loaded in the embedded interpreter, how do you get
the 
> result of the library Python functions that you invoke?

You load it using file_input (up to the end of foo), then
you evaluate the expressions (e.g. foo()) using eval_input
(passing the same locals and globals). This is also
(roughly) what the interactive interpreter does (it always
passes the dictionary of __main__).

>  my very simple patch

Which patch?

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-03-24 08:20

Message:
Logged In: NO 

>i = 1
>def foo():
>    return i
>class C:
>    pass
>What should be the result of executing this statement list
>(i.e. suite)? IMO, there is no meaningful result except for
>"success or exception".

True.
But you want to go further than that: actually calling a
function and getting its result, as it is done in
interactive mode.
Let us say that you have a nice library written in Python,
that you want to invoke from C. Once loaded in the embedded
interpreter, how do you get the result of the library Python
functions that you invoke?

Again, that is something that is readily done in other
interpreted languages. But maybe Python is not meant to be
also used as a C extension?

I think my very simple patch demonstrates otherwise, and
furthermore, that Python when run in interactive mode
behaves as I (and I guess most people) expect. For example,
when typing:
  i = 1
  def foo():
      return i
  foo()
one gets 1 as result.

Now if you pass the following C string to an embedded
interpreter:
char *code = "i = 1\ndef foo()\n    return i\nfoo()";
how to you get the result "1"?

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-03-20 13:40

Message:
Logged In: YES 
user_id=21627

What kind of result would you expect from evaluating a
file_input? E.g. given

i = 1
def foo():
  return i
class C:
  pass

What should be the result of executing this statement list
(i.e. suite)? IMO, there is no meaningful result except for
"success or exception".

You may also consider discussing this on
python-list@python.org.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-03-20 13:34

Message:
Logged In: NO 

I agree that this is not a bug per se.
I am puzzled though, that other scripting languages, such as
Perl and Tcl can readily do this.
I still have no answer to my request, so I guess I will try
help@python.org as you recommend.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-20 10:49

Message:
Logged In: YES 
user_id=6380

This is not a bug.   Closing the bug report now.

If you need more help still, wrote help@python.org.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-03-05 10:51

Message:
Logged In: NO 

> To evaluate a string, use Py_RunString with Py_eval_input,
> or perhaps Py_single_input.

Py_eval_input is for "isolated expressions", and
Py_single_input "for a single statement", so how do I
execute whole modules except by using Py_file_input, the
only remaining option?

I actually tested all the above options thoroughly and found
that only Py_file_input did the job, but without a way to
get at the result.

Please let me know whether there is something that I missed,
as I am stuck at the moment. If needed, I will be happy to
send you sample code that illustrates the problem.

Thank you very much for your prompt response.

Jean-Luc

PS: passing "def f(): pass\n" to Py_eval_input returns a
"SyntaxError: invalid syntax"


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-03-04 10:22

Message:
Logged In: YES 
user_id=21627

Sure there is. PyRun_SimpleString executes a string in "file
mode"; this has no result. The interactive interpreter, when
it prints a result, runs the string in "eval mode" - only
evaluation gives a result.

To evaluate a string, use Py_RunString with Py_eval_input,
or perhaps Py_single_input.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405837&group_id=5470


From noreply@sourceforge.net  Sun Mar 25 00:38:46 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 24 Mar 2001 16:38:46 -0800
Subject: [Python-bugs-list] [ python-Bugs-411118 ] Typo in Python Reference Manual
Message-ID: <E14gyYQ-0007fJ-00@usw-sf-web3.sourceforge.net>

Bugs item #411118, was updated on 2001-03-24 16:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411118&group_id=5470

Category: Documentation
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Typo in Python Reference Manual

Initial Comment:
Python Reference Manual, Release 2.1 beta 2,  
updated on March 23, 2001.

Section: A.3.1 Definitions and rules

The letter "v" is missing in:

"(The ariables of the module code block are local 
and global.)"



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411118&group_id=5470


From noreply@sourceforge.net  Sun Mar 25 05:42:56 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 24 Mar 2001 21:42:56 -0800
Subject: [Python-bugs-list] [ python-Bugs-411127 ] README file for Unix not up to date
Message-ID: <E14h3Im-00018p-00@usw-sf-web2.sourceforge.net>

Bugs item #411127, was updated on 2001-03-24 21:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411127&group_id=5470

Category: Documentation
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: README file for Unix not up to date

Initial Comment:
The README file instructions for building Python 
suggest editing the Modules/Setup directory to select
the modules to be built.  The new build process 
automatically builds some of the modules.  Is there a
reason for leaving the modules in Setup if they are
built automatically?

Perhaps the introductory paragraph or README should
mention the distutil build process.

With the rework of the build process is the 
instructions for using VPATH still valid?



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411127&group_id=5470


From noreply@sourceforge.net  Sun Mar 25 08:31:47 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 25 Mar 2001 00:31:47 -0800
Subject: [Python-bugs-list] [ python-Bugs-231774 ] Architecture-specific config.h is badly named
Message-ID: <E14h5wB-0002Jx-00@usw-sf-web2.sourceforge.net>

Bugs item #231774, was updated on 2001-02-09 13:57
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=231774&group_id=5470

Category: Build
Group: Feature Request
Status: Open
Priority: 5
Submitted By: Gilbert Ramirez (gramirez)
Assigned to: Thomas Wouters (twouters)
Summary: Architecture-specific config.h is badly named

Initial Comment:
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"



----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2001-03-25 00:31

Message:
Logged In: YES 
user_id=21627

A fix for that problem has been submitted as
http://sourceforge.net/tracker/index.php?func=detail&aid=411138&group_id=5470&atid=305470

----------------------------------------------------------------------

Comment By: Thomas Wouters (twouters)
Date: 2001-02-15 03:31

Message:
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. 


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-02-09 16:03

Message:
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>.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-02-09 14:10

Message:
Good idea!  Patch anybody?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=231774&group_id=5470


From noreply@sourceforge.net  Sun Mar 25 08:37:10 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 25 Mar 2001 00:37:10 -0800
Subject: [Python-bugs-list] [ python-Bugs-231774 ] Architecture-specific config.h is badly named
Message-ID: <E14h61O-0002MF-00@usw-sf-web2.sourceforge.net>

Bugs item #231774, was updated on 2001-02-09 13:57
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=231774&group_id=5470

Category: Build
Group: Feature Request
Status: Open
Priority: 5
Submitted By: Gilbert Ramirez (gramirez)
Assigned to: Thomas Wouters (twouters)
Summary: Architecture-specific config.h is badly named

Initial Comment:
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"



----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2001-03-25 00:37

Message:
Logged In: YES 
user_id=21627

As for legitimately including config.h: it is normally
included indirectly, as a result of
AC_CHECK_HEADER(Python.h) or the like. configure will add it
the project's config.h, which might confuse the further
configuration process or have arbitrary other strange
effects.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-03-25 00:31

Message:
Logged In: YES 
user_id=21627

A fix for that problem has been submitted as
http://sourceforge.net/tracker/index.php?func=detail&aid=411138&group_id=5470&atid=305470

----------------------------------------------------------------------

Comment By: Thomas Wouters (twouters)
Date: 2001-02-15 03:31

Message:
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. 


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-02-09 16:03

Message:
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>.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-02-09 14:10

Message:
Good idea!  Patch anybody?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=231774&group_id=5470


From noreply@sourceforge.net  Sun Mar 25 20:11:55 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 25 Mar 2001 12:11:55 -0800
Subject: [Python-bugs-list] [ python-Bugs-231222 ] Python-2.1a2: HP make continiously runs the configure script
Message-ID: <E14hGrj-0000Ap-00@usw-sf-web2.sourceforge.net>

Bugs item #231222, was updated on 2001-02-05 23:50
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=231222&group_id=5470

Category: Build
Group: None
>Status: Closed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Neil Schemenauer (nascheme)
Summary: Python-2.1a2: HP make continiously runs the configure script

Initial Comment:
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++

....


----------------------------------------------------------------------

>Comment By: Neil Schemenauer (nascheme)
Date: 2001-03-25 12:11

Message:
Logged In: YES 
user_id=35752

Patch 405792 has been checked in so this bug should be
fixed.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2001-03-21 15:50

Message:
Logged In: YES 
user_id=35752

I think patch 405792 will fix this bug.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2001-02-10 13:07

Message:
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.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2001-02-08 09:22

Message:
Reassigning to Neil, and reclassifying as a build problem.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=231222&group_id=5470


From noreply@sourceforge.net  Mon Mar 26 02:55:11 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 25 Mar 2001 18:55:11 -0800
Subject: [Python-bugs-list] [ python-Bugs-408085 ] urllib.py https redirect-302 bug
Message-ID: <E14hN9z-0002Nk-00@usw-sf-web3.sourceforge.net>

Bugs item #408085, was updated on 2001-03-12 17:05
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408085&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Dustin Boswell (boswell)
Assigned to: Moshe Zadka (moshez)
Summary: urllib.py https redirect-302 bug

Initial Comment:
Using urllib.urlopen("https://...") seems 
to hang because of a redirect problem. Looks 
like its trying to follow the redirect with 
http not https. 

>>> import urllib 
>>> params = ... 
>>> f = urllib.urlopen("https://...", params) 
connect: (securesite.com, 80) 
#a printout from httplib, line 354 

Traceback (most recent call last): 
File "<stdin>", line 1, in ? 
File "/usr/local/lib/python2.0/urllib.py", line 63, in
urlopen 
return _urlopener.open(url, data) 
File "/usr/local/lib/python2.0/urllib.py", line 168, in
open 
return getattr(self, name)(url, data) 
File "/usr/local/lib/python2.0/urllib.py", line 367, in
open_https 
data) 
File "/usr/local/lib/python2.0/urllib.py", line 301, in
http_error 
result = method(url, fp, errcode, errmsg, headers,
data) 
File "/usr/local/lib/python2.0/urllib.py", line 537, in
http_error_302 
return self.open(newurl, data) 
File "/usr/local/lib/python2.0/urllib.py", line 168, in
open 
return getattr(self, name)(url, data) 
File "/usr/local/lib/python2.0/urllib.py", line 269, in
open_http 
h.putrequest('POST', selector) 
File "/usr/local/lib/python2.0/httplib.py", line 428,
in putrequest 
self.send(str) 
File "/usr/local/lib/python2.0/httplib.py", line 370,
in send 
self.connect() 
File "/usr/local/lib/python2.0/httplib.py", line 354,
in connect 
self.sock.connect((self.host, self.port)) 
KeyboardInterrupt 
>>> 

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-03-25 18:55

Message:
Logged In: NO 

the location header must be an absolute uri
(rfc2616 section 14.30 and rfc1945 10.11).

----------------------------------------------------------------------

Comment By: Dustin Boswell (boswell)
Date: 2001-03-19 05:12

Message:
Logged In: YES 
user_id=153527

The server is https://trading.etrade.com

Unless you have an account there to try it yourself,
there's not much else specific information I can give you.

I know for sure that the redirection is to another
https url.  The "Location" header is actually a relative
one, which is where the bug in urllib.py is.  The problem
is that when open_https is called, if an error is
encountered, it calls http_error, which assumes the
url was an http, and so when a relative url is encountered,
just prepends a http:// to the front.  I can't think
of an elegant fix to this.  Maybe when http_error realizes
it's a relative location, it should prepend "proto" (some
argument to the function that doesn't exist yet) and
prepend THAT one to it...

def open_https(self, url, data=None):
  if errcode == 200:
     return addinfourl(fp, headers, url)
  else:
     if data is None:
        return self.http_error(url, fp, errcode, errmsg,
headers)
     else:
        return self.http_error(url, fp, errcode, errmsg,
headers, data)

... and here's the function called after the error is
realized...

  def http_error_302(self, url, fp, errcode, errmsg,
headers, data=None):
        """Error 302 -- relocated (temporarily)."""
        ######Here's the problem#############
        # In case the server sent a relative URL, join with
original:
        newurl = basejoin("http:" + url, newurl)
	#uh, what if it isn't http? we seem to have lost that
information...
        if data is None:
            return self.open(newurl)
        else:
            return self.open(newurl, data)

I originally was developing my project in JAVA and
had it working, but was realizing that I was re-inventing
the wheel (i.e. redirection handling). So I switched to
Python (for other reasons too).  But I went back and
placed a POST instead of GET in the redirection handling
and everything still worked, so as for the possible GET vs.
POST redirect server bug, it wasn't that (although that's
very interesting to know...).

Am I making any sense?

----------------------------------------------------------------------

Comment By: Moshe Zadka (moshez)
Date: 2001-03-18 01:13

Message:
Logged In: YES 
user_id=11645

Errr....I'm not sure I see the bug. Perhaps the "Location"
header actually contained an "http://" URL? If you can give
me the site or more information (like a printout of newurl),
I can probably be of more help.

In testing (sadly, against a server inside a firewall, so I
cannot give the URL) I have found that it seems to work.

One thing, that may or may not have to do with your problem:
when POSTing, a 302 means "POST to that other URL", not
"GET that other URL". Many webserver writers seem to ignore
this, and many browsers compensate for that server bug.
urllib2 does *not* compensate for that bug -- I haven't
thought through whether *that* may be the explanation.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408085&group_id=5470


From noreply@sourceforge.net  Mon Mar 26 03:31:43 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 25 Mar 2001 19:31:43 -0800
Subject: [Python-bugs-list] [ python-Bugs-411267 ] s.encode('latin-1') passes non-latin-1 c
Message-ID: <E14hNjL-0003PM-00@usw-sf-web2.sourceforge.net>

Bugs item #411267, was updated on 2001-03-25 19:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411267&group_id=5470

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: s.encode('latin-1') passes non-latin-1 c

Initial Comment:
>>> u'\x81'.encode('latin-1')
'\201'

this should probably raise an exception.

  -- erno@iki.fi



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411267&group_id=5470


From noreply@sourceforge.net  Mon Mar 26 09:14:35 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 26 Mar 2001 01:14:35 -0800
Subject: [Python-bugs-list] [ python-Bugs-411267 ] s.encode('latin-1') passes non-latin-1 c
Message-ID: <E14hT59-00058i-00@usw-sf-web3.sourceforge.net>

Bugs item #411267, was updated on 2001-03-25 19:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411267&group_id=5470

>Category: Unicode
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: M.-A. Lemburg (lemburg)
Summary: s.encode('latin-1') passes non-latin-1 c

Initial Comment:
>>> u'\x81'.encode('latin-1')
'\201'

this should probably raise an exception.

  -- erno@iki.fi



----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2001-03-26 01:14

Message:
Logged In: YES 
user_id=38388

u'\x81' is a perfectly valid Latin-1 character, in fact, the
first
256 Unicode characters are the Latin-1 characters.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411267&group_id=5470


From noreply@sourceforge.net  Mon Mar 26 14:38:16 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 26 Mar 2001 06:38:16 -0800
Subject: [Python-bugs-list] [ python-Bugs-411374 ] [Irix] SIGINT causes crash
Message-ID: <E14hY8O-0008SP-00@usw-sf-web1.sourceforge.net>

Bugs item #411374, was updated on 2001-03-26 06:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411374&group_id=5470

Category: Python Interpreter Core
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: [Irix] SIGINT causes crash

Initial Comment:
python version 2.1b2
on Irix 6.5.8f:

dumps core on a segfault when SIGINT is sent to the
process, either by keystroke or using the kill command.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411374&group_id=5470


From noreply@sourceforge.net  Mon Mar 26 15:50:05 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 26 Mar 2001 07:50:05 -0800
Subject: [Python-bugs-list] [ python-Bugs-411267 ] s.encode('latin-1') passes non-latin-1 c
Message-ID: <E14hZFt-0008Jw-00@usw-sf-web3.sourceforge.net>

Bugs item #411267, was updated on 2001-03-25 19:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411267&group_id=5470

Category: Unicode
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: M.-A. Lemburg (lemburg)
Summary: s.encode('latin-1') passes non-latin-1 c

Initial Comment:
>>> u'\x81'.encode('latin-1')
'\201'

this should probably raise an exception.

  -- erno@iki.fi



----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-03-26 07:50

Message:
Logged In: NO 

every reference i can find on the web (and my linux
latin1(7) manual page) says they are 160-255...?

i think the reason for 128-159 characters not being used
might be that with the high bit stripped off they would be
ascii control characters and not printable.

  -- erno


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-03-26 01:14

Message:
Logged In: YES 
user_id=38388

u'\x81' is a perfectly valid Latin-1 character, in fact, the
first
256 Unicode characters are the Latin-1 characters.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411267&group_id=5470


From noreply@sourceforge.net  Mon Mar 26 16:16:43 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 26 Mar 2001 08:16:43 -0800
Subject: [Python-bugs-list] [ python-Bugs-411267 ] s.encode('latin-1') passes non-latin-1 c
Message-ID: <E14hZff-00008R-00@usw-sf-web3.sourceforge.net>

Bugs item #411267, was updated on 2001-03-25 19:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411267&group_id=5470

Category: Unicode
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: M.-A. Lemburg (lemburg)
Summary: s.encode('latin-1') passes non-latin-1 c

Initial Comment:
>>> u'\x81'.encode('latin-1')
'\201'

this should probably raise an exception.

  -- erno@iki.fi



----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-03-26 08:16

Message:
Logged In: NO 

http://www.unicode.org/charts/PDF/U0080.pdf
shows 0080-009f in unicode being something called "c1
controls" and 00a0-00ff being iso-8859-1 aka latin-1.

  -- erno


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-03-26 07:50

Message:
Logged In: NO 

every reference i can find on the web (and my linux
latin1(7) manual page) says they are 160-255...?

i think the reason for 128-159 characters not being used
might be that with the high bit stripped off they would be
ascii control characters and not printable.

  -- erno


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-03-26 01:14

Message:
Logged In: YES 
user_id=38388

u'\x81' is a perfectly valid Latin-1 character, in fact, the
first
256 Unicode characters are the Latin-1 characters.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411267&group_id=5470


From noreply@sourceforge.net  Mon Mar 26 19:54:35 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 26 Mar 2001 11:54:35 -0800
Subject: [Python-bugs-list] [ python-Bugs-410274 ] sys.prefix isn't always set
Message-ID: <E14hd4V-0002zS-00@usw-sf-web2.sourceforge.net>

Bugs item #410274, was updated on 2001-03-21 01:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410274&group_id=5470

Category: Python Interpreter Core
Group: Platform-specific
Status: Open
Priority: 6
Submitted By: Fredrik Lundh (effbot)
Assigned to: Mark Hammond (mhammond)
Summary: sys.prefix isn't always set

Initial Comment:
(2.0 and earlier, Windows only)

it looks like sys.prefix isn't set unless

1) PYTHONHOME is set (either via an environment 
variable, or via a call to Py_SetPythonHome), or

2) lib/os.py (or lib/string.py, in 1.5.2) can be found 
somewhere between the directory your executable is 
found in, and the root.

if neither is set, the path is taken from the 
registry, but sys.prefix is left blank, and code 
depending on sys.prefix (e.g. FixTk.py) no longer 
works.

</F>


----------------------------------------------------------------------

>Comment By: Fredrik Lundh (effbot)
Date: 2001-03-26 11:54

Message:
Logged In: YES 
user_id=38376

InstallPath?

(I'd deprecate InstallPath, teach the installers to
use PythonHome as a fallback, and use PythonHome for
this purpose.  but that's me)

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2001-03-21 13:44

Message:
Logged In: YES 
user_id=14198

The main problem here is exactly how to detect it.

If the executable is not in the Python directory there are 
no reasonable hints.  The DLL is always in the system 
directory.  The core path entries may not may not be in the 
home.

But 228685 depends on this too.

The only solution I can come up with is to use the core 
sys.path entries, and one at a time try and see if the root 
could be the parent of one of them.  Any other ideas?  I 
would prefer to not assume another registry entry is 
written by installers.

I will try and write registry docs soon, but this isn't 
really relevant - I agree that sys.prefix should always be 
set, but just not sure how.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-03-21 10:19

Message:
Logged In: YES 
user_id=31435

Boosted priority a notch.  Mark, is this intentional or a 
bug?  You're a bit overdue in writing up the intended rules 
for Windows, and I'm very reluctant to go changing things 
like this myself in the absence of clarity.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410274&group_id=5470


From noreply@sourceforge.net  Mon Mar 26 22:33:34 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 26 Mar 2001 14:33:34 -0800
Subject: [Python-bugs-list] [ python-Bugs-411060 ] pydoc helpe(help) fails
Message-ID: <E14hfYM-0005ra-00@usw-sf-web1.sourceforge.net>

Bugs item #411060, was updated on 2001-03-24 08:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411060&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Emile van Sebille (evansebille)
>Assigned to: Ka-Ping Yee (ping)
Summary: pydoc helpe(help) fails

Initial Comment:
from pydoc import help
help(help)
-->
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "c:\python21\lib\pydoc.py", line 1147, in 
__call__
    doc(args[0])
  File "c:\python21\lib\pydoc.py", line 1106, in doc
    pager('Help on %s:\n\n' % desc + text.document
(thing))
  File "c:\python21\lib\pydoc.py", line 196, in 
document
    return apply(self.docother, args)
  File "c:\python21\lib\pydoc.py", line 895, in 
docother
    line = self.bold(name) + ' = ' + repr
  File "c:\python21\lib\pydoc.py", line 700, in bold
    return join(map(lambda ch: ch + '\b' + ch, 
text), '')
TypeError: argument 2 to map() must be a sequence 
object

---------------------------

by changing Helper in pydoc.py and wrapping calls in 
try/except:

    def __call__(self, *args):
        try:
            doc(args[0])
        except:
            print repr(self)


you get:

>>> help(help)
To get help on a Python object, call help(object).
To get help on a module or package, either import it 
before calling
help(module) or call help('modulename').
>>> 

This is obviously not the place to change it, but it 
did help!  ;-)



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411060&group_id=5470


From noreply@sourceforge.net  Mon Mar 26 22:35:08 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 26 Mar 2001 14:35:08 -0800
Subject: [Python-bugs-list] [ python-Bugs-411374 ] [Irix] SIGINT causes crash
Message-ID: <E14hfZs-0004Vp-00@usw-sf-web2.sourceforge.net>

Bugs item #411374, was updated on 2001-03-26 06:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411374&group_id=5470

Category: Python Interpreter Core
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Sjoerd Mullender (sjoerd)
Summary: [Irix] SIGINT causes crash

Initial Comment:
python version 2.1b2
on Irix 6.5.8f:

dumps core on a segfault when SIGINT is sent to the
process, either by keystroke or using the kill command.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411374&group_id=5470


From noreply@sourceforge.net  Mon Mar 26 22:35:52 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 26 Mar 2001 14:35:52 -0800
Subject: [Python-bugs-list] [ python-Bugs-410979 ] Python 2.1 breaks py-qt
Message-ID: <E14hfaa-0003P4-00@usw-sf-web3.sourceforge.net>

Bugs item #410979, was updated on 2001-03-23 21:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410979&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Python 2.1 breaks py-qt

Initial Comment:
Py-Qt, which works fine with Python 2.0, complains 
fails with RuntimeError: Signal has wrong argument 
types for slot under Python 2.1b2 when attempting to 
run any program with QT that uses signals and slots.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410979&group_id=5470


From noreply@sourceforge.net  Mon Mar 26 22:36:20 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 26 Mar 2001 14:36:20 -0800
Subject: [Python-bugs-list] [ python-Bugs-410993 ] linuxaudiodev fails during "make test".
Message-ID: <E14hfb2-0005tl-00@usw-sf-web1.sourceforge.net>

Bugs item #410993, was updated on 2001-03-24 02:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410993&group_id=5470

Category: Python Library
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Sean Reifschneider (jafo)
>Assigned to: Jeremy Hylton (jhylton)
>Summary: linuxaudiodev fails during "make test".

Initial Comment:
Picked up 2.1b2 and did "./configure" and "make test"
on a RedHat 7.0-based system:

test test_linuxaudiodev crashed -- linuxaudiodev.error:
(11, 'Resource temporarily unavailable')

Was running build as root, and "mpg123" runs
successfully before and after.  This is on a ThinkPad
240 with esssolo1 driver with 2.2.18 kernel.

Sean

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410993&group_id=5470


From noreply@sourceforge.net  Mon Mar 26 22:36:40 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 26 Mar 2001 14:36:40 -0800
Subject: [Python-bugs-list] [ python-Bugs-410708 ] Condition.wait() and KeyboardInterrupt
Message-ID: <E14hfbM-0004WN-00@usw-sf-web2.sourceforge.net>

Bugs item #410708, was updated on 2001-03-22 21:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410708&group_id=5470

Category: Threads
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Tim Peters (tim_one)
Summary: Condition.wait() and KeyboardInterrupt

Initial Comment:
>My problem is: Condition.wait() is not protected 
against
>KeyboardInterrupt. Fix is below.
>
>Regards,
>Oleg.
>
>-----------------------------
>#python 2.0, threading.py:
>
>...
>class _Condition(_Verbose):
>...
>    def wait(self, timeout=None):
>...
>        saved_state = self._release_save()
># line to be inserted
>        try:
>...
># line to be inserted
>        finally:
>            self._acquire_restore(saved_state)
>


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410708&group_id=5470


From noreply@sourceforge.net  Mon Mar 26 23:37:52 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 26 Mar 2001 15:37:52 -0800
Subject: [Python-bugs-list] [ python-Bugs-410164 ] pydoc can't find module in current dir
Message-ID: <E14hgYa-0003v4-00@usw-sf-web3.sourceforge.net>

Bugs item #410164, was updated on 2001-03-20 13:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410164&group_id=5470

Category: demos and tools
Group: Feature Request
>Status: Closed
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Ka-Ping Yee (ping)
Summary: pydoc can't find module in current dir

Initial Comment:
On my linux system pydoc doesn't seem able to find
modules in the current directory unless I set the
PYTHONPATH environment variable, including ".":

    % pydoc OO_Model
    No Python documentation found for 'OO_Model'.
    beluga:lib% PYTHONPATH=. pydoc OO_Model

    Python Library Documentation: module OO_Model
    ...

I examined the output of pydoc.pathdirs().  Even
without setting PYTHONPATH the directory containing the
OO_Model module is in the output (second directory):

    % python
    Python 2.1b1 (#1, Mar 12 2001, 16:13:37) 
    [GCC 2.95.3 19991030 (prerelease)] on linux2
    Type "copyright", "credits" or "license" for more
    information.
    >>> import pydoc
    >>> pydoc.pathdirs()
    ['/usr/local/lib/automatrix/python',
     '/home/skip/src/tttech/lib',
     '/usr/local/lib/python2.1',
     '/usr/local/lib/python2.1/plat-linux2',
     '/usr/local/lib/python2.1/lib-tk',
     '/usr/local/lib/python2.1/lib-dynload',
     '/usr/local/lib/python2.1/site-packages',
     '/home/skip/src/Zope/lib/python']

Seems like a bug to me.



----------------------------------------------------------------------

>Comment By: Ka-Ping Yee (ping)
Date: 2001-03-26 15:37

Message:
Logged In: YES 
user_id=45338

Python itself is inconsistent in this regard (as Fred
rightly points out).  For now, the pydoc that made it
into 2.1b2 adds '.' to the path when run as a script;
in future it should probably also *remove* the script
directory from sys.path (when the script directory is
not the same as the current dir) for good consistency
with running python and importing pydoc interactively.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-03-20 22:00

Message:
Logged In: YES 
user_id=3066

This ia a pydoc issue; sys.path for a script includes the
script dir but not (necessarily) the current dir.

Assigned to Ping.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410164&group_id=5470


From noreply@sourceforge.net  Mon Mar 26 23:41:07 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 26 Mar 2001 15:41:07 -0800
Subject: [Python-bugs-list] [ python-Bugs-408958 ] pydoc fails on exceptions.html (win2K)
Message-ID: <E14hgbj-0003ws-00@usw-sf-web3.sourceforge.net>

Bugs item #408958, was updated on 2001-03-15 15:13
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408958&group_id=5470

Category: Python Library
Group: Platform-specific
>Status: Closed
Priority: 5
Submitted By: Hernan Martinez Foffani (hfoffani)
Assigned to: Ka-Ping Yee (ping)
Summary: pydoc fails on exceptions.html (win2K)

Initial Comment:
Pydoc fails to show exceptions.html
Windows 2000, python 2.1b1
(FYI, I've got python 2.0 installed on the same 
machine)


----------------------------------------------------------------------

>Comment By: Ka-Ping Yee (ping)
Date: 2001-03-26 15:41

Message:
Logged In: YES 
user_id=45338

Fixed in 2.1b2, released last Friday.

Thanks!

----------------------------------------------------------------------

Comment By: Hernan Martinez Foffani (hfoffani)
Date: 2001-03-19 02:01

Message:
Logged In: YES 
user_id=112690

These messages, that i grab when trying to access to 
exceptions.html, may help (both in python 2.1b1 and python 
2.0):


C:\Python20\Lib>python pydoc.py
----------------------------------------
Exception happened during processing of request from 
('127.0.0.1', 1642)
Traceback (most recent call last):
  File "c:\python20\lib\SocketServer.py", line 221, in 
handle_request
    self.process_request(request, client_address)
  File "c:\python20\lib\SocketServer.py", line 247, in 
process_request
    self.finish_request(request, client_address)
  File "c:\python20\lib\SocketServer.py", line 251, in 
finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "c:\python20\lib\SocketServer.py", line 385, in 
__init__
    self.handle()
  File "c:\python20\lib\BaseHTTPServer.py", line 266, in 
handle
    method()
  File "pydoc.py", line 1116, in do_GET
    p, x = locate(path)
  File "pydoc.py", line 927, in locate
    filename = sys.modules[path].__file__
AttributeError: __file__
----------------------------------------


C:\Python21\Lib>python
Python 2.1b1 (#11, Mar  2 2001, 11:23:29) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
>>> ^Z


C:\Python21\Lib>python pydoc.py
----------------------------------------
Exception happened during processing of request from 
('127.0.0.1', 1651)
Traceback (most recent call last):
  File "c:\python21\lib\SocketServer.py", line 214, in 
handle_request
    self.process_request(request, client_address)
  File "c:\python21\lib\SocketServer.py", line 232, in 
process_request
    self.finish_request(request, client_address)
  File "c:\python21\lib\SocketServer.py", line 244, in 
finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "c:\python21\lib\SocketServer.py", line 481, in 
__init__
    self.handle()
  File "c:\python21\lib\BaseHTTPServer.py", line 266, in 
handle
    method()
  File "pydoc.py", line 1112, in do_GET
    p, x = locate(path)
  File "pydoc.py", line 923, in locate
    filename = sys.modules[path].__file__
AttributeError: 'exceptions' module has no 
attribute '__file__'
----------------------------------------



----------------------------------------------------------------------

Comment By: Hernan Martinez Foffani (hfoffani)
Date: 2001-03-19 01:50

Message:
Logged In: YES 
user_id=112690

These messages, that i grab when trying to access to 
exceptions.html, may help (both in python 2.1b1 and python 
2.0):


C:\Python20\Lib>python pydoc.py
----------------------------------------
Exception happened during processing of request from 
('127.0.0.1', 1642)
Traceback (most recent call last):
  File "c:\python20\lib\SocketServer.py", line 221, in 
handle_request
    self.process_request(request, client_address)
  File "c:\python20\lib\SocketServer.py", line 247, in 
process_request
    self.finish_request(request, client_address)
  File "c:\python20\lib\SocketServer.py", line 251, in 
finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "c:\python20\lib\SocketServer.py", line 385, in 
__init__
    self.handle()
  File "c:\python20\lib\BaseHTTPServer.py", line 266, in 
handle
    method()
  File "pydoc.py", line 1116, in do_GET
    p, x = locate(path)
  File "pydoc.py", line 927, in locate
    filename = sys.modules[path].__file__
AttributeError: __file__
----------------------------------------


C:\Python21\Lib>python
Python 2.1b1 (#11, Mar  2 2001, 11:23:29) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
>>> ^Z


C:\Python21\Lib>python pydoc.py
----------------------------------------
Exception happened during processing of request from 
('127.0.0.1', 1651)
Traceback (most recent call last):
  File "c:\python21\lib\SocketServer.py", line 214, in 
handle_request
    self.process_request(request, client_address)
  File "c:\python21\lib\SocketServer.py", line 232, in 
process_request
    self.finish_request(request, client_address)
  File "c:\python21\lib\SocketServer.py", line 244, in 
finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "c:\python21\lib\SocketServer.py", line 481, in 
__init__
    self.handle()
  File "c:\python21\lib\BaseHTTPServer.py", line 266, in 
handle
    method()
  File "pydoc.py", line 1112, in do_GET
    p, x = locate(path)
  File "pydoc.py", line 923, in locate
    filename = sys.modules[path].__file__
AttributeError: 'exceptions' module has no 
attribute '__file__'
----------------------------------------



----------------------------------------------------------------------

Comment By: Hernan Martinez Foffani (hfoffani)
Date: 2001-03-16 02:27

Message:
Logged In: YES 
user_id=112690

Aditional Info:
Windows 2000 and IE 5.5 SP1 both Spanish version.

IExplorer error is "Can't find server or DNS error"
(translated by me)

(sorry for the 2nd bug report, but sourceforge keeps 
fighting me)



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408958&group_id=5470


From noreply@sourceforge.net  Mon Mar 26 23:47:20 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 26 Mar 2001 15:47:20 -0800
Subject: [Python-bugs-list] [ python-Bugs-409684 ] pydoc htmls pages that fails or no-info
Message-ID: <E14hghk-0003zu-00@usw-sf-web3.sourceforge.net>

Bugs item #409684, was updated on 2001-03-19 02:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409684&group_id=5470

Category: Python Library
Group: None
>Status: Closed
Priority: 5
Submitted By: Hernan Martinez Foffani (hfoffani)
Assigned to: Ka-Ping Yee (ping)
Summary: pydoc htmls pages that fails or no-info

Initial Comment:
python 2.1b1, windows 2000 spanish version.
using pydoc webserver capability.

The following pages don't show info or fails.
Builtins:
- exceptions.html (already reported in Bugs item 
#408958)

DLLs:
- xmlparse.html
- xmltok.html
- tcl83.html (i guess that's very hard to get python 
doc info from this, right? :-)
- tk83.html (ditto?)

Library:
- tzparse.html (i posted a bug report on this)
- rlcompleter.html (a un*x capability)
- pty.html (ditto)





----------------------------------------------------------------------

>Comment By: Ka-Ping Yee (ping)
Date: 2001-03-26 15:47

Message:
Logged In: YES 
user_id=45338

These are fixed in 2.1b2:
    exceptions appears correctly;
    xmlparse, xmltok, tcl83, tk83 aren't Python modules,
        they're just DLLs.  The latest version of pydoc
        produces a more helpful error message in this case.
    tzparse, rlcompleter, pty are Unix-specific and don't
        work in Windows.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409684&group_id=5470


From noreply@sourceforge.net  Tue Mar 27 02:34:01 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 26 Mar 2001 18:34:01 -0800
Subject: [Python-bugs-list] [ python-Bugs-411508 ] httplib does not support user/pass
Message-ID: <E14hjJ3-0005Dt-00@usw-sf-web3.sourceforge.net>

Bugs item #411508, was updated on 2001-03-26 18:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411508&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Priority: 5
Submitted By: JAmes Atwill (idcmp)
Assigned to: Nobody/Anonymous (nobody)
Summary: httplib does not support user/pass 

Initial Comment:
_set_hostport looks for the first ':' it finds and
takes the text after it as the port.  This doesn't work
if the user supplies a username/password combination.

For example:

  
http://user:pass@hostname.org:8080/directory/filename.html

There is no mechanism for easily including the
username/password unless the calling object mangles the
headers itself.  This means every project that uses
httplib needs to implement authentication itself, over
and over and over again.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411508&group_id=5470


From noreply@sourceforge.net  Tue Mar 27 08:13:52 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 27 Mar 2001 00:13:52 -0800
Subject: [Python-bugs-list] [ python-Bugs-411267 ] s.encode('latin-1') passes non-latin-1 c
Message-ID: <E14hobw-0007mT-00@usw-sf-web3.sourceforge.net>

Bugs item #411267, was updated on 2001-03-25 19:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411267&group_id=5470

Category: Unicode
Group: None
>Status: Closed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Nobody/Anonymous (nobody)
Summary: s.encode('latin-1') passes non-latin-1 c

Initial Comment:
>>> u'\x81'.encode('latin-1')
'\201'

this should probably raise an exception.

  -- erno@iki.fi



----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2001-03-27 00:13

Message:
Logged In: YES 
user_id=21627

Please have a look at RFC 1345, which clearly lists the
characters between 80 and A0 as part of ISO_8859-1:1987. The
C1 control characters are shared among all character sets of
ISO 8859, so they are not specific to Latin-1.

Please also have a look at
http://czyborra.com/charsets/iso8859.html
which confirms that C1 is between US-ASCII and G1. So you
probably need to consult a copy of ISO/IEC 8859-1:1998 to
proof us wrong. Note that the Unicode charts do not
contradict with this theory: they only list the characters
*specific* to Latin-1 as such, the characters shared by
other parts of 8859 (C0, G0, and C1) are not named "Latin-1"
in these charts.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-03-26 08:16

Message:
Logged In: NO 

http://www.unicode.org/charts/PDF/U0080.pdf
shows 0080-009f in unicode being something called "c1
controls" and 00a0-00ff being iso-8859-1 aka latin-1.

  -- erno


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-03-26 07:50

Message:
Logged In: NO 

every reference i can find on the web (and my linux
latin1(7) manual page) says they are 160-255...?

i think the reason for 128-159 characters not being used
might be that with the high bit stripped off they would be
ascii control characters and not printable.

  -- erno


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-03-26 01:14

Message:
Logged In: YES 
user_id=38388

u'\x81' is a perfectly valid Latin-1 character, in fact, the
first
256 Unicode characters are the Latin-1 characters.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411267&group_id=5470


From noreply@sourceforge.net  Tue Mar 27 08:32:57 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 27 Mar 2001 00:32:57 -0800
Subject: [Python-bugs-list] [ python-Bugs-221479 ] Compiler warnings on Solaris
Message-ID: <E14houP-0007vM-00@usw-sf-web3.sourceforge.net>

Bugs item #221479, was updated on 2000-11-03 14:53
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=221479&group_id=5470

Category: Build
Group: Platform-specific
>Status: Closed
Priority: 5
Submitted By: Greg Ward (gward)
Assigned to: Greg Ward (gward)
Summary: Compiler warnings on Solaris

Initial Comment:
GCC 2.95.2 on Solaris 2.6 reports a bunch of warnings building the latest CVS source.  Here's the complete list:

intrcheck.c:151: warning: function declaration isn't a prototype
intrcheck.c: In function `PyOS_InitInterrupts':
intrcheck.c:156: warning: function declaration isn't a prototype
intrcheck.c:156: warning: function declaration isn't a prototype
floatobject.c:35: warning: function declaration isn't a prototype
intobject.c: In function `PyInt_FromString':
intobject.c:185: warning: subscript has type `char'
bltinmodule.c: In function `builtin_ord':
bltinmodule.c:1507: warning: `ord' might be used uninitialized in this function
errors.c: In function `PyErr_Format':
errors.c:405: warning: subscript has type `char'
errors.c:460: warning: subscript has type `char'
errors.c:465: warning: subscript has type `char'
errors.c:468: warning: subscript has type `char'
pythonrun.c: In function `initsigs':
pythonrun.c:1134: warning: function declaration isn't a prototype
./posixmodule.c: In function `posix_confstr':
./posixmodule.c:4471: warning: implicit declaration of function `confstr'
./signalmodule.c:88: warning: function declaration isn't a prototype
./signalmodule.c: In function `signal_signal':
./signalmodule.c:212: warning: function declaration isn't a prototype
./signalmodule.c:214: warning: function declaration isn't a prototype
./signalmodule.c:225: warning: function declaration isn't a prototype
./signalmodule.c: In function `initsignal':
./signalmodule.c:332: warning: function declaration isn't a prototype
./signalmodule.c:336: warning: function declaration isn't a prototype
./signalmodule.c:355: warning: function declaration isn't a prototype
./signalmodule.c:357: warning: function declaration isn't a prototype
./signalmodule.c: In function `finisignal':
./signalmodule.c:556: warning: function declaration isn't a prototype
./signalmodule.c:564: warning: function declaration isn't a prototype
make[1]: [add2lib] Error 2 (ignored)
./stropmodule.c: In function `strop_atoi':
./stropmodule.c:752: warning: subscript has type `char'
./timemodule.c: In function `time_strptime':
./timemodule.c:385: warning: subscript has type `char'
./socketmodule.c: In function `PySocket_socket':
./socketmodule.c:1768: warning: function declaration isn't a prototype
./socketmodule.c: In function `PySocket_fromfd':
./socketmodule.c:1806: warning: function declaration isn't a prototype

I'll look into these one at a time and see how many I can fix.

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2001-03-27 00:32

Message:
Logged In: YES 
user_id=21627

This is a duplicate of #232787. Most of the warnings have
been fixed; the remaining ones are all Sun's fault :-)
Closed as a duplicate.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2000-12-22 19:16

Message:
ha


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2000-12-19 18:48

Message:
Patch submitted for the bltinmodule.c warning.

The errors.c warnings are because isdigit() & friends expect
an int, and the code is using *f, which is a char.  isdigit() is a macro on Solaris.  Presumably the fix is to use (int)*f on those lines.   Same cause for the ones in stropmodule.c and intobject.c, I think.

The warnings in socketmodule.c, and presumably the ones
in signalmodule.c, intrcheck.c, and pythonrun.c too, seem to be because of Solaris's SIG_IGN.  I suspect GCC is getting confused by it.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=221479&group_id=5470


From noreply@sourceforge.net  Tue Mar 27 09:28:41 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 27 Mar 2001 01:28:41 -0800
Subject: [Python-bugs-list] [ python-Bugs-411267 ] s.encode('latin-1') passes non-latin-1 c
Message-ID: <E14hpmL-0008M9-00@usw-sf-web3.sourceforge.net>

Bugs item #411267, was updated on 2001-03-25 19:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411267&group_id=5470

Category: Unicode
Group: None
Status: Closed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: s.encode('latin-1') passes non-latin-1 c

Initial Comment:
>>> u'\x81'.encode('latin-1')
'\201'

this should probably raise an exception.

  -- erno@iki.fi



----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-03-27 01:28

Message:
Logged In: NO 

ok, you are probably right then.

  -- erno


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-03-27 00:13

Message:
Logged In: YES 
user_id=21627

Please have a look at RFC 1345, which clearly lists the
characters between 80 and A0 as part of ISO_8859-1:1987. The
C1 control characters are shared among all character sets of
ISO 8859, so they are not specific to Latin-1.

Please also have a look at
http://czyborra.com/charsets/iso8859.html
which confirms that C1 is between US-ASCII and G1. So you
probably need to consult a copy of ISO/IEC 8859-1:1998 to
proof us wrong. Note that the Unicode charts do not
contradict with this theory: they only list the characters
*specific* to Latin-1 as such, the characters shared by
other parts of 8859 (C0, G0, and C1) are not named "Latin-1"
in these charts.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-03-26 08:16

Message:
Logged In: NO 

http://www.unicode.org/charts/PDF/U0080.pdf
shows 0080-009f in unicode being something called "c1
controls" and 00a0-00ff being iso-8859-1 aka latin-1.

  -- erno


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-03-26 07:50

Message:
Logged In: NO 

every reference i can find on the web (and my linux
latin1(7) manual page) says they are 160-255...?

i think the reason for 128-159 characters not being used
might be that with the high bit stripped off they would be
ascii control characters and not printable.

  -- erno


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-03-26 01:14

Message:
Logged In: YES 
user_id=38388

u'\x81' is a perfectly valid Latin-1 character, in fact, the
first
256 Unicode characters are the Latin-1 characters.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411267&group_id=5470


From noreply@sourceforge.net  Tue Mar 27 11:58:51 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 27 Mar 2001 03:58:51 -0800
Subject: [Python-bugs-list] [ python-Bugs-411612 ] cgi.py sometimes ignores QUERY_STRING
Message-ID: <E14hs7f-000143-00@usw-sf-web3.sourceforge.net>

Bugs item #411612, was updated on 2001-03-27 03:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411612&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Viktor Fougstedt (viktordt)
Assigned to: Nobody/Anonymous (nobody)
Summary: cgi.py sometimes ignores QUERY_STRING

Initial Comment:
[Using Python 2.0/Sparc Solaris 8, should be
independent of operating system]

cgi.py sometimes ignores the QUERY_STRING when
REQUEST_METHOD is POST.

The CGI specifications says nothing about how programs
should respond to this particular combination. It does
however state that QUERY_STRING should always be set by
the server, regardless of the request method. Since
QUERY_STRING is set, it seems reasonable that the cgi
module should parse it as well and not just ignore it. 

If cgi.py intentionally ignores QUERY_STRING under
these circumstances, I think it should be documented.
:-)

What this means is that if i have a HTML form a'la

<form action="/cgi-bin/some_cgi?foo=foo">
  <input type="text" name="bar">
  <input type="submit">
</form>

and some_cgi is a python script using cgi.py, I should
get both foo and bar set. Currently, the QUERY_STRING
(i.e. "foo=foo") is ignored, and only bar gets set by
cgi.py.

I consider this a "bug" insofar as it is an unexpected
and somewhat inconsistent behaviour. If I e.g. use the
url "/cgi-bin/myprog/session_id=10023" everywhere in my
program, I must suddenly alter it if the URL is used in
a FORM action attribute, and instead insert a hidden
variable called session_id into the form to get cgi.py
to parse it.

The parse() function in cgi.py correctly checks and
appends QUERY_STRING if it is set. But the FieldStorage
read_urlencoded() method does not, and that is the
function that is actually used, not cgi.parse().

The fix should be to add two lines (marked with '>'
below) after the initial assignment to qs in the
read_urlencoded() method of the FieldStorage class so
that it begins:

    def read_urlencoded(self):
        """Internal: read data in query string
format."""
        qs = self.fp.read(self.length)
        if os.environ.has_key('QUERY_STRING'):
            if qs: qs = qs + '&'
            qs = qs + environ['QUERY_STRING']

(the three last lines are new, and identical to the
three lines in the cgi.parse() function which
accomplishes the same task).




----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411612&group_id=5470


From noreply@sourceforge.net  Tue Mar 27 12:23:01 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 27 Mar 2001 04:23:01 -0800
Subject: [Python-bugs-list] [ python-Bugs-411612 ] cgi.py sometimes ignores QUERY_STRING
Message-ID: <E14hsV3-0006hl-00@usw-sf-web1.sourceforge.net>

Bugs item #411612, was updated on 2001-03-27 03:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411612&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Viktor Fougstedt (viktordt)
Assigned to: Nobody/Anonymous (nobody)
Summary: cgi.py sometimes ignores QUERY_STRING

Initial Comment:
[Using Python 2.0/Sparc Solaris 8, should be
independent of operating system]

cgi.py sometimes ignores the QUERY_STRING when
REQUEST_METHOD is POST.

The CGI specifications says nothing about how programs
should respond to this particular combination. It does
however state that QUERY_STRING should always be set by
the server, regardless of the request method. Since
QUERY_STRING is set, it seems reasonable that the cgi
module should parse it as well and not just ignore it. 

If cgi.py intentionally ignores QUERY_STRING under
these circumstances, I think it should be documented.
:-)

What this means is that if i have a HTML form a'la

<form action="/cgi-bin/some_cgi?foo=foo">
  <input type="text" name="bar">
  <input type="submit">
</form>

and some_cgi is a python script using cgi.py, I should
get both foo and bar set. Currently, the QUERY_STRING
(i.e. "foo=foo") is ignored, and only bar gets set by
cgi.py.

I consider this a "bug" insofar as it is an unexpected
and somewhat inconsistent behaviour. If I e.g. use the
url "/cgi-bin/myprog/session_id=10023" everywhere in my
program, I must suddenly alter it if the URL is used in
a FORM action attribute, and instead insert a hidden
variable called session_id into the form to get cgi.py
to parse it.

The parse() function in cgi.py correctly checks and
appends QUERY_STRING if it is set. But the FieldStorage
read_urlencoded() method does not, and that is the
function that is actually used, not cgi.parse().

The fix should be to add two lines (marked with '>'
below) after the initial assignment to qs in the
read_urlencoded() method of the FieldStorage class so
that it begins:

    def read_urlencoded(self):
        """Internal: read data in query string
format."""
        qs = self.fp.read(self.length)
        if os.environ.has_key('QUERY_STRING'):
            if qs: qs = qs + '&'
            qs = qs + environ['QUERY_STRING']

(the three last lines are new, and identical to the
three lines in the cgi.parse() function which
accomplishes the same task).




----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-03-27 04:23

Message:
Logged In: NO 

Quick check: That "fix" does not work. It duplicates
the QUERY_STRING if you use the GET method. Additional
checks are necessary to ensure correct operation.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411612&group_id=5470


From noreply@sourceforge.net  Tue Mar 27 19:39:55 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 27 Mar 2001 11:39:55 -0800
Subject: [Python-bugs-list] [ python-Bugs-411713 ] __cmp__ and __rcmp__ have same descripti
Message-ID: <E14hzJr-0006e5-00@usw-sf-web2.sourceforge.net>

Bugs item #411713, was updated on 2001-03-27 11:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411713&group_id=5470

Category: Documentation
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: __cmp__ and __rcmp__ have same descripti

Initial Comment:
Here,

http://www.python.org/doc/current/ref/customization.html

__cmp__ and __rcmp__ apear to have the same
description, which describes __cmp__ only.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411713&group_id=5470


From noreply@sourceforge.net  Wed Mar 28 09:48:30 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 28 Mar 2001 01:48:30 -0800
Subject: [Python-bugs-list] [ python-Bugs-411845 ] problem on solaris7
Message-ID: <E14iCZ4-0004gQ-00@usw-sf-web2.sourceforge.net>

Bugs item #411845, was updated on 2001-03-28 01:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411845&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: problem on solaris7

Initial Comment:
Hi,
 
   I was trying to install PYTHON1.6.1 on a sparc
 solaris7 computer with support for thread and bsddb
 module (I used the BerkeleyDB3.0).
   I dont have GCC on this machine so I used CC (I add
 the  -mt and -D_REENTRANT).
  
   The compilation is ok except at the end when it
 tried to build the python executable. I received a
 message about unknow function Py_main.
 
   Is anybody knowing this problem (and the way to
 correct it) ?
 
  Best regards.
 
 ------
 
 ** This is the error message **
 
 make
 (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
 `Makefile' is up to date.
 (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  _sre.o 
 arraymodule.o 
 cmathmodule.o  mathmodule.o  stropmodule.o 
 structmodule.o 
 timemodule.o  operator.o  _codecsmodule.o 
 unicodedata.o 
 unicodedatabase.o  _localemodule.o  fcntlmodule.o 
 pwdmodule.o 
 grpmodule.o  errnomodule.o  mmapmodule.o 
 selectmodule.o 
 socketmodule.o  md5module.o md5c.o  shamodule.o 
 rotormodule.o 
 newmodule.o  bsddbmodule.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="-O -mt" VERSION="1.6" \
                 
 prefix="/usr/local/softs/Python/Pythus" 
 exec_prefix="/usr/local/softs/Python/Pythus" all
 cd Objects ; make OPT="-O -mt" VERSION="1.6" \
                 
 prefix="/usr/local/softs/Python/Pythus" 
 exec_prefix="/usr/local/softs/Python/Pythus" all
 cd Python ; make OPT="-O -mt" VERSION="1.6" \
                 
 prefix="/usr/local/softs/Python/Pythus" 
 exec_prefix="/usr/local/softs/Python/Pythus" all
 cd Modules ; make OPT="-O -mt" VERSION="1.6" \
                 
 prefix="/usr/local/softs/Python/Pythus" 
 exec_prefix="/usr/local/softs/Python/Pythus" all
 expr `cat buildno` + 1 >buildno1
 mv -f buildno1 buildno
 cc -c -O -mt -I. -DHAVE_CONFIG_H -D_REENTRANT
 -DBUILD=`cat buildno` \
                ./Modules/getbuildinfo.c
 ar cr libpython1.6.a getbuildinfo.o
 ranlib libpython1.6.a
 true
 cd Modules;  make OPT="-O -mt" VERSION="1.6" \
                 
 prefix="/usr/local/softs/Python/Pythus" 
 exec_prefix="/usr/local/softs/Python/Pythus" \
                  LIBRARY=../libpython1.6.a link
 cc   python.o \
            ../libpython1.6.a
 /usr/local/softs/Python/DB2/lib/libdb.a 
 -lpthread -lsocket -lnsl -ldl  -lthread -lm  -o python
 Undefined                       first referenced
   symbol                             in file
 Py_Main                             python.o
 ld: fatal: Symbol referencing errors. No output
 written to python
 *** Error code 1
 make: Fatal error: Command failed for target `link'
 Current working directory
 /usr/local/softs/Python/Python-1.6.1/Modules
 *** Error code 1
 make: Fatal error: Command failed for target `python'

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411845&group_id=5470


From noreply@sourceforge.net  Wed Mar 28 12:58:14 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 28 Mar 2001 04:58:14 -0800
Subject: [Python-bugs-list] [ python-Bugs-411881 ] Use of "except:" in modules
Message-ID: <E14iFWg-0006uH-00@usw-sf-web1.sourceforge.net>

Bugs item #411881, was updated on 2001-03-28 04:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411881&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Itamar Shtull-Trauring (itamar)
Assigned to: Nobody/Anonymous (nobody)
Summary: Use of "except:" in modules

Initial Comment:
A large amount of modules in the standard library use
"except:" instead of specifying the exceptions to be
caught. In some cases this may be correct, but I think
in most cases this not true and this may cause
problems. Here's the list of modules, which I got by
doing:

   grep "except:" *.py | cut -f 1 -d " " | sort | uniq

Bastion.py
CGIHTTPServer.py
Cookie.py
SocketServer.py
anydbm.py
asyncore.py
bdb.py
cgi.py
chunk.py
cmd.py
code.py
compileall.py
doctest.py
fileinput.py
formatter.py
getpass.py
htmllib.py
imaplib.py
inspect.py
locale.py
locale.py
mailcap.py
mhlib.py
mimetools.py
mimify.py
os.py
pdb.py
popen2.py
posixfile.py
pre.py
pstats.py
pty.py
pyclbr.py
pydoc.py
repr.py
rexec.py
rfc822.py
shelve.py
shutil.py
tempfile.py
threading.py
traceback.py
types.py
unittest.py
urllib.py
zipfile.py


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411881&group_id=5470


From noreply@sourceforge.net  Wed Mar 28 14:52:36 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 28 Mar 2001 06:52:36 -0800
Subject: [Python-bugs-list] [ python-Bugs-410164 ] pydoc can't find module in current dir
Message-ID: <E14iHJM-0007F4-00@usw-sf-web2.sourceforge.net>

Bugs item #410164, was updated on 2001-03-20 13:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410164&group_id=5470

Category: demos and tools
Group: Feature Request
Status: Closed
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Ka-Ping Yee (ping)
Summary: pydoc can't find module in current dir

Initial Comment:
On my linux system pydoc doesn't seem able to find
modules in the current directory unless I set the
PYTHONPATH environment variable, including ".":

    % pydoc OO_Model
    No Python documentation found for 'OO_Model'.
    beluga:lib% PYTHONPATH=. pydoc OO_Model

    Python Library Documentation: module OO_Model
    ...

I examined the output of pydoc.pathdirs().  Even
without setting PYTHONPATH the directory containing the
OO_Model module is in the output (second directory):

    % python
    Python 2.1b1 (#1, Mar 12 2001, 16:13:37) 
    [GCC 2.95.3 19991030 (prerelease)] on linux2
    Type "copyright", "credits" or "license" for more
    information.
    >>> import pydoc
    >>> pydoc.pathdirs()
    ['/usr/local/lib/automatrix/python',
     '/home/skip/src/tttech/lib',
     '/usr/local/lib/python2.1',
     '/usr/local/lib/python2.1/plat-linux2',
     '/usr/local/lib/python2.1/lib-tk',
     '/usr/local/lib/python2.1/lib-dynload',
     '/usr/local/lib/python2.1/site-packages',
     '/home/skip/src/Zope/lib/python']

Seems like a bug to me.



----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-03-28 06:52

Message:
Logged In: YES 
user_id=3066

I'd describe this as "Python does the right thing" -- pydoc is then overloading the semantics of sys.path.  It sounds like the internals of pydoc should receive a search path to use -- the startup code for pydoc can then compute that based on sys.path, removing it's own directory from it and adding anything more as appropriate.

----------------------------------------------------------------------

Comment By: Ka-Ping Yee (ping)
Date: 2001-03-26 15:37

Message:
Logged In: YES 
user_id=45338

Python itself is inconsistent in this regard (as Fred
rightly points out).  For now, the pydoc that made it
into 2.1b2 adds '.' to the path when run as a script;
in future it should probably also *remove* the script
directory from sys.path (when the script directory is
not the same as the current dir) for good consistency
with running python and importing pydoc interactively.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-03-20 22:00

Message:
Logged In: YES 
user_id=3066

This ia a pydoc issue; sys.path for a script includes the
script dir but not (necessarily) the current dir.

Assigned to Ping.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410164&group_id=5470


From noreply@sourceforge.net  Wed Mar 28 15:26:08 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 28 Mar 2001 07:26:08 -0800
Subject: [Python-bugs-list] [ python-Bugs-411713 ] __cmp__ and __rcmp__ have same descripti
Message-ID: <E14iHpo-0005yg-00@usw-sf-web3.sourceforge.net>

Bugs item #411713, was updated on 2001-03-27 11:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411713&group_id=5470

Category: Documentation
Group: None
>Status: Closed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: __cmp__ and __rcmp__ have same descripti

Initial Comment:
Here,

http://www.python.org/doc/current/ref/customization.html

__cmp__ and __rcmp__ apear to have the same
description, which describes __cmp__ only.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-03-28 07:26

Message:
Logged In: YES 
user_id=3066

__rcmp__() will no longer be supported in Python 2.1 -- the documentation for that release has been corrected.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411713&group_id=5470


From noreply@sourceforge.net  Wed Mar 28 16:51:51 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 28 Mar 2001 08:51:51 -0800
Subject: [Python-bugs-list] [ python-Bugs-411063 ] Minor flaws in "Documenting Python"
Message-ID: <E14iJAl-0001FP-00@usw-sf-web1.sourceforge.net>

Bugs item #411063, was updated on 2001-03-24 08:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411063&group_id=5470

Category: Documentation
Group: None
>Status: Closed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
>Summary: Minor flaws in "Documenting Python"

Initial Comment:
Documenting Python , Section 3.1
3.1 Syntax
	"There are only a things that....

==> Perhaps: a few things?

...
Syntactically, groups are enclosed in braces:

	{text in a group}

An alternative syntax for a group using 
brackets ({...}) is used by...

==> maybe ([...])


...
environment: 
This example shows an environment which takes a single 
required parameter:

	\begin{datadesc}{datadesc}{controlnames}
          A 33-element ....

==> Is the 2nd {datadesc} above needed?


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-03-28 08:51

Message:
Logged In: YES 
user_id=3066

Fixed in Doc/doc/doc.tex revision 1.38.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411063&group_id=5470


From noreply@sourceforge.net  Wed Mar 28 16:52:04 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 28 Mar 2001 08:52:04 -0800
Subject: [Python-bugs-list] [ python-Bugs-411948 ] SMIME support?
Message-ID: <E14iJAy-0001Fg-00@usw-sf-web1.sourceforge.net>

Bugs item #411948, was updated on 2001-03-28 08:52
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411948&group_id=5470

Category: Python Interpreter Core
Group: Feature Request
Status: Open
Priority: 5
Submitted By: eXom (jkuan)
Assigned to: Nobody/Anonymous (nobody)
Summary: SMIME support?

Initial Comment:
Is there any intention that python will support SMIME?


Thanks a lot
Joe

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411948&group_id=5470


From noreply@sourceforge.net  Wed Mar 28 16:53:13 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 28 Mar 2001 08:53:13 -0800
Subject: [Python-bugs-list] [ python-Bugs-411127 ] README file for Unix not up to date
Message-ID: <E14iJC5-0001GJ-00@usw-sf-web1.sourceforge.net>

Bugs item #411127, was updated on 2001-03-24 21:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411127&group_id=5470

Category: Documentation
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: A.M. Kuchling (akuchling)
Summary: README file for Unix not up to date

Initial Comment:
The README file instructions for building Python 
suggest editing the Modules/Setup directory to select
the modules to be built.  The new build process 
automatically builds some of the modules.  Is there a
reason for leaving the modules in Setup if they are
built automatically?

Perhaps the introductory paragraph or README should
mention the distutil build process.

With the rework of the build process is the 
instructions for using VPATH still valid?



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411127&group_id=5470


From noreply@sourceforge.net  Wed Mar 28 16:56:22 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 28 Mar 2001 08:56:22 -0800
Subject: [Python-bugs-list] [ python-Bugs-411118 ] Typo in Python Reference Manual
Message-ID: <E14iJF8-0001J6-00@usw-sf-web1.sourceforge.net>

Bugs item #411118, was updated on 2001-03-24 16:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411118&group_id=5470

Category: Documentation
Group: None
>Status: Closed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Typo in Python Reference Manual

Initial Comment:
Python Reference Manual, Release 2.1 beta 2,  
updated on March 23, 2001.

Section: A.3.1 Definitions and rules

The letter "v" is missing in:

"(The ariables of the module code block are local 
and global.)"



----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-03-28 08:56

Message:
Logged In: YES 
user_id=3066

Fixed in Doc/ref/refa1.tex revision 1.5.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411118&group_id=5470


From noreply@sourceforge.net  Wed Mar 28 20:09:55 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 28 Mar 2001 12:09:55 -0800
Subject: [Python-bugs-list] [ python-Bugs-411996 ] no "_" variable with displayhook
Message-ID: <E14iMGR-0003iT-00@usw-sf-web1.sourceforge.net>

Bugs item #411996, was updated on 2001-03-28 12:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411996&group_id=5470

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: no "_" variable with displayhook

Initial Comment:
after using the new displayhook function, the "_" 
variable is no longer functional.

>>> # Create a recursive data structure
... L = [1,2,3]
>>> L.append(L)
>>> L # Show Python's default output
[1, 2, 3, [...]]
>>> # Use pprint.pprint() as the display function
... import sys, pprint
>>> sys.displayhook = pprint.pprint
>>> L
[1, 2, 3,  <Recursion on list with id=135143996>]
>>> a = 1./4
>>> _
[1, 2, 3, <Recursion on list with id=135525660>] 





----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411996&group_id=5470


From noreply@sourceforge.net  Thu Mar 29 04:00:44 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 28 Mar 2001 20:00:44 -0800
Subject: [Python-bugs-list] [ python-Bugs-411996 ] no "_" variable with displayhook
Message-ID: <E14iTc4-0003UE-00@usw-sf-web3.sourceforge.net>

Bugs item #411996, was updated on 2001-03-28 12:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411996&group_id=5470

Category: None
>Group: Not a Bug
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
>Summary: no "_" variable with displayhook

Initial Comment:
after using the new displayhook function, the "_" 
variable is no longer functional.

>>> # Create a recursive data structure
... L = [1,2,3]
>>> L.append(L)
>>> L # Show Python's default output
[1, 2, 3, [...]]
>>> # Use pprint.pprint() as the display function
... import sys, pprint
>>> sys.displayhook = pprint.pprint
>>> L
[1, 2, 3,  <Recursion on list with id=135143996>]
>>> a = 1./4
>>> _
[1, 2, 3, <Recursion on list with id=135525660>] 





----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-03-28 20:00

Message:
Logged In: YES 
user_id=31435

Sorry, but setting "_" is done by the system-default 
display hook.  If you replace the default display hook, you 
lose it.  If you still want it, you have to implement it in 
*your* display hook (by assigning to __builtin__._ when you 
want its value to change).

Note that the example you gave is a bad one, because an 
assignment statement doesn't trigger the display hook 
anyway.  That is, "a = 1./4" would have had no effect on _ 
even if you hadn't replaced the display hook.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411996&group_id=5470


From noreply@sourceforge.net  Thu Mar 29 04:07:15 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 28 Mar 2001 20:07:15 -0800
Subject: [Python-bugs-list] [ python-Bugs-412086 ] curses module is missing some color vars
Message-ID: <E14iTiN-0005dm-00@usw-sf-web2.sourceforge.net>

Bugs item #412086, was updated on 2001-03-28 20:07
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=412086&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Peter Wilson (pabw)
Assigned to: Nobody/Anonymous (nobody)
Summary: curses module is missing some color vars

Initial Comment:
The _curses modules doesn't define COLORS or COLOR_PAIRS until after start_color() is called.

Adding a start_color() wrapper to curses/__init__.py along the same lines as the wrapper around initscr() fixes this.
(And I don't knowof or use any other variables that get dynamically added...)

def start_color():
    import _curses, curses  
    # This import is from the initscr() wrapper
    val = _curses.start_color()

    if _curses.__dict__.has_key('COLOR_PAIRS'):
        curses.COLOR_PAIRS = _curses.COLOR_PAIRS
    if _curses.__dict__.has_key('COLORS'):
        curses.COLORS = _curses.COLORS

    return val

-------

# Or, it's simple avoid the import in a function-level scope...
# If this version is used, then the initscr() wrapper should probably be changed to match.

import sys

def start_color():
    # If this code gets called, then these modules are guaranteed to exist:
    curses = sys.module['curses']
    _curses = sys.module['_curses']

    val = _curses.start_color()
    
    if _curses.__dict__.has_key('COLOR_PAIRS'):
        curses.COLOR_PAIRS = _curses.COLOR_PAIRS
    if _curses.__dict__.has_key('COLORS'):
        curses.COLORS = _curses.COLORS

    return val


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=412086&group_id=5470


From noreply@sourceforge.net  Thu Mar 29 13:59:24 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 29 Mar 2001 05:59:24 -0800
Subject: [Python-bugs-list] [ python-Bugs-410979 ] Python 2.1 breaks py-qt
Message-ID: <E14icxQ-0007Rk-00@usw-sf-web1.sourceforge.net>

Bugs item #410979, was updated on 2001-03-23 21:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410979&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Python 2.1 breaks py-qt

Initial Comment:
Py-Qt, which works fine with Python 2.0, complains 
fails with RuntimeError: Signal has wrong argument 
types for slot under Python 2.1b2 when attempting to 
run any program with QT that uses signals and slots.



----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-03-29 05:59

Message:
Logged In: NO 

This is a problem in PyQt not Python. PyQt v2.4pre1 works 
fine with Python v2.1b. PyQt v2.4 will be released as soon 
as Python v2.1 is released.

Phil Thompson

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410979&group_id=5470


From noreply@sourceforge.net  Thu Mar 29 14:41:52 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 29 Mar 2001 06:41:52 -0800
Subject: [Python-bugs-list] [ python-Bugs-410979 ] Python 2.1 breaks py-qt
Message-ID: <E14idcW-0008Lh-00@usw-sf-web3.sourceforge.net>

Bugs item #410979, was updated on 2001-03-23 21:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410979&group_id=5470

Category: Extension Modules
>Group: Not a Bug
>Status: Closed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Python 2.1 breaks py-qt

Initial Comment:
Py-Qt, which works fine with Python 2.0, complains 
fails with RuntimeError: Signal has wrong argument 
types for slot under Python 2.1b2 when attempting to 
run any program with QT that uses signals and slots.



----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-03-29 06:41

Message:
Logged In: YES 
user_id=3066

Closed based on Phil's comments.  Thanks, Phil!

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-03-29 05:59

Message:
Logged In: NO 

This is a problem in PyQt not Python. PyQt v2.4pre1 works 
fine with Python v2.1b. PyQt v2.4 will be released as soon 
as Python v2.1 is released.

Phil Thompson

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410979&group_id=5470


From noreply@sourceforge.net  Thu Mar 29 15:40:38 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 29 Mar 2001 07:40:38 -0800
Subject: [Python-bugs-list] [ python-Bugs-412214 ] ZipFile constructor leaves files open
Message-ID: <E14ieXO-0000KT-00@usw-sf-web1.sourceforge.net>

Bugs item #412214, was updated on 2001-03-29 07:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=412214&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Jens Quade (snejsource)
Assigned to: Nobody/Anonymous (nobody)
Summary: ZipFile constructor leaves files open

Initial Comment:
During the construction of a ZipFile object, a 
file is opened and assigned to self.fp.

If anything goes wrong, i.e. the file is not a zipfile,
it is not closed explicitly.  

On Windows, this does not work:

import zipfile, os

filename="test.zip" # it's a broken one
try:
  zf=zipfile.ZipFile(filename)
  zf.close()
finally:
  os.unlink(zipfile)

=> OSError: [errno 13] Permission denied "test.zip"

(on Unix, the file stays open too, but unlink doesn't
fail)


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=412214&group_id=5470


From noreply@sourceforge.net  Thu Mar 29 16:27:38 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 29 Mar 2001 08:27:38 -0800
Subject: [Python-bugs-list] [ python-Bugs-412214 ] ZipFile constructor leaves files open
Message-ID: <E14ifGs-0000nr-00@usw-sf-web3.sourceforge.net>

Bugs item #412214, was updated on 2001-03-29 07:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=412214&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Jens Quade (snejsource)
Assigned to: Nobody/Anonymous (nobody)
Summary: ZipFile constructor leaves files open

Initial Comment:
During the construction of a ZipFile object, a 
file is opened and assigned to self.fp.

If anything goes wrong, i.e. the file is not a zipfile,
it is not closed explicitly.  

On Windows, this does not work:

import zipfile, os

filename="test.zip" # it's a broken one
try:
  zf=zipfile.ZipFile(filename)
  zf.close()
finally:
  os.unlink(zipfile)

=> OSError: [errno 13] Permission denied "test.zip"

(on Unix, the file stays open too, but unlink doesn't
fail)


----------------------------------------------------------------------

>Comment By: Jens Quade (snejsource)
Date: 2001-03-29 08:27

Message:
Logged In: YES 
user_id=137089

os.unlink(zipfile) should read os.unlink(filename). 

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=412214&group_id=5470


From noreply@sourceforge.net  Thu Mar 29 17:06:34 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 29 Mar 2001 09:06:34 -0800
Subject: [Python-bugs-list] [ python-Bugs-412230 ] mailbox.BabylMailbox, missing headers
Message-ID: <E14ifsY-0001NF-00@usw-sf-web1.sourceforge.net>

Bugs item #412230, was updated on 2001-03-29 09:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=412230&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: mailbox.BabylMailbox, missing headers

Initial Comment:
I am playing around with mailbox.BabylMailbox to parse
my RMAIL
file. It seems like certain headers are only recognized
some of the
time.  For instance, "Message-Id:" headers sometime
appears, sometimes not. 

The following program:

------------------------------------------------------------------
#!/usr/bin/env python
import mailbox
mb = mailbox.BabylMailbox(
open("/home/students/kurlberg/ggg", "r"))
t = mb.next()
print t.headers
print "\nThe message-id is:", t.getheader("Message-ID")
------------------------------------------------------------------

produces:

------------------------------------------------------------------
['X-Sender: clancey@alpha.muga.com\012', 'Date: Wed, 28
Feb 2001 11:41:43 -0500\012', 'To:
faculty@muga.com\012', 'From: Kevin Clancey
<clancey@muga.com>\012', 'Subject: Travel Funds\012',
'Content-Type: text/plain; charset="us-ascii"\012',
'Content-Length: 183\012']

The message-id is: None
------------------------------------------------------------------

The file ggg contains: (I replaced the real domain by
muga.com to
avoid spambots.)

--------- ggg start:
---------------------------------------------
BABYL OPTIONS: -*- rmail -*-
Version: 5
Labels:
Note:   This is the header of an rmail file.
Note:   If you are seeing it in rmail,
Note:    it means the file has no messages in it.
  
1,,
Summary-line: 28-Feb       clancey@muga.com  [23]
#Travel Funds
X-Coding-System: nil
Mail-from: From clancey@muga.com Wed Feb 28 11:50 EST
2001
Received: from clancey.muga.com (clancey
[128.192.3.198])
	by alpha.muga.com (8.9.1/8.9.1) with SMTP id LAA28223
	for <faculty@muga.com>; Wed, 28 Feb 2001 11:48:43
-0500 (EST)
Message-Id:
<3.0.6.32.20010228114143.00921510@alpha.muga.com>
X-Sender: clancey@alpha.muga.com
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6
(32)
Date: Wed, 28 Feb 2001 11:41:43 -0500
To: faculty@muga.com
From: Kevin Clancey <clancey@muga.com>
Subject: Travel Funds
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Length: 183

*** EOOH ***
X-Sender: clancey@alpha.muga.com
Date: Wed, 28 Feb 2001 11:41:43 -0500
To: faculty@muga.com
From: Kevin Clancey <clancey@muga.com>
Subject: Travel Funds
Content-Type: text/plain; charset="us-ascii"
Content-Length: 183

Please try to submit any travel requests to the
department for travel
during this fiscal year by Friday, March 30, 2001. (FYI
the fiscal
year ends on June 30, 2001.)  Thanks.
-Kevin


 
--------- End of ggg:
-----------------------------------


On the other hand, message-id is found in the following
example:

-------- mail where message-id is
detected---------------

  
0, unseen,,
Summary-line:  4-Aug    root@gauss.muga.com  [18]
#gauss.muga.com 08/04/00:17.01 system check
*** EOOH ***
X-Coding-System: undecided-unix
Mail-from: From root  Fri Aug  4 17:01:01 2000
Return-Path: <root>
Received: (from root@localhost)
	by gauss.muga.com (8.9.3/8.9.3) id RAA13973
	for root; Fri, 4 Aug 2000 17:01:01 -0400
Date: Fri, 4 Aug 2000 17:01:01 -0400
From: root <root@gauss.muga.com>
Message-Id: <200008042101.RAA13973@gauss.muga.com>
To: root@gauss.muga.com
Subject: gauss.muga.com 08/04/00:17.01 system check


Unusual System Events
=-=-=-=-=-=-=-=-=-=-=
Aug  4 16:12:55 gauss sshd[381]: log: Generating new
768 bit RSA key.
Aug  4 16:12:55 gauss sshd[381]: log: RSA key
generation complete.

  
-------- end of mail where message-id is detected
----------


Is there a bug in mailbox/mailbox.BabylMailbox? 

P.S. The above program was run with python version
1.6b1. However,
there are similar problems with python 2.0.

Sorry about the ugly line breaks.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=412230&group_id=5470


From noreply@sourceforge.net  Thu Mar 29 18:08:51 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 29 Mar 2001 10:08:51 -0800
Subject: [Python-bugs-list] [ python-Bugs-411996 ] no "_" variable with displayhook
Message-ID: <E14igqp-0001fR-00@usw-sf-web3.sourceforge.net>

Bugs item #411996, was updated on 2001-03-28 12:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411996&group_id=5470

Category: None
Group: Not a Bug
>Status: Closed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
>Summary: no "_" variable with displayhook

Initial Comment:
after using the new displayhook function, the "_" 
variable is no longer functional.

>>> # Create a recursive data structure
... L = [1,2,3]
>>> L.append(L)
>>> L # Show Python's default output
[1, 2, 3, [...]]
>>> # Use pprint.pprint() as the display function
... import sys, pprint
>>> sys.displayhook = pprint.pprint
>>> L
[1, 2, 3,  <Recursion on list with id=135143996>]
>>> a = 1./4
>>> _
[1, 2, 3, <Recursion on list with id=135525660>] 





----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-03-28 20:00

Message:
Logged In: YES 
user_id=31435

Sorry, but setting "_" is done by the system-default 
display hook.  If you replace the default display hook, you 
lose it.  If you still want it, you have to implement it in 
*your* display hook (by assigning to __builtin__._ when you 
want its value to change).

Note that the example you gave is a bad one, because an 
assignment statement doesn't trigger the display hook 
anyway.  That is, "a = 1./4" would have had no effect on _ 
even if you hadn't replaced the display hook.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411996&group_id=5470


From noreply@sourceforge.net  Thu Mar 29 18:50:09 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 29 Mar 2001 10:50:09 -0800
Subject: [Python-bugs-list] [ python-Bugs-412252 ] mimetypes.py uses posixpath not os.path
Message-ID: <E14ihUn-0004N1-00@usw-sf-web2.sourceforge.net>

Bugs item #412252, was updated on 2001-03-29 10:50
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=412252&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: mimetypes.py uses posixpath not os.path

Initial Comment:
The mimetypes.py module imports posixpath instead of 
os.path.  There's nothing special from posixpath that 
it's using - only three calls to splitext, which 
should have the same implementation in all of the 
platform-specific path modules.

This was noted when using Gordon McMillan's installer, 
which normally excludes posixpath since it's creating 
Win32 executables that should be using ntpath.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=412252&group_id=5470


From noreply@sourceforge.net  Fri Mar 30 06:49:38 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 29 Mar 2001 22:49:38 -0800
Subject: [Python-bugs-list] [ python-Bugs-412402 ] ColorDelegator.py assigns to __debug__
Message-ID: <E14isj4-0007gA-00@usw-sf-web3.sourceforge.net>

Bugs item #412402, was updated on 2001-03-29 22:49
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=412402&group_id=5470

Category: IDLE
Group: None
Status: Open
Priority: 5
Submitted By: Martin v. Löwis (loewis)
Assigned to: Guido van Rossum (gvanrossum)
Summary: ColorDelegator.py assigns to __debug__

Initial Comment:
With the current CVS, when running IDLE, I get the
traceback

  File
"/usr/local/lib/python2.1/site-packages/idlelib/PyShell
.py", line 15, in ?
    from EditorWindow import EditorWindow,
fixwordbreaks
  File
"/usr/local/lib/python2.1/site-packages/idlelib/EditorWindow.py",
line 88, in ?
    class EditorWindow:
  File
"/usr/local/lib/python2.1/site-packages/idlelib/EditorWindow.py",
line 91, in EditorWindow
    from ColorDelegator import ColorDelegator
  File
"/usr/local/lib/python2.1/site-packages/idlelib/ColorDelegator.py",
line
13
    __debug__ = 0

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=412402&group_id=5470


From noreply@sourceforge.net  Fri Mar 30 06:57:08 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 29 Mar 2001 22:57:08 -0800
Subject: [Python-bugs-list] [ python-Bugs-411845 ] problem on solaris7
Message-ID: <E14isqK-000225-00@usw-sf-web2.sourceforge.net>

Bugs item #411845, was updated on 2001-03-28 01:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411845&group_id=5470

Category: Build
Group: Platform-specific
>Status: Closed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: problem on solaris7

Initial Comment:
Hi,
 
   I was trying to install PYTHON1.6.1 on a sparc
 solaris7 computer with support for thread and bsddb
 module (I used the BerkeleyDB3.0).
   I dont have GCC on this machine so I used CC (I add
 the  -mt and -D_REENTRANT).
  
   The compilation is ok except at the end when it
 tried to build the python executable. I received a
 message about unknow function Py_main.
 
   Is anybody knowing this problem (and the way to
 correct it) ?
 
  Best regards.
 
 ------
 
 ** This is the error message **
 
 make
 (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
 `Makefile' is up to date.
 (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  _sre.o 
 arraymodule.o 
 cmathmodule.o  mathmodule.o  stropmodule.o 
 structmodule.o 
 timemodule.o  operator.o  _codecsmodule.o 
 unicodedata.o 
 unicodedatabase.o  _localemodule.o  fcntlmodule.o 
 pwdmodule.o 
 grpmodule.o  errnomodule.o  mmapmodule.o 
 selectmodule.o 
 socketmodule.o  md5module.o md5c.o  shamodule.o 
 rotormodule.o 
 newmodule.o  bsddbmodule.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="-O -mt" VERSION="1.6" \
                 
 prefix="/usr/local/softs/Python/Pythus" 
 exec_prefix="/usr/local/softs/Python/Pythus" all
 cd Objects ; make OPT="-O -mt" VERSION="1.6" \
                 
 prefix="/usr/local/softs/Python/Pythus" 
 exec_prefix="/usr/local/softs/Python/Pythus" all
 cd Python ; make OPT="-O -mt" VERSION="1.6" \
                 
 prefix="/usr/local/softs/Python/Pythus" 
 exec_prefix="/usr/local/softs/Python/Pythus" all
 cd Modules ; make OPT="-O -mt" VERSION="1.6" \
                 
 prefix="/usr/local/softs/Python/Pythus" 
 exec_prefix="/usr/local/softs/Python/Pythus" all
 expr `cat buildno` + 1 >buildno1
 mv -f buildno1 buildno
 cc -c -O -mt -I. -DHAVE_CONFIG_H -D_REENTRANT
 -DBUILD=`cat buildno` \
                ./Modules/getbuildinfo.c
 ar cr libpython1.6.a getbuildinfo.o
 ranlib libpython1.6.a
 true
 cd Modules;  make OPT="-O -mt" VERSION="1.6" \
                 
 prefix="/usr/local/softs/Python/Pythus" 
 exec_prefix="/usr/local/softs/Python/Pythus" \
                  LIBRARY=../libpython1.6.a link
 cc   python.o \
            ../libpython1.6.a
 /usr/local/softs/Python/DB2/lib/libdb.a 
 -lpthread -lsocket -lnsl -ldl  -lthread -lm  -o python
 Undefined                       first referenced
   symbol                             in file
 Py_Main                             python.o
 ld: fatal: Symbol referencing errors. No output
 written to python
 *** Error code 1
 make: Fatal error: Command failed for target `link'
 Current working directory
 /usr/local/softs/Python/Python-1.6.1/Modules
 *** Error code 1
 make: Fatal error: Command failed for target `python'

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2001-03-29 22:57

Message:
Logged In: YES 
user_id=21627

Py_Main should be defined in main.o. Please to "ar tv
libpython1.6.a" to verify that main.o is really there, do
"nm main.o" to verify that it really provides Py_Main.
If not, please try wether rebuilding from a clean tree helps
(or correct the error manually, e.g. by adding main.o to
libpython1.6.a)

In any case,Python 1.6 is not maintained anymore: so if
there is a bug in it, it won't be fixed. Please try to
install Python 2.0 instead, or go back to 1.5.2, which is
known to work flawless on Solaris.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411845&group_id=5470


From noreply@sourceforge.net  Fri Mar 30 06:59:44 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 29 Mar 2001 22:59:44 -0800
Subject: [Python-bugs-list] [ python-Bugs-411881 ] Use of "except:" in modules
Message-ID: <E14issq-0007kf-00@usw-sf-web3.sourceforge.net>

Bugs item #411881, was updated on 2001-03-28 04:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411881&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Itamar Shtull-Trauring (itamar)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Use of "except:" in modules

Initial Comment:
A large amount of modules in the standard library use
"except:" instead of specifying the exceptions to be
caught. In some cases this may be correct, but I think
in most cases this not true and this may cause
problems. Here's the list of modules, which I got by
doing:

   grep "except:" *.py | cut -f 1 -d " " | sort | uniq

Bastion.py
CGIHTTPServer.py
Cookie.py
SocketServer.py
anydbm.py
asyncore.py
bdb.py
cgi.py
chunk.py
cmd.py
code.py
compileall.py
doctest.py
fileinput.py
formatter.py
getpass.py
htmllib.py
imaplib.py
inspect.py
locale.py
locale.py
mailcap.py
mhlib.py
mimetools.py
mimify.py
os.py
pdb.py
popen2.py
posixfile.py
pre.py
pstats.py
pty.py
pyclbr.py
pydoc.py
repr.py
rexec.py
rfc822.py
shelve.py
shutil.py
tempfile.py
threading.py
traceback.py
types.py
unittest.py
urllib.py
zipfile.py


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2001-03-29 22:59

Message:
Logged In: YES 
user_id=21627

Can you identify modules where catching everything is
incorrect, and propose changes to correct them. This should
be done one-by-one, with careful analysis in each case, and
may take well months or years to complete.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411881&group_id=5470


From noreply@sourceforge.net  Fri Mar 30 07:27:50 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 29 Mar 2001 23:27:50 -0800
Subject: [Python-bugs-list] [ python-Bugs-412214 ] ZipFile constructor leaves files open
Message-ID: <E14itK2-00035M-00@usw-sf-web1.sourceforge.net>

Bugs item #412214, was updated on 2001-03-29 07:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=412214&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Jens Quade (snejsource)
Assigned to: Nobody/Anonymous (nobody)
Summary: ZipFile constructor leaves files open

Initial Comment:
During the construction of a ZipFile object, a 
file is opened and assigned to self.fp.

If anything goes wrong, i.e. the file is not a zipfile,
it is not closed explicitly.  

On Windows, this does not work:

import zipfile, os

filename="test.zip" # it's a broken one
try:
  zf=zipfile.ZipFile(filename)
  zf.close()
finally:
  os.unlink(zipfile)

=> OSError: [errno 13] Permission denied "test.zip"

(on Unix, the file stays open too, but unlink doesn't
fail)


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2001-03-29 23:27

Message:
Logged In: YES 
user_id=21627

Normally, the file should be closed when the last reference
to the zipfile is dropped. In this case, the traceback holds
onto the innermost frame (i.e. the one of __init__), which
holds onto self, which is the ZipFile. I agree this should
be fixed in __init__.

----------------------------------------------------------------------

Comment By: Jens Quade (snejsource)
Date: 2001-03-29 08:27

Message:
Logged In: YES 
user_id=137089

os.unlink(zipfile) should read os.unlink(filename). 

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=412214&group_id=5470


From noreply@sourceforge.net  Fri Mar 30 10:54:50 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 30 Mar 2001 02:54:50 -0800
Subject: [Python-bugs-list] [ python-Bugs-411881 ] Use of "except:" in modules
Message-ID: <E14iwYM-0005S2-00@usw-sf-web1.sourceforge.net>

Bugs item #411881, was updated on 2001-03-28 04:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411881&group_id=5470

Category: Python Library
Group: None
Status: Open
>Priority: 3
Submitted By: Itamar Shtull-Trauring (itamar)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Use of "except:" in modules

Initial Comment:
A large amount of modules in the standard library use
"except:" instead of specifying the exceptions to be
caught. In some cases this may be correct, but I think
in most cases this not true and this may cause
problems. Here's the list of modules, which I got by
doing:

   grep "except:" *.py | cut -f 1 -d " " | sort | uniq

Bastion.py
CGIHTTPServer.py
Cookie.py
SocketServer.py
anydbm.py
asyncore.py
bdb.py
cgi.py
chunk.py
cmd.py
code.py
compileall.py
doctest.py
fileinput.py
formatter.py
getpass.py
htmllib.py
imaplib.py
inspect.py
locale.py
locale.py
mailcap.py
mhlib.py
mimetools.py
mimify.py
os.py
pdb.py
popen2.py
posixfile.py
pre.py
pstats.py
pty.py
pyclbr.py
pydoc.py
repr.py
rexec.py
rfc822.py
shelve.py
shutil.py
tempfile.py
threading.py
traceback.py
types.py
unittest.py
urllib.py
zipfile.py


----------------------------------------------------------------------

>Comment By: Itamar Shtull-Trauring (itamar)
Date: 2001-03-30 02:54

Message:
Logged In: YES 
user_id=32065

inspect.py should be removed from this list, the use is
correct.

In general, I just submitted this bug so that when people
are editing a module they'll notice these things, since in
some cases only someone who knows the code very well can
know if the "expect:" is needed or not.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-03-29 22:59

Message:
Logged In: YES 
user_id=21627

Can you identify modules where catching everything is
incorrect, and propose changes to correct them. This should
be done one-by-one, with careful analysis in each case, and
may take well months or years to complete.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411881&group_id=5470


From noreply@sourceforge.net  Fri Mar 30 10:59:09 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 30 Mar 2001 02:59:09 -0800
Subject: [Python-bugs-list] [ python-Bugs-412436 ] compileall doesn't notice syntax errors
Message-ID: <E14iwcX-0003zE-00@usw-sf-web2.sourceforge.net>

Bugs item #412436, was updated on 2001-03-30 02:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=412436&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: compileall doesn't notice syntax errors

Initial Comment:
compileall.py returns an exit code to indicate the
success or failure of compilation.  This feature was
added in compileall.py revision 1.7 in response to
distutils message 
http://mail.python.org/pipermail/distutils-sig/1999-March/000201.html

This is not as useful as it looks because a prior
change to py_compile.py (revision 1.13) catches syntax
errors, hiding them completely from compileall.py, so
compileall.py can't report the failure to its caller.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=412436&group_id=5470


From noreply@sourceforge.net  Fri Mar 30 12:25:01 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 30 Mar 2001 04:25:01 -0800
Subject: [Python-bugs-list] [ python-Bugs-412402 ] ColorDelegator.py assigns to __debug__
Message-ID: <E14ixxd-0006T2-00@usw-sf-web1.sourceforge.net>

Bugs item #412402, was updated on 2001-03-29 22:49
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=412402&group_id=5470

Category: IDLE
Group: None
>Status: Closed
Priority: 5
Submitted By: Martin v. Löwis (loewis)
Assigned to: Guido van Rossum (gvanrossum)
Summary: ColorDelegator.py assigns to __debug__

Initial Comment:
With the current CVS, when running IDLE, I get the
traceback

  File
"/usr/local/lib/python2.1/site-packages/idlelib/PyShell
.py", line 15, in ?
    from EditorWindow import EditorWindow,
fixwordbreaks
  File
"/usr/local/lib/python2.1/site-packages/idlelib/EditorWindow.py",
line 88, in ?
    class EditorWindow:
  File
"/usr/local/lib/python2.1/site-packages/idlelib/EditorWindow.py",
line 91, in EditorWindow
    from ColorDelegator import ColorDelegator
  File
"/usr/local/lib/python2.1/site-packages/idlelib/ColorDelegator.py",
line
13
    __debug__ = 0

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-30 04:25

Message:
Logged In: YES 
user_id=6380

That's not the current CVS for IDLE.  I fixed this before
Jeremy even checked in his prohibition of assignment to
__debug__.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=412402&group_id=5470


From noreply@sourceforge.net  Fri Mar 30 14:09:17 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 30 Mar 2001 06:09:17 -0800
Subject: [Python-bugs-list] [ python-Bugs-408820 ] 'install -d' fails on BSDI systems.
Message-ID: <E14izaX-0002b9-00@usw-sf-web3.sourceforge.net>

Bugs item #408820, was updated on 2001-03-15 08:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408820&group_id=5470

Category: Installation
Group: Platform-specific
Status: Open
Priority: 6
Submitted By: Thomas Wouters (twouters)
>Assigned to: Neil Schemenauer (nascheme)
Summary: 'install -d' fails on BSDI systems.

Initial Comment:
Apparently the Makefile was changed to use 'install -d'
to create directories. This does not work on BSDI. It
seems to be an autoconf failure (since configure.in
just contains 'AC_PROG_INSTALL' but I haven't
experienced this before, with other software or with
Python.


----------------------------------------------------------------------

>Comment By: Thomas Wouters (twouters)
Date: 2001-03-30 06:09

Message:
Logged In: YES 
user_id=34209

Nope, doesn't work. In fact, it royally screws my
installation... However, if you change 'install-sh' to
'install-sh -c', it does work properly ;) Can we check in a
modified version before the final release ? That would be
nice!


----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2001-03-21 15:44

Message:
Logged In: YES 
user_id=35752

Thomas, can you give this patch a go?

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2001-03-20 07:53

Message:
Logged In: YES 
user_id=11375

Makefile stuff is Neil's province.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-03-17 22:04

Message:
Logged In: YES 
user_id=31435

Assigned to Andrew because he's been known to succeed when 
installing things <ahem>.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408820&group_id=5470


From noreply@sourceforge.net  Fri Mar 30 15:01:21 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 30 Mar 2001 07:01:21 -0800
Subject: [Python-bugs-list] [ python-Bugs-412500 ] Unstable sort
Message-ID: <E14j0Ov-0003FP-00@usw-sf-web3.sourceforge.net>

Bugs item #412500, was updated on 2001-03-30 07:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=412500&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Tomasz Kowaltowski (kowaltowski)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unstable sort

Initial Comment:
The "sort" method for sequences uses an unstable
algorithm, ie, elements with equal keys may have their
original order not preserved.  It isn't exactly a bug,
but it can be annoying.  It seems that most sort
utilities are stable.

I am using:

   Python 2.0 (#1, Mar  1 2001, 15:35:16) 

-- Tomasz Kowaltowski

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=412500&group_id=5470


From noreply@sourceforge.net  Fri Mar 30 19:31:47 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 30 Mar 2001 11:31:47 -0800
Subject: [Python-bugs-list] [ python-Bugs-412402 ] ColorDelegator.py assigns to __debug__
Message-ID: <E14j4cd-0008Iu-00@usw-sf-web2.sourceforge.net>

Bugs item #412402, was updated on 2001-03-29 22:49
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=412402&group_id=5470

Category: IDLE
Group: None
Status: Closed
Priority: 5
Submitted By: Martin v. Löwis (loewis)
Assigned to: Guido van Rossum (gvanrossum)
Summary: ColorDelegator.py assigns to __debug__

Initial Comment:
With the current CVS, when running IDLE, I get the
traceback

  File
"/usr/local/lib/python2.1/site-packages/idlelib/PyShell
.py", line 15, in ?
    from EditorWindow import EditorWindow,
fixwordbreaks
  File
"/usr/local/lib/python2.1/site-packages/idlelib/EditorWindow.py",
line 88, in ?
    class EditorWindow:
  File
"/usr/local/lib/python2.1/site-packages/idlelib/EditorWindow.py",
line 91, in EditorWindow
    from ColorDelegator import ColorDelegator
  File
"/usr/local/lib/python2.1/site-packages/idlelib/ColorDelegator.py",
line
13
    __debug__ = 0

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2001-03-30 11:31

Message:
Logged In: YES 
user_id=21627

Sorry, I had a sticky tag on IDLE that prevented usage of
the changed code.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-30 04:25

Message:
Logged In: YES 
user_id=6380

That's not the current CVS for IDLE.  I fixed this before
Jeremy even checked in his prohibition of assignment to
__debug__.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=412402&group_id=5470


From noreply@sourceforge.net  Fri Mar 30 20:12:45 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 30 Mar 2001 12:12:45 -0800
Subject: [Python-bugs-list] [ python-Bugs-412500 ] Unstable sort
Message-ID: <E14j5GH-0000Bz-00@usw-sf-web2.sourceforge.net>

Bugs item #412500, was updated on 2001-03-30 07:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=412500&group_id=5470

Category: Python Library
>Group: Not a Bug
>Status: Closed
Priority: 5
Submitted By: Tomasz Kowaltowski (kowaltowski)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unstable sort

Initial Comment:
The "sort" method for sequences uses an unstable
algorithm, ie, elements with equal keys may have their
original order not preserved.  It isn't exactly a bug,
but it can be annoying.  It seems that most sort
utilities are stable.

I am using:

   Python 2.0 (#1, Mar  1 2001, 15:35:16) 

-- Tomasz Kowaltowski

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-03-30 12:12

Message:
Logged In: YES 
user_id=31435

This is functioning as designed, and no practical variant 
of quicksort or samplesort is stable.  I tried a dozen 
implementations of stable algorithms for list.sort(), but 
they were all significantly slower and/or more space-
consuming than the samplesort/binary-insertion hybrid 
Python uses.

Most apps simply don't care about stability, so by default 
Python shouldn't make people pay extra for it.  If your 
apps do care, you can take your sequence x and apply .sort
() to the derived sequence

zip(x, range(len(x)))

instead.  No two elements in the derived list compare 
equal, and because comparison of tuples is done 
lexicographically, tagging each original element with its 
original index preserves the original order of equal 
original elements.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=412500&group_id=5470


From noreply@sourceforge.net  Sat Mar 31 00:03:46 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 30 Mar 2001 16:03:46 -0800
Subject: [Python-bugs-list] [ python-Bugs-408820 ] 'install -d' fails on BSDI systems.
Message-ID: <E14j8rq-0007hS-00@usw-sf-web3.sourceforge.net>

Bugs item #408820, was updated on 2001-03-15 08:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408820&group_id=5470

Category: Installation
Group: Platform-specific
>Status: Closed
Priority: 6
Submitted By: Thomas Wouters (twouters)
Assigned to: Neil Schemenauer (nascheme)
Summary: 'install -d' fails on BSDI systems.

Initial Comment:
Apparently the Makefile was changed to use 'install -d'
to create directories. This does not work on BSDI. It
seems to be an autoconf failure (since configure.in
just contains 'AC_PROG_INSTALL' but I haven't
experienced this before, with other software or with
Python.


----------------------------------------------------------------------

>Comment By: Neil Schemenauer (nascheme)
Date: 2001-03-30 16:03

Message:
Logged In: YES 
user_id=35752

Checked in with the -c fix.  Thanks for the testing Thomas.


----------------------------------------------------------------------

Comment By: Thomas Wouters (twouters)
Date: 2001-03-30 06:09

Message:
Logged In: YES 
user_id=34209

Nope, doesn't work. In fact, it royally screws my
installation... However, if you change 'install-sh' to
'install-sh -c', it does work properly ;) Can we check in a
modified version before the final release ? That would be
nice!


----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2001-03-21 15:44

Message:
Logged In: YES 
user_id=35752

Thomas, can you give this patch a go?

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2001-03-20 07:53

Message:
Logged In: YES 
user_id=11375

Makefile stuff is Neil's province.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-03-17 22:04

Message:
Logged In: YES 
user_id=31435

Assigned to Andrew because he's been known to succeed when 
installing things <ahem>.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408820&group_id=5470


From noreply@sourceforge.net  Sat Mar 31 11:59:46 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 31 Mar 2001 03:59:46 -0800
Subject: [Python-bugs-list] [ python-Bugs-412682 ] Cannot play solitaire - buggy Canvas.py?
Message-ID: <E14jK2k-0005WH-00@usw-sf-web1.sourceforge.net>

Bugs item #412682, was updated on 2001-03-31 03:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=412682&group_id=5470

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Alastair Burt (alburt)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cannot play solitaire - buggy Canvas.py?

Initial Comment:
To test tkinter in my newly installed Python 2.0, I
tried Demos/tkinter/guido/soliatire.py. This bombed
with the following message:
Traceback (most recent call last):
  File "solitaire.py", line 637, in ?
    main()
  File "solitaire.py", line 632, in main
    game = Solitaire(root)
  File "solitaire.py", line 570, in __init__
    self.deck.fill()
  File "solitaire.py", line 412, in fill
    self.add(Card(suit, value, self.game.canvas))
  File "solitaire.py", line 295, in add
    card.tkraise()
  File "solitaire.py", line 200, in tkraise
    self.group.tkraise()
  File
"/home/burt/lib/python/lib/python2.0/lib-tk/Canvas.py",
line 177, in tkraise
    self._do('tag_raise', aboveThis)
  File
"/home/burt/lib/python/lib/python2.0/lib-tk/Canvas.py",
line 131, in _do
    return self.canvas._do(cmd, (self.tag,) +
_flatten(args))
  File
"/home/burt/lib/python/lib/python2.0/lib-tk/Tkinter.py",
line 1771, in _do
    return self.tk.call((self._w, name) + args)
TclError: bad option "tag_raise": must be addtag, bbox,
bind, canvasx, canvasy, cget, configure, coords,
create, dchars, delete, dtag, find, focus, gettags,
icursor, index, insert, itemcget, itemconfigure, lower,
move, postscript, raise, scale, scan, select, type,
xview, or yview

I managed to fix this with the following kludge to
Canvas.py:

*** Canvas.py	2001/03/31 10:55:24	1.1
--- Canvas.py	2001/03/31 11:38:12
***************
*** 170,180 ****
  	def config(self, cnf={}, **kw):
  		return self.canvas.itemconfigure(self.tag,
_cnfmerge((cnf,kw)))
  	def lower(self, belowThis=None):
! 		self._do('tag_lower', belowThis)
  	def move(self, xAmount, yAmount):
  		self._do('move', xAmount, yAmount)
  	def tkraise(self, aboveThis=None):
! 		self._do('tag_raise', aboveThis)
  	lift = tkraise
  	def scale(self, xOrigin, yOrigin, xScale, yScale):
  		self._do('scale', xOrigin, yOrigin, xScale, yScale)
--- 170,180 ----
  	def config(self, cnf={}, **kw):
  		return self.canvas.itemconfigure(self.tag,
_cnfmerge((cnf,kw)))
  	def lower(self, belowThis=None):
! 		self._do('lower', belowThis)
  	def move(self, xAmount, yAmount):
  		self._do('move', xAmount, yAmount)
  	def tkraise(self, aboveThis=None):
! 		self._do('raise', aboveThis)
  	lift = tkraise
  	def scale(self, xOrigin, yOrigin, xScale, yScale):
  		self._do('scale', xOrigin, yOrigin, xScale, yScale


--- Alastair

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=412682&group_id=5470


From noreply@sourceforge.net  Sat Mar 31 17:30:20 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 31 Mar 2001 09:30:20 -0800
Subject: [Python-bugs-list] [ python-Bugs-412718 ] Konqueror mis-spelled
Message-ID: <E14jPCe-0006I1-00@usw-sf-web3.sourceforge.net>

Bugs item #412718, was updated on 2001-03-31 09:30
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=412718&group_id=5470

Category: Documentation
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Konqueror mis-spelled

Initial Comment:
In the docs for module "webbrowser" 
(http://www.python.org/doc/current/lib/module-webbrowser.html), 
the KDE program Konqueror has been spelled 
"Konquerer" several times.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=412718&group_id=5470


From noreply@sourceforge.net  Sat Mar 31 19:08:11 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 31 Mar 2001 11:08:11 -0800
Subject: [Python-bugs-list] [ python-Bugs-412718 ] Konqueror mis-spelled
Message-ID: <E14jQjL-0001jI-00@usw-sf-web1.sourceforge.net>

Bugs item #412718, was updated on 2001-03-31 09:30
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=412718&group_id=5470

Category: Documentation
Group: None
>Status: Closed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Konqueror mis-spelled

Initial Comment:
In the docs for module "webbrowser" 
(http://www.python.org/doc/current/lib/module-webbrowser.html), 
the KDE program Konqueror has been spelled 
"Konquerer" several times.


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-03-31 11:08

Message:
Logged In: YES 
user_id=3066

This has already been corrected in the documentation sources.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=412718&group_id=5470