From noreply@sourceforge.net  Mon Apr  2 15:14:33 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 02 Apr 2001 07:14:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-413135 ] urllib2 fails with proxy requiring auth
Message-ID: <E14k56H-0001Bp-00@usw-sf-web3.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore (pmoore)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 fails with proxy requiring auth

Initial Comment:
The following program:

import urllib2

proxy_info = {
    'user' : 'my_name', 'pass' : 'my_pass',
    'host' : "my-proxy", 'port' : 80
}
 
# build a new opener that uses a proxy requiring
# authorization
proxy_support = urllib2.ProxyHandler(
    {"http" :
     "http://%(user)s:%(pass)s@%(host)s:%(port)d"
     % proxy_info})
opener = urllib2.build_opener(proxy_support, 
urllib2.HTTPHandler)
 
# install it
urllib2.install_opener(opener)
 
f = urllib2.urlopen('http://www.python.org/')
print f.headers
print f.read()


fails with the following error on Python 2.1b2 (on 
Windows)

C:\Data>python21 proxy_auth.py
Traceback (most recent call last):
  File "proxy_auth.py", line 18, in ?
    f = urllib2.urlopen('http://www.python.org/')
  File "c:\applications\python21\lib\urllib2.py", line 
135, in urlopen
    return _opener.open(url, data)
  File "c:\applications\python21\lib\urllib2.py", line 
318, in open
    '_open', req)
  File "c:\applications\python21\lib\urllib2.py", line 
297, in _call_chain
    result = func(*args)
  File "c:\applications\python21\lib\urllib2.py", line 
823, in http_open
    return self.do_open(httplib.HTTP, req)
  File "c:\applications\python21\lib\urllib2.py", line 
801, in do_open
    raise URLError(err)
urllib2.URLError: <urlopen error host not found>

A similar error occurred in beta 1, but this was 
reported as bug 406683. The fix is in beta 2. I 
applied the fix manually in beta 1, and it worked, so 
I can only assume that something else changed in the 
transition from beta 1 to beta 2, which broke this 
again.


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

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


From noreply@sourceforge.net  Mon Apr  2 16:05:49 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 02 Apr 2001 08:05:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-413144 ] sdist can't create empty directories
Message-ID: <E14k5tt-0005fb-00@usw-sf-web2.sourceforge.net>

Bugs item #413144, was updated on 2001-04-02 08:05
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=413144&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: sdist can't create empty directories

Initial Comment:
If a file fails an os.path.isfile()
check, sdist.py skips it and prints a warning.  That's
probably worth
loosening so an empty directory can be created in a
source distribution by listing it in the MANIFEST.



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

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


From noreply@sourceforge.net  Mon Apr  2 21:02:53 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 02 Apr 2001 13:02:53 -0700
Subject: [Python-bugs-list] [ python-Bugs-407300 ] Win32: pydoc command isn't executable
Message-ID: <E14kAXN-0001Du-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: Closed
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-04-02 13:02

Message:
Logged In: YES 
user_id=31435

Closing again -- AMK's pydoc is no longer copied to the 
install directory (and probably should not have been to 
begin with ...).

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

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  Mon Apr  2 21:04:57 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 02 Apr 2001 13:04:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-406563 ] test_long loops openbsd2.8 i386
Message-ID: <E14kAZN-0001FH-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: Irreproducible
>Status: Closed
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-04-02 13:04

Message:
Logged In: YES 
user_id=31435

As threatened two weeks ago, closing for lack of info, and 
presumed a platform/config glitch unique to the anonymous 
submitter (nobody else has reported this).

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

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  Mon Apr  2 21:06:49 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 02 Apr 2001 13:06:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-216289 ] Programs using Tkinter sometimes can't shut down (Windows)
Message-ID: <E14kAbB-0001Gs-00@usw-sf-web1.sourceforge.net>

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

Category: Windows
Group: 3rd Party
>Status: Closed
Priority: 3
Submitted By: Tim Peters (tim_one)
Assigned to: Tim Peters (tim_one)
Summary: Programs using Tkinter sometimes can't shut down (Windows)

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

python ../tool/idle/idle.pyw

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

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


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

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

That's my report on the problem.

Cheers,

Joe


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

>Comment By: Tim Peters (tim_one)
Date: 2001-04-02 13:06

Message:
Logged In: YES 
user_id=31435

No sign of progress on this presumed Tk/Tcl Windows bug in 
over 3 months, so closing it for lack of hope.

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

Comment By: Doug Henderson (djhender)
Date: 2001-02-05 21:13

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

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

Comment By: Tim Peters (tim_one)
Date: 2000-12-12 18:00

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

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

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-12-12 12:58

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

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

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


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

Comment By: Nobody/Anonymous (nobody)
Date: 2000-10-15 09:47

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

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

More later.

</F>

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

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

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

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

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

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

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

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

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

Comment By: Tim Peters (tim_one)
Date: 2000-10-07 00:37

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

+ Happens under release and debug builds.

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

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

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

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

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

+ The processes are not accumulating cycles.

+ Smells like deadlock.

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

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


From noreply@sourceforge.net  Mon Apr  2 21:07:54 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 02 Apr 2001 13:07:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-407019 ] Python-2.1 does not compile under cygwin
Message-ID: <E14kAcE-0001Hc-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: Closed
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-04-02 13:07

Message:
Logged In: YES 
user_id=31435

Closing for lack of followup info, and that Jason did all 
he could to set the anonymous submitter straight.

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

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 Apr  2 21:16:15 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 02 Apr 2001 13:16:15 -0700
Subject: [Python-bugs-list] [ python-Bugs-410708 ] Condition.wait() and KeyboardInterrupt
Message-ID: <E14kAkJ-00007P-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: Closed
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)
>


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

>Comment By: Tim Peters (tim_one)
Date: 2001-04-02 13:16

Message:
Logged In: YES 
user_id=31435

Looked reasonable to me -- thanks.  Applied to 
threading.py, rev 1.12.

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

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


From noreply@sourceforge.net  Tue Apr  3 05:56:56 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 02 Apr 2001 21:56:56 -0700
Subject: [Python-bugs-list] [ python-Bugs-413320 ] sys.argv should always be a sequence
Message-ID: <E14kIsC-0007NK-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Stephen McInerney (smcinerney)
Assigned to: Nobody/Anonymous (nobody)
Summary: sys.argv should always be a sequence

Initial Comment:
Hi,

It seems that sys.argv is not a sequence if there are
no args passed. Hence references to len() or
non-existent element sys.argv[1] cause a TypeError
which we have to kludge around with a try...except
TypeError. sys.argv should always be a sequence.

Python 1.6 (#4, Sep 13 2000, 17:24:07)  [GCC
egcs-2.91.66 19990314 (egcs-1.1.2 release)] on sunos5
(Solaris 8)

Best regards,
Stephen

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

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


From noreply@sourceforge.net  Wed Apr  4 01:42:03 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 03 Apr 2001 17:42:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-413582 ] g++ must be called for c++ extensions
Message-ID: <E14kbN5-00060e-00@usw-sf-web2.sourceforge.net>

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

Category: Distutils
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: g++ must be called for c++ extensions

Initial Comment:
When building c++ extension using distutils setup,
the compiler that was used to build python distribution
is always called. On Linux, it is normally gcc.
When gcc is called to link shared library, it does not
link certain c++ runtime stuff. As a result, when
extension is imported, missing symbols are reported,
e.g.:
>>> import ex_ext1
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError: ./ex_ext1.so: undefined symbol:
__vt_13runtime_error
>>>
I tried to use "extra_link_args = ['-x c++']" in
setup.py (it tells gcc to link as c++), but that gets
added to the end of compiler's command line, which
results in:
gcc -shared build/temp.linux-i686-2.1/ex_ext1.o
-L../boost/libs/python -lboost_python -o
build/lib.linux-i686-2.1/ex_ext1.so -x c++
gcc: Warning: `-x  c++' after last input file has no
effect

Proposed solution: either use CXX= variable from Python
Makefile when c++ files are involved, or prepend
extra_link_args to compiler's arguments instead of
appending them.


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

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


From noreply@sourceforge.net  Wed Apr  4 15:16:35 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 04 Apr 2001 07:16:35 -0700
Subject: [Python-bugs-list] [ python-Bugs-230029 ] [HP-UX] Python chokes on pthread_mutex_init
Message-ID: <E14ko5L-0006DK-00@usw-sf-web1.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: Harri Pasanen (harripasanen)
Date: 2001-04-04 07:16

Message:
Logged In: YES 
user_id=77088

This bug has been present a long time, I've reported it
myself sometime last year (maybe for Python 2.0 beta, and
for Python 1.6).  

Basically, autoconf gets wrong the required threading
library. For HP-UX 10.20 -lcma is the correct one I believe.

For HP-UX 11.x -lpthread should be used.

#210665 has a fairly long thread on this.  This item
(#230029) are just the symptoms the bug shows when present.

Well, as I have access both to HP-UX 11.00 and HP-UX 10.20
machines, I could help to put this problem to rest for
Python 2.1.

-Harri

PS. As I'm currently logged in I presume you'll get my
coordinates automatically?  Just in case, harri dot pasanen
at trema dot com.









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

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  Wed Apr  4 15:19:19 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 04 Apr 2001 07:19:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-231377 ] [HP-UX] Python chokes on pthread_mutex_init
Message-ID: <E14ko7z-0004Dg-00@usw-sf-web2.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: Harri Pasanen (harripasanen)
Date: 2001-04-04 07:19

Message:
Logged In: YES 
user_id=77088

If it is HP-UX 11.00, just perform the final link of python
manually, replacing -lcma with -lpthread

-Harri

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

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  Wed Apr  4 15:31:30 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 04 Apr 2001 07:31:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-413710 ] getopt module bug.
Message-ID: <E14koJm-0006OP-00@usw-sf-web1.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Harri Pasanen (harripasanen)
Assigned to: Nobody/Anonymous (nobody)
Summary: getopt module bug.

Initial Comment:
This is too subtle to be a feature, so it must be a
bug:

getopt.getopt(['--srv','x'],'',['srv=','srva=','srvb='])

and 

getopt.getopt(['--srv0','x'],'',['srv0=','srv1=','srv2='])

work.  But the following does not:

>>> getopt.getopt(['--srv','x'],
'',['srv=','srv1=','srv2='])
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.0/getopt.py", line 74,
in getopt
    opts, args = do_longs(opts, args[0][2:], longopts,
args[1:])
  File "/usr/local/lib/python2.0/getopt.py", line 87,
in do_longs
    has_arg, opt = long_has_args(opt, longopts)
  File "/usr/local/lib/python2.0/getopt.py", line 109,
in long_has_args
    raise GetoptError('option --%s not a unique prefix'
% opt, opt)
getopt.GetoptError: option --srv not a unique
prefix                            

Reason is that'=' is included the option sort, and it
sorts after numbers.  

-Harri

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

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


From noreply@sourceforge.net  Wed Apr  4 15:50:56 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 04 Apr 2001 07:50:56 -0700
Subject: [Python-bugs-list] [ python-Bugs-413714 ] ccpython.cc build failure in sep. tree
Message-ID: <E14koca-0008NB-00@usw-sf-web3.sourceforge.net>

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

Category: Build
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: ccpython.cc build failure in sep. tree

Initial Comment:
When building in a separate directory from the source 
tree, ccpython.cc cannot be built since the rule in 
Modules/Makefile.pre.in is currently:

ccpython.o: ccpython.cc
	$(CXX) $(CFLAGS) -c $*.cc

instead of

ccpython.o: ccpython.cc
	$(CXX) $(CFLAGS) -c $<

Thanks,

Guy.

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

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


From noreply@sourceforge.net  Wed Apr  4 19:04:24 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 04 Apr 2001 11:04:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-413320 ] sys.argv should always be a sequence
Message-ID: <E14krdo-0001em-00@usw-sf-web3.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Stephen McInerney (smcinerney)
>Assigned to: Jeremy Hylton (jhylton)
Summary: sys.argv should always be a sequence

Initial Comment:
Hi,

It seems that sys.argv is not a sequence if there are
no args passed. Hence references to len() or
non-existent element sys.argv[1] cause a TypeError
which we have to kludge around with a try...except
TypeError. sys.argv should always be a sequence.

Python 1.6 (#4, Sep 13 2000, 17:24:07)  [GCC
egcs-2.91.66 19990314 (egcs-1.1.2 release)] on sunos5
(Solaris 8)

Best regards,
Stephen

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

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-04-04 11:04

Message:
Logged In: YES 
user_id=31392

Can you provide an example of how you invoke Python with no
args and what value sys.argv[] has?  I can't reproduce.


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

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


From noreply@sourceforge.net  Wed Apr  4 19:04:37 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 04 Apr 2001 11:04:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-412214 ] ZipFile constructor leaves files open
Message-ID: <E14kre1-0001f1-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: Fred L. Drake, Jr. (fdrake)
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  Wed Apr  4 19:04:52 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 04 Apr 2001 11:04:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-412230 ] mailbox.BabylMailbox, missing headers
Message-ID: <E14kreG-0001fN-00@usw-sf-web3.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: Barry Warsaw (bwarsaw)
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  Wed Apr  4 19:05:06 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 04 Apr 2001 11:05:06 -0700
Subject: [Python-bugs-list] [ python-Bugs-413135 ] urllib2 fails with proxy requiring auth
Message-ID: <E14kreU-0001fp-00@usw-sf-web3.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore (pmoore)
>Assigned to: Moshe Zadka (moshez)
Summary: urllib2 fails with proxy requiring auth

Initial Comment:
The following program:

import urllib2

proxy_info = {
    'user' : 'my_name', 'pass' : 'my_pass',
    'host' : "my-proxy", 'port' : 80
}
 
# build a new opener that uses a proxy requiring
# authorization
proxy_support = urllib2.ProxyHandler(
    {"http" :
     "http://%(user)s:%(pass)s@%(host)s:%(port)d"
     % proxy_info})
opener = urllib2.build_opener(proxy_support, 
urllib2.HTTPHandler)
 
# install it
urllib2.install_opener(opener)
 
f = urllib2.urlopen('http://www.python.org/')
print f.headers
print f.read()


fails with the following error on Python 2.1b2 (on 
Windows)

C:\Data>python21 proxy_auth.py
Traceback (most recent call last):
  File "proxy_auth.py", line 18, in ?
    f = urllib2.urlopen('http://www.python.org/')
  File "c:\applications\python21\lib\urllib2.py", line 
135, in urlopen
    return _opener.open(url, data)
  File "c:\applications\python21\lib\urllib2.py", line 
318, in open
    '_open', req)
  File "c:\applications\python21\lib\urllib2.py", line 
297, in _call_chain
    result = func(*args)
  File "c:\applications\python21\lib\urllib2.py", line 
823, in http_open
    return self.do_open(httplib.HTTP, req)
  File "c:\applications\python21\lib\urllib2.py", line 
801, in do_open
    raise URLError(err)
urllib2.URLError: <urlopen error host not found>

A similar error occurred in beta 1, but this was 
reported as bug 406683. The fix is in beta 2. I 
applied the fix manually in beta 1, and it worked, so 
I can only assume that something else changed in the 
transition from beta 1 to beta 2, which broke this 
again.


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

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


From noreply@sourceforge.net  Wed Apr  4 19:05:27 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 04 Apr 2001 11:05:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-412086 ] curses module is missing some color vars
Message-ID: <E14krep-0001g6-00@usw-sf-web3.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: A.M. Kuchling (akuchling)
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  Wed Apr  4 19:05:38 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 04 Apr 2001 11:05:38 -0700
Subject: [Python-bugs-list] [ python-Bugs-411508 ] httplib does not support user/pass
Message-ID: <E14krf0-0001gE-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: Greg Stein (gstein)
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  Wed Apr  4 19:05:53 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 04 Apr 2001 11:05:53 -0700
Subject: [Python-bugs-list] [ python-Bugs-410620 ] pydoc installation w.r.t. RPM.
Message-ID: <E14krfF-0001gP-00@usw-sf-web3.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: Ka-Ping Yee (ping)
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  Wed Apr  4 19:06:32 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 04 Apr 2001 11:06:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-413710 ] getopt module bug.
Message-ID: <E14krfs-0001gl-00@usw-sf-web3.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Harri Pasanen (harripasanen)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: getopt module bug.

Initial Comment:
This is too subtle to be a feature, so it must be a
bug:

getopt.getopt(['--srv','x'],'',['srv=','srva=','srvb='])

and 

getopt.getopt(['--srv0','x'],'',['srv0=','srv1=','srv2='])

work.  But the following does not:

>>> getopt.getopt(['--srv','x'],
'',['srv=','srv1=','srv2='])
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.0/getopt.py", line 74,
in getopt
    opts, args = do_longs(opts, args[0][2:], longopts,
args[1:])
  File "/usr/local/lib/python2.0/getopt.py", line 87,
in do_longs
    has_arg, opt = long_has_args(opt, longopts)
  File "/usr/local/lib/python2.0/getopt.py", line 109,
in long_has_args
    raise GetoptError('option --%s not a unique prefix'
% opt, opt)
getopt.GetoptError: option --srv not a unique
prefix                            

Reason is that'=' is included the option sort, and it
sorts after numbers.  

-Harri

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

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


From noreply@sourceforge.net  Wed Apr  4 19:06:55 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 04 Apr 2001 11:06:55 -0700
Subject: [Python-bugs-list] [ python-Bugs-412436 ] compileall doesn't notice syntax errors
Message-ID: <E14krgF-0001h9-00@usw-sf-web3.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: Jeremy Hylton (jhylton)
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  Wed Apr  4 19:07:44 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 04 Apr 2001 11:07:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-413767 ] warn about __debug__ assignment
Message-ID: <E14krh2-0001hh-00@usw-sf-web3.sourceforge.net>

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

Category: Parser/Compiler
Group: None
Status: Open
Priority: 8
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Jeremy Hylton (jhylton)
Summary: warn about __debug__ assignment

Initial Comment:
Back out the change that makes it illegal to assign to
__debug__ and issue a warning instead.


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

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


From noreply@sourceforge.net  Wed Apr  4 19:22:22 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 04 Apr 2001 11:22:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-413710 ] getopt module bug.
Message-ID: <E14krvC-0000tt-00@usw-sf-web1.sourceforge.net>

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

Category: Python Library
Group: None
>Status: Closed
Priority: 5
Submitted By: Harri Pasanen (harripasanen)
>Assigned to: Tim Peters (tim_one)
Summary: getopt module bug.

Initial Comment:
This is too subtle to be a feature, so it must be a
bug:

getopt.getopt(['--srv','x'],'',['srv=','srva=','srvb='])

and 

getopt.getopt(['--srv0','x'],'',['srv0=','srv1=','srv2='])

work.  But the following does not:

>>> getopt.getopt(['--srv','x'],
'',['srv=','srv1=','srv2='])
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.0/getopt.py", line 74,
in getopt
    opts, args = do_longs(opts, args[0][2:], longopts,
args[1:])
  File "/usr/local/lib/python2.0/getopt.py", line 87,
in do_longs
    has_arg, opt = long_has_args(opt, longopts)
  File "/usr/local/lib/python2.0/getopt.py", line 109,
in long_has_args
    raise GetoptError('option --%s not a unique prefix'
% opt, opt)
getopt.GetoptError: option --srv not a unique
prefix                            

Reason is that'=' is included the option sort, and it
sorts after numbers.  

-Harri

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

>Comment By: Tim Peters (tim_one)
Date: 2001-04-04 11:22

Message:
Logged In: YES 
user_id=31435

2.0 getopt was too "clever" here.  Already fixed in 2.1:

>>> getopt.getopt(['--srv','x'],'',['srv=','srv1=','srv2='])
([('--srv', 'x')], [])
>>>


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

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


From noreply@sourceforge.net  Wed Apr  4 19:41:13 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 04 Apr 2001 11:41:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-412214 ] ZipFile constructor leaves files open
Message-ID: <E14ksDR-0006TL-00@usw-sf-web2.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: Tim Peters (tim_one)
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: Fred L. Drake, Jr. (fdrake)
Date: 2001-04-04 11:41

Message:
Logged In: YES 
user_id=3066

I've attached a patch and a test case, but I'm not running Windows.

Tim, can you test the patch and assign it back to me with your comments?

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

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  Wed Apr  4 19:57:38 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 04 Apr 2001 11:57:38 -0700
Subject: [Python-bugs-list] [ python-Bugs-412214 ] ZipFile constructor leaves files open
Message-ID: <E14ksTK-0001Jn-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: Closed
Priority: 5
Submitted By: Jens Quade (snejsource)
Assigned to: Tim Peters (tim_one)
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: Tim Peters (tim_one)
Date: 2001-04-04 11:57

Message:
Logged In: YES 
user_id=31435

Since I had to apply the patch to test it, and it worked 
fine, I checked it in too:

Lib/zipfile.py rev 1.11
Lib/test/test_zipfile.py rev 1.6

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-04-04 11:41

Message:
Logged In: YES 
user_id=3066

I've attached a patch and a test case, but I'm not running Windows.

Tim, can you test the patch and assign it back to me with your comments?

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

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  Wed Apr  4 20:53:02 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 04 Apr 2001 12:53:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-232637 ] can't compile modules on AIX 4.2.1 (for real this time)
Message-ID: <E14ktKw-00073Q-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: Benjamin Collar (bcollar)
Date: 2001-04-04 12:53

Message:
Logged In: YES 
user_id=7170

Hi,

I have a little bad news...I'm at another job now, so I
don't currently have access to the machines I was building
on. I am trying to get permission to use the machine in
order to follow up on this bug; I won't find out if I can
until next week.

Sorry
Ben

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

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  Wed Apr  4 21:07:41 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 04 Apr 2001 13:07:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-230029 ] [HP-UX] Python chokes on pthread_mutex_init
Message-ID: <E14ktZ7-0002kM-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: Tim Peters (tim_one)
Date: 2001-04-04 13:07

Message:
Logged In: YES 
user_id=31435

Harri, there are always HP-UX thread bug reports open, and 
against every release of Python.  A few HP-UX users submit 
patches, other HP-UX users argue about them, Guido takes 
his best guess and checks one or more of the patches in.  
It never solves anything, though -- come the next release, 
we get a fresh batch of HP-UX thread complaints.

It appears that no Python developer uses HP-UX, so we're 
never going to solve this.  If you think you can, please 
submit a patch.  Note that 2.1 final is scheduled for 
release a week from Friday (13-Apr-2001), so there isn't 
much time for this.

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

Comment By: Harri Pasanen (harripasanen)
Date: 2001-04-04 07:16

Message:
Logged In: YES 
user_id=77088

This bug has been present a long time, I've reported it
myself sometime last year (maybe for Python 2.0 beta, and
for Python 1.6).  

Basically, autoconf gets wrong the required threading
library. For HP-UX 10.20 -lcma is the correct one I believe.

For HP-UX 11.x -lpthread should be used.

#210665 has a fairly long thread on this.  This item
(#230029) are just the symptoms the bug shows when present.

Well, as I have access both to HP-UX 11.00 and HP-UX 10.20
machines, I could help to put this problem to rest for
Python 2.1.

-Harri

PS. As I'm currently logged in I presume you'll get my
coordinates automatically?  Just in case, harri dot pasanen
at trema dot com.









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

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  Thu Apr  5 01:23:40 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 04 Apr 2001 17:23:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-413582 ] g++ must be called for c++ extensions
Message-ID: <E14kxYq-00051O-00@usw-sf-web1.sourceforge.net>

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

Category: Distutils
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: g++ must be called for c++ extensions

Initial Comment:
When building c++ extension using distutils setup,
the compiler that was used to build python distribution
is always called. On Linux, it is normally gcc.
When gcc is called to link shared library, it does not
link certain c++ runtime stuff. As a result, when
extension is imported, missing symbols are reported,
e.g.:
>>> import ex_ext1
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError: ./ex_ext1.so: undefined symbol:
__vt_13runtime_error
>>>
I tried to use "extra_link_args = ['-x c++']" in
setup.py (it tells gcc to link as c++), but that gets
added to the end of compiler's command line, which
results in:
gcc -shared build/temp.linux-i686-2.1/ex_ext1.o
-L../boost/libs/python -lboost_python -o
build/lib.linux-i686-2.1/ex_ext1.so -x c++
gcc: Warning: `-x  c++' after last input file has no
effect

Proposed solution: either use CXX= variable from Python
Makefile when c++ files are involved, or prepend
extra_link_args to compiler's arguments instead of
appending them.


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

Comment By: Andrei Tovtchigretchko (andreitd)
Date: 2001-04-04 17:23

Message:
Logged In: YES 
user_id=189208

Follow-up:
If I link with a static library (-lboost_python is
libboost_python.a in bug post example), the problem shows.
If I link with shared c++ library (libboost_python.so),
everything is ok.

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

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


From noreply@sourceforge.net  Thu Apr  5 01:50:44 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 04 Apr 2001 17:50:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-413876 ] rfc822.AddressList methods incorrect
Message-ID: <E14kxz2-0005Ec-00@usw-sf-web3.sourceforge.net>

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

Category: Documentation
Group: None
Status: Open
Priority: 5
Submitted By: Steve Holden (holdenweb)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: rfc822.AddressList methods incorrect

Initial Comment:
The current 2.0, and the latest development, 
documentation shows rfc822.AddressList methods __len__
() and __str__() as requiring arguments. Inspection of 
the 2.0 code shows this to be incorrect. I presume 
this will also be true of 2.1.

Furthermore, the __add__() and __sub__() methods are 
documented as taking a "name" argument, which is 
somewhat misleading since the required argument should 
be another rfc822.AddressList object. It might be 
better to use a more meaningful name such as "alist", 
and document its required type.


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

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


From noreply@sourceforge.net  Thu Apr  5 02:50:45 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 04 Apr 2001 18:50:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-411948 ] SMIME support?
Message-ID: <E14kyv7-0006L1-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: Closed
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

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

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-04-04 18:50

Message:
Logged In: YES 
user_id=31392

No.  This sounds like a good project for a third-party
library.  Why don't you bring it up on comp.lang.python?


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

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


From noreply@sourceforge.net  Thu Apr  5 02:51:48 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 04 Apr 2001 18:51:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-410608 ] popen with threads
Message-ID: <E14kyw8-0006LW-00@usw-sf-web1.sourceforge.net>

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

>Category: Threads
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Tim Peters (tim_one)
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 Apr  5 03:33:45 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 04 Apr 2001 19:33:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-410608 ] popen with threads
Message-ID: <E14kzaj-0005uo-00@usw-sf-web3.sourceforge.net>

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

Category: Threads
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Thomas Wouters (twouters)
Summary: popen with threads

Initial Comment:
This code generate a error

##########################
import threading
import os

class TestPopen( threading.Thread ):

   def run( self ):
      while 1:
         f = os.popen( "ls -l /" )
         lines = f.read()
         f.close()

if __name__ == "__main__":
   for i in range(50):
      t = TestPopen()
      t.start()
###########################

it eventually dies w/ IOErrors in the f.close() calls.

My system is:
Linux RedHat 6.2
Python 1.5.2
I tested in Python 2.0 and the same error occur.




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

>Comment By: Tim Peters (tim_one)
Date: 2001-04-04 19:33

Message:
Logged In: YES 
user_id=31435

Thomas, you want to play with this on Linux?  I already 
gave my best guesses on c.l.py; there's no hope running 
popen stress tests on Win9x, as whether even one popen 
works there one time is a crapshoot.  I assume Mr./Ms. 
Anonymous is running out of system resources, but even if 
so that leaves the question of whether that's 1.5.2's or 
Linux's fault (if it works under current CVS, we can assume 
it was 1.5.2's fault).

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

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


From noreply@sourceforge.net  Thu Apr  5 12:06:19 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 05 Apr 2001 04:06:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-413956 ] 2.1b2 CVS termios no longer compiles
Message-ID: <E14l7al-0000wc-00@usw-sf-web3.sourceforge.net>

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

Category: Build
Group: None
Status: Open
Priority: 5
Submitted By: Mark Favas (mfavas)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.1b2 CVS termios no longer compiles

Initial Comment:
CVS version of 2.1b2 termios module now fails to
compile on Tru64 Unix. The April 5 version of termios.c
has a bunch of new constants defined, protected by
#ifdef's. Unfortunately, some of these constants are
defined in sys/ioctl.h under Tru64 Unix, but not in a
compatible way with constants defined in termios.h.
More detail: compilation fails thusly:
building 'termios' extension
cc -O -Olimit 1500 -I. -I./Include -I/usr/local/include
-IInclude/ -c Modules/termios.c -o
build/temp.osf1-V4.0-alpha-2.1/termios.o
cc: Error: Modules/termios.c, line 662: In the
initializer for termios_constants[142].value, "struct
termio" is an incomplete type, and so has no size.
(sizeincomptyp)
        {"TCGETA", TCGETA},
-------------------^
cc: Error: Modules/termios.c, line 674: In the
initializer for termios_constants[145].value, "struct
termio" is an incomplete type, and so has no size.
(sizeincomptyp)
        {"TCSETA", TCSETA},
-------------------^
cc: Error: Modules/termios.c, line 677: In the
initializer for termios_constants[146].value, "struct
termio" is an incomplete type, and so has no size.
(sizeincomptyp)
        {"TCSETAF", TCSETAF},
--------------------^
cc: Error: Modules/termios.c, line 680: In the
initializer for termios_constants[147].value, "struct
termio" is an incomplete type, and so has no size.
(sizeincomptyp)
        {"TCSETAW", TCSETAW},
--------------------^
WARNING: building of extension "termios" failed:
command 'cc' failed with exit status 1

TCGETA, TCSETA, TCSETAF, and TCSETAW are defined in
/usr/include/sys/ioctl.h as, for example,
#define TCGETA          _IOW('t', 23, struct termio) /*
set termio struct */
which is not compatible with their use in termios.c,
where the expectation is that the constants will be
defined as small integers.

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

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


From noreply@sourceforge.net  Thu Apr  5 13:36:26 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 05 Apr 2001 05:36:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-413980 ] core dump with regrtest.py on SGI
Message-ID: <E14l8zy-00057v-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: core dump with regrtest.py on SGI

Initial Comment:
the 'make test' part of the installation on SGI (IRIX
6.5, 64 bits) ends with
the following output:

running build_scripts
not copying
/tmp_mnt/home/ibiology1/laurent/download/Python-2.1b2a/Tools/scripts/pydoc
(up-to-date)
        find ./Lib -name '*.py[co]' -print | xargs rm
-f
        PYTHONPATH= ./python -tt ./Lib/test/regrtest.py
-l
sh[4]: 1754889 Bus error(coredump)
        PYTHONPATH= ./python -tt ./Lib/test/regrtest.py
-l
sh: 1756018 Bus error(coredump)
*** Error code 138




Laurent

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

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


From noreply@sourceforge.net  Thu Apr  5 17:00:53 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 05 Apr 2001 09:00:53 -0700
Subject: [Python-bugs-list] [ python-Bugs-414032 ] clib option is broken
Message-ID: <E14lCBp-0003LU-00@usw-sf-web3.sourceforge.net>

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

Category: Distutils
Group: None
Status: Open
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: A.M. Kuchling (akuchling)
Summary: clib option is broken

Initial Comment:
You cannot build a source distribution when the setup script contains libraries.

Here is the traceback:

C:\sf\py2exe>setup sdist
running sdist
Traceback (most recent call last):
  File "C:\sf\py2exe\setup.py", line 317, in ?
    package_dir={'py2exe.tools': "tools" + sys.version[:3]},
  File "c:\python20\distutils\core.py", line 138, in setup
    dist.run_commands()
  File "c:\python20\distutils\dist.py", line 903, in run_commands
    self.run_command(cmd)
  File "c:\python20\distutils\dist.py", line 923, in run_command
    cmd_obj.run()
  File "C:\Python20\distutils\command\sdist.py", line 142, in run
    self.get_file_list()
  File "C:\Python20\distutils\command\sdist.py", line 241, in get_file_list
    self.add_defaults()
  File "C:\Python20\distutils\command\sdist.py", line 318, in add_defaults
    self.filelist.extend(build_clib.get_source_files())
  File "c:\python20\distutils\cmd.py", line 107, in __getattr__
    raise AttributeError, attr
AttributeError: get_source_files

C:\sf\py2exe>

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

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


From noreply@sourceforge.net  Thu Apr  5 17:09:47 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 05 Apr 2001 09:09:47 -0700
Subject: [Python-bugs-list] [ python-Bugs-412086 ] curses module is missing some color vars
Message-ID: <E14lCKR-0008WG-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: Closed
Priority: 5
Submitted By: Peter Wilson (pabw)
Assigned to: A.M. Kuchling (akuchling)
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


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

>Comment By: A.M. Kuchling (akuchling)
Date: 2001-04-05 09:09

Message:
Logged In: YES 
user_id=11375

Good point!  Fixed in revision 1.4 of curses/__init__.py,
using a 
slightly modified version of your first patch.  Thanks!

initscr() and start_color() are the only functions which add
more 
variables to the module dictionary, so no additional
wrappers 
should be necessary.

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

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


From noreply@sourceforge.net  Thu Apr  5 17:14:18 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 05 Apr 2001 09:14:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-413980 ] core dump with regrtest.py on SGI
Message-ID: <E14lCOo-0003Tk-00@usw-sf-web3.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: core dump with regrtest.py on SGI

Initial Comment:
the 'make test' part of the installation on SGI (IRIX
6.5, 64 bits) ends with
the following output:

running build_scripts
not copying
/tmp_mnt/home/ibiology1/laurent/download/Python-2.1b2a/Tools/scripts/pydoc
(up-to-date)
        find ./Lib -name '*.py[co]' -print | xargs rm
-f
        PYTHONPATH= ./python -tt ./Lib/test/regrtest.py
-l
sh[4]: 1754889 Bus error(coredump)
        PYTHONPATH= ./python -tt ./Lib/test/regrtest.py
-l
sh: 1756018 Bus error(coredump)
*** Error code 138




Laurent

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

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

Message:
Logged In: YES 
user_id=31435

The first thing to try on an SGI box is to recompile Python 
with optimization turned off, and see whether that makes 
the problem go away (historically, the bulk of "Python 
problems" on SGI turn out to be compiler optimization bugs).

So try that, and see whether the problem goes away.


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

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


From noreply@sourceforge.net  Thu Apr  5 18:51:34 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 05 Apr 2001 10:51:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-406792 ] python2.1b1 core dumps --with-pymalloc
Message-ID: <E14lDuw-0000vW-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-04-05 10:51

Message:
Logged In: NO 

With an updated version of gcc it (python2.1b1) still fails
with -O2 but in a different place.

% gcc --version
2.95.3
% uname -a
HP-UX wvenus B.10.20 A 9000/782 2009382447 two-user license
% gdb
GNU gdb 5.0
(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 SIGSEGV, Segmentation fault.
0x4d984 in PyNumber_CoerceEx (pv=0x7b03c4b4, pw=0x7b03c4b0)
    at Objects/object.c:1175
1175            if (v->ob_type->tp_as_number &&
v->ob_type->tp_as_number->nb_coerce) {


If I remove the -O2 when compiling Objects/object.o then
python builds without a crash.
% gcc -c -g -Wall -Wstrict-prototypes -I. -I./Include
-DHAVE_CONFIG_H  -o Objects/object.o Objects/object.c


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

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 Apr  5 19:27:47 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 05 Apr 2001 11:27:47 -0700
Subject: [Python-bugs-list] [ python-Bugs-231377 ] [HP-UX] Python chokes on pthread_mutex_init
Message-ID: <E14lETz-0004gH-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: T Farrell (glory_2_god)
Date: 2001-04-05 11:27

Message:
Logged In: YES 
user_id=11441

harripasanen has the solution nailed.  Unfortunately, just 
how to do this escapes many people.  I will explain a bit 
more thoroughly, so people who come across this by a google 
search (as I did) will have more info.
This is for HP-UX 11.00, Python-2.0, compiling with GNU 
tools:
./configure --with-threads
make
rm python
cd Modules
gcc -Wl,-E -Wl,+s -Wl,+b/lib/python2.0/lib-dynload \
    python.o ../libpython2.0.a -lnsl -ldld \
    -lpthread -lm -o python
mv python ..
make install

Happy Zoping :)
PS. If you built zope before, don't forget to 
python wo_pcgi.py

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

Comment By: Harri Pasanen (harripasanen)
Date: 2001-04-04 07:19

Message:
Logged In: YES 
user_id=77088

If it is HP-UX 11.00, just perform the final link of python
manually, replacing -lcma with -lpthread

-Harri

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

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  Thu Apr  5 19:59:56 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 05 Apr 2001 11:59:56 -0700
Subject: [Python-bugs-list] [ python-Bugs-414080 ] site-packages initialization
Message-ID: <E14lEz6-0001VL-00@usw-sf-web2.sourceforge.net>

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

Category: Windows
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Ondrej Krajicek (okay)
Assigned to: Nobody/Anonymous (nobody)
Summary: site-packages initialization

Initial Comment:
It seems that site.py does not support site-packages 
on Windows. I do not know whether it is bug 
or "feature".

It does not check neither for site-
packages/subdirectories nor pth files.
Simple workaround is to reproduce
the code which handles site-packages
under un*x.


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

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


From noreply@sourceforge.net  Thu Apr  5 22:33:39 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 05 Apr 2001 14:33:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-406792 ] python2.1b1 core dumps --with-pymalloc
Message-ID: <E14lHNr-0002wC-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-04-05 14:33

Message:
Logged In: NO 

Downloaded python2.1beta2. Used gcc 2.95.3 on HPUX 10.2

This time it blew up in different manner:
PYTHONPATH= ./python ./setup.py build
Fatal Python error: unknown scope for name in __init__(0) in
./Lib/site.py
symbols: {'data': 12, 'self': 12, 'files': 12, 'name': 12,
'None': 264, 'dirs': 12}
locals: {'self': 0}
globals: {'None': 1}

/bin/sh: 22414 Abort
gmake: *** [sharedmods] Error 134

Removed Objects/object.o and rebuilt it without the -O2
option and then the system fully built with no crashes.


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

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

Message:
Logged In: NO 

With an updated version of gcc it (python2.1b1) still fails
with -O2 but in a different place.

% gcc --version
2.95.3
% uname -a
HP-UX wvenus B.10.20 A 9000/782 2009382447 two-user license
% gdb
GNU gdb 5.0
(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 SIGSEGV, Segmentation fault.
0x4d984 in PyNumber_CoerceEx (pv=0x7b03c4b4, pw=0x7b03c4b0)
    at Objects/object.c:1175
1175            if (v->ob_type->tp_as_number &&
v->ob_type->tp_as_number->nb_coerce) {


If I remove the -O2 when compiling Objects/object.o then
python builds without a crash.
% gcc -c -g -Wall -Wstrict-prototypes -I. -I./Include
-DHAVE_CONFIG_H  -o Objects/object.o Objects/object.c


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

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 Apr  5 22:34:04 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 05 Apr 2001 14:34:04 -0700
Subject: [Python-bugs-list] [ python-Bugs-410608 ] popen with threads
Message-ID: <E14lHOG-0006J8-00@usw-sf-web3.sourceforge.net>

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

Category: Threads
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Thomas Wouters (twouters)
Summary: popen with threads

Initial Comment:
This code generate a error

##########################
import threading
import os

class TestPopen( threading.Thread ):

   def run( self ):
      while 1:
         f = os.popen( "ls -l /" )
         lines = f.read()
         f.close()

if __name__ == "__main__":
   for i in range(50):
      t = TestPopen()
      t.start()
###########################

it eventually dies w/ IOErrors in the f.close() calls.

My system is:
Linux RedHat 6.2
Python 1.5.2
I tested in Python 2.0 and the same error occur.




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

>Comment By: Thomas Wouters (twouters)
Date: 2001-04-05 14:34

Message:
Logged In: YES 
user_id=34209

I cannot reproduce this with 2.1-CVS, but I am not able to
test this on RedHat 6.2 right now. It could be a limits
problem. If the original submittor is reading this: try
doing an 'unlimit' or 'ulimit -a' before running the script.
If it still crashes, please paste one of the tracebacks. I
do get IOErrors and some weird crashes when I run the above
script with lower filedescriptor limits, but not on the
f.close() call. 


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

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

Message:
Logged In: YES 
user_id=31435

Thomas, you want to play with this on Linux?  I already 
gave my best guesses on c.l.py; there's no hope running 
popen stress tests on Win9x, as whether even one popen 
works there one time is a crapshoot.  I assume Mr./Ms. 
Anonymous is running out of system resources, but even if 
so that leaves the question of whether that's 1.5.2's or 
Linux's fault (if it works under current CVS, we can assume 
it was 1.5.2's fault).

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

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


From noreply@sourceforge.net  Fri Apr  6 08:12:54 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 06 Apr 2001 00:12:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-414228 ] Wrong PYTHONPATH in Makefile
Message-ID: <E14lQQQ-0007Fl-00@usw-sf-web2.sourceforge.net>

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

Category: Build
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Wrong PYTHONPATH in Makefile

Initial Comment:
The build process stopped with error in target 
sharemods

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
*** Error code 1
make: Fatal error: Command failed for target 
`sharedmods'

This is cured with changing the Makefile (inserting 
./Lib)

# Build the shared modules
sharedmods: $(PYTHON)
	PYTHONPATH=./Lib ./$(PYTHON) 
$(srcdir)/setup.py build


Python: Python-2.1b2a
System: SunOS 5.7 Generic sun4u sparc SUNW,Ultra-60




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

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


From noreply@sourceforge.net  Fri Apr  6 13:00:18 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 06 Apr 2001 05:00:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-414279 ] incorrect example in asyncore mod. docs
Message-ID: <E14lUuY-0004ak-00@usw-sf-web1.sourceforge.net>

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

Category: Documentation
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: incorrect example in asyncore mod. docs

Initial Comment:
The example in 11.18.1 (asyncore) of the online module 
docs has two typos:

`writeable' should be `writable'

and

`GET %s HTTP/1.0\r\b\r\n'
should be
`GET %s HTTP/1.0\r\n\r\n'

As it stands, it doesn't work.

Guy.

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

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


From noreply@sourceforge.net  Fri Apr  6 16:21:02 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 06 Apr 2001 08:21:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-414316 ] Script installation failures
Message-ID: <E14lY2o-00036Q-00@usw-sf-web2.sourceforge.net>

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

Category: Distutils
Group: None
Status: Open
Priority: 5
Submitted By: Paul F. Dubois (dubois)
Assigned to: Nobody/Anonymous (nobody)
Summary: Script installation failures

Initial Comment:
The "scripts" feature installs scripts with no write 
permission. This is a good thing. But when copying 
scripts down into build/scripts or installing into the 
target python, there are failures because distutils 
does not have write permission on the target when it 
has been previously installed. I assume attempts to 
uninstall are going to have similar difficulties.

In a related matter, we have had to create 
an "artificial user", which is a big pain, who owns 
the files installed because Distutils doesn't work 
right when the file has group write but is owned by 
another developer.

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

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


From noreply@sourceforge.net  Fri Apr  6 19:11:05 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 06 Apr 2001 11:11:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-414354 ] PyArg_ParseTupleAndKeywords is misnamed
Message-ID: <E14lahN-0004Vg-00@usw-sf-web2.sourceforge.net>

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

Category: Documentation
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: PyArg_ParseTupleAndKeywords is misnamed

Initial Comment:
This actually describes a mechanism for handling *optional arguments* using argument names, not true keyword handling.  True keyword handling would allow specification of arbitrary values.  For example, in Python code, I can have my functions accept arbitrary keyword arguments and pass them on to another function even if I don't understand them myself (Tkinter does this a lot).  If I try to pass a keyword parameter named xyzzy to an *extension* module that only understands foo and bar parameters, though, I get an error.  The only semi-reasonable alternative is to pass a normal argument that happens to be a dictionary of keyword arguments, but that's not really the same.

Ideally, extensions would be allowed to use true keywords.  Failing that, the documentation should be amended to reflect the lesser functionality that PyArg_ParseTupleAndKeywords actually provides.

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

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


From noreply@sourceforge.net  Fri Apr  6 20:26:54 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 06 Apr 2001 12:26:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-414371 ] bad gcc/glibc  config
Message-ID: <E14lbsk-00087m-00@usw-sf-web3.sourceforge.net>

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

Category: Build
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: bad gcc/glibc  config

Initial Comment:
When attempting to build version 2.1(b2a) on a RedHat
7.0 system (upgraded to kernel 2.4.3, glibc 2.2-12, and
libstc 2.96-69) package failed to make. Previous
version of 2.0 also failed at this point but I elected
to use 1.5 rather than resolve the problem. 

After 'make' the following was  wrote to the terminal:
gcc -c -g -O2 -Wall -Wstrict - prototypes -I.
-I./Include -DHAVE_CONFIG_H -o Modu{...]
In file included from Include/Python.h:54, from
Modules/python.c:3:
Include/pyport.h:422:2: #error "LONG_BIT definition
appears wrong for platform (bad gcc/glibc config)[...]
make: *** {Modules/python.o] Error 1 [End Error]  So no
build and no Python 2. ||

Hardware specs: PIII, 256 MB Ram, 20 GB HD, used as a
development platform.

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

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


From noreply@sourceforge.net  Sat Apr  7 15:07:37 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 07 Apr 2001 07:07:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-411508 ] httplib does not support user/pass
Message-ID: <E14ltNJ-0007Zk-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: Python Library
>Group: Feature Request
>Status: Closed
Priority: 5
Submitted By: JAmes Atwill (idcmp)
Assigned to: Greg Stein (gstein)
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.


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

>Comment By: Greg Stein (gstein)
Date: 2001-04-07 07:07

Message:
Logged In: YES 
user_id=6501

1) _set_hostport takes a host/port, NOT a URL.

2) Authentication is for a higher level than the 
HTTPConnection object. The latter is simply to enable 
HTTP/1.1 functionality. Most features can layer on top of 
that as a subclass, or as a class which uses/delegates to a 
connection.

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

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


From noreply@sourceforge.net  Sat Apr  7 17:14:55 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 07 Apr 2001 09:14:55 -0700
Subject: [Python-bugs-list] [ python-Bugs-233308 ] Python C-API for adding int (*getreadbufferproc) is wrong
Message-ID: <E14lvMV-00006v-00@usw-sf-web3.sourceforge.net>

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

Category: Documentation
Group: None
>Status: Closed
Priority: 6
Submitted By: Travis Oliphant (teoliphant)
Assigned to: Greg Stein (gstein)
Summary: Python C-API for adding int (*getreadbufferproc) is wrong

Initial Comment:
In all docs, the description for the routine int (*getreadbufferproc) states that a return value of 0 means success.  However, in order to get your object to work correctly with the "buffer" command in Python, this routine needs to return the total size (in bytes) of the buffer. 

This same problem may also exist for the documentation of int (*getwritebufferproc).



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

>Comment By: Greg Stein (gstein)
Date: 2001-04-07 09:14

Message:
Logged In: YES 
user_id=6501

Good call. Fixed in the API docs.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-02-22 14:46

Message:
Greg, you're the lead for the buffer API; can you clarify or correct the docs as appropriate?  Thanks!

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

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


From noreply@sourceforge.net  Sat Apr  7 19:11:09 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 07 Apr 2001 11:11:09 -0700
Subject: [Python-bugs-list] [ python-Bugs-411508 ] httplib does not support user/pass
Message-ID: <E14lxAz-00010z-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: Python Library
Group: Feature Request
>Status: Open
Priority: 5
Submitted By: JAmes Atwill (idcmp)
Assigned to: Greg Stein (gstein)
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.


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

>Comment By: JAmes Atwill (idcmp)
Date: 2001-04-07 11:11

Message:
Logged In: YES 
user_id=2329

Then whatever method that parses the URL is not properly
stripping away the user:pass@ part from the URL before
passing it to _set_hostport.

Seperating authentication in this mechanism (meaning
everyone has to do the same thing) makes it impossible to do
authentication through things like xmlrpclib without a lot
of black voodoo magic as the protocol is purposely hidden
from you.

The added complexity cancels out the bonus of having an
xmlrpclib.

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

Comment By: Greg Stein (gstein)
Date: 2001-04-07 07:07

Message:
Logged In: YES 
user_id=6501

1) _set_hostport takes a host/port, NOT a URL.

2) Authentication is for a higher level than the 
HTTPConnection object. The latter is simply to enable 
HTTP/1.1 functionality. Most features can layer on top of 
that as a subclass, or as a class which uses/delegates to a 
connection.

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

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


From noreply@sourceforge.net  Sat Apr  7 21:03:40 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 07 Apr 2001 13:03:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-414371 ] bad gcc/glibc  config
Message-ID: <E14lyvs-0001qY-00@usw-sf-web3.sourceforge.net>

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

Category: Build
>Group: 3rd Party
>Status: Closed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: bad gcc/glibc  config

Initial Comment:
When attempting to build version 2.1(b2a) on a RedHat
7.0 system (upgraded to kernel 2.4.3, glibc 2.2-12, and
libstc 2.96-69) package failed to make. Previous
version of 2.0 also failed at this point but I elected
to use 1.5 rather than resolve the problem. 

After 'make' the following was  wrote to the terminal:
gcc -c -g -O2 -Wall -Wstrict - prototypes -I.
-I./Include -DHAVE_CONFIG_H -o Modu{...]
In file included from Include/Python.h:54, from
Modules/python.c:3:
Include/pyport.h:422:2: #error "LONG_BIT definition
appears wrong for platform (bad gcc/glibc config)[...]
make: *** {Modules/python.o] Error 1 [End Error]  So no
build and no Python 2. ||

Hardware specs: PIII, 256 MB Ram, 20 GB HD, used as a
development platform.

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

Comment By: Tim Peters (tim_one)
Date: 2001-04-07 13:03

Message:
Logged In: YES 
user_id=31435

The GCC version that comes with Red Hat 7.0 is not fit for
distribution.

In particular, it defines LONG_BIT as 64 on 32-bit machines under
certain circumstances, and letting this go unchecked would cause
it to generate bad code for various Python arithmetic operations.

The solution is to download a valid version of GCC.

See

http://www.python.org/cgi-
bin/moinmoin/FrequentlyAskedQuestions#line53

for more information.

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

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


From noreply@sourceforge.net  Sat Apr  7 21:04:49 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 07 Apr 2001 13:04:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-414316 ] Script installation failures
Message-ID: <E14lywz-0001rG-00@usw-sf-web3.sourceforge.net>

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

Category: Distutils
Group: None
Status: Open
Priority: 5
Submitted By: Paul F. Dubois (dubois)
>Assigned to: Greg Ward (gward)
Summary: Script installation failures

Initial Comment:
The "scripts" feature installs scripts with no write 
permission. This is a good thing. But when copying 
scripts down into build/scripts or installing into the 
target python, there are failures because distutils 
does not have write permission on the target when it 
has been previously installed. I assume attempts to 
uninstall are going to have similar difficulties.

In a related matter, we have had to create 
an "artificial user", which is a big pain, who owns 
the files installed because Distutils doesn't work 
right when the file has group write but is owned by 
another developer.

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

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

Message:
Logged In: YES 
user_id=31435

Assigned to Greg Ward.

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

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


From noreply@sourceforge.net  Sun Apr  8 15:45:50 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 08 Apr 2001 07:45:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-413956 ] 2.1b2 CVS termios no longer compiles
Message-ID: <E14mGRq-0001kr-00@usw-sf-web3.sourceforge.net>

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

Category: Build
Group: None
Status: Open
Priority: 5
Submitted By: Mark Favas (mfavas)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.1b2 CVS termios no longer compiles

Initial Comment:
CVS version of 2.1b2 termios module now fails to
compile on Tru64 Unix. The April 5 version of termios.c
has a bunch of new constants defined, protected by
#ifdef's. Unfortunately, some of these constants are
defined in sys/ioctl.h under Tru64 Unix, but not in a
compatible way with constants defined in termios.h.
More detail: compilation fails thusly:
building 'termios' extension
cc -O -Olimit 1500 -I. -I./Include -I/usr/local/include
-IInclude/ -c Modules/termios.c -o
build/temp.osf1-V4.0-alpha-2.1/termios.o
cc: Error: Modules/termios.c, line 662: In the
initializer for termios_constants[142].value, "struct
termio" is an incomplete type, and so has no size.
(sizeincomptyp)
        {"TCGETA", TCGETA},
-------------------^
cc: Error: Modules/termios.c, line 674: In the
initializer for termios_constants[145].value, "struct
termio" is an incomplete type, and so has no size.
(sizeincomptyp)
        {"TCSETA", TCSETA},
-------------------^
cc: Error: Modules/termios.c, line 677: In the
initializer for termios_constants[146].value, "struct
termio" is an incomplete type, and so has no size.
(sizeincomptyp)
        {"TCSETAF", TCSETAF},
--------------------^
cc: Error: Modules/termios.c, line 680: In the
initializer for termios_constants[147].value, "struct
termio" is an incomplete type, and so has no size.
(sizeincomptyp)
        {"TCSETAW", TCSETAW},
--------------------^
WARNING: building of extension "termios" failed:
command 'cc' failed with exit status 1

TCGETA, TCSETA, TCSETAF, and TCSETAW are defined in
/usr/include/sys/ioctl.h as, for example,
#define TCGETA          _IOW('t', 23, struct termio) /*
set termio struct */
which is not compatible with their use in termios.c,
where the expectation is that the constants will be
defined as small integers.

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

Comment By: Michael Hudson (mwh)
Date: 2001-04-08 07:45

Message:
Logged In: YES 
user_id=6656

I can make this compile on alpha by #include-ing <termio.h>

This also works on linux.  Don't know about the many
millions of other unixen (I only have a linux box, and an
account on an elderly department alpha).

Unless the build can be tested everywhere we try to build
termios, the #include should probably be left out - but
programs that used TERMIOS in 2.0 have a good chance of
breaking.

Maybe an

#ifdef linux /* or whatever */
#inlcude <sys/ioctl.h>
#endif

could be added?  This would keep /me/ happy, at least.

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

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


From noreply@sourceforge.net  Sun Apr  8 20:35:39 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 08 Apr 2001 12:35:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-414743 ] Access violation in call to map
Message-ID: <E14mKyJ-0003vd-00@usw-sf-web3.sourceforge.net>

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

Category: Python Interpreter Core
Group: None
Status: Open
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Access violation in call to map

Initial Comment:
This call:

  map(None, *None)

results in an access violation (read of NULL pointer) 
under Python 2.1b2 (Win32 binaries downloaded from 
Sourceforge).  OS in Win2000.


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

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


From noreply@sourceforge.net  Sun Apr  8 21:25:28 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 08 Apr 2001 13:25:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-414743 ] Access violation in call to map
Message-ID: <E14mLkW-0000RS-00@usw-sf-web1.sourceforge.net>

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

Category: Python Interpreter Core
Group: None
Status: Open
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Access violation in call to map

Initial Comment:
This call:

  map(None, *None)

results in an access violation (read of NULL pointer) 
under Python 2.1b2 (Win32 binaries downloaded from 
Sourceforge).  OS in Win2000.


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

Comment By: Michael Hudson (mwh)
Date: 2001-04-08 13:25

Message:
Logged In: YES 
user_id=6656

Eek!

>>> None(*None)
Segmentation fault (core dumped)

This is Ping's fault.  In ext_do_call the code that tries to
work out the function name assumes that func is a
PyFunctionObject, where in fact it can be anything at all,
because this is called before the check to see whether we
really have a callable!  Oops.

Anyway, look at patch #414743 for my attempted fix.

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

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


From noreply@sourceforge.net  Sun Apr  8 21:38:50 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 08 Apr 2001 13:38:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-414743 ] Access violation in call to map
Message-ID: <E14mLxS-0002BR-00@usw-sf-web2.sourceforge.net>

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

Category: Python Interpreter Core
Group: None
Status: Open
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Access violation in call to map

Initial Comment:
This call:

  map(None, *None)

results in an access violation (read of NULL pointer) 
under Python 2.1b2 (Win32 binaries downloaded from 
Sourceforge).  OS in Win2000.


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

Comment By: Michael Hudson (mwh)
Date: 2001-04-08 13:38

Message:
Logged In: YES 
user_id=6656

Ooh, another one:

>>> dir(b=1,**{'b':1})
Segmentation fault (core dumped)

I'll update #414743 presently.

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

Comment By: Michael Hudson (mwh)
Date: 2001-04-08 13:25

Message:
Logged In: YES 
user_id=6656

Eek!

>>> None(*None)
Segmentation fault (core dumped)

This is Ping's fault.  In ext_do_call the code that tries to
work out the function name assumes that func is a
PyFunctionObject, where in fact it can be anything at all,
because this is called before the check to see whether we
really have a callable!  Oops.

Anyway, look at patch #414743 for my attempted fix.

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

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


From noreply@sourceforge.net  Mon Apr  9 06:10:35 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 08 Apr 2001 22:10:35 -0700
Subject: [Python-bugs-list] [ python-Bugs-406280 ] Python 2.1b1 - pydoc shows nothing
Message-ID: <E14mTwh-00063d-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: Ka-Ping Yee (ping)
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-04-08 22:10

Message:
Logged In: YES 
user_id=31435

Reassigned to Ping since wrestling w/ popen() on Windows is 
hopeless.  Left the priority low because it's gotta be rare 
for anyone to define a PAGER envar under Windows.  Note 
that Paul mailed some kind of related patch to Python-Dev 
recently ... mumble, mumble, ... here:

http://mail.python.org/pipermail/python-dev/2001-
April/014070.html

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

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  Mon Apr  9 15:00:32 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 09 Apr 2001 07:00:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-215026 ] SSL features undocumented
Message-ID: <E14mcDY-0005W3-00@usw-sf-web1.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: Moshe Zadka (moshez)
Date: 2001-04-09 07:00

Message:
Logged In: YES 
user_id=11645

Test case is trivial:

>>> a = urllib2.urlopen('https://sourceforge.net')
>>> a.read(10)

And see that something comes out.

I can't help any more with that, I haven't seen a windows
machine for longer then Tim hasn't seen a socket...
Assigning back to tim -- if you can't solve it, someone more
qualified them me will have to solve it.

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

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  Mon Apr  9 15:02:17 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 09 Apr 2001 07:02:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-407783 ] urllib2: AbstractHTTPHandler limits flexible client implemen
Message-ID: <E14mcFF-0005Xj-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: Moshe Zadka (moshez)
Date: 2001-04-09 07:02

Message:
Logged In: YES 
user_id=11645

I'm formally postponing it until the 2.1 release comes out
-- clearly none of this can be considered a bug fix.

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

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  Mon Apr  9 15:11:58 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 09 Apr 2001 07:11:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-413135 ] urllib2 fails with proxy requiring auth
Message-ID: <E14mcOc-0005bf-00@usw-sf-web3.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore (pmoore)
Assigned to: Moshe Zadka (moshez)
Summary: urllib2 fails with proxy requiring auth

Initial Comment:
The following program:

import urllib2

proxy_info = {
    'user' : 'my_name', 'pass' : 'my_pass',
    'host' : "my-proxy", 'port' : 80
}
 
# build a new opener that uses a proxy requiring
# authorization
proxy_support = urllib2.ProxyHandler(
    {"http" :
     "http://%(user)s:%(pass)s@%(host)s:%(port)d"
     % proxy_info})
opener = urllib2.build_opener(proxy_support, 
urllib2.HTTPHandler)
 
# install it
urllib2.install_opener(opener)
 
f = urllib2.urlopen('http://www.python.org/')
print f.headers
print f.read()


fails with the following error on Python 2.1b2 (on 
Windows)

C:\Data>python21 proxy_auth.py
Traceback (most recent call last):
  File "proxy_auth.py", line 18, in ?
    f = urllib2.urlopen('http://www.python.org/')
  File "c:\applications\python21\lib\urllib2.py", line 
135, in urlopen
    return _opener.open(url, data)
  File "c:\applications\python21\lib\urllib2.py", line 
318, in open
    '_open', req)
  File "c:\applications\python21\lib\urllib2.py", line 
297, in _call_chain
    result = func(*args)
  File "c:\applications\python21\lib\urllib2.py", line 
823, in http_open
    return self.do_open(httplib.HTTP, req)
  File "c:\applications\python21\lib\urllib2.py", line 
801, in do_open
    raise URLError(err)
urllib2.URLError: <urlopen error host not found>

A similar error occurred in beta 1, but this was 
reported as bug 406683. The fix is in beta 2. I 
applied the fix manually in beta 1, and it worked, so 
I can only assume that something else changed in the 
transition from beta 1 to beta 2, which broke this 
again.


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

>Comment By: Moshe Zadka (moshez)
Date: 2001-04-09 07:11

Message:
Logged In: YES 
user_id=11645

I've just tested with my installation of Python 2.1b2 and it
works. So I cannot reproduce the problem, and I need more
information from you: can you insert prints in the correct
places (e.g. do_open) to see what host urllib2 *thinks* it
is trying to access?
Thanks.

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

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


From noreply@sourceforge.net  Mon Apr  9 15:36:59 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 09 Apr 2001 07:36:59 -0700
Subject: [Python-bugs-list] [ python-Bugs-408085 ] urllib.py https redirect-302 bug
Message-ID: <E14mcmp-00065P-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-04-09 07:36

Message:
Logged In: YES 
user_id=11645

Fixed in urllib.py v 1.125
urllib.py added http: to the url, instead of self.type.
I haven't checked with the original server or with POSTs
since I couldn't find such a server -- but I verified it by
opening https://sourceforge.net/account which redirects
to https://sourceforge.net/account/. It redirects properly,
unfortunately, but I did check that I'm adding the correct
thing.

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

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 Apr  9 15:38:18 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 09 Apr 2001 07:38:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-408085 ] urllib.py https redirect-302 bug
Message-ID: <E14mco6-00068e-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: Closed
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-04-09 07:38

Message:
Logged In: YES 
user_id=11645

Forgot to actually close the bug report.

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

Comment By: Moshe Zadka (moshez)
Date: 2001-04-09 07:36

Message:
Logged In: YES 
user_id=11645

Fixed in urllib.py v 1.125
urllib.py added http: to the url, instead of self.type.
I haven't checked with the original server or with POSTs
since I couldn't find such a server -- but I verified it by
opening https://sourceforge.net/account which redirects
to https://sourceforge.net/account/. It redirects properly,
unfortunately, but I did check that I'm adding the correct
thing.

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

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 Apr  9 15:45:31 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 09 Apr 2001 07:45:31 -0700
Subject: [Python-bugs-list] [ python-Bugs-414899 ] Pyton1.5.2: urllib.always_safe variable
Message-ID: <E14mcv5-000638-00@usw-sf-web3.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: HERMAN Etienne (delun)
Assigned to: Nobody/Anonymous (nobody)
Summary: Pyton1.5.2: urllib.always_safe variable

Initial Comment:
Our environment is:
Python 1.5.2 (#1, Feb  1 2000, 16:32:16)  [GCC
egcs-2.91.66 19990314/Linux (egcs- on linux-i386)
LANG=fr_FR

Bug in the urllib.always_safe variable, it contains
accented characters :

>>> import urllib
>>> print urllib.always_safe
abcdefghijklmnopqrstuvwxyzßàáâãäåæçèéêëìíîïðñòóôõöøùúûüýþÿABCDEFGHIJKLMNOPQRSTUVWXYZÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖØÙÚÛÜÝÞ0123456789_,.-
>>> urllib.quote('élève')
'\351l\350ve'


>>> urllib.always_safe = 'abcdefghijklmnopqrstuvwxyz' +
'ABCDEFGHIJKLMNOPQRSTUVWXYZ' + '0123456789' + '*' +
'_.-'
>>> urllib.quote('élève')
'%e9l%e8ve'

Etienne HERMAN
devel@logilab.fr

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

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


From noreply@sourceforge.net  Mon Apr  9 16:43:35 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 09 Apr 2001 08:43:35 -0700
Subject: [Python-bugs-list] [ python-Bugs-413876 ] rfc822.AddressList methods incorrect
Message-ID: <E14mdpH-0006mU-00@usw-sf-web3.sourceforge.net>

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

Category: Documentation
Group: None
>Status: Closed
Priority: 5
Submitted By: Steve Holden (holdenweb)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: rfc822.AddressList methods incorrect

Initial Comment:
The current 2.0, and the latest development, 
documentation shows rfc822.AddressList methods __len__
() and __str__() as requiring arguments. Inspection of 
the 2.0 code shows this to be incorrect. I presume 
this will also be true of 2.1.

Furthermore, the __add__() and __sub__() methods are 
documented as taking a "name" argument, which is 
somewhat misleading since the required argument should 
be another rfc822.AddressList object. It might be 
better to use a more meaningful name such as "alist", 
and document its required type.


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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-04-09 08:43

Message:
Logged In: YES 
user_id=3066

The documentation also failed to mention the support of the in-place variants added with the advent of augmented assignment.  All corrected in Doc/lib/librfc822.tex revision 1.31.

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

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


From noreply@sourceforge.net  Mon Apr  9 16:59:01 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 09 Apr 2001 08:59:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-414279 ] incorrect example in asyncore mod. docs
Message-ID: <E14me4D-0006xy-00@usw-sf-web3.sourceforge.net>

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

Category: Documentation
Group: None
>Status: Closed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: incorrect example in asyncore mod. docs

Initial Comment:
The example in 11.18.1 (asyncore) of the online module 
docs has two typos:

`writeable' should be `writable'

and

`GET %s HTTP/1.0\r\b\r\n'
should be
`GET %s HTTP/1.0\r\n\r\n'

As it stands, it doesn't work.

Guy.

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-04-09 08:59

Message:
Logged In: YES 
user_id=3066

The 'writeable' typo has already been corrected in CVS; the example typo has now been fixed as Doc/lib/libasyncore.tex revision 1.7.

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

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


From noreply@sourceforge.net  Mon Apr  9 17:14:51 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 09 Apr 2001 09:14:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-413767 ] warn about __debug__ assignment
Message-ID: <E14meJX-00055i-00@usw-sf-web2.sourceforge.net>

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

Category: Parser/Compiler
Group: None
>Status: Closed
Priority: 8
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Jeremy Hylton (jhylton)
Summary: warn about __debug__ assignment

Initial Comment:
Back out the change that makes it illegal to assign to
__debug__ and issue a warning instead.


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

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-04-09 09:14

Message:
Logged In: YES 
user_id=31392

fixed in rev 2.195 of compile.c


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

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


From noreply@sourceforge.net  Mon Apr  9 17:35:46 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 09 Apr 2001 09:35:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-414940 ] locale.format broken in 2.1b2
Message-ID: <E14medm-0005OV-00@usw-sf-web2.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Walter Dörwald (doerwalter)
Assigned to: Nobody/Anonymous (nobody)
Summary: locale.format broken in 2.1b2

Initial Comment:
locale.format seems
to be broken in 2.1b2:

>>> import locale
>>> locale.format("%+.02f", -42., 1) 
'-+42.00'


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

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


From noreply@sourceforge.net  Tue Apr 10 10:45:01 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 10 Apr 2001 02:45:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-413135 ] urllib2 fails with proxy requiring auth
Message-ID: <E14muhp-0002WC-00@usw-sf-web3.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore (pmoore)
Assigned to: Moshe Zadka (moshez)
Summary: urllib2 fails with proxy requiring auth

Initial Comment:
The following program:

import urllib2

proxy_info = {
    'user' : 'my_name', 'pass' : 'my_pass',
    'host' : "my-proxy", 'port' : 80
}
 
# build a new opener that uses a proxy requiring
# authorization
proxy_support = urllib2.ProxyHandler(
    {"http" :
     "http://%(user)s:%(pass)s@%(host)s:%(port)d"
     % proxy_info})
opener = urllib2.build_opener(proxy_support, 
urllib2.HTTPHandler)
 
# install it
urllib2.install_opener(opener)
 
f = urllib2.urlopen('http://www.python.org/')
print f.headers
print f.read()


fails with the following error on Python 2.1b2 (on 
Windows)

C:\Data>python21 proxy_auth.py
Traceback (most recent call last):
  File "proxy_auth.py", line 18, in ?
    f = urllib2.urlopen('http://www.python.org/')
  File "c:\applications\python21\lib\urllib2.py", line 
135, in urlopen
    return _opener.open(url, data)
  File "c:\applications\python21\lib\urllib2.py", line 
318, in open
    '_open', req)
  File "c:\applications\python21\lib\urllib2.py", line 
297, in _call_chain
    result = func(*args)
  File "c:\applications\python21\lib\urllib2.py", line 
823, in http_open
    return self.do_open(httplib.HTTP, req)
  File "c:\applications\python21\lib\urllib2.py", line 
801, in do_open
    raise URLError(err)
urllib2.URLError: <urlopen error host not found>

A similar error occurred in beta 1, but this was 
reported as bug 406683. The fix is in beta 2. I 
applied the fix manually in beta 1, and it worked, so 
I can only assume that something else changed in the 
transition from beta 1 to beta 2, which broke this 
again.


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

>Comment By: Paul Moore (pmoore)
Date: 2001-04-10 02:45

Message:
Logged In: YES 
user_id=113328

I found the problem. In urllib2.py, class 
AbstractHTTPHandler, method do_open, the first line is now 

        host = urlparse.urlparse(req.get_full_url())[1]

It used to be

        host = req.get_host()

With the old version, the code works (with my proxy). With 
the new version it doesn't, as it passes the destination 
host, rather than the proxy name (and so loses the proxy 
info totally).

Paul.


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

Comment By: Moshe Zadka (moshez)
Date: 2001-04-09 07:11

Message:
Logged In: YES 
user_id=11645

I've just tested with my installation of Python 2.1b2 and it
works. So I cannot reproduce the problem, and I need more
information from you: can you insert prints in the correct
places (e.g. do_open) to see what host urllib2 *thinks* it
is trying to access?
Thanks.

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

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


From noreply@sourceforge.net  Tue Apr 10 10:46:11 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 10 Apr 2001 02:46:11 -0700
Subject: [Python-bugs-list] [ python-Bugs-413135 ] urllib2 fails with proxy requiring auth
Message-ID: <E14muix-0002XS-00@usw-sf-web3.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Paul Moore (pmoore)
Assigned to: Moshe Zadka (moshez)
Summary: urllib2 fails with proxy requiring auth

Initial Comment:
The following program:

import urllib2

proxy_info = {
    'user' : 'my_name', 'pass' : 'my_pass',
    'host' : "my-proxy", 'port' : 80
}
 
# build a new opener that uses a proxy requiring
# authorization
proxy_support = urllib2.ProxyHandler(
    {"http" :
     "http://%(user)s:%(pass)s@%(host)s:%(port)d"
     % proxy_info})
opener = urllib2.build_opener(proxy_support, 
urllib2.HTTPHandler)
 
# install it
urllib2.install_opener(opener)
 
f = urllib2.urlopen('http://www.python.org/')
print f.headers
print f.read()


fails with the following error on Python 2.1b2 (on 
Windows)

C:\Data>python21 proxy_auth.py
Traceback (most recent call last):
  File "proxy_auth.py", line 18, in ?
    f = urllib2.urlopen('http://www.python.org/')
  File "c:\applications\python21\lib\urllib2.py", line 
135, in urlopen
    return _opener.open(url, data)
  File "c:\applications\python21\lib\urllib2.py", line 
318, in open
    '_open', req)
  File "c:\applications\python21\lib\urllib2.py", line 
297, in _call_chain
    result = func(*args)
  File "c:\applications\python21\lib\urllib2.py", line 
823, in http_open
    return self.do_open(httplib.HTTP, req)
  File "c:\applications\python21\lib\urllib2.py", line 
801, in do_open
    raise URLError(err)
urllib2.URLError: <urlopen error host not found>

A similar error occurred in beta 1, but this was 
reported as bug 406683. The fix is in beta 2. I 
applied the fix manually in beta 1, and it worked, so 
I can only assume that something else changed in the 
transition from beta 1 to beta 2, which broke this 
again.


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

>Comment By: Paul Moore (pmoore)
Date: 2001-04-10 02:46

Message:
Logged In: YES 
user_id=113328

I found the problem. In urllib2.py, class 
AbstractHTTPHandler, method do_open, the first line is now 

        host = urlparse.urlparse(req.get_full_url())[1]

It used to be

        host = req.get_host()

With the old version, the code works (with my proxy). With 
the new version it doesn't, as it passes the destination 
host, rather than the proxy name (and so loses the proxy 
info totally).

Paul.


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

Comment By: Paul Moore (pmoore)
Date: 2001-04-10 02:45

Message:
Logged In: YES 
user_id=113328

I found the problem. In urllib2.py, class 
AbstractHTTPHandler, method do_open, the first line is now 

        host = urlparse.urlparse(req.get_full_url())[1]

It used to be

        host = req.get_host()

With the old version, the code works (with my proxy). With 
the new version it doesn't, as it passes the destination 
host, rather than the proxy name (and so loses the proxy 
info totally).

Paul.


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

Comment By: Moshe Zadka (moshez)
Date: 2001-04-09 07:11

Message:
Logged In: YES 
user_id=11645

I've just tested with my installation of Python 2.1b2 and it
works. So I cannot reproduce the problem, and I need more
information from you: can you insert prints in the correct
places (e.g. do_open) to see what host urllib2 *thinks* it
is trying to access?
Thanks.

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

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


From noreply@sourceforge.net  Tue Apr 10 13:52:36 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 10 Apr 2001 05:52:36 -0700
Subject: [Python-bugs-list] [ python-Bugs-408936 ] Python2.0 re module: greedy regexp bug 2
Message-ID: <E14mxdM-0003Eo-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.


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

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

Message:
Logged In: YES 
user_id=6656

Works for me in recent builds, so I guess it's fixed.

Someone want to mark it closed?

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

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


From noreply@sourceforge.net  Tue Apr 10 14:11:53 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 10 Apr 2001 06:11:53 -0700
Subject: [Python-bugs-list] [ python-Bugs-408936 ] Python2.0 re module: greedy regexp bug 2
Message-ID: <E14mxw1-0003Tz-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.


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

>Comment By: Bastian Kleineidam (calvin)
Date: 2001-04-10 06:11

Message:
Logged In: YES 
user_id=9205

Ok, its closed in recent builds, but this is still a
candidate for the
Python 2.01 bugfix release.


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

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

Message:
Logged In: YES 
user_id=6656

Works for me in recent builds, so I guess it's fixed.

Someone want to mark it closed?

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

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


From noreply@sourceforge.net  Tue Apr 10 16:21:33 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 10 Apr 2001 08:21:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-406792 ] python2.1b1 core dumps --with-pymalloc
Message-ID: <E14mzxV-00030M-00@usw-sf-web1.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: Closed
Priority: 2
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


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 08:21

Message:
Logged In: YES 
user_id=6380

I'm closing this -- it seems to be a compiler problem.

The moral of the story: turn off -O2 when you're
experiencing weird crashes.

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

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

Message:
Logged In: NO 

Downloaded python2.1beta2. Used gcc 2.95.3 on HPUX 10.2

This time it blew up in different manner:
PYTHONPATH= ./python ./setup.py build
Fatal Python error: unknown scope for name in __init__(0) in
./Lib/site.py
symbols: {'data': 12, 'self': 12, 'files': 12, 'name': 12,
'None': 264, 'dirs': 12}
locals: {'self': 0}
globals: {'None': 1}

/bin/sh: 22414 Abort
gmake: *** [sharedmods] Error 134

Removed Objects/object.o and rebuilt it without the -O2
option and then the system fully built with no crashes.


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

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

Message:
Logged In: NO 

With an updated version of gcc it (python2.1b1) still fails
with -O2 but in a different place.

% gcc --version
2.95.3
% uname -a
HP-UX wvenus B.10.20 A 9000/782 2009382447 two-user license
% gdb
GNU gdb 5.0
(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 SIGSEGV, Segmentation fault.
0x4d984 in PyNumber_CoerceEx (pv=0x7b03c4b4, pw=0x7b03c4b0)
    at Objects/object.c:1175
1175            if (v->ob_type->tp_as_number &&
v->ob_type->tp_as_number->nb_coerce) {


If I remove the -O2 when compiling Objects/object.o then
python builds without a crash.
% gcc -c -g -Wall -Wstrict-prototypes -I. -I./Include
-DHAVE_CONFIG_H  -o Objects/object.o Objects/object.c


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

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  Tue Apr 10 16:30:44 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 10 Apr 2001 08:30:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-411612 ] cgi.py sometimes ignores QUERY_STRING
Message-ID: <E14n06O-00038s-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: Guido van Rossum (gvanrossum)
Date: 2001-04-10 08:30

Message:
Logged In: YES 
user_id=6380

The idea is right, but since nobody volunteered a working
patch, this won't make it into 2.1.  Sorry.  Try again after
2.1!

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

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 Apr 10 16:45:41 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 10 Apr 2001 08:45:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-411881 ] Use of "except:" in modules
Message-ID: <E14n0Kr-0006zY-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: 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: Guido van Rossum (gvanrossum)
Date: 2001-04-10 08:45

Message:
Logged In: YES 
user_id=6380

I've applied the three patches you supplied.

I agree with Martin that to do this right we'll have to
tread carefully. But please go on!

(No way more of this will find its way into 2.1 though.)

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

Comment By: Itamar Shtull-Trauring (itamar)
Date: 2001-03-30 02:54

Message:
Logged In: YES 
user_id=32065

inspect.py should be removed from this list, the use is
correct.

In general, I just submitted this bug so that when people
are editing a module they'll notice these things, since in
some cases only someone who knows the code very well can
know if the "expect:" is needed or not.

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

Comment By: Martin v. Löwis (loewis)
Date: 2001-03-29 22:59

Message:
Logged In: YES 
user_id=21627

Can you identify modules where catching everything is
incorrect, and propose changes to correct them. This should
be done one-by-one, with careful analysis in each case, and
may take well months or years to complete.

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

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


From noreply@sourceforge.net  Tue Apr 10 16:48:50 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 10 Apr 2001 08:48:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-412252 ] mimetypes.py uses posixpath not os.path
Message-ID: <E14n0Nu-00071e-00@usw-sf-web3.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: Closed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Guido van Rossum (gvanrossum)
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.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 08:48

Message:
Logged In: YES 
user_id=6380

Actually, the use of posixpath is intentional. The
splitext() function only looks at the extension after the
last pathname delimiter, and for URLs, we should always use
the Unix style pathname delimiters.

It's very clear that the argument to guesstype should be a
URL, not a filename in local filesystem syntax.

So, closing as Invalid.

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

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


From noreply@sourceforge.net  Tue Apr 10 16:50:14 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 10 Apr 2001 08:50:14 -0700
Subject: [Python-bugs-list] [ python-Bugs-412682 ] Cannot play solitaire - buggy Canvas.py?
Message-ID: <E14n0PG-0005XH-00@usw-sf-web2.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: demos and tools
Group: None
Status: Open
>Priority: 1
Submitted By: Alastair Burt (alburt)
>Assigned to: Guido van Rossum (gvanrossum)
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

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 08:50

Message:
Logged In: YES 
user_id=6380

I bet that demo is broken, not the Canvas module, but I have
no time to fix this before the 2.1 release.

Use PySol if you want to play. :-)

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

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


From noreply@sourceforge.net  Tue Apr 10 16:51:40 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 10 Apr 2001 08:51:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-413582 ] g++ must be called for c++ extensions
Message-ID: <E14n0Qe-0005YK-00@usw-sf-web2.sourceforge.net>

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

Category: Distutils
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: A.M. Kuchling (akuchling)
Summary: g++ must be called for c++ extensions

Initial Comment:
When building c++ extension using distutils setup,
the compiler that was used to build python distribution
is always called. On Linux, it is normally gcc.
When gcc is called to link shared library, it does not
link certain c++ runtime stuff. As a result, when
extension is imported, missing symbols are reported,
e.g.:
>>> import ex_ext1
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError: ./ex_ext1.so: undefined symbol:
__vt_13runtime_error
>>>
I tried to use "extra_link_args = ['-x c++']" in
setup.py (it tells gcc to link as c++), but that gets
added to the end of compiler's command line, which
results in:
gcc -shared build/temp.linux-i686-2.1/ex_ext1.o
-L../boost/libs/python -lboost_python -o
build/lib.linux-i686-2.1/ex_ext1.so -x c++
gcc: Warning: `-x  c++' after last input file has no
effect

Proposed solution: either use CXX= variable from Python
Makefile when c++ files are involved, or prepend
extra_link_args to compiler's arguments instead of
appending them.


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 08:51

Message:
Logged In: YES 
user_id=6380

Assigning this to Andrew, who is the current distutils
maintainer.


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

Comment By: Andrei Tovtchigretchko (andreitd)
Date: 2001-04-04 17:23

Message:
Logged In: YES 
user_id=189208

Follow-up:
If I link with a static library (-lboost_python is
libboost_python.a in bug post example), the problem shows.
If I link with shared c++ library (libboost_python.so),
everything is ok.

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

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


From noreply@sourceforge.net  Tue Apr 10 16:53:05 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 10 Apr 2001 08:53:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-413714 ] ccpython.cc build failure in sep. tree
Message-ID: <E14n0S1-0003VM-00@usw-sf-web1.sourceforge.net>

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

Category: Build
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Neil Schemenauer (nascheme)
Summary: ccpython.cc build failure in sep. tree

Initial Comment:
When building in a separate directory from the source 
tree, ccpython.cc cannot be built since the rule in 
Modules/Makefile.pre.in is currently:

ccpython.o: ccpython.cc
	$(CXX) $(CFLAGS) -c $*.cc

instead of

ccpython.o: ccpython.cc
	$(CXX) $(CFLAGS) -c $<

Thanks,

Guy.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 08:53

Message:
Logged In: YES 
user_id=6380

Assigned to Neil Schemenauer, the build expert.

Neil, this looks like a trivial fix.  If you agree, can you
check it in?

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

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


From noreply@sourceforge.net  Tue Apr 10 17:02:33 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 10 Apr 2001 09:02:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-412682 ] Cannot play solitaire - buggy Canvas.py?
Message-ID: <E14n0bB-0003eC-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: demos and tools
Group: None
Status: Open
Priority: 1
Submitted By: Alastair Burt (alburt)
Assigned to: Guido van Rossum (gvanrossum)
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

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

>Comment By: Alastair Burt (alburt)
Date: 2001-04-10 09:02

Message:
Logged In: YES 
user_id=45573

The demo might be the only piece of software in the world
that tickles this bug but I think it is not the real
culprit. There is a mismatch between the interface offered
by lib-tk/Tkinter.py and that used by lib-tk/Canvas.py which
is the result of name changes related to "tag_lower" and
"tag_raise".

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 08:50

Message:
Logged In: YES 
user_id=6380

I bet that demo is broken, not the Canvas module, but I have
no time to fix this before the 2.1 release.

Use PySol if you want to play. :-)

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

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


From noreply@sourceforge.net  Tue Apr 10 17:05:57 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 10 Apr 2001 09:05:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-413714 ] ccpython.cc build failure in sep. tree
Message-ID: <E14n0eT-0005jo-00@usw-sf-web2.sourceforge.net>

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

Category: Build
Group: Platform-specific
>Status: Closed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Neil Schemenauer (nascheme)
Summary: ccpython.cc build failure in sep. tree

Initial Comment:
When building in a separate directory from the source 
tree, ccpython.cc cannot be built since the rule in 
Modules/Makefile.pre.in is currently:

ccpython.o: ccpython.cc
	$(CXX) $(CFLAGS) -c $*.cc

instead of

ccpython.o: ccpython.cc
	$(CXX) $(CFLAGS) -c $<

Thanks,

Guy.

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

>Comment By: Neil Schemenauer (nascheme)
Date: 2001-04-10 09:05

Message:
Logged In: YES 
user_id=35752

This bug must be referring to an old version of Python. 
There
is no longer a Modules/Makefile.pre.in file.  Making
ccpython.o
using a separate build directory seems to work fine for me.
Setting status to "closed" and resolution to "fixed".  I
hope that's
the correct flags.


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 08:53

Message:
Logged In: YES 
user_id=6380

Assigned to Neil Schemenauer, the build expert.

Neil, this looks like a trivial fix.  If you agree, can you
check it in?

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

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


From noreply@sourceforge.net  Tue Apr 10 17:15:04 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 10 Apr 2001 09:15:04 -0700
Subject: [Python-bugs-list] [ python-Bugs-414228 ] Wrong PYTHONPATH in Makefile
Message-ID: <E14n0nI-0003tS-00@usw-sf-web1.sourceforge.net>

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

Category: Build
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Wrong PYTHONPATH in Makefile

Initial Comment:
The build process stopped with error in target 
sharemods

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
*** Error code 1
make: Fatal error: Command failed for target 
`sharedmods'

This is cured with changing the Makefile (inserting 
./Lib)

# Build the shared modules
sharedmods: $(PYTHON)
	PYTHONPATH=./Lib ./$(PYTHON) 
$(srcdir)/setup.py build


Python: Python-2.1b2a
System: SunOS 5.7 Generic sun4u sparc SUNW,Ultra-60




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

>Comment By: Neil Schemenauer (nascheme)
Date: 2001-04-10 09:15

Message:
Logged In: YES 
user_id=35752

Setting PYTHONPATH should not be required.  Modules/getpath
must be getting confused.  I have no idea why.  The output
from

  ./python -c "import sys; print sys.path"

might be helpful.

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

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


From noreply@sourceforge.net  Tue Apr 10 18:49:45 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 10 Apr 2001 10:49:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-413956 ] 2.1b2 CVS termios no longer compiles
Message-ID: <E14n2Gv-0008Sx-00@usw-sf-web3.sourceforge.net>

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

Category: Build
>Group: Platform-specific
>Status: Closed
Priority: 5
Submitted By: Mark Favas (mfavas)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: 2.1b2 CVS termios no longer compiles

Initial Comment:
CVS version of 2.1b2 termios module now fails to
compile on Tru64 Unix. The April 5 version of termios.c
has a bunch of new constants defined, protected by
#ifdef's. Unfortunately, some of these constants are
defined in sys/ioctl.h under Tru64 Unix, but not in a
compatible way with constants defined in termios.h.
More detail: compilation fails thusly:
building 'termios' extension
cc -O -Olimit 1500 -I. -I./Include -I/usr/local/include
-IInclude/ -c Modules/termios.c -o
build/temp.osf1-V4.0-alpha-2.1/termios.o
cc: Error: Modules/termios.c, line 662: In the
initializer for termios_constants[142].value, "struct
termio" is an incomplete type, and so has no size.
(sizeincomptyp)
        {"TCGETA", TCGETA},
-------------------^
cc: Error: Modules/termios.c, line 674: In the
initializer for termios_constants[145].value, "struct
termio" is an incomplete type, and so has no size.
(sizeincomptyp)
        {"TCSETA", TCSETA},
-------------------^
cc: Error: Modules/termios.c, line 677: In the
initializer for termios_constants[146].value, "struct
termio" is an incomplete type, and so has no size.
(sizeincomptyp)
        {"TCSETAF", TCSETAF},
--------------------^
cc: Error: Modules/termios.c, line 680: In the
initializer for termios_constants[147].value, "struct
termio" is an incomplete type, and so has no size.
(sizeincomptyp)
        {"TCSETAW", TCSETAW},
--------------------^
WARNING: building of extension "termios" failed:
command 'cc' failed with exit status 1

TCGETA, TCSETA, TCSETAF, and TCSETAW are defined in
/usr/include/sys/ioctl.h as, for example,
#define TCGETA          _IOW('t', 23, struct termio) /*
set termio struct */
which is not compatible with their use in termios.c,
where the expectation is that the constants will be
defined as small integers.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 10:49

Message:
Logged In: YES 
user_id=6380

This now compiles fine on Tru64 with the latest CVS version,
so I'm closing this bug report.


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

Comment By: Michael Hudson (mwh)
Date: 2001-04-08 07:45

Message:
Logged In: YES 
user_id=6656

I can make this compile on alpha by #include-ing <termio.h>

This also works on linux.  Don't know about the many
millions of other unixen (I only have a linux box, and an
account on an elderly department alpha).

Unless the build can be tested everywhere we try to build
termios, the #include should probably be left out - but
programs that used TERMIOS in 2.0 have a good chance of
breaking.

Maybe an

#ifdef linux /* or whatever */
#inlcude <sys/ioctl.h>
#endif

could be added?  This would keep /me/ happy, at least.

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

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


From noreply@sourceforge.net  Tue Apr 10 18:53:24 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 10 Apr 2001 10:53:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-231328 ] fcntl module functions should accept file module arguments.
Message-ID: <E14n2KS-0007Ds-00@usw-sf-web2.sourceforge.net>

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

Category: Python Library
Group: Feature Request
Status: Open
Priority: 5
Submitted By: Eric S. Raymond (esr)
Assigned to: A.M. Kuchling (akuchling)
Summary: fcntl module functions should accept file module arguments.

Initial Comment:
The functions in the standard library fcntl module require integer
(file descriptor) arguments.  They should accept arguments with a
fileno() method as well, in particular file objects.


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

>Comment By: A.M. Kuchling (akuchling)
Date: 2001-04-10 10:53

Message:
Logged In: YES 
user_id=11375

I've let this gather dust long enough; unassigning so
someone else can take responsibility for it.

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

Comment By: Tim Peters (tim_one)
Date: 2001-02-08 19:02

Message:
Care to add mmap.mmap while you're at it?

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

Comment By: A.M. Kuchling (akuchling)
Date: 2001-02-08 09:24

Message:
Assigning to akuchling.

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

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


From noreply@sourceforge.net  Tue Apr 10 18:53:48 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 10 Apr 2001 10:53:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-231328 ] fcntl module functions should accept file module arguments.
Message-ID: <E14n2Kq-0007E5-00@usw-sf-web2.sourceforge.net>

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

Category: Python Library
Group: Feature Request
Status: Open
Priority: 5
Submitted By: Eric S. Raymond (esr)
>Assigned to: Nobody/Anonymous (nobody)
Summary: fcntl module functions should accept file module arguments.

Initial Comment:
The functions in the standard library fcntl module require integer
(file descriptor) arguments.  They should accept arguments with a
fileno() method as well, in particular file objects.


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

>Comment By: A.M. Kuchling (akuchling)
Date: 2001-04-10 10:53

Message:
Logged In: YES 
user_id=11375

I've let this gather dust long enough; unassigning so
someone else can take responsibility for it.

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

Comment By: A.M. Kuchling (akuchling)
Date: 2001-04-10 10:53

Message:
Logged In: YES 
user_id=11375

I've let this gather dust long enough; unassigning so
someone else can take responsibility for it.

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

Comment By: Tim Peters (tim_one)
Date: 2001-02-08 19:02

Message:
Care to add mmap.mmap while you're at it?

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

Comment By: A.M. Kuchling (akuchling)
Date: 2001-02-08 09:24

Message:
Assigning to akuchling.

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

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


From noreply@sourceforge.net  Tue Apr 10 18:54:19 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 10 Apr 2001 10:54:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-232460 ] SSL Support (Apparently) Broken on Solaris
Message-ID: <E14n2LL-0007Eb-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: Nobody/Anonymous (nobody)
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 Apr 10 18:54:57 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 10 Apr 2001 10:54:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-231249 ] cgi.py opens too many (temporary) files
Message-ID: <E14n2Lx-0007FI-00@usw-sf-web2.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Richard van de Stadt (stadt)
>Assigned to: Nobody/Anonymous (nobody)
Summary: cgi.py opens too many (temporary) files

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

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

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

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

>Comment By: A.M. Kuchling (akuchling)
Date: 2001-04-10 10:54

Message:
Logged In: YES 
user_id=11375

Unassigning so someone else can take a look at it.

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

Comment By: Kurt B. Kaiser (kbk)
Date: 2001-02-18 23:32

Message:
In the particular HTML form referenced it appears that a workaround might be to eliminate the enctype attribute in the <form> tag and take the application/x-www-form-urlencoded default since no files are being uploaded. 

When make_file creates the temporary files they are immediately unlinked. There is probably a brief period before the unlink is finalized during which the ls process might see a file; that would account for the output of ls | wc. It appears that the current cgi.py implementation leaves all the (hundreds of) files open until the cgi process releases the FieldStorage object or exits. 

My first thought was, if the filename recovered from the header is None have make_file create a StringIO object instead of a temp file. That way a temp file is only created when a file is uploaded. This is not inconsistent with the cgi.py docs.

Unfortunately, RFC2388 4.4 states that a filename is not required to be sent, so it looks like your solution based on the size of the data received is the correct one. Below 1K you could copy the temp file contents to a StringIO and assign it to self.file, then explicitly close the temp file via its descriptor. 

If only I understood the module better ::-(( and had a way of tunnel testing it I might have had the temerity to offer a patch. (I'm away for a couple of weeks starting tomorrow.)

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

Comment By: A.M. Kuchling (akuchling)
Date: 2001-02-18 14:08

Message:
Ah, I see; the traceback makes this much clearer.  When you're uploading a file, everything in the form is sent as 
a MIME document in the body; every field is accompanied by 
a boundary separator and Content-Disposition header.
In multipart mode, cgi.py copies each field into a temporary file.  

The first idea I had was to only use tempfiles for the actual upload field; unfortunately, that doesn't help because the upload field isn't special, and cgi.py has no way to know which it is ahead of time.

Possible second approach: measure the size of the resulting file; if it's less than some threshold (1K? 10K?), read its contents into memory and close the tempfile.  This means only the largest fields will require that a file descriptor be kept open.  I'll explore this more after beta1.




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

Comment By: Richard van de Stadt (stadt)
Date: 2001-02-17 18:37

Message:
I do *not* mean file upload fields. I stumbled upon this with a webform that
contains 141 'simple' input fields like the form you can see here (which 'only'
contains 31 of those input fields):

http://www.cyberchair.org/cgi-cyb/genAssignPageReviewerPapers.py

(use chair/chair to login)

When the maximum number of file descriptors used per process was increased
to 160 (by the sysadmins), the problem did not occur anymore, and the webform
could be processed.

This was the error message I got: 

Traceback (most recent call last):
  File "/usr/local/etc/httpd/DocumentRoot/ICML2001/cgi-bin/submitAssignRP.py", line 144, in main
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/cgi.py", line 504, in __init__
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/cgi.py", line 593, in read_multi
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/cgi.py", line 506, in __init__
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/cgi.py", line 603, in read_single
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/cgi.py", line 623, in read_lines
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/cgi.py", line 713, in make_file
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/tempfile.py", line 144, in TemporaryFile
OSError: [Errno 24] Too many open files: '/home/yara/brodley/icml2001/tmp/@26048.61'

I understand why you assume that it would concern *file* uploads, but this is
not the case. As I reported before, it turns out that for each 'simple' <input> field
a temporary file is used in to transfer the contents to the script that uses the
cgi.FieldStorage() method, even if no files are being uploaded. The problem is not
that too many files are open at the same time (which is 1 at most). It is the *amount*
of files that is causing the troubles. If the same temporary file would be used, this
problem would probably not have happened. 

My colleague Fred Gansevles wrote a possible solution, but mentioned that this
might introduce the need for protection against a 'symlink attack' (whatever
that may be). This solution(?) concentrates on the open file descriptor's problem,
while Fred suggests a redesign of FieldStorage() would probably be better.

import os, tempfile
AANTAL = 50

class TemporaryFile:
    def __init__(self):
        self.name = tempfile.mktemp("")
        open(self.name, 'w').close()
        self.offset = 0
    
    def seek(self, offset):
        self.offset = offset
    
    def read(self):
        fd = open(self.name, 'w+b', -1)
        fd.seek(self.offset)
        data = fd.read()
        self.offset = fd.tell()
        fd.close()
        return data
    
    def write(self, data):
        fd = open(self.name, 'w+b', -1)
        fd.seek(self.offset)
        fd.write(data)
        self.offset = fd.tell()
        fd.close()

    def __del__(self):
        os.unlink(self.name)

def add_fd(l, n) :
    map(lambda x,l=l: l.append(open('/dev/null')), range(n))

def add_tmp(l, n) :
    map(lambda x,l=l: l.append(TemporaryFile()), range(n))

def main ():
    import getopt, sys
    try:
        import resource
        soft, hard = resource.getrlimit (resource.RLIMIT_NOFILE)
        resource.setrlimit (resource.RLIMIT_NOFILE, (hard, hard))
    except ImportError:
        soft, hard = 64, 1024
    opts, args = getopt.getopt(sys.argv[1:], 'n:t')
    aantal = AANTAL
    tmp = add_fd
    for o, a in opts:
        if o == '-n':
            aantal = int(a)
        elif o == '-t':
            tmp = add_tmp
    print "aantal te gebruiken fd's:", aantal   #dutch; English: 'number of fds to be used'
    print 'tmp:', tmp.func_name
    tmp_files = []
    files=[]
    tmp(tmp_files, aantal)
    try:
        add_fd(files,hard)
    except IOError:
        pass
    print "aantal vrije gebruiken fd's:", len(files)  #enlish: 'number of free fds'

main()

Running the above code:

    python ulimit.py [-n number] [-t]
    default number = 50, while using 'real' fd-s for temporary files.
    When using the '-t' flag 'smart' temporary files are used.

    Output:

        $ python ulimit.py
        aantal te gebruiken fd's: 50
        tmp: add_fd
        aantal vrije gebruiken fd's: 970

        $ python ulimit.py -t
        aantal te gebruiken fd's: 50
        tmp: add_tmp
        aantal vrije gebruiken fd's: 1020

        $ python ulimit.py -n 1000
        aantal te gebruiken fd's: 1000
        tmp: add_fd
        aantal vrije gebruiken fd's: 20

        $ python ulimit.py -n 1000 -t
        aantal te gebruiken fd's: 1000
        tmp: add_tmp
        aantal vrije gebruiken fd's: 1020

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

Comment By: A.M. Kuchling (akuchling)
Date: 2001-02-16 21:41

Message:
I assume you mean 64 file upload fields, right?  
Can you provide a small test program that triggers the problem?

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

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


From noreply@sourceforge.net  Tue Apr 10 18:57:12 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 10 Apr 2001 10:57:12 -0700
Subject: [Python-bugs-list] [ python-Bugs-409430 ] pydoc shouldn't use #!/usr/bin/env
Message-ID: <E14n2O8-0007HT-00@usw-sf-web2.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.

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

>Comment By: A.M. Kuchling (akuchling)
Date: 2001-04-10 10:57

Message:
Logged In: YES 
user_id=11375

The pydoc script is Ping's, really.  Fixing this requires
Distutils 
hackery, and I don't see that this is worth fixing.  Leaving
it to someone else to make the decision to close it, though.

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

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  Tue Apr 10 18:58:06 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 10 Apr 2001 10:58:06 -0700
Subject: [Python-bugs-list] [ python-Bugs-232597 ] 2.1a2 compiler warnings on Compaq Tru64 Unix
Message-ID: <E14n2P0-00007c-00@usw-sf-web3.sourceforge.net>

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

Category: Build
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Mark Favas (mfavas)
>Assigned to: Nobody/Anonymous (nobody)
Summary: 2.1a2 compiler warnings on Compaq Tru64 Unix

Initial Comment:
2.1a2 from CVS of Feb 16 produces the following compiler warnings on Tru64
Unix (uname -a: OSF1 gonzo.per.dem.csiro.au V4.0 1229 alpha, Compaq C compiler, version: Compaq C V6.3-129 (dtk), Compiler Driver V6.3-126 (dtk)):

cc -c -O -Olimit 1500 -I. -I./Include -DHAVE_CONFIG_H  -o Python/ceval.o Python/ceval.c
cc: Info: Python/ceval.c, line 327: Trailing comma found in enumerator list. (trailcomma)
};


cc -O -Olimit 1500 -I. -I./Include -IInclude/ -I/usr/local/include -c Modules/_cursesmodule.c -o build/temp.osf1-V4.0-alpha-2.1/_cursesmodule.o
cc: Warning: Modules/_cursesmodule.c, line 632: In this statement, "derwin(...)" of type "int", is being converted to "pointer to struct _win_st". (cvtdiftypes)
  win = derwin(self->win,nlines,ncols,begin_y,begin_x);

cc: Warning: Modules/_cursesmodule.c, line 1287: In this statement, "subpad(...)" of type "int", is being converted to "pointer to struct _win_st". (cvtdiftypes)
    win = subpad(self->win, nlines, ncols, begin_y, begin_x);

cc: Warning: Modules/_cursesmodule.c, line 1517: In this statement, "termname(...)" of type "int", is being converted to "pointer to const char". (cvtdiftypes)
NoArgReturnStringFunction(termname)

cc: Warning: Modules/_cursesmodule.c, line 1686: In this statement, "getwin(...)" of type "int", is being converted to "pointer to struct _win_st". (cvtdiftypes)
  win = getwin(PyFile_AsFile(temp));

cc: Warning: Modules/_cursesmodule.c, line 1954: In this statement, "keyname(...)" of type "int", is being converted to "pointer to const char". (cvtdiftypes)
  knp = keyname(ch);

cc: Warning: Modules/_cursesmodule.c, line 2245: In this statement, "tigetstr(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
        capname = tigetstr( capname );

cc: Warning: Modules/_cursesmodule.c, line 2270: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt);

cc: Warning: Modules/_cursesmodule.c, line 2273: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1);

cc: Warning: Modules/_cursesmodule.c, line 2276: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1,i2);

cc: Warning: Modules/_cursesmodule.c, line 2279: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1,i2,i3);

cc: Warning: Modules/_cursesmodule.c, line 2282: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1,i2,i3,i4);

cc: Warning: Modules/_cursesmodule.c, line 2285: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1,i2,i3,i4,i5);

cc: Warning: Modules/_cursesmodule.c, line 2288: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1,i2,i3,i4,i5,i6);

cc: Warning: Modules/_cursesmodule.c, line 2291: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1,i2,i3,i4,i5,i6,i7);

cc: Warning: Modules/_cursesmodule.c, line 2294: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1,i2,i3,i4,i5,i6,i7,i8);

cc: Warning: Modules/_cursesmodule.c, line 2297: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1,i2,i3,i4,i5,i6,i7,i8,i9);

cc: Warning: Modules/_cursesmodule.c, line 310: The scalar variable "arg1" is fetched but not initialized.  And there may be other such fetches of this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getparyx, int, "(ii)")

cc: Warning: Modules/_cursesmodule.c, line 310: The scalar variable "arg2" is fetched but not initialized.  And there may be other such fetches of this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getparyx, int, "(ii)")

cc: Warning: Modules/_cursesmodule.c, line 309: The scalar variable "arg1" is fetched but not initialized.  And there may be other such fetches of this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getmaxyx, int, "(ii)")

cc: Warning: Modules/_cursesmodule.c, line 309: The scalar variable "arg2" is fetched but not initialized.  And there may be other such fetches of this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getmaxyx, int, "(ii)")

cc: Warning: Modules/_cursesmodule.c, line 308: The scalar variable "arg1" is fetched but not initialized.  And there may be other such fetches of this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getbegyx, int, "(ii)")

cc: Warning: Modules/_cursesmodule.c, line 308: The scalar variable "arg2" is fetched but not initialized.  And there may be other such fetches of this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getbegyx, int, "(ii)")






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

>Comment By: A.M. Kuchling (akuchling)
Date: 2001-04-10 10:58

Message:
Logged In: YES 
user_id=11375

Unassigning, since I have no way of debugging this problem.

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

Comment By: A.M. Kuchling (akuchling)
Date: 2001-02-27 11:42

Message:
Logged In: YES 
user_id=11375

The get*yx() calls are always defined as macros.  This does
look like the correct curses.h header isn't  being picked
up.  Does Tru64's curses.h header require some magical
#define in order to work?

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-02-19 13:55

Message:
Looks like a different header may be needed to pick up the prototypes for many of these.  Assigned to the curses module guy.

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

Comment By: Thomas Wouters (twouters)
Date: 2001-02-16 04:14

Message:
The first warning is my mistake. I thought I fixed that in a more recent version of my continue-inside-try patch, but apparently I didn't. Fixed in revision 2.230 of Python/ceval.c

The warnings in Modules/_cursusmodule.c are most likely caused by undefined functions, though why you don't see an error for those beats me. (undefined functions default to int-returning functions, so that's probably why you see those warnings.) 

The *other* warnings look damned legit, though, and the only reason they aren't is because getmaxyx and co. are (on the BSDI and Linux boxes I have acces to) defined as being macro calls, and in fact they *have* to be macro calls (or non-standard C calls) or they can't work. I'm not a curses expert, but I think an initialization is in place here (or just rewriting the silly macros so they make *sense* :-)


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

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


From noreply@sourceforge.net  Tue Apr 10 19:53:30 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 10 Apr 2001 11:53:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-231328 ] fcntl module functions should accept file module arguments.
Message-ID: <E14n3Gc-0006UP-00@usw-sf-web1.sourceforge.net>

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

Category: Python Library
Group: Feature Request
Status: Open
>Priority: 2
Submitted By: Eric S. Raymond (esr)
Assigned to: Nobody/Anonymous (nobody)
Summary: fcntl module functions should accept file module arguments.

Initial Comment:
The functions in the standard library fcntl module require integer
(file descriptor) arguments.  They should accept arguments with a
fileno() method as well, in particular file objects.


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 11:53

Message:
Logged In: YES 
user_id=6380

This would be a simple patch. Anyone care to provide one?

(Too late for 2.1 though -- sorry.)


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

Comment By: A.M. Kuchling (akuchling)
Date: 2001-04-10 10:53

Message:
Logged In: YES 
user_id=11375

I've let this gather dust long enough; unassigning so
someone else can take responsibility for it.

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

Comment By: A.M. Kuchling (akuchling)
Date: 2001-04-10 10:53

Message:
Logged In: YES 
user_id=11375

I've let this gather dust long enough; unassigning so
someone else can take responsibility for it.

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

Comment By: Tim Peters (tim_one)
Date: 2001-02-08 19:02

Message:
Care to add mmap.mmap while you're at it?

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

Comment By: A.M. Kuchling (akuchling)
Date: 2001-02-08 09:24

Message:
Assigning to akuchling.

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

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


From noreply@sourceforge.net  Tue Apr 10 19:54:23 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 10 Apr 2001 11:54:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-231249 ] cgi.py opens too many (temporary) files
Message-ID: <E14n3HT-0006Vb-00@usw-sf-web1.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Richard van de Stadt (stadt)
Assigned to: Nobody/Anonymous (nobody)
Summary: cgi.py opens too many (temporary) files

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

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

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

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 11:54

Message:
Logged In: YES 
user_id=6380

I wish I'd heard about this sooner.

It does seem a problem and it does make sense to use StringIO unless there's a lot of data.

But we can't fix this in time for 2.1...


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

Comment By: A.M. Kuchling (akuchling)
Date: 2001-04-10 10:54

Message:
Logged In: YES 
user_id=11375

Unassigning so someone else can take a look at it.

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

Comment By: Kurt B. Kaiser (kbk)
Date: 2001-02-18 23:32

Message:
In the particular HTML form referenced it appears that a workaround might be to eliminate the enctype attribute in the <form> tag and take the application/x-www-form-urlencoded default since no files are being uploaded. 

When make_file creates the temporary files they are immediately unlinked. There is probably a brief period before the unlink is finalized during which the ls process might see a file; that would account for the output of ls | wc. It appears that the current cgi.py implementation leaves all the (hundreds of) files open until the cgi process releases the FieldStorage object or exits. 

My first thought was, if the filename recovered from the header is None have make_file create a StringIO object instead of a temp file. That way a temp file is only created when a file is uploaded. This is not inconsistent with the cgi.py docs.

Unfortunately, RFC2388 4.4 states that a filename is not required to be sent, so it looks like your solution based on the size of the data received is the correct one. Below 1K you could copy the temp file contents to a StringIO and assign it to self.file, then explicitly close the temp file via its descriptor. 

If only I understood the module better ::-(( and had a way of tunnel testing it I might have had the temerity to offer a patch. (I'm away for a couple of weeks starting tomorrow.)

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

Comment By: A.M. Kuchling (akuchling)
Date: 2001-02-18 14:08

Message:
Ah, I see; the traceback makes this much clearer.  When you're uploading a file, everything in the form is sent as 
a MIME document in the body; every field is accompanied by 
a boundary separator and Content-Disposition header.
In multipart mode, cgi.py copies each field into a temporary file.  

The first idea I had was to only use tempfiles for the actual upload field; unfortunately, that doesn't help because the upload field isn't special, and cgi.py has no way to know which it is ahead of time.

Possible second approach: measure the size of the resulting file; if it's less than some threshold (1K? 10K?), read its contents into memory and close the tempfile.  This means only the largest fields will require that a file descriptor be kept open.  I'll explore this more after beta1.




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

Comment By: Richard van de Stadt (stadt)
Date: 2001-02-17 18:37

Message:
I do *not* mean file upload fields. I stumbled upon this with a webform that
contains 141 'simple' input fields like the form you can see here (which 'only'
contains 31 of those input fields):

http://www.cyberchair.org/cgi-cyb/genAssignPageReviewerPapers.py

(use chair/chair to login)

When the maximum number of file descriptors used per process was increased
to 160 (by the sysadmins), the problem did not occur anymore, and the webform
could be processed.

This was the error message I got: 

Traceback (most recent call last):
  File "/usr/local/etc/httpd/DocumentRoot/ICML2001/cgi-bin/submitAssignRP.py", line 144, in main
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/cgi.py", line 504, in __init__
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/cgi.py", line 593, in read_multi
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/cgi.py", line 506, in __init__
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/cgi.py", line 603, in read_single
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/cgi.py", line 623, in read_lines
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/cgi.py", line 713, in make_file
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/tempfile.py", line 144, in TemporaryFile
OSError: [Errno 24] Too many open files: '/home/yara/brodley/icml2001/tmp/@26048.61'

I understand why you assume that it would concern *file* uploads, but this is
not the case. As I reported before, it turns out that for each 'simple' <input> field
a temporary file is used in to transfer the contents to the script that uses the
cgi.FieldStorage() method, even if no files are being uploaded. The problem is not
that too many files are open at the same time (which is 1 at most). It is the *amount*
of files that is causing the troubles. If the same temporary file would be used, this
problem would probably not have happened. 

My colleague Fred Gansevles wrote a possible solution, but mentioned that this
might introduce the need for protection against a 'symlink attack' (whatever
that may be). This solution(?) concentrates on the open file descriptor's problem,
while Fred suggests a redesign of FieldStorage() would probably be better.

import os, tempfile
AANTAL = 50

class TemporaryFile:
    def __init__(self):
        self.name = tempfile.mktemp("")
        open(self.name, 'w').close()
        self.offset = 0
    
    def seek(self, offset):
        self.offset = offset
    
    def read(self):
        fd = open(self.name, 'w+b', -1)
        fd.seek(self.offset)
        data = fd.read()
        self.offset = fd.tell()
        fd.close()
        return data
    
    def write(self, data):
        fd = open(self.name, 'w+b', -1)
        fd.seek(self.offset)
        fd.write(data)
        self.offset = fd.tell()
        fd.close()

    def __del__(self):
        os.unlink(self.name)

def add_fd(l, n) :
    map(lambda x,l=l: l.append(open('/dev/null')), range(n))

def add_tmp(l, n) :
    map(lambda x,l=l: l.append(TemporaryFile()), range(n))

def main ():
    import getopt, sys
    try:
        import resource
        soft, hard = resource.getrlimit (resource.RLIMIT_NOFILE)
        resource.setrlimit (resource.RLIMIT_NOFILE, (hard, hard))
    except ImportError:
        soft, hard = 64, 1024
    opts, args = getopt.getopt(sys.argv[1:], 'n:t')
    aantal = AANTAL
    tmp = add_fd
    for o, a in opts:
        if o == '-n':
            aantal = int(a)
        elif o == '-t':
            tmp = add_tmp
    print "aantal te gebruiken fd's:", aantal   #dutch; English: 'number of fds to be used'
    print 'tmp:', tmp.func_name
    tmp_files = []
    files=[]
    tmp(tmp_files, aantal)
    try:
        add_fd(files,hard)
    except IOError:
        pass
    print "aantal vrije gebruiken fd's:", len(files)  #enlish: 'number of free fds'

main()

Running the above code:

    python ulimit.py [-n number] [-t]
    default number = 50, while using 'real' fd-s for temporary files.
    When using the '-t' flag 'smart' temporary files are used.

    Output:

        $ python ulimit.py
        aantal te gebruiken fd's: 50
        tmp: add_fd
        aantal vrije gebruiken fd's: 970

        $ python ulimit.py -t
        aantal te gebruiken fd's: 50
        tmp: add_tmp
        aantal vrije gebruiken fd's: 1020

        $ python ulimit.py -n 1000
        aantal te gebruiken fd's: 1000
        tmp: add_fd
        aantal vrije gebruiken fd's: 20

        $ python ulimit.py -n 1000 -t
        aantal te gebruiken fd's: 1000
        tmp: add_tmp
        aantal vrije gebruiken fd's: 1020

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

Comment By: A.M. Kuchling (akuchling)
Date: 2001-02-16 21:41

Message:
I assume you mean 64 file upload fields, right?  
Can you provide a small test program that triggers the problem?

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

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


From noreply@sourceforge.net  Tue Apr 10 19:55:36 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 10 Apr 2001 11:55:36 -0700
Subject: [Python-bugs-list] [ python-Bugs-232460 ] SSL Support (Apparently) Broken on Solaris
Message-ID: <E14n3Ie-0006XL-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: Nobody/Anonymous (nobody)
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: Guido van Rossum (gvanrossum)
Date: 2001-04-10 11:55

Message:
Logged In: YES 
user_id=6380

So, David, you still interested in this?

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

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 Apr 10 20:09:36 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 10 Apr 2001 12:09:36 -0700
Subject: [Python-bugs-list] [ python-Bugs-232597 ] 2.1a2 compiler warnings on Compaq Tru64 Unix
Message-ID: <E14n3WC-0008C2-00@usw-sf-web2.sourceforge.net>

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

Category: Build
Group: Platform-specific
Status: Open
>Priority: 2
Submitted By: Mark Favas (mfavas)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.1a2 compiler warnings on Compaq Tru64 Unix

Initial Comment:
2.1a2 from CVS of Feb 16 produces the following compiler warnings on Tru64
Unix (uname -a: OSF1 gonzo.per.dem.csiro.au V4.0 1229 alpha, Compaq C compiler, version: Compaq C V6.3-129 (dtk), Compiler Driver V6.3-126 (dtk)):

cc -c -O -Olimit 1500 -I. -I./Include -DHAVE_CONFIG_H  -o Python/ceval.o Python/ceval.c
cc: Info: Python/ceval.c, line 327: Trailing comma found in enumerator list. (trailcomma)
};


cc -O -Olimit 1500 -I. -I./Include -IInclude/ -I/usr/local/include -c Modules/_cursesmodule.c -o build/temp.osf1-V4.0-alpha-2.1/_cursesmodule.o
cc: Warning: Modules/_cursesmodule.c, line 632: In this statement, "derwin(...)" of type "int", is being converted to "pointer to struct _win_st". (cvtdiftypes)
  win = derwin(self->win,nlines,ncols,begin_y,begin_x);

cc: Warning: Modules/_cursesmodule.c, line 1287: In this statement, "subpad(...)" of type "int", is being converted to "pointer to struct _win_st". (cvtdiftypes)
    win = subpad(self->win, nlines, ncols, begin_y, begin_x);

cc: Warning: Modules/_cursesmodule.c, line 1517: In this statement, "termname(...)" of type "int", is being converted to "pointer to const char". (cvtdiftypes)
NoArgReturnStringFunction(termname)

cc: Warning: Modules/_cursesmodule.c, line 1686: In this statement, "getwin(...)" of type "int", is being converted to "pointer to struct _win_st". (cvtdiftypes)
  win = getwin(PyFile_AsFile(temp));

cc: Warning: Modules/_cursesmodule.c, line 1954: In this statement, "keyname(...)" of type "int", is being converted to "pointer to const char". (cvtdiftypes)
  knp = keyname(ch);

cc: Warning: Modules/_cursesmodule.c, line 2245: In this statement, "tigetstr(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
        capname = tigetstr( capname );

cc: Warning: Modules/_cursesmodule.c, line 2270: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt);

cc: Warning: Modules/_cursesmodule.c, line 2273: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1);

cc: Warning: Modules/_cursesmodule.c, line 2276: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1,i2);

cc: Warning: Modules/_cursesmodule.c, line 2279: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1,i2,i3);

cc: Warning: Modules/_cursesmodule.c, line 2282: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1,i2,i3,i4);

cc: Warning: Modules/_cursesmodule.c, line 2285: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1,i2,i3,i4,i5);

cc: Warning: Modules/_cursesmodule.c, line 2288: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1,i2,i3,i4,i5,i6);

cc: Warning: Modules/_cursesmodule.c, line 2291: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1,i2,i3,i4,i5,i6,i7);

cc: Warning: Modules/_cursesmodule.c, line 2294: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1,i2,i3,i4,i5,i6,i7,i8);

cc: Warning: Modules/_cursesmodule.c, line 2297: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1,i2,i3,i4,i5,i6,i7,i8,i9);

cc: Warning: Modules/_cursesmodule.c, line 310: The scalar variable "arg1" is fetched but not initialized.  And there may be other such fetches of this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getparyx, int, "(ii)")

cc: Warning: Modules/_cursesmodule.c, line 310: The scalar variable "arg2" is fetched but not initialized.  And there may be other such fetches of this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getparyx, int, "(ii)")

cc: Warning: Modules/_cursesmodule.c, line 309: The scalar variable "arg1" is fetched but not initialized.  And there may be other such fetches of this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getmaxyx, int, "(ii)")

cc: Warning: Modules/_cursesmodule.c, line 309: The scalar variable "arg2" is fetched but not initialized.  And there may be other such fetches of this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getmaxyx, int, "(ii)")

cc: Warning: Modules/_cursesmodule.c, line 308: The scalar variable "arg1" is fetched but not initialized.  And there may be other such fetches of this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getbegyx, int, "(ii)")

cc: Warning: Modules/_cursesmodule.c, line 308: The scalar variable "arg2" is fetched but not initialized.  And there may be other such fetches of this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getbegyx, int, "(ii)")






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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 12:09

Message:
Logged In: YES 
user_id=6380

Having just discovered the Tru64 test machine at the SourceForge Compile Farm, I can confirm that the curses 
module is not built correctly on that platform.

My suspicion is that there's a curses.h header for an ancient version of curses, so that the setup script is mistaken 
in even trying to build the _curses module.  I don't know how to prevent it from doing so though...  Maybe a check 
for a certain symbol in the curses.h header could be added to the setup.py script???

Andrew, I'm not reassigning this back to you, because you just unassigned it; but you really do seem to have the 
knowledge to move this forward...

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

Comment By: A.M. Kuchling (akuchling)
Date: 2001-04-10 10:58

Message:
Logged In: YES 
user_id=11375

Unassigning, since I have no way of debugging this problem.

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

Comment By: A.M. Kuchling (akuchling)
Date: 2001-02-27 11:42

Message:
Logged In: YES 
user_id=11375

The get*yx() calls are always defined as macros.  This does
look like the correct curses.h header isn't  being picked
up.  Does Tru64's curses.h header require some magical
#define in order to work?

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-02-19 13:55

Message:
Looks like a different header may be needed to pick up the prototypes for many of these.  Assigned to the curses module guy.

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

Comment By: Thomas Wouters (twouters)
Date: 2001-02-16 04:14

Message:
The first warning is my mistake. I thought I fixed that in a more recent version of my continue-inside-try patch, but apparently I didn't. Fixed in revision 2.230 of Python/ceval.c

The warnings in Modules/_cursusmodule.c are most likely caused by undefined functions, though why you don't see an error for those beats me. (undefined functions default to int-returning functions, so that's probably why you see those warnings.) 

The *other* warnings look damned legit, though, and the only reason they aren't is because getmaxyx and co. are (on the BSDI and Linux boxes I have acces to) defined as being macro calls, and in fact they *have* to be macro calls (or non-standard C calls) or they can't work. I'm not a curses expert, but I think an initialization is in place here (or just rewriting the silly macros so they make *sense* :-)


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

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


From noreply@sourceforge.net  Tue Apr 10 20:10:10 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 10 Apr 2001 12:10:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-232597 ] _curses build broken on Compaq Tru64 Unix
Message-ID: <E14n3Wk-0008Cn-00@usw-sf-web2.sourceforge.net>

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

Category: Build
Group: Platform-specific
Status: Open
Priority: 2
Submitted By: Mark Favas (mfavas)
Assigned to: Nobody/Anonymous (nobody)
>Summary: _curses build broken on Compaq Tru64 Unix

Initial Comment:
2.1a2 from CVS of Feb 16 produces the following compiler warnings on Tru64
Unix (uname -a: OSF1 gonzo.per.dem.csiro.au V4.0 1229 alpha, Compaq C compiler, version: Compaq C V6.3-129 (dtk), Compiler Driver V6.3-126 (dtk)):

cc -c -O -Olimit 1500 -I. -I./Include -DHAVE_CONFIG_H  -o Python/ceval.o Python/ceval.c
cc: Info: Python/ceval.c, line 327: Trailing comma found in enumerator list. (trailcomma)
};


cc -O -Olimit 1500 -I. -I./Include -IInclude/ -I/usr/local/include -c Modules/_cursesmodule.c -o build/temp.osf1-V4.0-alpha-2.1/_cursesmodule.o
cc: Warning: Modules/_cursesmodule.c, line 632: In this statement, "derwin(...)" of type "int", is being converted to "pointer to struct _win_st". (cvtdiftypes)
  win = derwin(self->win,nlines,ncols,begin_y,begin_x);

cc: Warning: Modules/_cursesmodule.c, line 1287: In this statement, "subpad(...)" of type "int", is being converted to "pointer to struct _win_st". (cvtdiftypes)
    win = subpad(self->win, nlines, ncols, begin_y, begin_x);

cc: Warning: Modules/_cursesmodule.c, line 1517: In this statement, "termname(...)" of type "int", is being converted to "pointer to const char". (cvtdiftypes)
NoArgReturnStringFunction(termname)

cc: Warning: Modules/_cursesmodule.c, line 1686: In this statement, "getwin(...)" of type "int", is being converted to "pointer to struct _win_st". (cvtdiftypes)
  win = getwin(PyFile_AsFile(temp));

cc: Warning: Modules/_cursesmodule.c, line 1954: In this statement, "keyname(...)" of type "int", is being converted to "pointer to const char". (cvtdiftypes)
  knp = keyname(ch);

cc: Warning: Modules/_cursesmodule.c, line 2245: In this statement, "tigetstr(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
        capname = tigetstr( capname );

cc: Warning: Modules/_cursesmodule.c, line 2270: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt);

cc: Warning: Modules/_cursesmodule.c, line 2273: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1);

cc: Warning: Modules/_cursesmodule.c, line 2276: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1,i2);

cc: Warning: Modules/_cursesmodule.c, line 2279: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1,i2,i3);

cc: Warning: Modules/_cursesmodule.c, line 2282: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1,i2,i3,i4);

cc: Warning: Modules/_cursesmodule.c, line 2285: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1,i2,i3,i4,i5);

cc: Warning: Modules/_cursesmodule.c, line 2288: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1,i2,i3,i4,i5,i6);

cc: Warning: Modules/_cursesmodule.c, line 2291: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1,i2,i3,i4,i5,i6,i7);

cc: Warning: Modules/_cursesmodule.c, line 2294: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1,i2,i3,i4,i5,i6,i7,i8);

cc: Warning: Modules/_cursesmodule.c, line 2297: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1,i2,i3,i4,i5,i6,i7,i8,i9);

cc: Warning: Modules/_cursesmodule.c, line 310: The scalar variable "arg1" is fetched but not initialized.  And there may be other such fetches of this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getparyx, int, "(ii)")

cc: Warning: Modules/_cursesmodule.c, line 310: The scalar variable "arg2" is fetched but not initialized.  And there may be other such fetches of this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getparyx, int, "(ii)")

cc: Warning: Modules/_cursesmodule.c, line 309: The scalar variable "arg1" is fetched but not initialized.  And there may be other such fetches of this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getmaxyx, int, "(ii)")

cc: Warning: Modules/_cursesmodule.c, line 309: The scalar variable "arg2" is fetched but not initialized.  And there may be other such fetches of this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getmaxyx, int, "(ii)")

cc: Warning: Modules/_cursesmodule.c, line 308: The scalar variable "arg1" is fetched but not initialized.  And there may be other such fetches of this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getbegyx, int, "(ii)")

cc: Warning: Modules/_cursesmodule.c, line 308: The scalar variable "arg2" is fetched but not initialized.  And there may be other such fetches of this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getbegyx, int, "(ii)")






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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 12:10

Message:
Logged In: YES 
user_id=6380

Changing the subject -- it's only about _curses now.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 12:09

Message:
Logged In: YES 
user_id=6380

Having just discovered the Tru64 test machine at the SourceForge Compile Farm, I can confirm that the curses 
module is not built correctly on that platform.

My suspicion is that there's a curses.h header for an ancient version of curses, so that the setup script is mistaken 
in even trying to build the _curses module.  I don't know how to prevent it from doing so though...  Maybe a check 
for a certain symbol in the curses.h header could be added to the setup.py script???

Andrew, I'm not reassigning this back to you, because you just unassigned it; but you really do seem to have the 
knowledge to move this forward...

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

Comment By: A.M. Kuchling (akuchling)
Date: 2001-04-10 10:58

Message:
Logged In: YES 
user_id=11375

Unassigning, since I have no way of debugging this problem.

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

Comment By: A.M. Kuchling (akuchling)
Date: 2001-02-27 11:42

Message:
Logged In: YES 
user_id=11375

The get*yx() calls are always defined as macros.  This does
look like the correct curses.h header isn't  being picked
up.  Does Tru64's curses.h header require some magical
#define in order to work?

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-02-19 13:55

Message:
Looks like a different header may be needed to pick up the prototypes for many of these.  Assigned to the curses module guy.

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

Comment By: Thomas Wouters (twouters)
Date: 2001-02-16 04:14

Message:
The first warning is my mistake. I thought I fixed that in a more recent version of my continue-inside-try patch, but apparently I didn't. Fixed in revision 2.230 of Python/ceval.c

The warnings in Modules/_cursusmodule.c are most likely caused by undefined functions, though why you don't see an error for those beats me. (undefined functions default to int-returning functions, so that's probably why you see those warnings.) 

The *other* warnings look damned legit, though, and the only reason they aren't is because getmaxyx and co. are (on the BSDI and Linux boxes I have acces to) defined as being macro calls, and in fact they *have* to be macro calls (or non-standard C calls) or they can't work. I'm not a curses expert, but I think an initialization is in place here (or just rewriting the silly macros so they make *sense* :-)


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

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


From noreply@sourceforge.net  Tue Apr 10 20:11:34 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 10 Apr 2001 12:11:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-409430 ] pydoc shouldn't use #!/usr/bin/env
Message-ID: <E14n3Y6-0008Dw-00@usw-sf-web2.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: 3
Submitted By: Michael Hudson (mwh)
>Assigned to: Ka-Ping Yee (ping)
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: Guido van Rossum (gvanrossum)
Date: 2001-04-10 12:11

Message:
Logged In: YES 
user_id=6380

OK, ping-pong.  Ping, do you have any bright ideas?

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

Comment By: A.M. Kuchling (akuchling)
Date: 2001-04-10 10:57

Message:
Logged In: YES 
user_id=11375

The pydoc script is Ping's, really.  Fixing this requires
Distutils 
hackery, and I don't see that this is worth fixing.  Leaving
it to someone else to make the decision to close it, though.

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

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  Tue Apr 10 20:15:12 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 10 Apr 2001 12:15:12 -0700
Subject: [Python-bugs-list] [ python-Bugs-414940 ] locale.format broken in 2.1b2
Message-ID: <E14n3bc-0008Gq-00@usw-sf-web2.sourceforge.net>

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

>Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Walter Dörwald (doerwalter)
>Assigned to: Martin v. Löwis (loewis)
Summary: locale.format broken in 2.1b2

Initial Comment:
locale.format seems
to be broken in 2.1b2:

>>> import locale
>>> locale.format("%+.02f", -42., 1) 
'-+42.00'


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 12:15

Message:
Logged In: YES 
user_id=6380

Yup, it's broken.  A simpler example is: locale.format("%+f", -42.).

Assigned to Martin, who is probably the author.  The code is incomprehensible to me (after 1 minute of trying :-).

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

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


From noreply@sourceforge.net  Tue Apr 10 20:18:42 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 10 Apr 2001 12:18:42 -0700
Subject: [Python-bugs-list] [ python-Bugs-414899 ] Pyton1.5.2: urllib.always_safe variable
Message-ID: <E14n3f0-0008JL-00@usw-sf-web2.sourceforge.net>

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

>Category: Python Library
Group: None
>Status: Closed
Priority: 5
Submitted By: HERMAN Etienne (delun)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: Pyton1.5.2: urllib.always_safe variable

Initial Comment:
Our environment is:
Python 1.5.2 (#1, Feb  1 2000, 16:32:16)  [GCC
egcs-2.91.66 19990314/Linux (egcs- on linux-i386)
LANG=fr_FR

Bug in the urllib.always_safe variable, it contains
accented characters :

>>> import urllib
>>> print urllib.always_safe
abcdefghijklmnopqrstuvwxyzßàáâãäåæçèéêëìíîïðñòóôõöøùúûüýþÿABCDEFGHIJKLMNOPQRSTUVWXYZÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖØÙÚÛÜÝÞ0123456789_,.-
>>> urllib.quote('élève')
'\351l\350ve'


>>> urllib.always_safe = 'abcdefghijklmnopqrstuvwxyz' +
'ABCDEFGHIJKLMNOPQRSTUVWXYZ' + '0123456789' + '*' +
'_.-'
>>> urllib.quote('élève')
'%e9l%e8ve'

Etienne HERMAN
devel@logilab.fr

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 12:18

Message:
Logged In: YES 
user_id=6380

Thanks; this was fixed in Python 2.x already.

We now simply do this in urllib.py

always_safe = ('ABCDEFGHIJKLMNOPQRSTUVWXYZ'
               'abcdefghijklmnopqrstuvwxyz'
               '0123456789' '_.-')


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

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


From noreply@sourceforge.net  Tue Apr 10 20:34:38 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 10 Apr 2001 12:34:38 -0700
Subject: [Python-bugs-list] [ python-Bugs-232597 ] _curses build broken on Compaq Tru64 Unix
Message-ID: <E14n3uQ-0001Fy-00@usw-sf-web3.sourceforge.net>

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

Category: Build
Group: Platform-specific
Status: Open
Priority: 2
Submitted By: Mark Favas (mfavas)
Assigned to: Nobody/Anonymous (nobody)
Summary: _curses build broken on Compaq Tru64 Unix

Initial Comment:
2.1a2 from CVS of Feb 16 produces the following compiler warnings on Tru64
Unix (uname -a: OSF1 gonzo.per.dem.csiro.au V4.0 1229 alpha, Compaq C compiler, version: Compaq C V6.3-129 (dtk), Compiler Driver V6.3-126 (dtk)):

cc -c -O -Olimit 1500 -I. -I./Include -DHAVE_CONFIG_H  -o Python/ceval.o Python/ceval.c
cc: Info: Python/ceval.c, line 327: Trailing comma found in enumerator list. (trailcomma)
};


cc -O -Olimit 1500 -I. -I./Include -IInclude/ -I/usr/local/include -c Modules/_cursesmodule.c -o build/temp.osf1-V4.0-alpha-2.1/_cursesmodule.o
cc: Warning: Modules/_cursesmodule.c, line 632: In this statement, "derwin(...)" of type "int", is being converted to "pointer to struct _win_st". (cvtdiftypes)
  win = derwin(self->win,nlines,ncols,begin_y,begin_x);

cc: Warning: Modules/_cursesmodule.c, line 1287: In this statement, "subpad(...)" of type "int", is being converted to "pointer to struct _win_st". (cvtdiftypes)
    win = subpad(self->win, nlines, ncols, begin_y, begin_x);

cc: Warning: Modules/_cursesmodule.c, line 1517: In this statement, "termname(...)" of type "int", is being converted to "pointer to const char". (cvtdiftypes)
NoArgReturnStringFunction(termname)

cc: Warning: Modules/_cursesmodule.c, line 1686: In this statement, "getwin(...)" of type "int", is being converted to "pointer to struct _win_st". (cvtdiftypes)
  win = getwin(PyFile_AsFile(temp));

cc: Warning: Modules/_cursesmodule.c, line 1954: In this statement, "keyname(...)" of type "int", is being converted to "pointer to const char". (cvtdiftypes)
  knp = keyname(ch);

cc: Warning: Modules/_cursesmodule.c, line 2245: In this statement, "tigetstr(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
        capname = tigetstr( capname );

cc: Warning: Modules/_cursesmodule.c, line 2270: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt);

cc: Warning: Modules/_cursesmodule.c, line 2273: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1);

cc: Warning: Modules/_cursesmodule.c, line 2276: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1,i2);

cc: Warning: Modules/_cursesmodule.c, line 2279: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1,i2,i3);

cc: Warning: Modules/_cursesmodule.c, line 2282: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1,i2,i3,i4);

cc: Warning: Modules/_cursesmodule.c, line 2285: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1,i2,i3,i4,i5);

cc: Warning: Modules/_cursesmodule.c, line 2288: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1,i2,i3,i4,i5,i6);

cc: Warning: Modules/_cursesmodule.c, line 2291: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1,i2,i3,i4,i5,i6,i7);

cc: Warning: Modules/_cursesmodule.c, line 2294: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1,i2,i3,i4,i5,i6,i7,i8);

cc: Warning: Modules/_cursesmodule.c, line 2297: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1,i2,i3,i4,i5,i6,i7,i8,i9);

cc: Warning: Modules/_cursesmodule.c, line 310: The scalar variable "arg1" is fetched but not initialized.  And there may be other such fetches of this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getparyx, int, "(ii)")

cc: Warning: Modules/_cursesmodule.c, line 310: The scalar variable "arg2" is fetched but not initialized.  And there may be other such fetches of this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getparyx, int, "(ii)")

cc: Warning: Modules/_cursesmodule.c, line 309: The scalar variable "arg1" is fetched but not initialized.  And there may be other such fetches of this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getmaxyx, int, "(ii)")

cc: Warning: Modules/_cursesmodule.c, line 309: The scalar variable "arg2" is fetched but not initialized.  And there may be other such fetches of this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getmaxyx, int, "(ii)")

cc: Warning: Modules/_cursesmodule.c, line 308: The scalar variable "arg1" is fetched but not initialized.  And there may be other such fetches of this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getbegyx, int, "(ii)")

cc: Warning: Modules/_cursesmodule.c, line 308: The scalar variable "arg2" is fetched but not initialized.  And there may be other such fetches of this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getbegyx, int, "(ii)")






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

Comment By: Michael Hudson (mwh)
Date: 2001-04-10 12:34

Message:
Logged In: YES 
user_id=6656

try this (aka it's not much use #defining
_XOPEN_SOURCE_EXTENDED *after* including <curses.h>!!)

Index: _cursesmodule.c
===================================================================
RCS file:
/cvsroot/python/python/dist/src/Modules/_cursesmodule.c,v
retrieving revision 2.50
diff -c -r2.50 _cursesmodule.c
*** _cursesmodule.c     2001/01/29 20:47:59     2.50
--- _cursesmodule.c     2001/04/10 19:31:41
***************
*** 100,112 ****
  /* Includes */
  
  #include "Python.h"
- #define CURSES_MODULE
- #include "py_curses.h"
  
  #ifdef __osf__
  #define _XOPEN_SOURCE_EXTENDED  /* Define macro for OSF/1 */
  #define STRICT_SYSV_CURSES      /* Don't use ncurses
extensions */
  #endif
  
  /*  These prototypes are in <term.h>, but including this
header 
      #defines many common symbols (such as "lines") which
breaks the 
--- 100,113 ----
  /* Includes */
  
  #include "Python.h"
  
  #ifdef __osf__
  #define _XOPEN_SOURCE_EXTENDED  /* Define macro for OSF/1 */
  #define STRICT_SYSV_CURSES      /* Don't use ncurses
extensions */
  #endif
+ 
+ #define CURSES_MODULE
+ #include "py_curses.h"
  
  /*  These prototypes are in <term.h>, but including this
header 
      #defines many common symbols (such as "lines") which
breaks the 

not sure this is correct fix, but i think this is the
problem.  no time for more investigation just yet.


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 12:10

Message:
Logged In: YES 
user_id=6380

Changing the subject -- it's only about _curses now.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 12:09

Message:
Logged In: YES 
user_id=6380

Having just discovered the Tru64 test machine at the SourceForge Compile Farm, I can confirm that the curses 
module is not built correctly on that platform.

My suspicion is that there's a curses.h header for an ancient version of curses, so that the setup script is mistaken 
in even trying to build the _curses module.  I don't know how to prevent it from doing so though...  Maybe a check 
for a certain symbol in the curses.h header could be added to the setup.py script???

Andrew, I'm not reassigning this back to you, because you just unassigned it; but you really do seem to have the 
knowledge to move this forward...

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

Comment By: A.M. Kuchling (akuchling)
Date: 2001-04-10 10:58

Message:
Logged In: YES 
user_id=11375

Unassigning, since I have no way of debugging this problem.

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

Comment By: A.M. Kuchling (akuchling)
Date: 2001-02-27 11:42

Message:
Logged In: YES 
user_id=11375

The get*yx() calls are always defined as macros.  This does
look like the correct curses.h header isn't  being picked
up.  Does Tru64's curses.h header require some magical
#define in order to work?

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-02-19 13:55

Message:
Looks like a different header may be needed to pick up the prototypes for many of these.  Assigned to the curses module guy.

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

Comment By: Thomas Wouters (twouters)
Date: 2001-02-16 04:14

Message:
The first warning is my mistake. I thought I fixed that in a more recent version of my continue-inside-try patch, but apparently I didn't. Fixed in revision 2.230 of Python/ceval.c

The warnings in Modules/_cursusmodule.c are most likely caused by undefined functions, though why you don't see an error for those beats me. (undefined functions default to int-returning functions, so that's probably why you see those warnings.) 

The *other* warnings look damned legit, though, and the only reason they aren't is because getmaxyx and co. are (on the BSDI and Linux boxes I have acces to) defined as being macro calls, and in fact they *have* to be macro calls (or non-standard C calls) or they can't work. I'm not a curses expert, but I think an initialization is in place here (or just rewriting the silly macros so they make *sense* :-)


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

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


From noreply@sourceforge.net  Tue Apr 10 20:54:47 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 10 Apr 2001 12:54:47 -0700
Subject: [Python-bugs-list] [ python-Bugs-232597 ] _curses build broken on Compaq Tru64 Unix
Message-ID: <E14n4Dv-0007Tx-00@usw-sf-web1.sourceforge.net>

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

Category: Build
Group: Platform-specific
>Status: Closed
Priority: 2
Submitted By: Mark Favas (mfavas)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: _curses build broken on Compaq Tru64 Unix

Initial Comment:
2.1a2 from CVS of Feb 16 produces the following compiler warnings on Tru64
Unix (uname -a: OSF1 gonzo.per.dem.csiro.au V4.0 1229 alpha, Compaq C compiler, version: Compaq C V6.3-129 (dtk), Compiler Driver V6.3-126 (dtk)):

cc -c -O -Olimit 1500 -I. -I./Include -DHAVE_CONFIG_H  -o Python/ceval.o Python/ceval.c
cc: Info: Python/ceval.c, line 327: Trailing comma found in enumerator list. (trailcomma)
};


cc -O -Olimit 1500 -I. -I./Include -IInclude/ -I/usr/local/include -c Modules/_cursesmodule.c -o build/temp.osf1-V4.0-alpha-2.1/_cursesmodule.o
cc: Warning: Modules/_cursesmodule.c, line 632: In this statement, "derwin(...)" of type "int", is being converted to "pointer to struct _win_st". (cvtdiftypes)
  win = derwin(self->win,nlines,ncols,begin_y,begin_x);

cc: Warning: Modules/_cursesmodule.c, line 1287: In this statement, "subpad(...)" of type "int", is being converted to "pointer to struct _win_st". (cvtdiftypes)
    win = subpad(self->win, nlines, ncols, begin_y, begin_x);

cc: Warning: Modules/_cursesmodule.c, line 1517: In this statement, "termname(...)" of type "int", is being converted to "pointer to const char". (cvtdiftypes)
NoArgReturnStringFunction(termname)

cc: Warning: Modules/_cursesmodule.c, line 1686: In this statement, "getwin(...)" of type "int", is being converted to "pointer to struct _win_st". (cvtdiftypes)
  win = getwin(PyFile_AsFile(temp));

cc: Warning: Modules/_cursesmodule.c, line 1954: In this statement, "keyname(...)" of type "int", is being converted to "pointer to const char". (cvtdiftypes)
  knp = keyname(ch);

cc: Warning: Modules/_cursesmodule.c, line 2245: In this statement, "tigetstr(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
        capname = tigetstr( capname );

cc: Warning: Modules/_cursesmodule.c, line 2270: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt);

cc: Warning: Modules/_cursesmodule.c, line 2273: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1);

cc: Warning: Modules/_cursesmodule.c, line 2276: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1,i2);

cc: Warning: Modules/_cursesmodule.c, line 2279: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1,i2,i3);

cc: Warning: Modules/_cursesmodule.c, line 2282: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1,i2,i3,i4);

cc: Warning: Modules/_cursesmodule.c, line 2285: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1,i2,i3,i4,i5);

cc: Warning: Modules/_cursesmodule.c, line 2288: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1,i2,i3,i4,i5,i6);

cc: Warning: Modules/_cursesmodule.c, line 2291: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1,i2,i3,i4,i5,i6,i7);

cc: Warning: Modules/_cursesmodule.c, line 2294: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1,i2,i3,i4,i5,i6,i7,i8);

cc: Warning: Modules/_cursesmodule.c, line 2297: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1,i2,i3,i4,i5,i6,i7,i8,i9);

cc: Warning: Modules/_cursesmodule.c, line 310: The scalar variable "arg1" is fetched but not initialized.  And there may be other such fetches of this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getparyx, int, "(ii)")

cc: Warning: Modules/_cursesmodule.c, line 310: The scalar variable "arg2" is fetched but not initialized.  And there may be other such fetches of this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getparyx, int, "(ii)")

cc: Warning: Modules/_cursesmodule.c, line 309: The scalar variable "arg1" is fetched but not initialized.  And there may be other such fetches of this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getmaxyx, int, "(ii)")

cc: Warning: Modules/_cursesmodule.c, line 309: The scalar variable "arg2" is fetched but not initialized.  And there may be other such fetches of this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getmaxyx, int, "(ii)")

cc: Warning: Modules/_cursesmodule.c, line 308: The scalar variable "arg1" is fetched but not initialized.  And there may be other such fetches of this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getbegyx, int, "(ii)")

cc: Warning: Modules/_cursesmodule.c, line 308: The scalar variable "arg2" is fetched but not initialized.  And there may be other such fetches of this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getbegyx, int, "(ii)")






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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 12:54

Message:
Logged In: YES 
user_id=6380

Thanks, Michael.  That works.  I'm checking this in, since
it doesn't seem to break anything on Linux.

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

Comment By: Michael Hudson (mwh)
Date: 2001-04-10 12:34

Message:
Logged In: YES 
user_id=6656

try this (aka it's not much use #defining
_XOPEN_SOURCE_EXTENDED *after* including <curses.h>!!)

Index: _cursesmodule.c
===================================================================
RCS file:
/cvsroot/python/python/dist/src/Modules/_cursesmodule.c,v
retrieving revision 2.50
diff -c -r2.50 _cursesmodule.c
*** _cursesmodule.c     2001/01/29 20:47:59     2.50
--- _cursesmodule.c     2001/04/10 19:31:41
***************
*** 100,112 ****
  /* Includes */
  
  #include "Python.h"
- #define CURSES_MODULE
- #include "py_curses.h"
  
  #ifdef __osf__
  #define _XOPEN_SOURCE_EXTENDED  /* Define macro for OSF/1 */
  #define STRICT_SYSV_CURSES      /* Don't use ncurses
extensions */
  #endif
  
  /*  These prototypes are in <term.h>, but including this
header 
      #defines many common symbols (such as "lines") which
breaks the 
--- 100,113 ----
  /* Includes */
  
  #include "Python.h"
  
  #ifdef __osf__
  #define _XOPEN_SOURCE_EXTENDED  /* Define macro for OSF/1 */
  #define STRICT_SYSV_CURSES      /* Don't use ncurses
extensions */
  #endif
+ 
+ #define CURSES_MODULE
+ #include "py_curses.h"
  
  /*  These prototypes are in <term.h>, but including this
header 
      #defines many common symbols (such as "lines") which
breaks the 

not sure this is correct fix, but i think this is the
problem.  no time for more investigation just yet.


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 12:10

Message:
Logged In: YES 
user_id=6380

Changing the subject -- it's only about _curses now.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 12:09

Message:
Logged In: YES 
user_id=6380

Having just discovered the Tru64 test machine at the SourceForge Compile Farm, I can confirm that the curses 
module is not built correctly on that platform.

My suspicion is that there's a curses.h header for an ancient version of curses, so that the setup script is mistaken 
in even trying to build the _curses module.  I don't know how to prevent it from doing so though...  Maybe a check 
for a certain symbol in the curses.h header could be added to the setup.py script???

Andrew, I'm not reassigning this back to you, because you just unassigned it; but you really do seem to have the 
knowledge to move this forward...

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

Comment By: A.M. Kuchling (akuchling)
Date: 2001-04-10 10:58

Message:
Logged In: YES 
user_id=11375

Unassigning, since I have no way of debugging this problem.

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

Comment By: A.M. Kuchling (akuchling)
Date: 2001-02-27 11:42

Message:
Logged In: YES 
user_id=11375

The get*yx() calls are always defined as macros.  This does
look like the correct curses.h header isn't  being picked
up.  Does Tru64's curses.h header require some magical
#define in order to work?

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-02-19 13:55

Message:
Looks like a different header may be needed to pick up the prototypes for many of these.  Assigned to the curses module guy.

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

Comment By: Thomas Wouters (twouters)
Date: 2001-02-16 04:14

Message:
The first warning is my mistake. I thought I fixed that in a more recent version of my continue-inside-try patch, but apparently I didn't. Fixed in revision 2.230 of Python/ceval.c

The warnings in Modules/_cursusmodule.c are most likely caused by undefined functions, though why you don't see an error for those beats me. (undefined functions default to int-returning functions, so that's probably why you see those warnings.) 

The *other* warnings look damned legit, though, and the only reason they aren't is because getmaxyx and co. are (on the BSDI and Linux boxes I have acces to) defined as being macro calls, and in fact they *have* to be macro calls (or non-standard C calls) or they can't work. I'm not a curses expert, but I think an initialization is in place here (or just rewriting the silly macros so they make *sense* :-)


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

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


From noreply@sourceforge.net  Tue Apr 10 20:58:23 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 10 Apr 2001 12:58:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-414743 ] Access violation in call to map
Message-ID: <E14n4HP-0007Xc-00@usw-sf-web1.sourceforge.net>

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

Category: Python Interpreter Core
Group: None
Status: Open
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Access violation in call to map

Initial Comment:
This call:

  map(None, *None)

results in an access violation (read of NULL pointer) 
under Python 2.1b2 (Win32 binaries downloaded from 
Sourceforge).  OS in Win2000.


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 12:58

Message:
Logged In: YES 
user_id=6380

Actually, the patch is #414750.

(Now you can search by patch/bug ID in the SF search box! 
Hurray!)

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

Comment By: Michael Hudson (mwh)
Date: 2001-04-08 13:38

Message:
Logged In: YES 
user_id=6656

Ooh, another one:

>>> dir(b=1,**{'b':1})
Segmentation fault (core dumped)

I'll update #414743 presently.

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

Comment By: Michael Hudson (mwh)
Date: 2001-04-08 13:25

Message:
Logged In: YES 
user_id=6656

Eek!

>>> None(*None)
Segmentation fault (core dumped)

This is Ping's fault.  In ext_do_call the code that tries to
work out the function name assumes that func is a
PyFunctionObject, where in fact it can be anything at all,
because this is called before the check to see whether we
really have a callable!  Oops.

Anyway, look at patch #414743 for my attempted fix.

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

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


From noreply@sourceforge.net  Tue Apr 10 21:00:30 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 10 Apr 2001 13:00:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-414743 ] Access violation in call to map
Message-ID: <E14n4JS-0007ai-00@usw-sf-web1.sourceforge.net>

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

Category: Python Interpreter Core
Group: None
Status: Open
Priority: 5
Submitted By: Greg Chapman (glchapman)
>Assigned to: Jeremy Hylton (jhylton)
Summary: Access violation in call to map

Initial Comment:
This call:

  map(None, *None)

results in an access violation (read of NULL pointer) 
under Python 2.1b2 (Win32 binaries downloaded from 
Sourceforge).  OS in Win2000.


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 13:00

Message:
Logged In: YES 
user_id=6380

Assigned to Jeremy.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 12:58

Message:
Logged In: YES 
user_id=6380

Actually, the patch is #414750.

(Now you can search by patch/bug ID in the SF search box! 
Hurray!)

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

Comment By: Michael Hudson (mwh)
Date: 2001-04-08 13:38

Message:
Logged In: YES 
user_id=6656

Ooh, another one:

>>> dir(b=1,**{'b':1})
Segmentation fault (core dumped)

I'll update #414743 presently.

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

Comment By: Michael Hudson (mwh)
Date: 2001-04-08 13:25

Message:
Logged In: YES 
user_id=6656

Eek!

>>> None(*None)
Segmentation fault (core dumped)

This is Ping's fault.  In ext_do_call the code that tries to
work out the function name assumes that func is a
PyFunctionObject, where in fact it can be anything at all,
because this is called before the check to see whether we
really have a callable!  Oops.

Anyway, look at patch #414743 for my attempted fix.

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

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


From noreply@sourceforge.net  Tue Apr 10 21:05:11 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 10 Apr 2001 13:05:11 -0700
Subject: [Python-bugs-list] [ python-Bugs-414228 ] Wrong PYTHONPATH in Makefile
Message-ID: <E14n4Nz-0007es-00@usw-sf-web1.sourceforge.net>

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

Category: Build
>Group: Irreproducible
Status: Open
>Priority: 2
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Wrong PYTHONPATH in Makefile

Initial Comment:
The build process stopped with error in target 
sharemods

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
*** Error code 1
make: Fatal error: Command failed for target 
`sharedmods'

This is cured with changing the Makefile (inserting 
./Lib)

# Build the shared modules
sharedmods: $(PYTHON)
	PYTHONPATH=./Lib ./$(PYTHON) 
$(srcdir)/setup.py build


Python: Python-2.1b2a
System: SunOS 5.7 Generic sun4u sparc SUNW,Ultra-60




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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 13:05

Message:
Logged In: YES 
user_id=6380

Have you set PYTHONHOME in the environment?  That could
cause this.

Lowering the priority since, as Neil says, this should not
be required.

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

Comment By: Neil Schemenauer (nascheme)
Date: 2001-04-10 09:15

Message:
Logged In: YES 
user_id=35752

Setting PYTHONPATH should not be required.  Modules/getpath
must be getting confused.  I have no idea why.  The output
from

  ./python -c "import sys; print sys.path"

might be helpful.

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

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


From noreply@sourceforge.net  Tue Apr 10 21:08:47 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 10 Apr 2001 13:08:47 -0700
Subject: [Python-bugs-list] [ python-Bugs-413980 ] core dump with regrtest.py on SGI
Message-ID: <E14n4RT-0007jV-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Open
>Priority: 2
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: core dump with regrtest.py on SGI

Initial Comment:
the 'make test' part of the installation on SGI (IRIX
6.5, 64 bits) ends with
the following output:

running build_scripts
not copying
/tmp_mnt/home/ibiology1/laurent/download/Python-2.1b2a/Tools/scripts/pydoc
(up-to-date)
        find ./Lib -name '*.py[co]' -print | xargs rm
-f
        PYTHONPATH= ./python -tt ./Lib/test/regrtest.py
-l
sh[4]: 1754889 Bus error(coredump)
        PYTHONPATH= ./python -tt ./Lib/test/regrtest.py
-l
sh: 1756018 Bus error(coredump)
*** Error code 138




Laurent

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 13:08

Message:
Logged In: YES 
user_id=6380

Lowering the priority -- as Tim said, it's likely an
optimizer bug anyway, so I see no reason (for us :-) to lose
much sleep over it.

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

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

Message:
Logged In: YES 
user_id=31435

The first thing to try on an SGI box is to recompile Python 
with optimization turned off, and see whether that makes 
the problem go away (historically, the bulk of "Python 
problems" on SGI turn out to be compiler optimization bugs).

So try that, and see whether the problem goes away.


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

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


From noreply@sourceforge.net  Tue Apr 10 21:09:18 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 10 Apr 2001 13:09:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-232460 ] SSL Support (Apparently) Broken on Solaris
Message-ID: <E14n4Ry-0007kD-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: 3
Submitted By: David M. Beazley (beazley)
Assigned to: Nobody/Anonymous (nobody)
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: Guido van Rossum (gvanrossum)
Date: 2001-04-10 11:55

Message:
Logged In: YES 
user_id=6380

So, David, you still interested in this?

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

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 Apr 10 21:09:37 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 10 Apr 2001 13:09:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-411612 ] cgi.py sometimes ignores QUERY_STRING
Message-ID: <E14n4SH-0007kW-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: 3
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: Guido van Rossum (gvanrossum)
Date: 2001-04-10 08:30

Message:
Logged In: YES 
user_id=6380

The idea is right, but since nobody volunteered a working
patch, this won't make it into 2.1.  Sorry.  Try again after
2.1!

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

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 Apr 10 21:14:57 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 10 Apr 2001 13:14:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-409355 ] Meta-class inheritance problem
Message-ID: <E14n4XR-0007pC-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: 3
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-04-10 13:14

Message:
Logged In: YES 
user_id=6380

Sorry, I'm at a loss with this.

What does isinstance(self, MyPurePythonClass) return? 
(Should be 1)

Lowering the priority -- unless we get some light quickly,
this won't make it into 2.1.

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

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  Tue Apr 10 21:33:29 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 10 Apr 2001 13:33:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-219486 ] fcntl.lockf() is broken
Message-ID: <E14n4pN-0000rO-00@usw-sf-web2.sourceforge.net>

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

Category: Extension Modules
>Group: Not a Bug
>Status: Closed
Priority: 5
Submitted By: Gregor Hoffleit (flight)
Assigned to: Guido van Rossum (gvanrossum)
Summary: fcntl.lockf() is broken

Initial Comment:
Another observation by James Troup <troup@debian.org>: fcntl.lockf()
seems to be severly `broken': it's acting like flock, not like lockf, 
and the code seems to be a copy/paste of flock.
(registered in the Debian Bug Tracking System as bug #74777,
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=74777).

James includes a first start at filling in a correct lockf function.
Looks like it needs some more work, therefore I don't submit it as
patch. The patch is against 1.5.2, though there seem to be no changes in 2.0.

These are James' words:


fcntl.lockf() doesn't work as expected.  

        fcntl.lockf(fd, FCNTL.F_TLOCK);

will block.. looking at the source is exteremly confusing.
fcntl.lockf() appears to want flock() style arguments?!  It almost
looks like someone cut'n'wasted from the fcntl_flock() function just
above...

Anyway, here is a patch which is IMO the Right Thing,
i.e. fcnt.lockf() acting like libc lockf() and like it's documented to
do...

--- python-1.5.2/Modules/fcntlmodule.c.orig     Sat Oct 14 15:46:40 2000
+++ python-1.5.2/Modules/fcntlmodule.c  Sat Oct 14 18:31:44 2000
@@ -233,30 +233,12 @@
 {
        int fd, code, ret, whence = 0;
        PyObject *lenobj = NULL, *startobj = NULL;
+       struct flock l;
 
        if (!PyArg_ParseTuple(args, "ii|OOi", &fd, &code,
                              &lenobj, &startobj, &whence))
            return NULL;
 
-#ifndef LOCK_SH
-#define LOCK_SH                1       /* shared lock */
-#define LOCK_EX                2       /* exclusive lock */
-#define LOCK_NB                4       /* don't block when locking */
-#define LOCK_UN                8       /* unlock */
-#endif
-       {
-               struct flock l;
-               if (code == LOCK_UN)
-                       l.l_type = F_UNLCK;
-               else if (code & LOCK_SH)
-                       l.l_type = F_RDLCK;
-               else if (code & LOCK_EX)
-                       l.l_type = F_WRLCK;
-               else {
-                       PyErr_SetString(PyExc_ValueError,
-                                       "unrecognized flock argument");
-                       return NULL;
-               }
                l.l_start = l.l_len = 0;
                if (startobj != NULL) {
 #if !defined(HAVE_LARGEFILE_SUPPORT)
@@ -281,10 +263,48 @@
                                return NULL;
                }
                l.l_whence = whence;
+       switch (code)
+         {
+         case F_TEST:
+           /* Test the lock: return 0 if FD is unlocked or locked by this process;
+              return -1, set errno to EACCES, if another process holds the lock.  */
+           if (fcntl (fd, F_GETLK, &l) < 0) {
+             fprintf(stderr, "andrea: 1");
+             PyErr_SetFromErrno(PyExc_IOError);
+             return NULL;
+           }
+           if (l.l_type == F_UNLCK || l.l_pid == getpid ()) {
+             fprintf(stderr, "andrea: 2");
+             Py_INCREF(Py_None);
+             return Py_None;
+           }
+           fprintf(stderr, "andrea: 3");
+           errno = EACCES;
+           PyErr_SetFromErrno(PyExc_IOError);
+           return NULL;
+
+         case F_ULOCK:
+           l.l_type = F_UNLCK;
+           code = F_SETLK;
+           break;
+         case F_LOCK:
+           l.l_type = F_WRLCK;
+           code = F_SETLKW;
+           break;
+         case F_TLOCK:
+           l.l_type = F_WRLCK;
+           code = F_SETLK;
+           break;
+           
+         default:
+           PyErr_SetString(PyExc_ValueError,
+                           "unrecognized flock argument");
+           return NULL;
+         }
                Py_BEGIN_ALLOW_THREADS
-               ret = fcntl(fd, (code & LOCK_NB) ? F_SETLK : F_SETLKW, &l);
+         ret = fcntl(fd, code, &l);
                Py_END_ALLOW_THREADS
-       }
+
        if (ret < 0) {
                PyErr_SetFromErrno(PyExc_IOError);
                return NULL;



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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 13:33

Message:
Logged In: YES 
user_id=6380

I've looked into this, and I finally have an idea what's the
matter here.

The similarity with flock is intentional; the lockf and
flock calls are an abstraction level away from the fcntl
locking call.  By using the same arguments in both cases we
hoped to make things easier for the Python user.

We may not have succeeded there, but I prefer to document
the status quo over "fixing" the interface and breaking code
that uses it.

Therefore, I'm rejecting the patch.  The documentation has
been updated, see the working docs:

http://python.sourceforge.net/devel-docs/lib/module-fcntl.html


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-01-18 19:37

Message:
I apologize. I should've looked into this earlier.  Now I won't have time to look at it before releasing 2.1a1.  I promise I'll come back to it later.

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

Comment By: A.M. Kuchling (akuchling)
Date: 2000-12-19 17:19

Message:
Note that the docs say that lockf "is a wrapper around the \constant{FCNTL.F_SETLK} and
\constant{FCNTL.F_SETLKW} \function{fcntl()} calls."  Stevens's 
"Advanced Programming in the Unix Env." concurs, on page 367: "The System V lockf() is just an interface to fcntl()."

However, none of us are serious Unix weenies.   Unfortunately, the documented Python lockf() provides features above the libc lockf(), so
using the system lockf() seems impossible unless we break backwards compatibility.   Unfortunately none of us are serious Unix weenies, so writing a lockf() emulation that's completely correct everywhere might be very difficult.

Troup's patch attempts to fix the emulation; I haven't looked at it closely.  I'd suggest breaking backwards compatibility; if that's out, 
we should take a close look at the patch.  


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

Comment By: Sjoerd Mullender (sjoerd)
Date: 2000-11-24 01:32

Message:
Yeah, I looked at it.  In 1996.  I don't think I looked at flock since then.
Anyway, it compiles on my system (IRIX 6.5.2), and I don't think I will have time in the near future to look any further into this.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-26 14:29

Message:
Sjoerd, you once looked at this code. Can you comment on this? If you don't have time, please assign back to me.

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

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


From noreply@sourceforge.net  Tue Apr 10 21:39:49 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 10 Apr 2001 13:39:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-233050 ] Python-2.1a2 tests failed on NetBSD 1.5 i386
Message-ID: <E14n4vV-0000vf-00@usw-sf-web2.sourceforge.net>

Bugs item #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: Closed
Priority: 3
Submitted By: Anders Andersen (aandersen)
Assigned to: Guido van Rossum (gvanrossum)
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 (gvanrossum)
Date: 2001-04-10 13:39

Message:
Logged In: YES 
user_id=6380

I just fixed the test_largefile failure -- on some (64bit?)
systems f.seek() with a value > 2**32 raises IOError, not
OverflowError.

The failure in test_largefile caused it to leave behind a
file @test which prevented test_mailbox from doing
mkdir('@test'). I also fixed this today.

I can't help you with the fork1 and ucn failures or with the
threading; AFAIC, pth is not stable enough to worry about. 

Hence, I'm closing the bug report.  If you find the causes
for the problems and can provide patches relative to current
CVS, please open a new patch entry.

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

Comment By: Guido van Rossum (gvanrossum)
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 (aandersen)
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 noreply@sourceforge.net  Tue Apr 10 22:14:13 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 10 Apr 2001 14:14:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-412682 ] Cannot play solitaire - buggy Canvas.py?
Message-ID: <E14n5Sn-0000Oc-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: Tkinter
Group: None
>Status: Closed
>Priority: 5
Submitted By: Alastair Burt (alburt)
Assigned to: Guido van Rossum (gvanrossum)
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

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 14:14

Message:
Logged In: YES 
user_id=6380

You're right!  Thanks for persisting.  I've fixed this now.

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

Comment By: Alastair Burt (alburt)
Date: 2001-04-10 09:02

Message:
Logged In: YES 
user_id=45573

The demo might be the only piece of software in the world
that tickles this bug but I think it is not the real
culprit. There is a mismatch between the interface offered
by lib-tk/Tkinter.py and that used by lib-tk/Canvas.py which
is the result of name changes related to "tag_lower" and
"tag_raise".

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 08:50

Message:
Logged In: YES 
user_id=6380

I bet that demo is broken, not the Canvas module, but I have
no time to fix this before the 2.1 release.

Use PySol if you want to play. :-)

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

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


From noreply@sourceforge.net  Tue Apr 10 23:25:45 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 10 Apr 2001 15:25:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-232597 ] _curses build broken on Compaq Tru64 Unix
Message-ID: <E14n6a1-0003Fe-00@usw-sf-web3.sourceforge.net>

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

Category: Build
Group: Platform-specific
Status: Closed
Priority: 2
Submitted By: Mark Favas (mfavas)
Assigned to: Guido van Rossum (gvanrossum)
Summary: _curses build broken on Compaq Tru64 Unix

Initial Comment:
2.1a2 from CVS of Feb 16 produces the following compiler warnings on Tru64
Unix (uname -a: OSF1 gonzo.per.dem.csiro.au V4.0 1229 alpha, Compaq C compiler, version: Compaq C V6.3-129 (dtk), Compiler Driver V6.3-126 (dtk)):

cc -c -O -Olimit 1500 -I. -I./Include -DHAVE_CONFIG_H  -o Python/ceval.o Python/ceval.c
cc: Info: Python/ceval.c, line 327: Trailing comma found in enumerator list. (trailcomma)
};


cc -O -Olimit 1500 -I. -I./Include -IInclude/ -I/usr/local/include -c Modules/_cursesmodule.c -o build/temp.osf1-V4.0-alpha-2.1/_cursesmodule.o
cc: Warning: Modules/_cursesmodule.c, line 632: In this statement, "derwin(...)" of type "int", is being converted to "pointer to struct _win_st". (cvtdiftypes)
  win = derwin(self->win,nlines,ncols,begin_y,begin_x);

cc: Warning: Modules/_cursesmodule.c, line 1287: In this statement, "subpad(...)" of type "int", is being converted to "pointer to struct _win_st". (cvtdiftypes)
    win = subpad(self->win, nlines, ncols, begin_y, begin_x);

cc: Warning: Modules/_cursesmodule.c, line 1517: In this statement, "termname(...)" of type "int", is being converted to "pointer to const char". (cvtdiftypes)
NoArgReturnStringFunction(termname)

cc: Warning: Modules/_cursesmodule.c, line 1686: In this statement, "getwin(...)" of type "int", is being converted to "pointer to struct _win_st". (cvtdiftypes)
  win = getwin(PyFile_AsFile(temp));

cc: Warning: Modules/_cursesmodule.c, line 1954: In this statement, "keyname(...)" of type "int", is being converted to "pointer to const char". (cvtdiftypes)
  knp = keyname(ch);

cc: Warning: Modules/_cursesmodule.c, line 2245: In this statement, "tigetstr(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
        capname = tigetstr( capname );

cc: Warning: Modules/_cursesmodule.c, line 2270: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt);

cc: Warning: Modules/_cursesmodule.c, line 2273: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1);

cc: Warning: Modules/_cursesmodule.c, line 2276: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1,i2);

cc: Warning: Modules/_cursesmodule.c, line 2279: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1,i2,i3);

cc: Warning: Modules/_cursesmodule.c, line 2282: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1,i2,i3,i4);

cc: Warning: Modules/_cursesmodule.c, line 2285: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1,i2,i3,i4,i5);

cc: Warning: Modules/_cursesmodule.c, line 2288: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1,i2,i3,i4,i5,i6);

cc: Warning: Modules/_cursesmodule.c, line 2291: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1,i2,i3,i4,i5,i6,i7);

cc: Warning: Modules/_cursesmodule.c, line 2294: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1,i2,i3,i4,i5,i6,i7,i8);

cc: Warning: Modules/_cursesmodule.c, line 2297: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1,i2,i3,i4,i5,i6,i7,i8,i9);

cc: Warning: Modules/_cursesmodule.c, line 310: The scalar variable "arg1" is fetched but not initialized.  And there may be other such fetches of this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getparyx, int, "(ii)")

cc: Warning: Modules/_cursesmodule.c, line 310: The scalar variable "arg2" is fetched but not initialized.  And there may be other such fetches of this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getparyx, int, "(ii)")

cc: Warning: Modules/_cursesmodule.c, line 309: The scalar variable "arg1" is fetched but not initialized.  And there may be other such fetches of this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getmaxyx, int, "(ii)")

cc: Warning: Modules/_cursesmodule.c, line 309: The scalar variable "arg2" is fetched but not initialized.  And there may be other such fetches of this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getmaxyx, int, "(ii)")

cc: Warning: Modules/_cursesmodule.c, line 308: The scalar variable "arg1" is fetched but not initialized.  And there may be other such fetches of this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getbegyx, int, "(ii)")

cc: Warning: Modules/_cursesmodule.c, line 308: The scalar variable "arg2" is fetched but not initialized.  And there may be other such fetches of this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getbegyx, int, "(ii)")






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

Comment By: Michael Hudson (mwh)
Date: 2001-04-10 15:25

Message:
Logged In: YES 
user_id=6656

Glad to be of help.

It's not going to break any other platform as all I did was
move a block that was inside an "#ifdef __osf__" about,
though that's not how diff(1) saw it.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 12:54

Message:
Logged In: YES 
user_id=6380

Thanks, Michael.  That works.  I'm checking this in, since
it doesn't seem to break anything on Linux.

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

Comment By: Michael Hudson (mwh)
Date: 2001-04-10 12:34

Message:
Logged In: YES 
user_id=6656

try this (aka it's not much use #defining
_XOPEN_SOURCE_EXTENDED *after* including <curses.h>!!)

Index: _cursesmodule.c
===================================================================
RCS file:
/cvsroot/python/python/dist/src/Modules/_cursesmodule.c,v
retrieving revision 2.50
diff -c -r2.50 _cursesmodule.c
*** _cursesmodule.c     2001/01/29 20:47:59     2.50
--- _cursesmodule.c     2001/04/10 19:31:41
***************
*** 100,112 ****
  /* Includes */
  
  #include "Python.h"
- #define CURSES_MODULE
- #include "py_curses.h"
  
  #ifdef __osf__
  #define _XOPEN_SOURCE_EXTENDED  /* Define macro for OSF/1 */
  #define STRICT_SYSV_CURSES      /* Don't use ncurses
extensions */
  #endif
  
  /*  These prototypes are in <term.h>, but including this
header 
      #defines many common symbols (such as "lines") which
breaks the 
--- 100,113 ----
  /* Includes */
  
  #include "Python.h"
  
  #ifdef __osf__
  #define _XOPEN_SOURCE_EXTENDED  /* Define macro for OSF/1 */
  #define STRICT_SYSV_CURSES      /* Don't use ncurses
extensions */
  #endif
+ 
+ #define CURSES_MODULE
+ #include "py_curses.h"
  
  /*  These prototypes are in <term.h>, but including this
header 
      #defines many common symbols (such as "lines") which
breaks the 

not sure this is correct fix, but i think this is the
problem.  no time for more investigation just yet.


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 12:10

Message:
Logged In: YES 
user_id=6380

Changing the subject -- it's only about _curses now.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 12:09

Message:
Logged In: YES 
user_id=6380

Having just discovered the Tru64 test machine at the SourceForge Compile Farm, I can confirm that the curses 
module is not built correctly on that platform.

My suspicion is that there's a curses.h header for an ancient version of curses, so that the setup script is mistaken 
in even trying to build the _curses module.  I don't know how to prevent it from doing so though...  Maybe a check 
for a certain symbol in the curses.h header could be added to the setup.py script???

Andrew, I'm not reassigning this back to you, because you just unassigned it; but you really do seem to have the 
knowledge to move this forward...

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

Comment By: A.M. Kuchling (akuchling)
Date: 2001-04-10 10:58

Message:
Logged In: YES 
user_id=11375

Unassigning, since I have no way of debugging this problem.

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

Comment By: A.M. Kuchling (akuchling)
Date: 2001-02-27 11:42

Message:
Logged In: YES 
user_id=11375

The get*yx() calls are always defined as macros.  This does
look like the correct curses.h header isn't  being picked
up.  Does Tru64's curses.h header require some magical
#define in order to work?

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-02-19 13:55

Message:
Looks like a different header may be needed to pick up the prototypes for many of these.  Assigned to the curses module guy.

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

Comment By: Thomas Wouters (twouters)
Date: 2001-02-16 04:14

Message:
The first warning is my mistake. I thought I fixed that in a more recent version of my continue-inside-try patch, but apparently I didn't. Fixed in revision 2.230 of Python/ceval.c

The warnings in Modules/_cursusmodule.c are most likely caused by undefined functions, though why you don't see an error for those beats me. (undefined functions default to int-returning functions, so that's probably why you see those warnings.) 

The *other* warnings look damned legit, though, and the only reason they aren't is because getmaxyx and co. are (on the BSDI and Linux boxes I have acces to) defined as being macro calls, and in fact they *have* to be macro calls (or non-standard C calls) or they can't work. I'm not a curses expert, but I think an initialization is in place here (or just rewriting the silly macros so they make *sense* :-)


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

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


From noreply@sourceforge.net  Wed Apr 11 08:33:54 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 11 Apr 2001 00:33:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-405999 ] getopt: extra args behavior wrong
Message-ID: <E14nF8U-0000g2-00@usw-sf-web3.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: Closed
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: Moshe Zadka (moshez)
Date: 2001-04-11 00:33

Message:
Logged In: YES 
user_id=11645

Checked in as libgetopt.tex v 1.17

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

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  Wed Apr 11 08:45:52 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 11 Apr 2001 00:45:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-413135 ] urllib2 fails with proxy requiring auth
Message-ID: <E14nFK4-0001EL-00@usw-sf-web1.sourceforge.net>

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

Category: Python Library
Group: None
>Status: Closed
Priority: 5
Submitted By: Paul Moore (pmoore)
Assigned to: Moshe Zadka (moshez)
Summary: urllib2 fails with proxy requiring auth

Initial Comment:
The following program:

import urllib2

proxy_info = {
    'user' : 'my_name', 'pass' : 'my_pass',
    'host' : "my-proxy", 'port' : 80
}
 
# build a new opener that uses a proxy requiring
# authorization
proxy_support = urllib2.ProxyHandler(
    {"http" :
     "http://%(user)s:%(pass)s@%(host)s:%(port)d"
     % proxy_info})
opener = urllib2.build_opener(proxy_support, 
urllib2.HTTPHandler)
 
# install it
urllib2.install_opener(opener)
 
f = urllib2.urlopen('http://www.python.org/')
print f.headers
print f.read()


fails with the following error on Python 2.1b2 (on 
Windows)

C:\Data>python21 proxy_auth.py
Traceback (most recent call last):
  File "proxy_auth.py", line 18, in ?
    f = urllib2.urlopen('http://www.python.org/')
  File "c:\applications\python21\lib\urllib2.py", line 
135, in urlopen
    return _opener.open(url, data)
  File "c:\applications\python21\lib\urllib2.py", line 
318, in open
    '_open', req)
  File "c:\applications\python21\lib\urllib2.py", line 
297, in _call_chain
    result = func(*args)
  File "c:\applications\python21\lib\urllib2.py", line 
823, in http_open
    return self.do_open(httplib.HTTP, req)
  File "c:\applications\python21\lib\urllib2.py", line 
801, in do_open
    raise URLError(err)
urllib2.URLError: <urlopen error host not found>

A similar error occurred in beta 1, but this was 
reported as bug 406683. The fix is in beta 2. I 
applied the fix manually in beta 1, and it worked, so 
I can only assume that something else changed in the 
transition from beta 1 to beta 2, which broke this 
again.


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

>Comment By: Moshe Zadka (moshez)
Date: 2001-04-11 00:45

Message:
Logged In: YES 
user_id=11645

You're right!
I've fixed this in urllib2.py v 1.12

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

Comment By: Paul Moore (pmoore)
Date: 2001-04-10 02:46

Message:
Logged In: YES 
user_id=113328

I found the problem. In urllib2.py, class 
AbstractHTTPHandler, method do_open, the first line is now 

        host = urlparse.urlparse(req.get_full_url())[1]

It used to be

        host = req.get_host()

With the old version, the code works (with my proxy). With 
the new version it doesn't, as it passes the destination 
host, rather than the proxy name (and so loses the proxy 
info totally).

Paul.


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

Comment By: Paul Moore (pmoore)
Date: 2001-04-10 02:45

Message:
Logged In: YES 
user_id=113328

I found the problem. In urllib2.py, class 
AbstractHTTPHandler, method do_open, the first line is now 

        host = urlparse.urlparse(req.get_full_url())[1]

It used to be

        host = req.get_host()

With the old version, the code works (with my proxy). With 
the new version it doesn't, as it passes the destination 
host, rather than the proxy name (and so loses the proxy 
info totally).

Paul.


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

Comment By: Moshe Zadka (moshez)
Date: 2001-04-09 07:11

Message:
Logged In: YES 
user_id=11645

I've just tested with my installation of Python 2.1b2 and it
works. So I cannot reproduce the problem, and I need more
information from you: can you insert prints in the correct
places (e.g. do_open) to see what host urllib2 *thinks* it
is trying to access?
Thanks.

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

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


From noreply@sourceforge.net  Wed Apr 11 15:04:20 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 11 Apr 2001 07:04:20 -0700
Subject: [Python-bugs-list] [ python-Bugs-414743 ] Access violation in call to map
Message-ID: <E14nLEK-0006t5-00@usw-sf-web1.sourceforge.net>

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

Category: Python Interpreter Core
Group: None
>Status: Closed
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Jeremy Hylton (jhylton)
Summary: Access violation in call to map

Initial Comment:
This call:

  map(None, *None)

results in an access violation (read of NULL pointer) 
under Python 2.1b2 (Win32 binaries downloaded from 
Sourceforge).  OS in Win2000.


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 13:00

Message:
Logged In: YES 
user_id=6380

Assigned to Jeremy.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 12:58

Message:
Logged In: YES 
user_id=6380

Actually, the patch is #414750.

(Now you can search by patch/bug ID in the SF search box! 
Hurray!)

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

Comment By: Michael Hudson (mwh)
Date: 2001-04-08 13:38

Message:
Logged In: YES 
user_id=6656

Ooh, another one:

>>> dir(b=1,**{'b':1})
Segmentation fault (core dumped)

I'll update #414743 presently.

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

Comment By: Michael Hudson (mwh)
Date: 2001-04-08 13:25

Message:
Logged In: YES 
user_id=6656

Eek!

>>> None(*None)
Segmentation fault (core dumped)

This is Ping's fault.  In ext_do_call the code that tries to
work out the function name assumes that func is a
PyFunctionObject, where in fact it can be anything at all,
because this is called before the check to see whether we
really have a callable!  Oops.

Anyway, look at patch #414743 for my attempted fix.

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

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


From noreply@sourceforge.net  Wed Apr 11 15:07:06 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 11 Apr 2001 07:07:06 -0700
Subject: [Python-bugs-list] [ python-Bugs-413320 ] sys.argv should always be a sequence
Message-ID: <E14nLH0-0006xB-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Open
>Priority: 2
Submitted By: Stephen McInerney (smcinerney)
Assigned to: Jeremy Hylton (jhylton)
Summary: sys.argv should always be a sequence

Initial Comment:
Hi,

It seems that sys.argv is not a sequence if there are
no args passed. Hence references to len() or
non-existent element sys.argv[1] cause a TypeError
which we have to kludge around with a try...except
TypeError. sys.argv should always be a sequence.

Python 1.6 (#4, Sep 13 2000, 17:24:07)  [GCC
egcs-2.91.66 19990314 (egcs-1.1.2 release)] on sunos5
(Solaris 8)

Best regards,
Stephen

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

Comment By: Jeremy Hylton (jhylton)
Date: 2001-04-04 11:04

Message:
Logged In: YES 
user_id=31392

Can you provide an example of how you invoke Python with no
args and what value sys.argv[] has?  I can't reproduce.


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

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


From noreply@sourceforge.net  Wed Apr 11 15:19:28 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 11 Apr 2001 07:19:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-410993 ] linuxaudiodev fails during "make test".
Message-ID: <E14nLSy-0005Cc-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: 6
Submitted By: Sean Reifschneider (jafo)
>Assigned to: Guido van Rossum (gvanrossum)
>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

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

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-04-11 07:19

Message:
Logged In: YES 
user_id=31392

I think we should report this failure as "test skipped."  I
think it
would be essentially correct: The test was skipped because
the 
device was in use.  It's not a crash.

Not sure how this test is affected by the recent changes to
the module to handle EAGAIN.
 
Sean or Guido-- can you try it with the updated module?  My
Linux audio config is screwed up.


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

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


From noreply@sourceforge.net  Wed Apr 11 16:49:36 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 11 Apr 2001 08:49:36 -0700
Subject: [Python-bugs-list] [ python-Bugs-412230 ] mailbox.BabylMailbox, missing headers
Message-ID: <E14nMsC-0000DT-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: Barry Warsaw (bwarsaw)
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.

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

>Comment By: Barry Warsaw (bwarsaw)
Date: 2001-04-11 08:49

Message:
Logged In: YES 
user_id=12800

Ignore this.

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

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


From noreply@sourceforge.net  Wed Apr 11 17:20:04 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 11 Apr 2001 09:20:04 -0700
Subject: [Python-bugs-list] [ python-Bugs-412230 ] mailbox.BabylMailbox, missing headers
Message-ID: <E14nNLg-0006rW-00@usw-sf-web3.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: Documentation
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Fred L. Drake, Jr. (fdrake)
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.

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

>Comment By: Barry Warsaw (bwarsaw)
Date: 2001-04-11 09:20

Message:
Logged In: YES 
user_id=12800

What is actually happening is that the mailbox module is
returning only the headers in the "visible" message, and in
your examples, the Message-ID is only in the original
headers.

Babyl's a weird format in that for each message, you have
all the original headers, which appear before the EOOH line,
and then a subset of those headers, called the "visible"
headers.  This is all the headers that a Babyl compliant
mail reader will show you.

I think it's fine for mailbox to return a mail message
containing only the visible headers.  You'll have to custom
parse a Babyl mailbox file to get at the original headers.

Attached is a suggested change to the mailbox module's
documentation to explain this.  I'm bumping this bug report
over to Fred because it's now a documentation issue, as I
don't believe the mailbox.py module should be changed.

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

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-04-11 08:49

Message:
Logged In: YES 
user_id=12800

Ignore this.

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

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


From noreply@sourceforge.net  Wed Apr 11 17:24:48 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 11 Apr 2001 09:24:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-217004 ] Tools/compiler does not create doc strings
Message-ID: <E14nNQG-0005um-00@usw-sf-web2.sourceforge.net>

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

Category: demos and tools
Group: None
>Status: Closed
Priority: 3
Submitted By: Neil Schemenauer (nascheme)
Assigned to: Jeremy Hylton (jhylton)
Summary: Tools/compiler does not create doc strings

Initial Comment:
Transformer.get_docstring() seems to be working fine but the __doc__ attributes are always None in the compiled code.

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

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-04-11 09:24

Message:
Logged In: YES 
user_id=31392

fix in rev 1.29 of pycodegen.py


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

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


From noreply@sourceforge.net  Wed Apr 11 17:36:46 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 11 Apr 2001 09:36:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-410993 ] linuxaudiodev fails during "make test".
Message-ID: <E14nNbq-000662-00@usw-sf-web2.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: 4
Submitted By: Sean Reifschneider (jafo)
Assigned to: Guido van Rossum (gvanrossum)
>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

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-11 09:36

Message:
Logged In: YES 
user_id=6380

I think you misread his comment. He wasn't mpg123 *during*
the test, he ran it before and after the test to verify that
in fact his audio was in good working order.

But, I do suggest to him to try the CVS version, which is
one (relevant) fix ahead of 2.1b2.

That version passes the test for me, but I don't hear a
thing, so I'm not sure what's going on...

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

Comment By: Jeremy Hylton (jhylton)
Date: 2001-04-11 07:19

Message:
Logged In: YES 
user_id=31392

I think we should report this failure as "test skipped."  I
think it
would be essentially correct: The test was skipped because
the 
device was in use.  It's not a crash.

Not sure how this test is affected by the recent changes to
the module to handle EAGAIN.
 
Sean or Guido-- can you try it with the updated module?  My
Linux audio config is screwed up.


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

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


From noreply@sourceforge.net  Wed Apr 11 17:37:54 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 11 Apr 2001 09:37:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-409587 ] Tools/compiler loses linenos
Message-ID: <E14nNcw-000767-00@usw-sf-web3.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: Closed
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


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

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-04-11 09:37

Message:
Logged In: YES 
user_id=31392

Fix in rev 1.30 of pycodegen.py and rev 1.21 of
transformer.py


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

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


From noreply@sourceforge.net  Wed Apr 11 18:13:09 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 11 Apr 2001 10:13:09 -0700
Subject: [Python-bugs-list] [ python-Bugs-411881 ] Use of "except:" in modules
Message-ID: <E14nOB3-0007Wg-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: 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: Walter Dörwald (doerwalter)
Date: 2001-04-11 10:13

Message:
Logged In: YES 
user_id=89016

> Can you identify modules where catching everything 
> is incorrect

If "everything" includes KeyboardInterrupt, it's
definitely incorrect, even in inspect.py's simple

    try:
        raise 'catch me'
    except:
        return sys.exc_traceback.tb_frame.f_back

which should probably be:

    try:
        raise 'catch me'
    except KeyboardInterrupt:
        raise
    except:
        return sys.exc_traceback.tb_frame.f_back


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 08:45

Message:
Logged In: YES 
user_id=6380

I've applied the three patches you supplied.

I agree with Martin that to do this right we'll have to
tread carefully. But please go on!

(No way more of this will find its way into 2.1 though.)

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

Comment By: Itamar Shtull-Trauring (itamar)
Date: 2001-03-30 02:54

Message:
Logged In: YES 
user_id=32065

inspect.py should be removed from this list, the use is
correct.

In general, I just submitted this bug so that when people
are editing a module they'll notice these things, since in
some cases only someone who knows the code very well can
know if the "expect:" is needed or not.

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

Comment By: Martin v. Löwis (loewis)
Date: 2001-03-29 22:59

Message:
Logged In: YES 
user_id=21627

Can you identify modules where catching everything is
incorrect, and propose changes to correct them. This should
be done one-by-one, with careful analysis in each case, and
may take well months or years to complete.

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

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


From noreply@sourceforge.net  Wed Apr 11 18:15:04 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 11 Apr 2001 10:15:04 -0700
Subject: [Python-bugs-list] [ python-Bugs-411881 ] Use of "except:" in modules
Message-ID: <E14nOCu-0007Yr-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: 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: Walter Dörwald (doerwalter)
Date: 2001-04-11 10:15

Message:
Logged In: YES 
user_id=89016

> Can you identify modules where catching everything 
> is incorrect

If "everything" includes KeyboardInterrupt, it's
definitely incorrect, even in inspect.py's simple

    try:
        raise 'catch me'
    except:
        return sys.exc_traceback.tb_frame.f_back

which should probably be:

    try:
        raise 'catch me'
    except KeyboardInterrupt:
        raise
    except:
        return sys.exc_traceback.tb_frame.f_back


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

Comment By: Walter Dörwald (doerwalter)
Date: 2001-04-11 10:13

Message:
Logged In: YES 
user_id=89016

> Can you identify modules where catching everything 
> is incorrect

If "everything" includes KeyboardInterrupt, it's
definitely incorrect, even in inspect.py's simple

    try:
        raise 'catch me'
    except:
        return sys.exc_traceback.tb_frame.f_back

which should probably be:

    try:
        raise 'catch me'
    except KeyboardInterrupt:
        raise
    except:
        return sys.exc_traceback.tb_frame.f_back


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 08:45

Message:
Logged In: YES 
user_id=6380

I've applied the three patches you supplied.

I agree with Martin that to do this right we'll have to
tread carefully. But please go on!

(No way more of this will find its way into 2.1 though.)

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

Comment By: Itamar Shtull-Trauring (itamar)
Date: 2001-03-30 02:54

Message:
Logged In: YES 
user_id=32065

inspect.py should be removed from this list, the use is
correct.

In general, I just submitted this bug so that when people
are editing a module they'll notice these things, since in
some cases only someone who knows the code very well can
know if the "expect:" is needed or not.

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

Comment By: Martin v. Löwis (loewis)
Date: 2001-03-29 22:59

Message:
Logged In: YES 
user_id=21627

Can you identify modules where catching everything is
incorrect, and propose changes to correct them. This should
be done one-by-one, with careful analysis in each case, and
may take well months or years to complete.

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

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


From noreply@sourceforge.net  Wed Apr 11 18:24:23 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 11 Apr 2001 10:24:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-411881 ] Use of "except:" in modules
Message-ID: <E14nOLv-0007gH-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: 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: Guido van Rossum (gvanrossum)
Date: 2001-04-11 10:24

Message:
Logged In: YES 
user_id=6380

Actually, inspect.py should use sys._getframe()!

And yes, KeyboardError is definitely one of the reasons why
this is such a bad idiom...

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

Comment By: Walter Dörwald (doerwalter)
Date: 2001-04-11 10:15

Message:
Logged In: YES 
user_id=89016

> Can you identify modules where catching everything 
> is incorrect

If "everything" includes KeyboardInterrupt, it's
definitely incorrect, even in inspect.py's simple

    try:
        raise 'catch me'
    except:
        return sys.exc_traceback.tb_frame.f_back

which should probably be:

    try:
        raise 'catch me'
    except KeyboardInterrupt:
        raise
    except:
        return sys.exc_traceback.tb_frame.f_back


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

Comment By: Walter Dörwald (doerwalter)
Date: 2001-04-11 10:13

Message:
Logged In: YES 
user_id=89016

> Can you identify modules where catching everything 
> is incorrect

If "everything" includes KeyboardInterrupt, it's
definitely incorrect, even in inspect.py's simple

    try:
        raise 'catch me'
    except:
        return sys.exc_traceback.tb_frame.f_back

which should probably be:

    try:
        raise 'catch me'
    except KeyboardInterrupt:
        raise
    except:
        return sys.exc_traceback.tb_frame.f_back


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 08:45

Message:
Logged In: YES 
user_id=6380

I've applied the three patches you supplied.

I agree with Martin that to do this right we'll have to
tread carefully. But please go on!

(No way more of this will find its way into 2.1 though.)

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

Comment By: Itamar Shtull-Trauring (itamar)
Date: 2001-03-30 02:54

Message:
Logged In: YES 
user_id=32065

inspect.py should be removed from this list, the use is
correct.

In general, I just submitted this bug so that when people
are editing a module they'll notice these things, since in
some cases only someone who knows the code very well can
know if the "expect:" is needed or not.

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

Comment By: Martin v. Löwis (loewis)
Date: 2001-03-29 22:59

Message:
Logged In: YES 
user_id=21627

Can you identify modules where catching everything is
incorrect, and propose changes to correct them. This should
be done one-by-one, with careful analysis in each case, and
may take well months or years to complete.

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

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


From noreply@sourceforge.net  Wed Apr 11 19:52:39 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 11 Apr 2001 11:52:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-415492 ] Compiler generates relative filenames
Message-ID: <E14nPjL-0003NM-00@usw-sf-web1.sourceforge.net>

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

Category: Parser/Compiler
Group: None
Status: Open
Priority: 5
Submitted By: Paul Prescod (prescod)
Assigned to: Jeremy Hylton (jhylton)
Summary: Compiler generates relative filenames

Initial Comment:
Make a file called "test.py"
----
import pack

print pack.func.func_code.co_filename
-----

Make a directory called "pack". Put a file in it 
called "__init__.py" with the contents:

def func(): pass

Now run test.py. It will compile a relative path into 
these modules. Now you can change to any directory on 
the system and run test.py and it will return the 
original relative path. The problem is that the 
relative path is compiled into the .pyc. It should be 
an absolute path.

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

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


From noreply@sourceforge.net  Wed Apr 11 21:05:33 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 11 Apr 2001 13:05:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-412230 ] mailbox.BabylMailbox, missing headers
Message-ID: <E14nQrt-0004bl-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: Documentation
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Barry Warsaw (bwarsaw)
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.

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

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

Message:
Logged In: YES 
user_id=3066

Documentation patch is accepted; please check in.

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

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-04-11 09:20

Message:
Logged In: YES 
user_id=12800

What is actually happening is that the mailbox module is
returning only the headers in the "visible" message, and in
your examples, the Message-ID is only in the original
headers.

Babyl's a weird format in that for each message, you have
all the original headers, which appear before the EOOH line,
and then a subset of those headers, called the "visible"
headers.  This is all the headers that a Babyl compliant
mail reader will show you.

I think it's fine for mailbox to return a mail message
containing only the visible headers.  You'll have to custom
parse a Babyl mailbox file to get at the original headers.

Attached is a suggested change to the mailbox module's
documentation to explain this.  I'm bumping this bug report
over to Fred because it's now a documentation issue, as I
don't believe the mailbox.py module should be changed.

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

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-04-11 08:49

Message:
Logged In: YES 
user_id=12800

Ignore this.

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

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


From noreply@sourceforge.net  Wed Apr 11 21:08:08 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 11 Apr 2001 13:08:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-231328 ] fcntl module functions should accept file module arguments.
Message-ID: <E14nQuO-0004fw-00@usw-sf-web1.sourceforge.net>

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

Category: Python Library
Group: Feature Request
Status: Open
Priority: 2
Submitted By: Eric S. Raymond (esr)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: fcntl module functions should accept file module arguments.

Initial Comment:
The functions in the standard library fcntl module require integer
(file descriptor) arguments.  They should accept arguments with a
fileno() method as well, in particular file objects.


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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-04-11 13:08

Message:
Logged In: YES 
user_id=3066

Assigned to me so it at least appears on someone's list.  Set resolution to "Later" since it's too late for Python 2.1, but it should be done for 2.2.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 11:53

Message:
Logged In: YES 
user_id=6380

This would be a simple patch. Anyone care to provide one?

(Too late for 2.1 though -- sorry.)


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

Comment By: A.M. Kuchling (akuchling)
Date: 2001-04-10 10:53

Message:
Logged In: YES 
user_id=11375

I've let this gather dust long enough; unassigning so
someone else can take responsibility for it.

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

Comment By: A.M. Kuchling (akuchling)
Date: 2001-04-10 10:53

Message:
Logged In: YES 
user_id=11375

I've let this gather dust long enough; unassigning so
someone else can take responsibility for it.

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

Comment By: Tim Peters (tim_one)
Date: 2001-02-08 19:02

Message:
Care to add mmap.mmap while you're at it?

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

Comment By: A.M. Kuchling (akuchling)
Date: 2001-02-08 09:24

Message:
Assigning to akuchling.

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

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


From noreply@sourceforge.net  Wed Apr 11 21:13:01 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 11 Apr 2001 13:13:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-412230 ] mailbox.BabylMailbox, missing headers
Message-ID: <E14nQz7-0004kV-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: Documentation
Group: None
>Status: Closed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Barry Warsaw (bwarsaw)
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.

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

>Comment By: Barry Warsaw (bwarsaw)
Date: 2001-04-11 13:13

Message:
Logged In: YES 
user_id=12800

Patch checked in for libmailbox.tex 1.18

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-04-11 13:05

Message:
Logged In: YES 
user_id=3066

Documentation patch is accepted; please check in.

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

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-04-11 09:20

Message:
Logged In: YES 
user_id=12800

What is actually happening is that the mailbox module is
returning only the headers in the "visible" message, and in
your examples, the Message-ID is only in the original
headers.

Babyl's a weird format in that for each message, you have
all the original headers, which appear before the EOOH line,
and then a subset of those headers, called the "visible"
headers.  This is all the headers that a Babyl compliant
mail reader will show you.

I think it's fine for mailbox to return a mail message
containing only the visible headers.  You'll have to custom
parse a Babyl mailbox file to get at the original headers.

Attached is a suggested change to the mailbox module's
documentation to explain this.  I'm bumping this bug report
over to Fred because it's now a documentation issue, as I
don't believe the mailbox.py module should be changed.

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

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-04-11 08:49

Message:
Logged In: YES 
user_id=12800

Ignore this.

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

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


From noreply@sourceforge.net  Wed Apr 11 21:20:26 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 11 Apr 2001 13:20:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-231249 ] cgi.py opens too many (temporary) files
Message-ID: <E14nR6I-0004rc-00@usw-sf-web1.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Richard van de Stadt (stadt)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: cgi.py opens too many (temporary) files

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

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

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

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-11 13:20

Message:
Logged In: YES 
user_id=6380

Here's a proposed patch.

Can anyone think of a reason why this should not be checked
in as part of 2.1?

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 11:54

Message:
Logged In: YES 
user_id=6380

I wish I'd heard about this sooner.

It does seem a problem and it does make sense to use StringIO unless there's a lot of data.

But we can't fix this in time for 2.1...


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

Comment By: A.M. Kuchling (akuchling)
Date: 2001-04-10 10:54

Message:
Logged In: YES 
user_id=11375

Unassigning so someone else can take a look at it.

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

Comment By: Kurt B. Kaiser (kbk)
Date: 2001-02-18 23:32

Message:
In the particular HTML form referenced it appears that a workaround might be to eliminate the enctype attribute in the <form> tag and take the application/x-www-form-urlencoded default since no files are being uploaded. 

When make_file creates the temporary files they are immediately unlinked. There is probably a brief period before the unlink is finalized during which the ls process might see a file; that would account for the output of ls | wc. It appears that the current cgi.py implementation leaves all the (hundreds of) files open until the cgi process releases the FieldStorage object or exits. 

My first thought was, if the filename recovered from the header is None have make_file create a StringIO object instead of a temp file. That way a temp file is only created when a file is uploaded. This is not inconsistent with the cgi.py docs.

Unfortunately, RFC2388 4.4 states that a filename is not required to be sent, so it looks like your solution based on the size of the data received is the correct one. Below 1K you could copy the temp file contents to a StringIO and assign it to self.file, then explicitly close the temp file via its descriptor. 

If only I understood the module better ::-(( and had a way of tunnel testing it I might have had the temerity to offer a patch. (I'm away for a couple of weeks starting tomorrow.)

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

Comment By: A.M. Kuchling (akuchling)
Date: 2001-02-18 14:08

Message:
Ah, I see; the traceback makes this much clearer.  When you're uploading a file, everything in the form is sent as 
a MIME document in the body; every field is accompanied by 
a boundary separator and Content-Disposition header.
In multipart mode, cgi.py copies each field into a temporary file.  

The first idea I had was to only use tempfiles for the actual upload field; unfortunately, that doesn't help because the upload field isn't special, and cgi.py has no way to know which it is ahead of time.

Possible second approach: measure the size of the resulting file; if it's less than some threshold (1K? 10K?), read its contents into memory and close the tempfile.  This means only the largest fields will require that a file descriptor be kept open.  I'll explore this more after beta1.




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

Comment By: Richard van de Stadt (stadt)
Date: 2001-02-17 18:37

Message:
I do *not* mean file upload fields. I stumbled upon this with a webform that
contains 141 'simple' input fields like the form you can see here (which 'only'
contains 31 of those input fields):

http://www.cyberchair.org/cgi-cyb/genAssignPageReviewerPapers.py

(use chair/chair to login)

When the maximum number of file descriptors used per process was increased
to 160 (by the sysadmins), the problem did not occur anymore, and the webform
could be processed.

This was the error message I got: 

Traceback (most recent call last):
  File "/usr/local/etc/httpd/DocumentRoot/ICML2001/cgi-bin/submitAssignRP.py", line 144, in main
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/cgi.py", line 504, in __init__
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/cgi.py", line 593, in read_multi
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/cgi.py", line 506, in __init__
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/cgi.py", line 603, in read_single
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/cgi.py", line 623, in read_lines
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/cgi.py", line 713, in make_file
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/tempfile.py", line 144, in TemporaryFile
OSError: [Errno 24] Too many open files: '/home/yara/brodley/icml2001/tmp/@26048.61'

I understand why you assume that it would concern *file* uploads, but this is
not the case. As I reported before, it turns out that for each 'simple' <input> field
a temporary file is used in to transfer the contents to the script that uses the
cgi.FieldStorage() method, even if no files are being uploaded. The problem is not
that too many files are open at the same time (which is 1 at most). It is the *amount*
of files that is causing the troubles. If the same temporary file would be used, this
problem would probably not have happened. 

My colleague Fred Gansevles wrote a possible solution, but mentioned that this
might introduce the need for protection against a 'symlink attack' (whatever
that may be). This solution(?) concentrates on the open file descriptor's problem,
while Fred suggests a redesign of FieldStorage() would probably be better.

import os, tempfile
AANTAL = 50

class TemporaryFile:
    def __init__(self):
        self.name = tempfile.mktemp("")
        open(self.name, 'w').close()
        self.offset = 0
    
    def seek(self, offset):
        self.offset = offset
    
    def read(self):
        fd = open(self.name, 'w+b', -1)
        fd.seek(self.offset)
        data = fd.read()
        self.offset = fd.tell()
        fd.close()
        return data
    
    def write(self, data):
        fd = open(self.name, 'w+b', -1)
        fd.seek(self.offset)
        fd.write(data)
        self.offset = fd.tell()
        fd.close()

    def __del__(self):
        os.unlink(self.name)

def add_fd(l, n) :
    map(lambda x,l=l: l.append(open('/dev/null')), range(n))

def add_tmp(l, n) :
    map(lambda x,l=l: l.append(TemporaryFile()), range(n))

def main ():
    import getopt, sys
    try:
        import resource
        soft, hard = resource.getrlimit (resource.RLIMIT_NOFILE)
        resource.setrlimit (resource.RLIMIT_NOFILE, (hard, hard))
    except ImportError:
        soft, hard = 64, 1024
    opts, args = getopt.getopt(sys.argv[1:], 'n:t')
    aantal = AANTAL
    tmp = add_fd
    for o, a in opts:
        if o == '-n':
            aantal = int(a)
        elif o == '-t':
            tmp = add_tmp
    print "aantal te gebruiken fd's:", aantal   #dutch; English: 'number of fds to be used'
    print 'tmp:', tmp.func_name
    tmp_files = []
    files=[]
    tmp(tmp_files, aantal)
    try:
        add_fd(files,hard)
    except IOError:
        pass
    print "aantal vrije gebruiken fd's:", len(files)  #enlish: 'number of free fds'

main()

Running the above code:

    python ulimit.py [-n number] [-t]
    default number = 50, while using 'real' fd-s for temporary files.
    When using the '-t' flag 'smart' temporary files are used.

    Output:

        $ python ulimit.py
        aantal te gebruiken fd's: 50
        tmp: add_fd
        aantal vrije gebruiken fd's: 970

        $ python ulimit.py -t
        aantal te gebruiken fd's: 50
        tmp: add_tmp
        aantal vrije gebruiken fd's: 1020

        $ python ulimit.py -n 1000
        aantal te gebruiken fd's: 1000
        tmp: add_fd
        aantal vrije gebruiken fd's: 20

        $ python ulimit.py -n 1000 -t
        aantal te gebruiken fd's: 1000
        tmp: add_tmp
        aantal vrije gebruiken fd's: 1020

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

Comment By: A.M. Kuchling (akuchling)
Date: 2001-02-16 21:41

Message:
I assume you mean 64 file upload fields, right?  
Can you provide a small test program that triggers the problem?

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

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


From noreply@sourceforge.net  Wed Apr 11 21:38:23 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 11 Apr 2001 13:38:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-415514 ] "%#x" % 0 caused assertion failure/abort
Message-ID: <E14nRNf-0000pl-00@usw-sf-web2.sourceforge.net>

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

Category: Python Interpreter Core
Group: None
Status: Open
Priority: 5
Submitted By: Fergal Mc Carthy (rahn_tamalin)
Assigned to: Nobody/Anonymous (nobody)
Summary: "%#x" % 0 caused assertion failure/abort

Initial Comment:
[I am unable to fix a similar problem report, even
 searching for the assertion failure. Please forgive
 me if I'm reporting a known problem.]

With python 2.0, I've found that if I tried to print a 
value of 0 with a % format of "%#x" that this 
generates the following aborts under both Unix (Tru64) 
and Windows (98SE).

"%#o" doesn't have problems.

[python 2.0 built for Digital UNIX (DEC OSF) V4.0d]
Python 2.0 (#1, Apr 11 2001, 20:48:08) [C] on osf1V4
Type "copyright", "credits" or "license" for more 
information.
>>> "%#x" % 0
Assertion failed: pbuf[1] == c, file stringobject.c, 
line 2981

[python 2.0 built for Tru64 UNIX (DEC OSF) V5.0]
Python 2.0 (#1, Apr 11 2001, 20:35:33) [C] on osf1V5
Type "copyright", "credits" or "license" for more 
information.
>>> "%#x" % 0
Assertion failed: pbuf[1] == c, file stringobject.c, 
line 2981

[python 2.0 built for Tru64 UNIX (DEC OSF) V5.1]
Python 2.0 (#2, Apr  8 2001, 20:54:56) [C] on osf1V5
Type "copyright", "credits" or "license" for more 
information.
>>> "%#x" % 0
Assertion failed: pbuf[1] == c, file stringobject.c, 
line 2981


[Windows 98 SE Illegal Operation Exception Details]
PYTHON caused an invalid page fault in
module PYTHON20.DLL at 0167:1e15a784.
Registers:
EAX=ffffffff CS=0167 EIP=1e15a784 EFLGS=00010207
EBX=00000000 SS=016f ESP=0063fb98 EBP=00000078
ECX=3ffffefe DS=016f ESI=0063fffe FS=4b17
EDX=00790f87 ES=016f EDI=0079138b GS=0000
Bytes at CS:EIP:
f3 a5 8b c8 83 e1 03 f3 a4 8b 44 24 18 8b 74 24 
Stack dump:
00761b6c 007747fc 00761b6c 00790ad0 00000000 0063fbfa 
ffffffff 00000064 00790f87 00790f70 ffffffff 00790ae7 
00000008 ffffffff ffffffff 00000000 

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

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


From noreply@sourceforge.net  Wed Apr 11 22:21:58 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 11 Apr 2001 14:21:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-415522 ] documentation: fnctl 8.12
Message-ID: <E14nS3q-0005qr-00@usw-sf-web1.sourceforge.net>

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

Category: Documentation
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: documentation: fnctl 8.12

Initial Comment:
The sample code does not work.  Call ti fcntl should
have second
argument as FCNTL.SETFL and third arg as FCNTL.NDELAY.

Corrected example:

import struct, fcntl, FCNTL

     file = open(...)
     rv = fcntl.fcntl(file.fileno(),
FCNTL.F_SETFL,FCNTL.O_NDELAY)

....rest of sample code



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

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


From noreply@sourceforge.net  Wed Apr 11 22:34:10 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 11 Apr 2001 14:34:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-415522 ] documentation: fnctl 8.12
Message-ID: <E14nSFe-000628-00@usw-sf-web1.sourceforge.net>

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

Category: Documentation
Group: None
>Status: Closed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: documentation: fnctl 8.12

Initial Comment:
The sample code does not work.  Call ti fcntl should
have second
argument as FCNTL.SETFL and third arg as FCNTL.NDELAY.

Corrected example:

import struct, fcntl, FCNTL

     file = open(...)
     rv = fcntl.fcntl(file.fileno(),
FCNTL.F_SETFL,FCNTL.O_NDELAY)

....rest of sample code



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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-04-11 14:34

Message:
Logged In: YES 
user_id=3066

Fixed in Doc/lib/libfcntl.tex revision 1.25.

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

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


From noreply@sourceforge.net  Wed Apr 11 23:22:00 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 11 Apr 2001 15:22:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-415514 ] "%#x" % 0 caused assertion failure/abort
Message-ID: <E14nSzw-0006m9-00@usw-sf-web1.sourceforge.net>

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

Category: Python Interpreter Core
Group: None
Status: Open
>Priority: 7
Submitted By: Fergal Mc Carthy (rahn_tamalin)
>Assigned to: Tim Peters (tim_one)
>Summary: "%#x" % 0 caused assertion failure/abort

Initial Comment:
[I am unable to fix a similar problem report, even
 searching for the assertion failure. Please forgive
 me if I'm reporting a known problem.]

With python 2.0, I've found that if I tried to print a 
value of 0 with a % format of "%#x" that this 
generates the following aborts under both Unix (Tru64) 
and Windows (98SE).

"%#o" doesn't have problems.

[python 2.0 built for Digital UNIX (DEC OSF) V4.0d]
Python 2.0 (#1, Apr 11 2001, 20:48:08) [C] on osf1V4
Type "copyright", "credits" or "license" for more 
information.
>>> "%#x" % 0
Assertion failed: pbuf[1] == c, file stringobject.c, 
line 2981

[python 2.0 built for Tru64 UNIX (DEC OSF) V5.0]
Python 2.0 (#1, Apr 11 2001, 20:35:33) [C] on osf1V5
Type "copyright", "credits" or "license" for more 
information.
>>> "%#x" % 0
Assertion failed: pbuf[1] == c, file stringobject.c, 
line 2981

[python 2.0 built for Tru64 UNIX (DEC OSF) V5.1]
Python 2.0 (#2, Apr  8 2001, 20:54:56) [C] on osf1V5
Type "copyright", "credits" or "license" for more 
information.
>>> "%#x" % 0
Assertion failed: pbuf[1] == c, file stringobject.c, 
line 2981


[Windows 98 SE Illegal Operation Exception Details]
PYTHON caused an invalid page fault in
module PYTHON20.DLL at 0167:1e15a784.
Registers:
EAX=ffffffff CS=0167 EIP=1e15a784 EFLGS=00010207
EBX=00000000 SS=016f ESP=0063fb98 EBP=00000078
ECX=3ffffefe DS=016f ESI=0063fffe FS=4b17
EDX=00790f87 ES=016f EDI=0079138b GS=0000
Bytes at CS:EIP:
f3 a5 8b c8 83 e1 03 f3 a4 8b 44 24 18 8b 74 24 
Stack dump:
00761b6c 007747fc 00761b6c 00790ad0 00000000 0063fbfa 
ffffffff 00000064 00790f87 00790f70 ffffffff 00790ae7 
00000008 ffffffff ffffffff 00000000 

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

>Comment By: Tim Peters (tim_one)
Date: 2001-04-11 15:21

Message:
Logged In: YES 
user_id=31435

Assigned to me and boosted the priority.  Dies with the 
same assertion under a debug-build Windows Python.  Since I 
almost certainly added the assert(), I must have been 
suspicious at one time <wink/sigh>.

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

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


From noreply@sourceforge.net  Thu Apr 12 01:38:46 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 11 Apr 2001 17:38:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-415514 ] "%#x" % 0 caused assertion failure/abort
Message-ID: <E14nV8I-0000Rb-00@usw-sf-web1.sourceforge.net>

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

Category: Python Interpreter Core
Group: None
>Status: Closed
Priority: 7
Submitted By: Fergal Mc Carthy (rahn_tamalin)
Assigned to: Tim Peters (tim_one)
>Summary: "%#x" % 0 caused assertion failure/abort

Initial Comment:
[I am unable to fix a similar problem report, even
 searching for the assertion failure. Please forgive
 me if I'm reporting a known problem.]

With python 2.0, I've found that if I tried to print a 
value of 0 with a % format of "%#x" that this 
generates the following aborts under both Unix (Tru64) 
and Windows (98SE).

"%#o" doesn't have problems.

[python 2.0 built for Digital UNIX (DEC OSF) V4.0d]
Python 2.0 (#1, Apr 11 2001, 20:48:08) [C] on osf1V4
Type "copyright", "credits" or "license" for more 
information.
>>> "%#x" % 0
Assertion failed: pbuf[1] == c, file stringobject.c, 
line 2981

[python 2.0 built for Tru64 UNIX (DEC OSF) V5.0]
Python 2.0 (#1, Apr 11 2001, 20:35:33) [C] on osf1V5
Type "copyright", "credits" or "license" for more 
information.
>>> "%#x" % 0
Assertion failed: pbuf[1] == c, file stringobject.c, 
line 2981

[python 2.0 built for Tru64 UNIX (DEC OSF) V5.1]
Python 2.0 (#2, Apr  8 2001, 20:54:56) [C] on osf1V5
Type "copyright", "credits" or "license" for more 
information.
>>> "%#x" % 0
Assertion failed: pbuf[1] == c, file stringobject.c, 
line 2981


[Windows 98 SE Illegal Operation Exception Details]
PYTHON caused an invalid page fault in
module PYTHON20.DLL at 0167:1e15a784.
Registers:
EAX=ffffffff CS=0167 EIP=1e15a784 EFLGS=00010207
EBX=00000000 SS=016f ESP=0063fb98 EBP=00000078
ECX=3ffffefe DS=016f ESI=0063fffe FS=4b17
EDX=00790f87 ES=016f EDI=0079138b GS=0000
Bytes at CS:EIP:
f3 a5 8b c8 83 e1 03 f3 a4 8b 44 24 18 8b 74 24 
Stack dump:
00761b6c 007747fc 00761b6c 00790ad0 00000000 0063fbfa 
ffffffff 00000064 00790f87 00790f70 ffffffff 00790ae7 
00000008 ffffffff ffffffff 00000000 

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

>Comment By: Tim Peters (tim_one)
Date: 2001-04-11 17:38

Message:
Logged In: YES 
user_id=31435

Fixed and closed.

Lib/test/test_format.py; new revision: 1.10
Objects/stringobject.c; new revision: 2.101
Objects/unicodeobject.c; new revision: 2.81

>From the checkin msg:

"""
For short ints, Python defers to the platform C library to 
figure out what %#x should do.  The code asserted that the 
platform C returned a string beginning with "0x".  However, 
that's not true when-- and only when --the *value* being 
formatted is 0.  Changed the code to live with C's 
inconsistency here.  In the meantime, the problem does not 
arise if you format a long 0 (0L) instead.  However, that's 
because the code *we* wrote to do %#x conversions on longs 
produces a leading "0x" regardless of value.  That's 
probably wrong too:  we should drop leading "0x", for 
consistency with C, when (& only when) formatting
0L.  So I changed the long formatting code to do that too.
"""

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

Comment By: Tim Peters (tim_one)
Date: 2001-04-11 15:21

Message:
Logged In: YES 
user_id=31435

Assigned to me and boosted the priority.  Dies with the 
same assertion under a debug-build Windows Python.  Since I 
almost certainly added the assert(), I must have been 
suspicious at one time <wink/sigh>.

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

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


From noreply@sourceforge.net  Thu Apr 12 06:37:10 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 11 Apr 2001 22:37:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-415597 ] asynchat.py - bug in terminator find
Message-ID: <E14nZn4-0007kf-00@usw-sf-web3.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: asynchat.py - bug in terminator find

Initial Comment:
Id: asynchat.py,v 2.26 2000/09/07 22:29:26 rushing Exp
line 122-"index = terminator.find (self.ac_in_buffer)"

This should be the other way around - 
index = self.ac_in_buffer.find(terminator)

The Python 1.5.2 version I looked at used the string 
find method, and in the right order, which works OK.

It doesn't find the data string inside the terminator 
string very often in my app !


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

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


From noreply@sourceforge.net  Thu Apr 12 07:14:17 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 11 Apr 2001 23:14:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-415597 ] asynchat.py - bug in terminator find
Message-ID: <E14naMz-0007Zm-00@usw-sf-web2.sourceforge.net>

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

Category: Python Library
Group: None
>Status: Closed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: asynchat.py - bug in terminator find

Initial Comment:
Id: asynchat.py,v 2.26 2000/09/07 22:29:26 rushing Exp
line 122-"index = terminator.find (self.ac_in_buffer)"

This should be the other way around - 
index = self.ac_in_buffer.find(terminator)

The Python 1.5.2 version I looked at used the string 
find method, and in the right order, which works OK.

It doesn't find the data string inside the terminator 
string very often in my app !


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

>Comment By: Tim Peters (tim_one)
Date: 2001-04-11 23:14

Message:
Logged In: YES 
user_id=31435

Yes, this was fixed a few days in the CVS tree, and will be 
distributed with Python 2.1.

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

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


From noreply@sourceforge.net  Thu Apr 12 07:32:51 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 11 Apr 2001 23:32:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-415612 ] readline ext fails w/ new v4.2
Message-ID: <E14naex-0005ad-00@usw-sf-web1.sourceforge.net>

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

Category: Extension Modules
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Gordon Sadler (gbsadler)
Assigned to: Nobody/Anonymous (nobody)
Summary: readline ext fails w/ new v4.2

Initial Comment:
Top of my test.log from make test:


PYTHONPATH= ./python ./setup.py build
/home/gbsadler/cvs/python/dist/src/Modules/readline.c:34: 
conflicting types for `rl_read_init_file'
/usr/include/readline/readline.h:304: previous declaration of 
`rl_read_init_file'
/home/gbsadler/cvs/python/dist/src/Modules/readline.c:35: 
conflicting types for `rl_insert_text'
/usr/include/readline/readline.h:364: previous declaration of 
`rl_insert_text'
/home/gbsadler/cvs/python/dist/src/Modules/readline.c: In 
function `set_completer_delims':
/home/gbsadler/cvs/python/dist/src/Modules/readline.c:231: 
warning: passing arg 1 of `free' discards qualifiers from poi
nter target type
/home/gbsadler/cvs/python/dist/src/Modules/readline.c: In 
function `flex_complete':
/home/gbsadler/cvs/python/dist/src/Modules/readline.c:403: 
warning: implicit declaration of function `completion_matches
'
/home/gbsadler/cvs/python/dist/src/Modules/readline.c:403: 
warning: return makes pointer from integer without a cast


rl_read_init_file and rl_insert_text both now expect (const 
char*) as parameters.

These are your choices for completion_matches:

readline.h:extern char **rl_completion_matches __P((const char 
*, rl_compentry_func_t *));
readline.h:extern char **completion_matches __P((char *, 
rl_compentry_func_t *));

Here's the compile line from test.log:

building 'readline' extension
gcc -g -O2 -Wall -Wstrict-prototypes -fPIC -I. 
-I/home/gbsadler/cvs/python/dist/src/./Include 
-I/usr/local/include -IInc
lude/ -c 
/home/gbsadler/cvs/python/dist/src/Modules/readline.c -o 
build/temp.linux-i686-2.1/readline.o -g -O2 -Wall -Wst
rict-prototypes -I. -I./Include -DHAVE_CONFIG_H
WARNING: building of extension "readline" failed: command 'gcc' 
failed with exit status 1






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

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


From noreply@sourceforge.net  Thu Apr 12 10:45:31 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 12 Apr 2001 02:45:31 -0700
Subject: [Python-bugs-list] [ python-Bugs-415634 ] Empty section in lib ref not tagged
Message-ID: <E14ndfP-00009R-00@usw-sf-web1.sourceforge.net>

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

Category: Documentation
Group: None
Status: Open
Priority: 3
Submitted By: Skip Montanaro (montanaro)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Empty section in lib ref not tagged

Initial Comment:
Section 5.2.1 of the Library Reference Manual (release
2.1c1) is empty.  It should probably contain at least
"TBD", so users don't think there is something wrong
with their browsers.



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

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


From noreply@sourceforge.net  Thu Apr 12 14:58:06 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 12 Apr 2001 06:58:06 -0700
Subject: [Python-bugs-list] [ python-Bugs-415660 ] Weak references cause illegal memory ref
Message-ID: <E14nhbq-0004C7-00@usw-sf-web2.sourceforge.net>

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

Category: Python Interpreter Core
Group: None
Status: Open
Priority: 5
Submitted By: Duncan Booth (duncanb)
Assigned to: Nobody/Anonymous (nobody)
Summary: Weak references cause illegal memory ref

Initial Comment:
Python 2.1b2 on Windows 2000
I was playing with weak references and found that the 
following script (test.py) caused the program to crash 
reliably with the error '''The instruction 
at "0x1e12b486" referenced memory at "0x00007479". the 
memory could not be "read".'''

Program test.py
---------------------------------
import weakref
from sys import getrefcount
from thread import get_ident

class C:
    def __del__(self):
        print "object deleted", `self`

def callback(object):
    print get_ident(),"callback for deletion",`object`
    print get_ident(),"ref is", `ref`, `ref()`
    print get_ident(),"ref1 is", `ref1`, `ref1()`
    print get_ident(),"end of callback"

c = C()
ref = weakref.ref(c, callback)
ref1 = weakref.ref(c, callback)
print get_ident(),"c is",`c`
print get_ident(),"ref is", `ref`, `ref()`
print get_ident(),"ref1 is", `ref1`, `ref1()`
del c
print get_ident(),"c was deleted"
print get_ident(),"ref is", `ref`, `ref()`
print get_ident(),"ref1 is", `ref1`, `ref1()`
print get_ident(),"Done"
---------------------------------

The output from the program is as follows. Something 
strange seems to be happening as both callbacks seem 
to be active at the same time on the same thread(?), 
and at least one newline has gone missing (in case 
this gets wrapped: every print begins with 1332, and 
the second 'callback for deletion' print is not at the 
start of a line).
---------------------------------
D:\temp>\python21\python test.py
1332 c is <__main__.C instance at 007DDD0C>
1332 ref is <weakref at 0x798f8c; to 'instance' at 
0x7ddd0c> <__main__.C instance at 007DDD0C>
1332 ref1 is <weakref at 0x7d9f7c; to 'instance' at 
0x7ddd0c> <__main__.C instance at 007DDD0C>
1332 callback for deletion <weakref at 7d9f7c; dead>
1332 ref is <weakref at 0x798f8c; to 'instance' at 
0x7ddd0c> 1332 callback for deletion <weakref at 
798f8c; dead>
1332 ref is <weakref at 798f8c; dead> None
1332 ref1 is <weakref at 7d9f7c; dead> None
1332 end of callback
object deleted <__main__.C instance at 007DDD0C>
<__main__.C instance at 007DDD0C>
1332 ref1 is <weakref at 7d9f7c; dead> None
1332 end of callback

D:\temp>
---------------------------------



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

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


From noreply@sourceforge.net  Thu Apr 12 15:10:06 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 12 Apr 2001 07:10:06 -0700
Subject: [Python-bugs-list] [ python-Bugs-415634 ] Empty section in lib ref not tagged
Message-ID: <E14nhnS-0003ka-00@usw-sf-web1.sourceforge.net>

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

Category: Documentation
Group: None
Status: Open
>Priority: 6
Submitted By: Skip Montanaro (montanaro)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Empty section in lib ref not tagged

Initial Comment:
Section 5.2.1 of the Library Reference Manual (release
2.1c1) is empty.  It should probably contain at least
"TBD", so users don't think there is something wrong
with their browsers.



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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-04-12 07:10

Message:
Logged In: YES 
user_id=3066

The bug is that the section isn't written yet!  It will either be written in time for the release or it will be removed.  I'll leave this bug report open so I don't lose track of this.

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

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


From noreply@sourceforge.net  Thu Apr 12 18:05:55 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 12 Apr 2001 10:05:55 -0700
Subject: [Python-bugs-list] [ python-Bugs-231249 ] cgi.py opens too many (temporary) files
Message-ID: <E14nkXb-0006bV-00@usw-sf-web2.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Richard van de Stadt (stadt)
Assigned to: Guido van Rossum (gvanrossum)
Summary: cgi.py opens too many (temporary) files

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

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

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

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

Comment By: Kurt B. Kaiser (kbk)
Date: 2001-04-12 10:05

Message:
Logged In: YES 
user_id=149084

I have a thought on this, but it will be about 10 hours before I can submit it.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-11 13:20

Message:
Logged In: YES 
user_id=6380

Here's a proposed patch.

Can anyone think of a reason why this should not be checked
in as part of 2.1?

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 11:54

Message:
Logged In: YES 
user_id=6380

I wish I'd heard about this sooner.

It does seem a problem and it does make sense to use StringIO unless there's a lot of data.

But we can't fix this in time for 2.1...


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

Comment By: A.M. Kuchling (akuchling)
Date: 2001-04-10 10:54

Message:
Logged In: YES 
user_id=11375

Unassigning so someone else can take a look at it.

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

Comment By: Kurt B. Kaiser (kbk)
Date: 2001-02-18 23:32

Message:
In the particular HTML form referenced it appears that a workaround might be to eliminate the enctype attribute in the <form> tag and take the application/x-www-form-urlencoded default since no files are being uploaded. 

When make_file creates the temporary files they are immediately unlinked. There is probably a brief period before the unlink is finalized during which the ls process might see a file; that would account for the output of ls | wc. It appears that the current cgi.py implementation leaves all the (hundreds of) files open until the cgi process releases the FieldStorage object or exits. 

My first thought was, if the filename recovered from the header is None have make_file create a StringIO object instead of a temp file. That way a temp file is only created when a file is uploaded. This is not inconsistent with the cgi.py docs.

Unfortunately, RFC2388 4.4 states that a filename is not required to be sent, so it looks like your solution based on the size of the data received is the correct one. Below 1K you could copy the temp file contents to a StringIO and assign it to self.file, then explicitly close the temp file via its descriptor. 

If only I understood the module better ::-(( and had a way of tunnel testing it I might have had the temerity to offer a patch. (I'm away for a couple of weeks starting tomorrow.)

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

Comment By: A.M. Kuchling (akuchling)
Date: 2001-02-18 14:08

Message:
Ah, I see; the traceback makes this much clearer.  When you're uploading a file, everything in the form is sent as 
a MIME document in the body; every field is accompanied by 
a boundary separator and Content-Disposition header.
In multipart mode, cgi.py copies each field into a temporary file.  

The first idea I had was to only use tempfiles for the actual upload field; unfortunately, that doesn't help because the upload field isn't special, and cgi.py has no way to know which it is ahead of time.

Possible second approach: measure the size of the resulting file; if it's less than some threshold (1K? 10K?), read its contents into memory and close the tempfile.  This means only the largest fields will require that a file descriptor be kept open.  I'll explore this more after beta1.




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

Comment By: Richard van de Stadt (stadt)
Date: 2001-02-17 18:37

Message:
I do *not* mean file upload fields. I stumbled upon this with a webform that
contains 141 'simple' input fields like the form you can see here (which 'only'
contains 31 of those input fields):

http://www.cyberchair.org/cgi-cyb/genAssignPageReviewerPapers.py

(use chair/chair to login)

When the maximum number of file descriptors used per process was increased
to 160 (by the sysadmins), the problem did not occur anymore, and the webform
could be processed.

This was the error message I got: 

Traceback (most recent call last):
  File "/usr/local/etc/httpd/DocumentRoot/ICML2001/cgi-bin/submitAssignRP.py", line 144, in main
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/cgi.py", line 504, in __init__
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/cgi.py", line 593, in read_multi
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/cgi.py", line 506, in __init__
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/cgi.py", line 603, in read_single
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/cgi.py", line 623, in read_lines
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/cgi.py", line 713, in make_file
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/tempfile.py", line 144, in TemporaryFile
OSError: [Errno 24] Too many open files: '/home/yara/brodley/icml2001/tmp/@26048.61'

I understand why you assume that it would concern *file* uploads, but this is
not the case. As I reported before, it turns out that for each 'simple' <input> field
a temporary file is used in to transfer the contents to the script that uses the
cgi.FieldStorage() method, even if no files are being uploaded. The problem is not
that too many files are open at the same time (which is 1 at most). It is the *amount*
of files that is causing the troubles. If the same temporary file would be used, this
problem would probably not have happened. 

My colleague Fred Gansevles wrote a possible solution, but mentioned that this
might introduce the need for protection against a 'symlink attack' (whatever
that may be). This solution(?) concentrates on the open file descriptor's problem,
while Fred suggests a redesign of FieldStorage() would probably be better.

import os, tempfile
AANTAL = 50

class TemporaryFile:
    def __init__(self):
        self.name = tempfile.mktemp("")
        open(self.name, 'w').close()
        self.offset = 0
    
    def seek(self, offset):
        self.offset = offset
    
    def read(self):
        fd = open(self.name, 'w+b', -1)
        fd.seek(self.offset)
        data = fd.read()
        self.offset = fd.tell()
        fd.close()
        return data
    
    def write(self, data):
        fd = open(self.name, 'w+b', -1)
        fd.seek(self.offset)
        fd.write(data)
        self.offset = fd.tell()
        fd.close()

    def __del__(self):
        os.unlink(self.name)

def add_fd(l, n) :
    map(lambda x,l=l: l.append(open('/dev/null')), range(n))

def add_tmp(l, n) :
    map(lambda x,l=l: l.append(TemporaryFile()), range(n))

def main ():
    import getopt, sys
    try:
        import resource
        soft, hard = resource.getrlimit (resource.RLIMIT_NOFILE)
        resource.setrlimit (resource.RLIMIT_NOFILE, (hard, hard))
    except ImportError:
        soft, hard = 64, 1024
    opts, args = getopt.getopt(sys.argv[1:], 'n:t')
    aantal = AANTAL
    tmp = add_fd
    for o, a in opts:
        if o == '-n':
            aantal = int(a)
        elif o == '-t':
            tmp = add_tmp
    print "aantal te gebruiken fd's:", aantal   #dutch; English: 'number of fds to be used'
    print 'tmp:', tmp.func_name
    tmp_files = []
    files=[]
    tmp(tmp_files, aantal)
    try:
        add_fd(files,hard)
    except IOError:
        pass
    print "aantal vrije gebruiken fd's:", len(files)  #enlish: 'number of free fds'

main()

Running the above code:

    python ulimit.py [-n number] [-t]
    default number = 50, while using 'real' fd-s for temporary files.
    When using the '-t' flag 'smart' temporary files are used.

    Output:

        $ python ulimit.py
        aantal te gebruiken fd's: 50
        tmp: add_fd
        aantal vrije gebruiken fd's: 970

        $ python ulimit.py -t
        aantal te gebruiken fd's: 50
        tmp: add_tmp
        aantal vrije gebruiken fd's: 1020

        $ python ulimit.py -n 1000
        aantal te gebruiken fd's: 1000
        tmp: add_fd
        aantal vrije gebruiken fd's: 20

        $ python ulimit.py -n 1000 -t
        aantal te gebruiken fd's: 1000
        tmp: add_tmp
        aantal vrije gebruiken fd's: 1020

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

Comment By: A.M. Kuchling (akuchling)
Date: 2001-02-16 21:41

Message:
I assume you mean 64 file upload fields, right?  
Can you provide a small test program that triggers the problem?

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

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


From noreply@sourceforge.net  Thu Apr 12 19:41:03 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 12 Apr 2001 11:41:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-415514 ] "%#x" % 0 caused assertion failure/abort
Message-ID: <E14nm1f-0007kM-00@usw-sf-web2.sourceforge.net>

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

Category: Python Interpreter Core
Group: None
Status: Closed
Priority: 7
Submitted By: Fergal Mc Carthy (rahn_tamalin)
Assigned to: Tim Peters (tim_one)
>Summary: "%#x" % 0 caused assertion failure/abort

Initial Comment:
[I am unable to fix a similar problem report, even
 searching for the assertion failure. Please forgive
 me if I'm reporting a known problem.]

With python 2.0, I've found that if I tried to print a 
value of 0 with a % format of "%#x" that this 
generates the following aborts under both Unix (Tru64) 
and Windows (98SE).

"%#o" doesn't have problems.

[python 2.0 built for Digital UNIX (DEC OSF) V4.0d]
Python 2.0 (#1, Apr 11 2001, 20:48:08) [C] on osf1V4
Type "copyright", "credits" or "license" for more 
information.
>>> "%#x" % 0
Assertion failed: pbuf[1] == c, file stringobject.c, 
line 2981

[python 2.0 built for Tru64 UNIX (DEC OSF) V5.0]
Python 2.0 (#1, Apr 11 2001, 20:35:33) [C] on osf1V5
Type "copyright", "credits" or "license" for more 
information.
>>> "%#x" % 0
Assertion failed: pbuf[1] == c, file stringobject.c, 
line 2981

[python 2.0 built for Tru64 UNIX (DEC OSF) V5.1]
Python 2.0 (#2, Apr  8 2001, 20:54:56) [C] on osf1V5
Type "copyright", "credits" or "license" for more 
information.
>>> "%#x" % 0
Assertion failed: pbuf[1] == c, file stringobject.c, 
line 2981


[Windows 98 SE Illegal Operation Exception Details]
PYTHON caused an invalid page fault in
module PYTHON20.DLL at 0167:1e15a784.
Registers:
EAX=ffffffff CS=0167 EIP=1e15a784 EFLGS=00010207
EBX=00000000 SS=016f ESP=0063fb98 EBP=00000078
ECX=3ffffefe DS=016f ESI=0063fffe FS=4b17
EDX=00790f87 ES=016f EDI=0079138b GS=0000
Bytes at CS:EIP:
f3 a5 8b c8 83 e1 03 f3 a4 8b 44 24 18 8b 74 24 
Stack dump:
00761b6c 007747fc 00761b6c 00790ad0 00000000 0063fbfa 
ffffffff 00000064 00790f87 00790f70 ffffffff 00790ae7 
00000008 ffffffff ffffffff 00000000 

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

>Comment By: Tim Peters (tim_one)
Date: 2001-04-12 11:41

Message:
Logged In: YES 
user_id=31435

Changed the fix:  Python now produces a base marker (for %
#x and %#X conversion) whether or not the value is 0, and 
whether or not 0 is short or long.  This is inconsistent 
with C, but is consistent with Python's hex(), consistent 
with what Python did before for conversion of 0L, and more 
predictable in any case.  Since conversion of short 0 blew 
up before, Python didn't follow C's behavior before either.

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

Comment By: Tim Peters (tim_one)
Date: 2001-04-11 17:38

Message:
Logged In: YES 
user_id=31435

Fixed and closed.

Lib/test/test_format.py; new revision: 1.10
Objects/stringobject.c; new revision: 2.101
Objects/unicodeobject.c; new revision: 2.81

>From the checkin msg:

"""
For short ints, Python defers to the platform C library to 
figure out what %#x should do.  The code asserted that the 
platform C returned a string beginning with "0x".  However, 
that's not true when-- and only when --the *value* being 
formatted is 0.  Changed the code to live with C's 
inconsistency here.  In the meantime, the problem does not 
arise if you format a long 0 (0L) instead.  However, that's 
because the code *we* wrote to do %#x conversions on longs 
produces a leading "0x" regardless of value.  That's 
probably wrong too:  we should drop leading "0x", for 
consistency with C, when (& only when) formatting
0L.  So I changed the long formatting code to do that too.
"""

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

Comment By: Tim Peters (tim_one)
Date: 2001-04-11 15:21

Message:
Logged In: YES 
user_id=31435

Assigned to me and boosted the priority.  Dies with the 
same assertion under a debug-build Windows Python.  Since I 
almost certainly added the assert(), I must have been 
suspicious at one time <wink/sigh>.

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

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


From noreply@sourceforge.net  Thu Apr 12 19:59:35 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 12 Apr 2001 11:59:35 -0700
Subject: [Python-bugs-list] [ python-Bugs-231249 ] cgi.py opens too many (temporary) files
Message-ID: <E14nmJb-0007xt-00@usw-sf-web2.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Richard van de Stadt (stadt)
Assigned to: Guido van Rossum (gvanrossum)
Summary: cgi.py opens too many (temporary) files

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

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

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

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-12 11:59

Message:
Logged In: YES 
user_id=6380

Uploading a new patch, more complicated.  I don't like it as
much. But it works even if the caller uses
item.file.fileno().

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

Comment By: Kurt B. Kaiser (kbk)
Date: 2001-04-12 10:05

Message:
Logged In: YES 
user_id=149084

I have a thought on this, but it will be about 10 hours before I can submit it.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-11 13:20

Message:
Logged In: YES 
user_id=6380

Here's a proposed patch.

Can anyone think of a reason why this should not be checked
in as part of 2.1?

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 11:54

Message:
Logged In: YES 
user_id=6380

I wish I'd heard about this sooner.

It does seem a problem and it does make sense to use StringIO unless there's a lot of data.

But we can't fix this in time for 2.1...


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

Comment By: A.M. Kuchling (akuchling)
Date: 2001-04-10 10:54

Message:
Logged In: YES 
user_id=11375

Unassigning so someone else can take a look at it.

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

Comment By: Kurt B. Kaiser (kbk)
Date: 2001-02-18 23:32

Message:
In the particular HTML form referenced it appears that a workaround might be to eliminate the enctype attribute in the <form> tag and take the application/x-www-form-urlencoded default since no files are being uploaded. 

When make_file creates the temporary files they are immediately unlinked. There is probably a brief period before the unlink is finalized during which the ls process might see a file; that would account for the output of ls | wc. It appears that the current cgi.py implementation leaves all the (hundreds of) files open until the cgi process releases the FieldStorage object or exits. 

My first thought was, if the filename recovered from the header is None have make_file create a StringIO object instead of a temp file. That way a temp file is only created when a file is uploaded. This is not inconsistent with the cgi.py docs.

Unfortunately, RFC2388 4.4 states that a filename is not required to be sent, so it looks like your solution based on the size of the data received is the correct one. Below 1K you could copy the temp file contents to a StringIO and assign it to self.file, then explicitly close the temp file via its descriptor. 

If only I understood the module better ::-(( and had a way of tunnel testing it I might have had the temerity to offer a patch. (I'm away for a couple of weeks starting tomorrow.)

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

Comment By: A.M. Kuchling (akuchling)
Date: 2001-02-18 14:08

Message:
Ah, I see; the traceback makes this much clearer.  When you're uploading a file, everything in the form is sent as 
a MIME document in the body; every field is accompanied by 
a boundary separator and Content-Disposition header.
In multipart mode, cgi.py copies each field into a temporary file.  

The first idea I had was to only use tempfiles for the actual upload field; unfortunately, that doesn't help because the upload field isn't special, and cgi.py has no way to know which it is ahead of time.

Possible second approach: measure the size of the resulting file; if it's less than some threshold (1K? 10K?), read its contents into memory and close the tempfile.  This means only the largest fields will require that a file descriptor be kept open.  I'll explore this more after beta1.




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

Comment By: Richard van de Stadt (stadt)
Date: 2001-02-17 18:37

Message:
I do *not* mean file upload fields. I stumbled upon this with a webform that
contains 141 'simple' input fields like the form you can see here (which 'only'
contains 31 of those input fields):

http://www.cyberchair.org/cgi-cyb/genAssignPageReviewerPapers.py

(use chair/chair to login)

When the maximum number of file descriptors used per process was increased
to 160 (by the sysadmins), the problem did not occur anymore, and the webform
could be processed.

This was the error message I got: 

Traceback (most recent call last):
  File "/usr/local/etc/httpd/DocumentRoot/ICML2001/cgi-bin/submitAssignRP.py", line 144, in main
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/cgi.py", line 504, in __init__
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/cgi.py", line 593, in read_multi
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/cgi.py", line 506, in __init__
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/cgi.py", line 603, in read_single
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/cgi.py", line 623, in read_lines
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/cgi.py", line 713, in make_file
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/tempfile.py", line 144, in TemporaryFile
OSError: [Errno 24] Too many open files: '/home/yara/brodley/icml2001/tmp/@26048.61'

I understand why you assume that it would concern *file* uploads, but this is
not the case. As I reported before, it turns out that for each 'simple' <input> field
a temporary file is used in to transfer the contents to the script that uses the
cgi.FieldStorage() method, even if no files are being uploaded. The problem is not
that too many files are open at the same time (which is 1 at most). It is the *amount*
of files that is causing the troubles. If the same temporary file would be used, this
problem would probably not have happened. 

My colleague Fred Gansevles wrote a possible solution, but mentioned that this
might introduce the need for protection against a 'symlink attack' (whatever
that may be). This solution(?) concentrates on the open file descriptor's problem,
while Fred suggests a redesign of FieldStorage() would probably be better.

import os, tempfile
AANTAL = 50

class TemporaryFile:
    def __init__(self):
        self.name = tempfile.mktemp("")
        open(self.name, 'w').close()
        self.offset = 0
    
    def seek(self, offset):
        self.offset = offset
    
    def read(self):
        fd = open(self.name, 'w+b', -1)
        fd.seek(self.offset)
        data = fd.read()
        self.offset = fd.tell()
        fd.close()
        return data
    
    def write(self, data):
        fd = open(self.name, 'w+b', -1)
        fd.seek(self.offset)
        fd.write(data)
        self.offset = fd.tell()
        fd.close()

    def __del__(self):
        os.unlink(self.name)

def add_fd(l, n) :
    map(lambda x,l=l: l.append(open('/dev/null')), range(n))

def add_tmp(l, n) :
    map(lambda x,l=l: l.append(TemporaryFile()), range(n))

def main ():
    import getopt, sys
    try:
        import resource
        soft, hard = resource.getrlimit (resource.RLIMIT_NOFILE)
        resource.setrlimit (resource.RLIMIT_NOFILE, (hard, hard))
    except ImportError:
        soft, hard = 64, 1024
    opts, args = getopt.getopt(sys.argv[1:], 'n:t')
    aantal = AANTAL
    tmp = add_fd
    for o, a in opts:
        if o == '-n':
            aantal = int(a)
        elif o == '-t':
            tmp = add_tmp
    print "aantal te gebruiken fd's:", aantal   #dutch; English: 'number of fds to be used'
    print 'tmp:', tmp.func_name
    tmp_files = []
    files=[]
    tmp(tmp_files, aantal)
    try:
        add_fd(files,hard)
    except IOError:
        pass
    print "aantal vrije gebruiken fd's:", len(files)  #enlish: 'number of free fds'

main()

Running the above code:

    python ulimit.py [-n number] [-t]
    default number = 50, while using 'real' fd-s for temporary files.
    When using the '-t' flag 'smart' temporary files are used.

    Output:

        $ python ulimit.py
        aantal te gebruiken fd's: 50
        tmp: add_fd
        aantal vrije gebruiken fd's: 970

        $ python ulimit.py -t
        aantal te gebruiken fd's: 50
        tmp: add_tmp
        aantal vrije gebruiken fd's: 1020

        $ python ulimit.py -n 1000
        aantal te gebruiken fd's: 1000
        tmp: add_fd
        aantal vrije gebruiken fd's: 20

        $ python ulimit.py -n 1000 -t
        aantal te gebruiken fd's: 1000
        tmp: add_tmp
        aantal vrije gebruiken fd's: 1020

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

Comment By: A.M. Kuchling (akuchling)
Date: 2001-02-16 21:41

Message:
I assume you mean 64 file upload fields, right?  
Can you provide a small test program that triggers the problem?

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

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


From noreply@sourceforge.net  Thu Apr 12 20:41:39 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 12 Apr 2001 12:41:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-415634 ] Empty section in lib ref not tagged
Message-ID: <E14nmyJ-0000XI-00@usw-sf-web1.sourceforge.net>

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

Category: Documentation
Group: None
>Status: Closed
Priority: 6
Submitted By: Skip Montanaro (montanaro)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Empty section in lib ref not tagged

Initial Comment:
Section 5.2.1 of the Library Reference Manual (release
2.1c1) is empty.  It should probably contain at least
"TBD", so users don't think there is something wrong
with their browsers.



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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-04-12 12:41

Message:
Logged In: YES 
user_id=3066

The text has been written and integrated in Doc/lib/libunittest.tex revision 1.4, but no longer forms a separate section.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-04-12 07:10

Message:
Logged In: YES 
user_id=3066

The bug is that the section isn't written yet!  It will either be written in time for the release or it will be removed.  I'll leave this bug report open so I don't lose track of this.

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

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


From noreply@sourceforge.net  Thu Apr 12 22:37:11 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 12 Apr 2001 14:37:11 -0700
Subject: [Python-bugs-list] [ python-Bugs-414940 ] locale.format broken in 2.1b2
Message-ID: <E14nom7-0002OI-00@usw-sf-web1.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Walter Dörwald (doerwalter)
Assigned to: Martin v. Löwis (loewis)
Summary: locale.format broken in 2.1b2

Initial Comment:
locale.format seems
to be broken in 2.1b2:

>>> import locale
>>> locale.format("%+.02f", -42., 1) 
'-+42.00'


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

>Comment By: Martin v. Löwis (loewis)
Date: 2001-04-12 14:37

Message:
Logged In: YES 
user_id=21627

A fix for that bug is now available at

http://sourceforge.net/tracker/index.php?group_id=5470&atid=305470

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 12:15

Message:
Logged In: YES 
user_id=6380

Yup, it's broken.  A simpler example is: locale.format("%+f", -42.).

Assigned to Martin, who is probably the author.  The code is incomprehensible to me (after 1 minute of trying :-).

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

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


From noreply@sourceforge.net  Fri Apr 13 05:04:48 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 12 Apr 2001 21:04:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-231249 ] cgi.py opens too many (temporary) files
Message-ID: <E14nupE-0007y5-00@usw-sf-web1.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Richard van de Stadt (stadt)
Assigned to: Guido van Rossum (gvanrossum)
Summary: cgi.py opens too many (temporary) files

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

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

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

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

Comment By: Kurt B. Kaiser (kbk)
Date: 2001-04-12 21:04

Message:
Logged In: YES 
user_id=149084

The patch posted 11 Apr is a neat and compact solution! 

The only thing I can imagine would be a problem would be if a form had a large number of (small) fields 
which set the content-length attribute.  I don't have an example of such, though. Text fields perhaps? If 
that was a realistic problem, a solution might be for make_file() to maintain a pool of temporary files; if the 
field (binary or not) turned out to be small a StringIO could be created and the temporary file returned to 
the pool.

There are a couple of things I've been thinking about in cgi.py; the patch doesn't seem to change the 
situation one way or the other:

There doesn't seem to be any RFC requirement that a file upload be accompanied by a content-length 
attribute, regardless of whether it is binary or ascii. In fact, some of the RFC examples I've seen omit it. If 
content-length is not specified, the upload will be processed by file.readline(). Can this cause problems for 
arbitrary binary files?

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-12 11:59

Message:
Logged In: YES 
user_id=6380

Uploading a new patch, more complicated.  I don't like it as
much. But it works even if the caller uses
item.file.fileno().

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

Comment By: Kurt B. Kaiser (kbk)
Date: 2001-04-12 10:05

Message:
Logged In: YES 
user_id=149084

I have a thought on this, but it will be about 10 hours before I can submit it.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-11 13:20

Message:
Logged In: YES 
user_id=6380

Here's a proposed patch.

Can anyone think of a reason why this should not be checked
in as part of 2.1?

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 11:54

Message:
Logged In: YES 
user_id=6380

I wish I'd heard about this sooner.

It does seem a problem and it does make sense to use StringIO unless there's a lot of data.

But we can't fix this in time for 2.1...


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

Comment By: A.M. Kuchling (akuchling)
Date: 2001-04-10 10:54

Message:
Logged In: YES 
user_id=11375

Unassigning so someone else can take a look at it.

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

Comment By: Kurt B. Kaiser (kbk)
Date: 2001-02-18 23:32

Message:
In the particular HTML form referenced it appears that a workaround might be to eliminate the enctype attribute in the <form> tag and take the application/x-www-form-urlencoded default since no files are being uploaded. 

When make_file creates the temporary files they are immediately unlinked. There is probably a brief period before the unlink is finalized during which the ls process might see a file; that would account for the output of ls | wc. It appears that the current cgi.py implementation leaves all the (hundreds of) files open until the cgi process releases the FieldStorage object or exits. 

My first thought was, if the filename recovered from the header is None have make_file create a StringIO object instead of a temp file. That way a temp file is only created when a file is uploaded. This is not inconsistent with the cgi.py docs.

Unfortunately, RFC2388 4.4 states that a filename is not required to be sent, so it looks like your solution based on the size of the data received is the correct one. Below 1K you could copy the temp file contents to a StringIO and assign it to self.file, then explicitly close the temp file via its descriptor. 

If only I understood the module better ::-(( and had a way of tunnel testing it I might have had the temerity to offer a patch. (I'm away for a couple of weeks starting tomorrow.)

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

Comment By: A.M. Kuchling (akuchling)
Date: 2001-02-18 14:08

Message:
Ah, I see; the traceback makes this much clearer.  When you're uploading a file, everything in the form is sent as 
a MIME document in the body; every field is accompanied by 
a boundary separator and Content-Disposition header.
In multipart mode, cgi.py copies each field into a temporary file.  

The first idea I had was to only use tempfiles for the actual upload field; unfortunately, that doesn't help because the upload field isn't special, and cgi.py has no way to know which it is ahead of time.

Possible second approach: measure the size of the resulting file; if it's less than some threshold (1K? 10K?), read its contents into memory and close the tempfile.  This means only the largest fields will require that a file descriptor be kept open.  I'll explore this more after beta1.




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

Comment By: Richard van de Stadt (stadt)
Date: 2001-02-17 18:37

Message:
I do *not* mean file upload fields. I stumbled upon this with a webform that
contains 141 'simple' input fields like the form you can see here (which 'only'
contains 31 of those input fields):

http://www.cyberchair.org/cgi-cyb/genAssignPageReviewerPapers.py

(use chair/chair to login)

When the maximum number of file descriptors used per process was increased
to 160 (by the sysadmins), the problem did not occur anymore, and the webform
could be processed.

This was the error message I got: 

Traceback (most recent call last):
  File "/usr/local/etc/httpd/DocumentRoot/ICML2001/cgi-bin/submitAssignRP.py", line 144, in main
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/cgi.py", line 504, in __init__
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/cgi.py", line 593, in read_multi
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/cgi.py", line 506, in __init__
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/cgi.py", line 603, in read_single
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/cgi.py", line 623, in read_lines
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/cgi.py", line 713, in make_file
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/tempfile.py", line 144, in TemporaryFile
OSError: [Errno 24] Too many open files: '/home/yara/brodley/icml2001/tmp/@26048.61'

I understand why you assume that it would concern *file* uploads, but this is
not the case. As I reported before, it turns out that for each 'simple' <input> field
a temporary file is used in to transfer the contents to the script that uses the
cgi.FieldStorage() method, even if no files are being uploaded. The problem is not
that too many files are open at the same time (which is 1 at most). It is the *amount*
of files that is causing the troubles. If the same temporary file would be used, this
problem would probably not have happened. 

My colleague Fred Gansevles wrote a possible solution, but mentioned that this
might introduce the need for protection against a 'symlink attack' (whatever
that may be). This solution(?) concentrates on the open file descriptor's problem,
while Fred suggests a redesign of FieldStorage() would probably be better.

import os, tempfile
AANTAL = 50

class TemporaryFile:
    def __init__(self):
        self.name = tempfile.mktemp("")
        open(self.name, 'w').close()
        self.offset = 0
    
    def seek(self, offset):
        self.offset = offset
    
    def read(self):
        fd = open(self.name, 'w+b', -1)
        fd.seek(self.offset)
        data = fd.read()
        self.offset = fd.tell()
        fd.close()
        return data
    
    def write(self, data):
        fd = open(self.name, 'w+b', -1)
        fd.seek(self.offset)
        fd.write(data)
        self.offset = fd.tell()
        fd.close()

    def __del__(self):
        os.unlink(self.name)

def add_fd(l, n) :
    map(lambda x,l=l: l.append(open('/dev/null')), range(n))

def add_tmp(l, n) :
    map(lambda x,l=l: l.append(TemporaryFile()), range(n))

def main ():
    import getopt, sys
    try:
        import resource
        soft, hard = resource.getrlimit (resource.RLIMIT_NOFILE)
        resource.setrlimit (resource.RLIMIT_NOFILE, (hard, hard))
    except ImportError:
        soft, hard = 64, 1024
    opts, args = getopt.getopt(sys.argv[1:], 'n:t')
    aantal = AANTAL
    tmp = add_fd
    for o, a in opts:
        if o == '-n':
            aantal = int(a)
        elif o == '-t':
            tmp = add_tmp
    print "aantal te gebruiken fd's:", aantal   #dutch; English: 'number of fds to be used'
    print 'tmp:', tmp.func_name
    tmp_files = []
    files=[]
    tmp(tmp_files, aantal)
    try:
        add_fd(files,hard)
    except IOError:
        pass
    print "aantal vrije gebruiken fd's:", len(files)  #enlish: 'number of free fds'

main()

Running the above code:

    python ulimit.py [-n number] [-t]
    default number = 50, while using 'real' fd-s for temporary files.
    When using the '-t' flag 'smart' temporary files are used.

    Output:

        $ python ulimit.py
        aantal te gebruiken fd's: 50
        tmp: add_fd
        aantal vrije gebruiken fd's: 970

        $ python ulimit.py -t
        aantal te gebruiken fd's: 50
        tmp: add_tmp
        aantal vrije gebruiken fd's: 1020

        $ python ulimit.py -n 1000
        aantal te gebruiken fd's: 1000
        tmp: add_fd
        aantal vrije gebruiken fd's: 20

        $ python ulimit.py -n 1000 -t
        aantal te gebruiken fd's: 1000
        tmp: add_tmp
        aantal vrije gebruiken fd's: 1020

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

Comment By: A.M. Kuchling (akuchling)
Date: 2001-02-16 21:41

Message:
I assume you mean 64 file upload fields, right?  
Can you provide a small test program that triggers the problem?

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

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


From noreply@sourceforge.net  Fri Apr 13 07:29:50 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 12 Apr 2001 23:29:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-415660 ] Weak references cause illegal memory ref
Message-ID: <E14nx5a-0007EZ-00@usw-sf-web2.sourceforge.net>

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

Category: Python Interpreter Core
Group: None
Status: Open
>Priority: 7
Submitted By: Duncan Booth (duncanb)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Weak references cause illegal memory ref

Initial Comment:
Python 2.1b2 on Windows 2000
I was playing with weak references and found that the 
following script (test.py) caused the program to crash 
reliably with the error '''The instruction 
at "0x1e12b486" referenced memory at "0x00007479". the 
memory could not be "read".'''

Program test.py
---------------------------------
import weakref
from sys import getrefcount
from thread import get_ident

class C:
    def __del__(self):
        print "object deleted", `self`

def callback(object):
    print get_ident(),"callback for deletion",`object`
    print get_ident(),"ref is", `ref`, `ref()`
    print get_ident(),"ref1 is", `ref1`, `ref1()`
    print get_ident(),"end of callback"

c = C()
ref = weakref.ref(c, callback)
ref1 = weakref.ref(c, callback)
print get_ident(),"c is",`c`
print get_ident(),"ref is", `ref`, `ref()`
print get_ident(),"ref1 is", `ref1`, `ref1()`
del c
print get_ident(),"c was deleted"
print get_ident(),"ref is", `ref`, `ref()`
print get_ident(),"ref1 is", `ref1`, `ref1()`
print get_ident(),"Done"
---------------------------------

The output from the program is as follows. Something 
strange seems to be happening as both callbacks seem 
to be active at the same time on the same thread(?), 
and at least one newline has gone missing (in case 
this gets wrapped: every print begins with 1332, and 
the second 'callback for deletion' print is not at the 
start of a line).
---------------------------------
D:\temp>\python21\python test.py
1332 c is <__main__.C instance at 007DDD0C>
1332 ref is <weakref at 0x798f8c; to 'instance' at 
0x7ddd0c> <__main__.C instance at 007DDD0C>
1332 ref1 is <weakref at 0x7d9f7c; to 'instance' at 
0x7ddd0c> <__main__.C instance at 007DDD0C>
1332 callback for deletion <weakref at 7d9f7c; dead>
1332 ref is <weakref at 0x798f8c; to 'instance' at 
0x7ddd0c> 1332 callback for deletion <weakref at 
798f8c; dead>
1332 ref is <weakref at 798f8c; dead> None
1332 ref1 is <weakref at 7d9f7c; dead> None
1332 end of callback
object deleted <__main__.C instance at 007DDD0C>
<__main__.C instance at 007DDD0C>
1332 ref1 is <weakref at 7d9f7c; dead> None
1332 end of callback

D:\temp>
---------------------------------



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

>Comment By: Tim Peters (tim_one)
Date: 2001-04-12 23:29

Message:
Logged In: YES 
user_id=31435

Boosted priority, assigned to Fred.

The thread stuff is a distraction (throw out all the 
get_ident() stuff & it still blows up).

Problem goes away if the "print ... ref()" call in the 
callback is commented out.  Note that this is doing ref() 
within ref's own "I'm dead" callback, so it's at best odd 
code.  Here's a shorter case that blows up (and designed to 
survive SourceForge's whitespace lossage intact):

import weakref
def callback(object): print "in callback", repr(ref())
class C: pass
c = C()
ref = weakref.ref(c, callback)
ref1 = weakref.ref(c, callback)
del c

Does not blow up if "ref1 =" is commented out, or if repr() 
is not invoked in the callback.  As is, it prints

in callback in callback None
<__main__.C instance at 0079606C>

and then blows up.  In a debug build, a call to 
PyObject_ClearWeakRefs is "up the call stack", at the start 
of instance_dealloc.  The former is a pointer to function 
cleanup_helper at this time.  cleanup_helper is executing 
PyObject_CallFunction(callback, "O", current).  The 
callback is apparently done at the time of the blowup, and 
ceval.c's do_call is executing Py_XDECREF(callargs).  The 
first tuple item is being deallocated, when Py_XDECREF(op-
>ob_item[i]) calls _Py_Dealloc calls _Py_ForgetReference, 
and that's where it finally blows up, and because the op 
passed in already has op->ob_next == op->ob_prev == NULL.


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

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


From noreply@sourceforge.net  Fri Apr 13 09:16:35 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 13 Apr 2001 01:16:35 -0700
Subject: [Python-bugs-list] [ python-Bugs-414940 ] locale.format broken in 2.1b2
Message-ID: <E14nykt-00012y-00@usw-sf-web3.sourceforge.net>

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

Category: Python Library
Group: None
>Status: Closed
Priority: 5
Submitted By: Walter Dörwald (doerwalter)
>Assigned to: Nobody/Anonymous (nobody)
Summary: locale.format broken in 2.1b2

Initial Comment:
locale.format seems
to be broken in 2.1b2:

>>> import locale
>>> locale.format("%+.02f", -42., 1) 
'-+42.00'


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

>Comment By: Martin v. Löwis (loewis)
Date: 2001-04-13 01:16

Message:
Logged In: YES 
user_id=21627

Fixed in 1.17 of locale.py

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

Comment By: Martin v. Löwis (loewis)
Date: 2001-04-12 14:37

Message:
Logged In: YES 
user_id=21627

A fix for that bug is now available at

http://sourceforge.net/tracker/index.php?group_id=5470&atid=305470

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 12:15

Message:
Logged In: YES 
user_id=6380

Yup, it's broken.  A simpler example is: locale.format("%+f", -42.).

Assigned to Martin, who is probably the author.  The code is incomprehensible to me (after 1 minute of trying :-).

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

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


From noreply@sourceforge.net  Fri Apr 13 13:47:58 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 13 Apr 2001 05:47:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-411060 ] pydoc helpe(help) fails
Message-ID: <E14o2zW-0002vh-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: Closed
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!  ;-)



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

>Comment By: Ka-Ping Yee (ping)
Date: 2001-04-13 05:47

Message:
Logged In: YES 
user_id=45338

Fixed in the new version of pydoc.

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

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


From noreply@sourceforge.net  Fri Apr 13 13:48:49 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 13 Apr 2001 05:48:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-406280 ] Python 2.1b1 - pydoc shows nothing
Message-ID: <E14o30L-0002wb-00@usw-sf-web2.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: Closed
Priority: 3
Submitted By: Paul Moore (pmoore)
Assigned to: Ka-Ping Yee (ping)
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: Ka-Ping Yee (ping)
Date: 2001-04-13 05:48

Message:
Logged In: YES 
user_id=45338

Fixed by always using temp files in Windows.
New version is checked in.

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

Comment By: Tim Peters (tim_one)
Date: 2001-04-08 22:10

Message:
Logged In: YES 
user_id=31435

Reassigned to Ping since wrestling w/ popen() on Windows is 
hopeless.  Left the priority low because it's gotta be rare 
for anyone to define a PAGER envar under Windows.  Note 
that Paul mailed some kind of related patch to Python-Dev 
recently ... mumble, mumble, ... here:

http://mail.python.org/pipermail/python-dev/2001-
April/014070.html

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

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  Fri Apr 13 13:55:48 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 13 Apr 2001 05:55:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-405553 ] pydoc.help broken in IDLE
Message-ID: <E14o376-00032F-00@usw-sf-web2.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: Closed
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: Ka-Ping Yee (ping)
Date: 2001-04-13 05:55

Message:
Logged In: YES 
user_id=45338

Yes, this was fixed some time ago.  It's no longer an issue.

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

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  Fri Apr 13 13:59:12 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 13 Apr 2001 05:59:12 -0700
Subject: [Python-bugs-list] [ python-Bugs-405554 ] pydoc should be integrated with HTML doc
Message-ID: <E14o3AO-00034z-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?)


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

>Comment By: Ka-Ping Yee (ping)
Date: 2001-04-13 05:59

Message:
Logged In: YES 
user_id=45338

Although there is now some integration with the
reference manual, this issue is still largely
unaddressed, since we haven't decided how to
present the two kinds of documentation
together or whether to merge them somehow.

Leaving this open for now.

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

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


From noreply@sourceforge.net  Fri Apr 13 15:12:53 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 13 Apr 2001 07:12:53 -0700
Subject: [Python-bugs-list] [ python-Bugs-415492 ] Compiler generates relative filenames
Message-ID: <E14o4Jh-0000I7-00@usw-sf-web1.sourceforge.net>

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

Category: Parser/Compiler
Group: None
Status: Open
Priority: 5
Submitted By: Paul Prescod (prescod)
Assigned to: Jeremy Hylton (jhylton)
Summary: Compiler generates relative filenames

Initial Comment:
Make a file called "test.py"
----
import pack

print pack.func.func_code.co_filename
-----

Make a directory called "pack". Put a file in it 
called "__init__.py" with the contents:

def func(): pass

Now run test.py. It will compile a relative path into 
these modules. Now you can change to any directory on 
the system and run test.py and it will return the 
original relative path. The problem is that the 
relative path is compiled into the .pyc. It should be 
an absolute path.

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

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-04-13 07:12

Message:
Logged In: YES 
user_id=31392

I'm not clear on what the rules for co_filename are, but it
looks like the absolute path is only used for package
imports.  If you cd into the package directory, run python
-c "import __init__", and then later import the package the
path name is relative.

The compiler package isn't connected to the import
mechanism, so there's no way for it to know whether it is
compiling a module or a package.  I don't think there's a
way to do anything better.


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

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


From noreply@sourceforge.net  Fri Apr 13 15:31:29 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 13 Apr 2001 07:31:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-412436 ] compileall doesn't notice syntax errors
Message-ID: <E14o4bh-00059R-00@usw-sf-web3.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: Guido van Rossum (gvanrossum)
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.


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

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-04-13 07:31

Message:
Logged In: YES 
user_id=31392

I think this is easy enough to fix, but I don't know what
unintended side-effects the fix will have.

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

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


From noreply@sourceforge.net  Fri Apr 13 15:32:03 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 13 Apr 2001 07:32:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-228688 ] Tools/compiler can't compile Lib/*.py
Message-ID: <E14o4cF-00059v-00@usw-sf-web3.sourceforge.net>

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

Category: demos and tools
Group: None
>Status: Closed
Priority: 5
Submitted By: Neil Schemenauer (nascheme)
Assigned to: Jeremy Hylton (jhylton)
Summary: Tools/compiler can't compile Lib/*.py

Initial Comment:
Subject says it all.


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

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-04-13 07:32

Message:
Logged In: YES 
user_id=31392

It works now.


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

Comment By: Neil Schemenauer (nascheme)
Date: 2001-01-13 12:34

Message:
This (incorrect?) patch to transformer.py seems to help:

-    def com_NEWLINE(self):
+    def com_NEWLINE(self, nodelist):

but the resulting bytecode kills the interpreter:

(gdb) run Lib/test/regrtest.py
Starting program: /home/nas/Python/py/python Lib/test/regrtest.py
test_grammar
test_opcodes
test_operations
test_builtin
test_exceptions
test_types
test_MimeWriter
test_StringIO

Program received signal SIGSEGV, Segmentation fault.
0x805b8d3 in eval_code2 (co=0x8255f08, globals=0x8258e44, locals=0x0, 
    args=0x81ffd64, argcount=1, kws=0x81ffd68, kwcount=0, defs=0x0, defcount=0)
    at ceval.c:2079
2079                    Py_XDECREF(v);
(gdb) l
2074            
2075            /* Pop remaining stack entries */
2076            
2077            while (!EMPTY()) {
2078                    v = POP();
2079                    Py_XDECREF(v);
2080            }
2081            
2082            if (why != WHY_RETURN)
2083                    retval = NULL;
(gdb) p *v
Cannot access memory at address 0x22.


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

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


From noreply@sourceforge.net  Fri Apr 13 15:37:16 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 13 Apr 2001 07:37:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-230006 ] /test/tokenize_tests_.py minor bug
Message-ID: <E14o4hI-0005EB-00@usw-sf-web3.sourceforge.net>

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

Category: None
Group: None
>Status: Closed
Priority: 4
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Jeremy Hylton (jhylton)
Summary: /test/tokenize_tests_.py minor bug

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


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

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-04-13 07:37

Message:
Logged In: YES 
user_id=31392

Fix by rev 1.3 of tokenize_tests.py


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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-02-03 09:40

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

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

The message does NOT cause the install to abort.


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

Comment By: Jeremy Hylton (jhylton)
Date: 2001-01-31 12:19

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


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

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


From noreply@sourceforge.net  Fri Apr 13 15:59:27 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 13 Apr 2001 07:59:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-405427 ] SQL2000+XML returns "400.100" status
Message-ID: <E14o52l-0005Vg-00@usw-sf-web3.sourceforge.net>

Bugs item #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: Closed
Priority: 4
Submitted By: Luke Kenneth Casson Leighton (lkcl)
Assigned to: Jeremy Hylton (jhylton)
>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: Jeremy Hylton (jhylton)
Date: 2001-04-13 07:59

Message:
Logged In: YES 
user_id=31392

Martin's patch looks good.  I checked in with minor change.


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

Comment By: Luke Kenneth Casson Leighton (lkcl)
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 (loewis)
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 (loewis)
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. (fdrake)
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 (lkcl)
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. (fdrake)
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 (loewis)
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 noreply@sourceforge.net  Fri Apr 13 15:59:50 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 13 Apr 2001 07:59:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-224629 ] urllib2.CustomProxyHandler has invalid code sequence
Message-ID: <E14o538-0005Vu-00@usw-sf-web3.sourceforge.net>

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

Category: Python Library
Group: None
>Status: Closed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Jeremy Hylton (jhylton)
Summary: urllib2.CustomProxyHandler has invalid code sequence

Initial Comment:
The method "do_proxy" is defined:

    def do_proxy(self, p, req):
        p
        return self.parent.open(req)

Where the line "p" should probably be "p()".


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

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-04-13 07:59

Message:
Logged In: YES 
user_id=31392

This was fixed a while ago.


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

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


From noreply@sourceforge.net  Fri Apr 13 16:02:47 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 13 Apr 2001 08:02:47 -0700
Subject: [Python-bugs-list] [ python-Bugs-408767 ] pydoc-file url
Message-ID: <E14o55z-0005YB-00@usw-sf-web3.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: Closed
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

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

>Comment By: Ka-Ping Yee (ping)
Date: 2001-04-13 08:02

Message:
Logged In: YES 
user_id=45338

This is fixed by using nturl2path on Windows.

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

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


From noreply@sourceforge.net  Fri Apr 13 16:46:21 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 13 Apr 2001 08:46:21 -0700
Subject: [Python-bugs-list] [ python-Bugs-412271 ] licence/license confusion
Message-ID: <E14o5m9-0005EO-00@usw-sf-web2.sourceforge.net>

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

Category: Distutils
Group: None
Status: Open
Priority: 7
Submitted By: A.M. Kuchling (akuchling)
Assigned to: A.M. Kuchling (akuchling)
Summary: licence/license confusion

Initial Comment:
Thomas Heller points out:

Playing with the new meta info, I noticed that the
license specified in this way:
 
setup(..., license="MIT/X11", ...)
 
isn't recognized, while it works if one uses:
 
setup(..., licence="MIT/X11", ...)

BTW; according to www.opensource.org the MIT license
seems to be spelled MIT license nowadays, no longer
MIT/X11 license.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-13 08:46

Message:
Logged In: YES 
user_id=6380

andrew, were you going to fix this before 2.1?


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

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


From noreply@sourceforge.net  Fri Apr 13 18:20:17 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 13 Apr 2001 10:20:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-415660 ] Weak references cause illegal memory ref
Message-ID: <E14o7F3-0006Ry-00@usw-sf-web2.sourceforge.net>

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

Category: Python Interpreter Core
Group: None
Status: Open
Priority: 7
Submitted By: Duncan Booth (duncanb)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Weak references cause illegal memory ref

Initial Comment:
Python 2.1b2 on Windows 2000
I was playing with weak references and found that the 
following script (test.py) caused the program to crash 
reliably with the error '''The instruction 
at "0x1e12b486" referenced memory at "0x00007479". the 
memory could not be "read".'''

Program test.py
---------------------------------
import weakref
from sys import getrefcount
from thread import get_ident

class C:
    def __del__(self):
        print "object deleted", `self`

def callback(object):
    print get_ident(),"callback for deletion",`object`
    print get_ident(),"ref is", `ref`, `ref()`
    print get_ident(),"ref1 is", `ref1`, `ref1()`
    print get_ident(),"end of callback"

c = C()
ref = weakref.ref(c, callback)
ref1 = weakref.ref(c, callback)
print get_ident(),"c is",`c`
print get_ident(),"ref is", `ref`, `ref()`
print get_ident(),"ref1 is", `ref1`, `ref1()`
del c
print get_ident(),"c was deleted"
print get_ident(),"ref is", `ref`, `ref()`
print get_ident(),"ref1 is", `ref1`, `ref1()`
print get_ident(),"Done"
---------------------------------

The output from the program is as follows. Something 
strange seems to be happening as both callbacks seem 
to be active at the same time on the same thread(?), 
and at least one newline has gone missing (in case 
this gets wrapped: every print begins with 1332, and 
the second 'callback for deletion' print is not at the 
start of a line).
---------------------------------
D:\temp>\python21\python test.py
1332 c is <__main__.C instance at 007DDD0C>
1332 ref is <weakref at 0x798f8c; to 'instance' at 
0x7ddd0c> <__main__.C instance at 007DDD0C>
1332 ref1 is <weakref at 0x7d9f7c; to 'instance' at 
0x7ddd0c> <__main__.C instance at 007DDD0C>
1332 callback for deletion <weakref at 7d9f7c; dead>
1332 ref is <weakref at 0x798f8c; to 'instance' at 
0x7ddd0c> 1332 callback for deletion <weakref at 
798f8c; dead>
1332 ref is <weakref at 798f8c; dead> None
1332 ref1 is <weakref at 7d9f7c; dead> None
1332 end of callback
object deleted <__main__.C instance at 007DDD0C>
<__main__.C instance at 007DDD0C>
1332 ref1 is <weakref at 7d9f7c; dead> None
1332 end of callback

D:\temp>
---------------------------------



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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-04-13 10:20

Message:
Logged In: YES 
user_id=3066

Fixed in Modules/_weakref.c revision 1.10.

The problem is that not all references to an object were invalidated before callbacks were invoked.

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

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

Message:
Logged In: YES 
user_id=31435

Boosted priority, assigned to Fred.

The thread stuff is a distraction (throw out all the 
get_ident() stuff & it still blows up).

Problem goes away if the "print ... ref()" call in the 
callback is commented out.  Note that this is doing ref() 
within ref's own "I'm dead" callback, so it's at best odd 
code.  Here's a shorter case that blows up (and designed to 
survive SourceForge's whitespace lossage intact):

import weakref
def callback(object): print "in callback", repr(ref())
class C: pass
c = C()
ref = weakref.ref(c, callback)
ref1 = weakref.ref(c, callback)
del c

Does not blow up if "ref1 =" is commented out, or if repr() 
is not invoked in the callback.  As is, it prints

in callback in callback None
<__main__.C instance at 0079606C>

and then blows up.  In a debug build, a call to 
PyObject_ClearWeakRefs is "up the call stack", at the start 
of instance_dealloc.  The former is a pointer to function 
cleanup_helper at this time.  cleanup_helper is executing 
PyObject_CallFunction(callback, "O", current).  The 
callback is apparently done at the time of the blowup, and 
ceval.c's do_call is executing Py_XDECREF(callargs).  The 
first tuple item is being deallocated, when Py_XDECREF(op-
>ob_item[i]) calls _Py_Dealloc calls _Py_ForgetReference, 
and that's where it finally blows up, and because the op 
passed in already has op->ob_next == op->ob_prev == NULL.


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

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


From noreply@sourceforge.net  Fri Apr 13 18:21:02 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 13 Apr 2001 10:21:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-415660 ] Weak references cause illegal memory ref
Message-ID: <E14o7Fm-0006Sh-00@usw-sf-web2.sourceforge.net>

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

Category: Python Interpreter Core
Group: None
>Status: Closed
Priority: 7
Submitted By: Duncan Booth (duncanb)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Weak references cause illegal memory ref

Initial Comment:
Python 2.1b2 on Windows 2000
I was playing with weak references and found that the 
following script (test.py) caused the program to crash 
reliably with the error '''The instruction 
at "0x1e12b486" referenced memory at "0x00007479". the 
memory could not be "read".'''

Program test.py
---------------------------------
import weakref
from sys import getrefcount
from thread import get_ident

class C:
    def __del__(self):
        print "object deleted", `self`

def callback(object):
    print get_ident(),"callback for deletion",`object`
    print get_ident(),"ref is", `ref`, `ref()`
    print get_ident(),"ref1 is", `ref1`, `ref1()`
    print get_ident(),"end of callback"

c = C()
ref = weakref.ref(c, callback)
ref1 = weakref.ref(c, callback)
print get_ident(),"c is",`c`
print get_ident(),"ref is", `ref`, `ref()`
print get_ident(),"ref1 is", `ref1`, `ref1()`
del c
print get_ident(),"c was deleted"
print get_ident(),"ref is", `ref`, `ref()`
print get_ident(),"ref1 is", `ref1`, `ref1()`
print get_ident(),"Done"
---------------------------------

The output from the program is as follows. Something 
strange seems to be happening as both callbacks seem 
to be active at the same time on the same thread(?), 
and at least one newline has gone missing (in case 
this gets wrapped: every print begins with 1332, and 
the second 'callback for deletion' print is not at the 
start of a line).
---------------------------------
D:\temp>\python21\python test.py
1332 c is <__main__.C instance at 007DDD0C>
1332 ref is <weakref at 0x798f8c; to 'instance' at 
0x7ddd0c> <__main__.C instance at 007DDD0C>
1332 ref1 is <weakref at 0x7d9f7c; to 'instance' at 
0x7ddd0c> <__main__.C instance at 007DDD0C>
1332 callback for deletion <weakref at 7d9f7c; dead>
1332 ref is <weakref at 0x798f8c; to 'instance' at 
0x7ddd0c> 1332 callback for deletion <weakref at 
798f8c; dead>
1332 ref is <weakref at 798f8c; dead> None
1332 ref1 is <weakref at 7d9f7c; dead> None
1332 end of callback
object deleted <__main__.C instance at 007DDD0C>
<__main__.C instance at 007DDD0C>
1332 ref1 is <weakref at 7d9f7c; dead> None
1332 end of callback

D:\temp>
---------------------------------



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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-04-13 10:21

Message:
Logged In: YES 
user_id=3066

Ooops, actually have to mark this closed!

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-04-13 10:20

Message:
Logged In: YES 
user_id=3066

Fixed in Modules/_weakref.c revision 1.10.

The problem is that not all references to an object were invalidated before callbacks were invoked.

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

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

Message:
Logged In: YES 
user_id=31435

Boosted priority, assigned to Fred.

The thread stuff is a distraction (throw out all the 
get_ident() stuff & it still blows up).

Problem goes away if the "print ... ref()" call in the 
callback is commented out.  Note that this is doing ref() 
within ref's own "I'm dead" callback, so it's at best odd 
code.  Here's a shorter case that blows up (and designed to 
survive SourceForge's whitespace lossage intact):

import weakref
def callback(object): print "in callback", repr(ref())
class C: pass
c = C()
ref = weakref.ref(c, callback)
ref1 = weakref.ref(c, callback)
del c

Does not blow up if "ref1 =" is commented out, or if repr() 
is not invoked in the callback.  As is, it prints

in callback in callback None
<__main__.C instance at 0079606C>

and then blows up.  In a debug build, a call to 
PyObject_ClearWeakRefs is "up the call stack", at the start 
of instance_dealloc.  The former is a pointer to function 
cleanup_helper at this time.  cleanup_helper is executing 
PyObject_CallFunction(callback, "O", current).  The 
callback is apparently done at the time of the blowup, and 
ceval.c's do_call is executing Py_XDECREF(callargs).  The 
first tuple item is being deallocated, when Py_XDECREF(op-
>ob_item[i]) calls _Py_Dealloc calls _Py_ForgetReference, 
and that's where it finally blows up, and because the op 
passed in already has op->ob_next == op->ob_prev == NULL.


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

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


From noreply@sourceforge.net  Fri Apr 13 18:52:42 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 13 Apr 2001 10:52:42 -0700
Subject: [Python-bugs-list] [ python-Bugs-415492 ] Compiler generates relative filenames
Message-ID: <E14o7kQ-0003za-00@usw-sf-web1.sourceforge.net>

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

Category: Parser/Compiler
Group: None
Status: Open
Priority: 5
Submitted By: Paul Prescod (prescod)
>Assigned to: Paul Prescod (prescod)
Summary: Compiler generates relative filenames

Initial Comment:
Make a file called "test.py"
----
import pack

print pack.func.func_code.co_filename
-----

Make a directory called "pack". Put a file in it 
called "__init__.py" with the contents:

def func(): pass

Now run test.py. It will compile a relative path into 
these modules. Now you can change to any directory on 
the system and run test.py and it will return the 
original relative path. The problem is that the 
relative path is compiled into the .pyc. It should be 
an absolute path.

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

Comment By: Jeremy Hylton (jhylton)
Date: 2001-04-13 07:12

Message:
Logged In: YES 
user_id=31392

I'm not clear on what the rules for co_filename are, but it
looks like the absolute path is only used for package
imports.  If you cd into the package directory, run python
-c "import __init__", and then later import the package the
path name is relative.

The compiler package isn't connected to the import
mechanism, so there's no way for it to know whether it is
compiling a module or a package.  I don't think there's a
way to do anything better.


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

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


From noreply@sourceforge.net  Fri Apr 13 18:55:33 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 13 Apr 2001 10:55:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-415950 ] Problem with SSL and socketmodule
Message-ID: <E14o7nB-00042P-00@usw-sf-web1.sourceforge.net>

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

Category: Extension Modules
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem with SSL and socketmodule

Initial Comment:
Subject: [Python-Dev] Problem with SSL and socketmodule
on Debian Potato?
From: Neil Schemenauer <nas@python.ca>
To: python-dev@python.org
Cc: Moshe Zadka <moshez@zadka.site.co.il>
Date: Thu, 12 Apr 2001 14:39:37 -0700

Fresh CVS tree:

Python 2.1c1 (#2, Apr 12 2001, 17:23:20) 
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import socket
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File
"/scratch/nascheme/py_cvs/dist/src/Lib/socket.py", line
41, in ?
    from _socket import *
ImportError:
/scratch/nascheme/py_cvs/dist/src/linux/build/lib.linux-i686-2.1/_socket.so:
undefined symbol: RAND_status

socketmodule is linked thusly:

gcc -shared build/temp.linux-i686-2.1/socketmodule.o
-L/usr/local/lib -lssl -lcrypto -o
build/lib.linux-i686-2.1/_socket.so

The SSL package is:

    libssl09-dev 0.9.4-5

I've no time to dig into the details right now but I
should have
time tonight.  I will be gone on holiday tomorrow.

  Neil

_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev


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

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


From noreply@sourceforge.net  Fri Apr 13 21:56:15 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 13 Apr 2001 13:56:15 -0700
Subject: [Python-bugs-list] [ python-Bugs-415950 ] Problem with SSL and socketmodule
Message-ID: <E14oAc3-0000nC-00@usw-sf-web2.sourceforge.net>

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

Category: Extension Modules
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem with SSL and socketmodule

Initial Comment:
Subject: [Python-Dev] Problem with SSL and socketmodule
on Debian Potato?
From: Neil Schemenauer <nas@python.ca>
To: python-dev@python.org
Cc: Moshe Zadka <moshez@zadka.site.co.il>
Date: Thu, 12 Apr 2001 14:39:37 -0700

Fresh CVS tree:

Python 2.1c1 (#2, Apr 12 2001, 17:23:20) 
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import socket
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File
"/scratch/nascheme/py_cvs/dist/src/Lib/socket.py", line
41, in ?
    from _socket import *
ImportError:
/scratch/nascheme/py_cvs/dist/src/linux/build/lib.linux-i686-2.1/_socket.so:
undefined symbol: RAND_status

socketmodule is linked thusly:

gcc -shared build/temp.linux-i686-2.1/socketmodule.o
-L/usr/local/lib -lssl -lcrypto -o
build/lib.linux-i686-2.1/_socket.so

The SSL package is:

    libssl09-dev 0.9.4-5

I've no time to dig into the details right now but I
should have
time tonight.  I will be gone on holiday tomorrow.

  Neil

_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-13 13:56

Message:
Logged In: YES 
user_id=6380

I've checked in a tentative fix, provided by Martin von
Loewis.

I'm keeping this bug report open because Moshe thought that
Martin's fix was broken, but failed to give a better fix
that Martin could agree to.


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

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


From noreply@sourceforge.net  Fri Apr 13 21:57:51 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 13 Apr 2001 13:57:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-415612 ] readline ext fails w/ new v4.2
Message-ID: <E14oAdb-0001T5-00@usw-sf-web3.sourceforge.net>

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

Category: Extension Modules
Group: Platform-specific
Status: Open
>Priority: 2
Submitted By: Gordon Sadler (gbsadler)
Assigned to: Nobody/Anonymous (nobody)
Summary: readline ext fails w/ new v4.2

Initial Comment:
Top of my test.log from make test:


PYTHONPATH= ./python ./setup.py build
/home/gbsadler/cvs/python/dist/src/Modules/readline.c:34: 
conflicting types for `rl_read_init_file'
/usr/include/readline/readline.h:304: previous declaration of 
`rl_read_init_file'
/home/gbsadler/cvs/python/dist/src/Modules/readline.c:35: 
conflicting types for `rl_insert_text'
/usr/include/readline/readline.h:364: previous declaration of 
`rl_insert_text'
/home/gbsadler/cvs/python/dist/src/Modules/readline.c: In 
function `set_completer_delims':
/home/gbsadler/cvs/python/dist/src/Modules/readline.c:231: 
warning: passing arg 1 of `free' discards qualifiers from poi
nter target type
/home/gbsadler/cvs/python/dist/src/Modules/readline.c: In 
function `flex_complete':
/home/gbsadler/cvs/python/dist/src/Modules/readline.c:403: 
warning: implicit declaration of function `completion_matches
'
/home/gbsadler/cvs/python/dist/src/Modules/readline.c:403: 
warning: return makes pointer from integer without a cast


rl_read_init_file and rl_insert_text both now expect (const 
char*) as parameters.

These are your choices for completion_matches:

readline.h:extern char **rl_completion_matches __P((const char 
*, rl_compentry_func_t *));
readline.h:extern char **completion_matches __P((char *, 
rl_compentry_func_t *));

Here's the compile line from test.log:

building 'readline' extension
gcc -g -O2 -Wall -Wstrict-prototypes -fPIC -I. 
-I/home/gbsadler/cvs/python/dist/src/./Include 
-I/usr/local/include -IInc
lude/ -c 
/home/gbsadler/cvs/python/dist/src/Modules/readline.c -o 
build/temp.linux-i686-2.1/readline.o -g -O2 -Wall -Wst
rict-prototypes -I. -I./Include -DHAVE_CONFIG_H
WARNING: building of extension "readline" failed: command 'gcc' 
failed with exit status 1






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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-13 13:57

Message:
Logged In: YES 
user_id=6380

I've changed the readline module so that it always just
includes the readline.h and history.h header files; this
takes care of the errors with readline 4.2.

There are still a few warnings left; I can't get rid of
those without breaking the build for readline 3.x.

Leaving this issue open for now in case someone comes with a
bright idea on how to detect readline versions at compile
time.

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

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


From noreply@sourceforge.net  Fri Apr 13 22:15:31 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 13 Apr 2001 14:15:31 -0700
Subject: [Python-bugs-list] [ python-Bugs-415492 ] Compiler generates relative filenames
Message-ID: <E14oAuh-0001gM-00@usw-sf-web3.sourceforge.net>

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

Category: Parser/Compiler
Group: None
Status: Open
Priority: 5
Submitted By: Paul Prescod (prescod)
Assigned to: Paul Prescod (prescod)
Summary: Compiler generates relative filenames

Initial Comment:
Make a file called "test.py"
----
import pack

print pack.func.func_code.co_filename
-----

Make a directory called "pack". Put a file in it 
called "__init__.py" with the contents:

def func(): pass

Now run test.py. It will compile a relative path into 
these modules. Now you can change to any directory on 
the system and run test.py and it will return the 
original relative path. The problem is that the 
relative path is compiled into the .pyc. It should be 
an absolute path.

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

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-04-13 14:15

Message:
Logged In: YES 
user_id=31392

Just to clarify.  The compiler in question is the builtin
compiler.  It generates absolute path names unless the .py
file is in the current working directory.


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

Comment By: Jeremy Hylton (jhylton)
Date: 2001-04-13 07:12

Message:
Logged In: YES 
user_id=31392

I'm not clear on what the rules for co_filename are, but it
looks like the absolute path is only used for package
imports.  If you cd into the package directory, run python
-c "import __init__", and then later import the package the
path name is relative.

The compiler package isn't connected to the import
mechanism, so there's no way for it to know whether it is
compiling a module or a package.  I don't think there's a
way to do anything better.


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

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


From noreply@sourceforge.net  Fri Apr 13 22:16:27 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 13 Apr 2001 14:16:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-412436 ] compileall doesn't notice syntax errors
Message-ID: <E14oAvb-0001hK-00@usw-sf-web3.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: Jeremy Hylton (jhylton)
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.


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

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-04-13 14:16

Message:
Logged In: YES 
user_id=31392

Will fix following the 2.1 release


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

Comment By: Jeremy Hylton (jhylton)
Date: 2001-04-13 07:31

Message:
Logged In: YES 
user_id=31392

I think this is easy enough to fix, but I don't know what
unintended side-effects the fix will have.

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

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


From noreply@sourceforge.net  Fri Apr 13 23:21:42 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 13 Apr 2001 15:21:42 -0700
Subject: [Python-bugs-list] [ python-Bugs-416034 ] Confusing error message for top global
Message-ID: <E14oBwk-0001kv-00@usw-sf-web2.sourceforge.net>

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

Category: Parser/Compiler
Group: None
Status: Open
Priority: 7
Submitted By: Paul Prescod (prescod)
Assigned to: Jeremy Hylton (jhylton)
Summary: Confusing error message for top global

Initial Comment:
Call this test.py:

abc = 5
global abc
abc = 6

It is probably illegal to have a global at the top-
level but the error message prdocued is:

SyntaxWarning: name 'abc' is assigned to before global 
declaration

That's technically true but the real problm is that 
global statements should not be allowed outside of 
functions.


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

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


From noreply@sourceforge.net  Fri Apr 13 23:50:04 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 13 Apr 2001 15:50:04 -0700
Subject: [Python-bugs-list] [ python-Bugs-416034 ] Confusing error message for top global
Message-ID: <E14oCOC-0002n1-00@usw-sf-web3.sourceforge.net>

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

Category: Parser/Compiler
Group: None
>Status: Closed
Priority: 7
Submitted By: Paul Prescod (prescod)
Assigned to: Jeremy Hylton (jhylton)
Summary: Confusing error message for top global

Initial Comment:
Call this test.py:

abc = 5
global abc
abc = 6

It is probably illegal to have a global at the top-
level but the error message prdocued is:

SyntaxWarning: name 'abc' is assigned to before global 
declaration

That's technically true but the real problm is that 
global statements should not be allowed outside of 
functions.


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

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-04-13 15:50

Message:
Logged In: YES 
user_id=31392

Your complain isn't with the error message per se.  It is
correct.  You should not assign to a variable before the
global statement.

Your complaint is that you would *also* like to see a
warning or error about global statement at the top of a
module.  I would too, but... The compiled code might be
executed in a function body with exec, where the global
statement would be meaningful.

If you can think of a way to distinguish these two cases,
re-open the bug report.


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

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


From noreply@sourceforge.net  Fri Apr 13 23:55:17 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 13 Apr 2001 15:55:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-416039 ] pstats browser crashes
Message-ID: <E14oCTF-0002qb-00@usw-sf-web3.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Priority: 7
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Eric S. Raymond (esr)
Summary: pstats browser crashes

Initial Comment:
My very first attempt to use the pstats browser failed
immediately.

w221:~/src/python/dist/src/Tools/compiler> python2.1
../../Lib/pstats.py compiler/__init__.py.prof 
Welcome to the profile statistics browser.
% help

Documented commands (type help <topic>):
========================================
EOF             add             callees        
callers         quit           
read            reverse         sort           
stats           strip           

Undocumented commands:
======================
help            

% callers
Traceback (most recent call last):
  File "../../Lib/pstats.py", line 646, in ?
    ProfileBrowser(initprofile).cmdloop()
  File "../../Lib/cmd.py", line 86, in cmdloop
    stop = self.onecmd(line)
  File "../../Lib/cmd.py", line 124, in onecmd
    return func(arg)
  File "../../Lib/pstats.py", line 580, in do_callers
    return self.generic('callers', line)
  File "../../Lib/pstats.py", line 563, in generic
    apply(getattr(self.stats, fn), processed)
AttributeError: Stats instance has no attribute
'callers'

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

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


From noreply@sourceforge.net  Sat Apr 14 02:17:37 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 13 Apr 2001 18:17:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-415612 ] readline ext fails w/ new v4.2
Message-ID: <E14oEgz-0003fl-00@usw-sf-web2.sourceforge.net>

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

Category: Extension Modules
Group: Platform-specific
Status: Open
Priority: 2
Submitted By: Gordon Sadler (gbsadler)
Assigned to: Nobody/Anonymous (nobody)
Summary: readline ext fails w/ new v4.2

Initial Comment:
Top of my test.log from make test:


PYTHONPATH= ./python ./setup.py build
/home/gbsadler/cvs/python/dist/src/Modules/readline.c:34: 
conflicting types for `rl_read_init_file'
/usr/include/readline/readline.h:304: previous declaration of 
`rl_read_init_file'
/home/gbsadler/cvs/python/dist/src/Modules/readline.c:35: 
conflicting types for `rl_insert_text'
/usr/include/readline/readline.h:364: previous declaration of 
`rl_insert_text'
/home/gbsadler/cvs/python/dist/src/Modules/readline.c: In 
function `set_completer_delims':
/home/gbsadler/cvs/python/dist/src/Modules/readline.c:231: 
warning: passing arg 1 of `free' discards qualifiers from poi
nter target type
/home/gbsadler/cvs/python/dist/src/Modules/readline.c: In 
function `flex_complete':
/home/gbsadler/cvs/python/dist/src/Modules/readline.c:403: 
warning: implicit declaration of function `completion_matches
'
/home/gbsadler/cvs/python/dist/src/Modules/readline.c:403: 
warning: return makes pointer from integer without a cast


rl_read_init_file and rl_insert_text both now expect (const 
char*) as parameters.

These are your choices for completion_matches:

readline.h:extern char **rl_completion_matches __P((const char 
*, rl_compentry_func_t *));
readline.h:extern char **completion_matches __P((char *, 
rl_compentry_func_t *));

Here's the compile line from test.log:

building 'readline' extension
gcc -g -O2 -Wall -Wstrict-prototypes -fPIC -I. 
-I/home/gbsadler/cvs/python/dist/src/./Include 
-I/usr/local/include -IInc
lude/ -c 
/home/gbsadler/cvs/python/dist/src/Modules/readline.c -o 
build/temp.linux-i686-2.1/readline.o -g -O2 -Wall -Wst
rict-prototypes -I. -I./Include -DHAVE_CONFIG_H
WARNING: building of extension "readline" failed: command 'gcc' 
failed with exit status 1






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

>Comment By: Gordon Sadler (gbsadler)
Date: 2001-04-13 18:17

Message:
Logged In: YES 
user_id=150968

Have a feeling the file attachment didn't take. In case here it is.
#include <readline/readline.h>
#include <stdio.h>
 
int main ()
{
        printf ("version is %s \n",rl_library_version);
        return 0;
}

Real simple, but not sure what <4.2 will return/print.


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-13 13:57

Message:
Logged In: YES 
user_id=6380

I've changed the readline module so that it always just
includes the readline.h and history.h header files; this
takes care of the errors with readline 4.2.

There are still a few warnings left; I can't get rid of
those without breaking the build for readline 3.x.

Leaving this issue open for now in case someone comes with a
bright idea on how to detect readline versions at compile
time.

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

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


From noreply@sourceforge.net  Sat Apr 14 02:43:12 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 13 Apr 2001 18:43:12 -0700
Subject: [Python-bugs-list] [ python-Bugs-415612 ] readline ext fails w/ new v4.2
Message-ID: <E14oF5k-0004ZI-00@usw-sf-web3.sourceforge.net>

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

Category: Extension Modules
Group: Platform-specific
Status: Open
Priority: 2
Submitted By: Gordon Sadler (gbsadler)
Assigned to: Nobody/Anonymous (nobody)
Summary: readline ext fails w/ new v4.2

Initial Comment:
Top of my test.log from make test:


PYTHONPATH= ./python ./setup.py build
/home/gbsadler/cvs/python/dist/src/Modules/readline.c:34: 
conflicting types for `rl_read_init_file'
/usr/include/readline/readline.h:304: previous declaration of 
`rl_read_init_file'
/home/gbsadler/cvs/python/dist/src/Modules/readline.c:35: 
conflicting types for `rl_insert_text'
/usr/include/readline/readline.h:364: previous declaration of 
`rl_insert_text'
/home/gbsadler/cvs/python/dist/src/Modules/readline.c: In 
function `set_completer_delims':
/home/gbsadler/cvs/python/dist/src/Modules/readline.c:231: 
warning: passing arg 1 of `free' discards qualifiers from poi
nter target type
/home/gbsadler/cvs/python/dist/src/Modules/readline.c: In 
function `flex_complete':
/home/gbsadler/cvs/python/dist/src/Modules/readline.c:403: 
warning: implicit declaration of function `completion_matches
'
/home/gbsadler/cvs/python/dist/src/Modules/readline.c:403: 
warning: return makes pointer from integer without a cast


rl_read_init_file and rl_insert_text both now expect (const 
char*) as parameters.

These are your choices for completion_matches:

readline.h:extern char **rl_completion_matches __P((const char 
*, rl_compentry_func_t *));
readline.h:extern char **completion_matches __P((char *, 
rl_compentry_func_t *));

Here's the compile line from test.log:

building 'readline' extension
gcc -g -O2 -Wall -Wstrict-prototypes -fPIC -I. 
-I/home/gbsadler/cvs/python/dist/src/./Include 
-I/usr/local/include -IInc
lude/ -c 
/home/gbsadler/cvs/python/dist/src/Modules/readline.c -o 
build/temp.linux-i686-2.1/readline.o -g -O2 -Wall -Wst
rict-prototypes -I. -I./Include -DHAVE_CONFIG_H
WARNING: building of extension "readline" failed: command 'gcc' 
failed with exit status 1






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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-13 18:43

Message:
Logged In: YES 
user_id=6380

Really old versions of readline don'y have
rl_library_version, but most do (3.0 does).

Can you cook up a patch for the configure script to take
this into account?  I won't have time for this before
releasing 2.1 final, and I don't think it's a big enough
deal to worry about much.

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

Comment By: Gordon Sadler (gbsadler)
Date: 2001-04-13 18:17

Message:
Logged In: YES 
user_id=150968

Have a feeling the file attachment didn't take. In case here it is.
#include <readline/readline.h>
#include <stdio.h>
 
int main ()
{
        printf ("version is %s \n",rl_library_version);
        return 0;
}

Real simple, but not sure what <4.2 will return/print.


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-13 13:57

Message:
Logged In: YES 
user_id=6380

I've changed the readline module so that it always just
includes the readline.h and history.h header files; this
takes care of the errors with readline 4.2.

There are still a few warnings left; I can't get rid of
those without breaking the build for readline 3.x.

Leaving this issue open for now in case someone comes with a
bright idea on how to detect readline versions at compile
time.

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

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


From noreply@sourceforge.net  Sat Apr 14 10:39:52 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 14 Apr 2001 02:39:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-416089 ] import problem with 2.1c1
Message-ID: <E14oMX2-0000wp-00@usw-sf-web3.sourceforge.net>

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

Category: Python Interpreter Core
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: import problem with 2.1c1

Initial Comment:
I have built Python 2.1c1 under Linux and Irix
without the thread module.  When I import
threading an ImportError occurs as expected.
However, reissuing the import threading (not reloading)
statement does not raise an ImportError.  This causes a
failure in the regression tests with  the
following error message:

test test_threadedtempfile crashed --
exceptions.AttributeError: 'threading' module has no
attribute 'Event'

Here is a sample session from the interactive
interpreter.

>% ./python
Python 2.1c1 (#4, Apr 14 2001, 03:22:09) 
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)]
on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import threading
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/home/raj/python/dist/src/Lib/threading.py",
line 5, in ?
    import thread
ImportError: No module named thread
>>> import threading # No import error here
>>> 

and under IRIX

% ./python 
Python 2.1c1 (#3, Apr 13 2001, 21:38:25) [C] on irix646
Type "copyright", "credits" or "license" for more
information.
>>> import threading
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File                              
"/usr/people/raj/python/dist/src/Lib/threading.py",                             
line 5, in
?                                                   
    import
thread                                                   
ImportError: No module named thread                 
>>> import threading # Again no import error
here                               
>>>

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

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


From noreply@sourceforge.net  Sat Apr 14 21:18:27 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 14 Apr 2001 13:18:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-416181 ] 2.1c1 builds strangely on Solaris
Message-ID: <E14oWV1-0007PT-00@usw-sf-web2.sourceforge.net>

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

Category: Build
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: David M. Beazley (beazley)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.1c1 builds strangely on Solaris

Initial Comment:
Python 2.1c1 has problems with its build process on the
following
configuration:

     - Solaris 2.8 SPARC
     - gcc-2.95-2 compilers *AND* Sun Workshop 5.0
compilers
        installed.

Although the interpreter builds without problems, the
process of building various extension modules fails
under gcc, but works under the Sun compilers.  (for
example, I get tons of unresolved symbols in curses,
ncurses, etc. with gcc).

This appears to be a problem related to linker/compiler
options with gcc, but I don't see anything obvious
offhand.   I will post a followup if I am able to make
a fix.








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

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


From noreply@sourceforge.net  Sat Apr 14 21:19:41 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 14 Apr 2001 13:19:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-416089 ] import problem with 2.1c1
Message-ID: <E14oWWD-0007mc-00@usw-sf-web3.sourceforge.net>

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

>Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: import problem with 2.1c1

Initial Comment:
I have built Python 2.1c1 under Linux and Irix
without the thread module.  When I import
threading an ImportError occurs as expected.
However, reissuing the import threading (not reloading)
statement does not raise an ImportError.  This causes a
failure in the regression tests with  the
following error message:

test test_threadedtempfile crashed --
exceptions.AttributeError: 'threading' module has no
attribute 'Event'

Here is a sample session from the interactive
interpreter.

>% ./python
Python 2.1c1 (#4, Apr 14 2001, 03:22:09) 
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)]
on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import threading
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/home/raj/python/dist/src/Lib/threading.py",
line 5, in ?
    import thread
ImportError: No module named thread
>>> import threading # No import error here
>>> 

and under IRIX

% ./python 
Python 2.1c1 (#3, Apr 13 2001, 21:38:25) [C] on irix646
Type "copyright", "credits" or "license" for more
information.
>>> import threading
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File                              
"/usr/people/raj/python/dist/src/Lib/threading.py",                             
line 5, in
?                                                   
    import
thread                                                   
ImportError: No module named thread                 
>>> import threading # Again no import error
here                               
>>>

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

>Comment By: Tim Peters (tim_one)
Date: 2001-04-14 13:19

Message:
Logged In: YES 
user_id=31435

Assigned to Guido, because I suspect he just fixed this in 
the CVS tree.

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

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


From noreply@sourceforge.net  Sat Apr 14 22:11:25 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 14 Apr 2001 14:11:25 -0700
Subject: [Python-bugs-list] [ python-Bugs-416187 ] API problem causes unicode memory leak
Message-ID: <E14oXKH-00028i-00@usw-sf-web1.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: douglas orr (dougbo)
Assigned to: Nobody/Anonymous (nobody)
Summary: API problem causes unicode memory leak

Initial Comment:
The API PyString_ASString returns a pointer to a char 
* representation of its argument.  

PyString_ASStringAndSize tries to convert it to the 
default encoding.  In the process it makes a new 
string object holding the newly encoded buffer, it 
returns a pointer to the buffer (bad idea) and leaks 
the new object and the buffer -- which is the only 
choice since there is no control on how long the 
pointer to the buffer needs to be valid.

It should probably throw an error if you give it a 
unicode string and force you to convert it explicitly, 
before calling the API.

I encountered this problem trying to use XML data.


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

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


From noreply@sourceforge.net  Sun Apr 15 00:30:44 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 14 Apr 2001 16:30:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-416199 ] mailbox.py seek problems
Message-ID: <E14oZV6-00013O-00@usw-sf-web2.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Andrew Dalke (dalke)
Assigned to: Nobody/Anonymous (nobody)
Summary: mailbox.py seek problems

Initial Comment:
Here's some bugs I see in mailbox.py

>>> import mailbox, os
>>> mb = mailbox.UnixMailbox(open(os.environ["MAIL"]))
>>> mb.seek(0)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/home/dalke/local/lib/python2.0/mailbox.py", 
line 20, in seek
    self.pos = self.start + pos
AttributeError: UnixMailbox instance has no 
attribute 'start'
>>> mb.seek(0, whence = 2)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/home/dalke/local/lib/python2.0/mailbox.py", 
line 18, in seek
    self.pos = self.stop + pos
AttributeError: UnixMailbox instance has no 
attribute 'stop'
>>>

Looking at the seek code for mailbox._Mailbox:

    def seek(self, pos, whence=0):
        if whence==1:           # Relative to current 
position
            self.pos = self.pos + pos
        if whence==2:           # Relative to file's 
end
            self.pos = self.stop + pos
        else:                   # Default - absolute 
position
            self.pos = self.start + pos

The values for "self.start" and "self.stop" are never 
defined.  Instead, it appears mailbox._Mailbox.seek 
was copied from mailbox._Subfile.seek without making 
the needed changes.

I also think there needs to be a tell() method
on the _Mailbox if there's a seek() method.  I
needed in since I was trying to index my mailbox.



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

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


From noreply@sourceforge.net  Sun Apr 15 00:54:08 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 14 Apr 2001 16:54:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-416089 ] import problem with 2.1c1
Message-ID: <E14oZrk-0004Pz-00@usw-sf-web1.sourceforge.net>

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

Category: Python Library
Group: None
>Status: Closed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Guido van Rossum (gvanrossum)
Summary: import problem with 2.1c1

Initial Comment:
I have built Python 2.1c1 under Linux and Irix
without the thread module.  When I import
threading an ImportError occurs as expected.
However, reissuing the import threading (not reloading)
statement does not raise an ImportError.  This causes a
failure in the regression tests with  the
following error message:

test test_threadedtempfile crashed --
exceptions.AttributeError: 'threading' module has no
attribute 'Event'

Here is a sample session from the interactive
interpreter.

>% ./python
Python 2.1c1 (#4, Apr 14 2001, 03:22:09) 
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)]
on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import threading
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/home/raj/python/dist/src/Lib/threading.py",
line 5, in ?
    import thread
ImportError: No module named thread
>>> import threading # No import error here
>>> 

and under IRIX

% ./python 
Python 2.1c1 (#3, Apr 13 2001, 21:38:25) [C] on irix646
Type "copyright", "credits" or "license" for more
information.
>>> import threading
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File                              
"/usr/people/raj/python/dist/src/Lib/threading.py",                             
line 5, in
?                                                   
    import
thread                                                   
ImportError: No module named thread                 
>>> import threading # Again no import error
here                               
>>>

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-14 16:54

Message:
Logged In: YES 
user_id=6380

I fixed the specific issue with the test suite.

The more general issue can't be fixed.  The first time you
import threading it fails, not on the import of threading
itself (which is always around), but on the import of thread
(which is a built-in module that's only there when you
enable threading).  The second time you import threading,
you get a stub of the threading module (initialized up to
the point where threading.py tried to import thread). 
Unfortunately there are good and deep reasons why the
threading module can't just be deleted after its
initialization failed.  (One being that you might want to
debug the situation.)

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

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

Message:
Logged In: YES 
user_id=31435

Assigned to Guido, because I suspect he just fixed this in 
the CVS tree.

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

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


From noreply@sourceforge.net  Sun Apr 15 03:58:50 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 14 Apr 2001 19:58:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-416199 ] mailbox.py seek problems
Message-ID: <E14ockU-0006uI-00@usw-sf-web1.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
>Priority: 7
Submitted By: Andrew Dalke (dalke)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: mailbox.py seek problems

Initial Comment:
Here's some bugs I see in mailbox.py

>>> import mailbox, os
>>> mb = mailbox.UnixMailbox(open(os.environ["MAIL"]))
>>> mb.seek(0)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/home/dalke/local/lib/python2.0/mailbox.py", 
line 20, in seek
    self.pos = self.start + pos
AttributeError: UnixMailbox instance has no 
attribute 'start'
>>> mb.seek(0, whence = 2)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/home/dalke/local/lib/python2.0/mailbox.py", 
line 18, in seek
    self.pos = self.stop + pos
AttributeError: UnixMailbox instance has no 
attribute 'stop'
>>>

Looking at the seek code for mailbox._Mailbox:

    def seek(self, pos, whence=0):
        if whence==1:           # Relative to current 
position
            self.pos = self.pos + pos
        if whence==2:           # Relative to file's 
end
            self.pos = self.stop + pos
        else:                   # Default - absolute 
position
            self.pos = self.start + pos

The values for "self.start" and "self.stop" are never 
defined.  Instead, it appears mailbox._Mailbox.seek 
was copied from mailbox._Subfile.seek without making 
the needed changes.

I also think there needs to be a tell() method
on the _Mailbox if there's a seek() method.  I
needed in since I was trying to index my mailbox.



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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-14 19:58

Message:
Logged In: YES 
user_id=6380

Sigh.  This module has been riddled with bugs ever since it
was created, it seems.  I'll fix this before releasing
2.1final!

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

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


From noreply@sourceforge.net  Sun Apr 15 04:05:07 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 14 Apr 2001 20:05:07 -0700
Subject: [Python-bugs-list] [ python-Bugs-416187 ] API problem causes unicode memory leak
Message-ID: <E14ocqZ-0003Vy-00@usw-sf-web3.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
>Priority: 9
Submitted By: douglas orr (dougbo)
Assigned to: Nobody/Anonymous (nobody)
Summary: API problem causes unicode memory leak

Initial Comment:
The API PyString_ASString returns a pointer to a char 
* representation of its argument.  

PyString_ASStringAndSize tries to convert it to the 
default encoding.  In the process it makes a new 
string object holding the newly encoded buffer, it 
returns a pointer to the buffer (bad idea) and leaks 
the new object and the buffer -- which is the only 
choice since there is no control on how long the 
pointer to the buffer needs to be valid.

It should probably throw an error if you give it a 
unicode string and force you to convert it explicitly, 
before calling the API.

I encountered this problem trying to use XML data.


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-14 20:05

Message:
Logged In: YES 
user_id=6380

Shit!  You're right.  What now?  if I change it to throw an
error, how do I know it won't break some code that depends
on this???

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

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


From noreply@sourceforge.net  Sun Apr 15 04:07:14 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 14 Apr 2001 20:07:14 -0700
Subject: [Python-bugs-list] [ python-Bugs-416181 ] 2.1c1 builds strangely on Solaris
Message-ID: <E14ocsc-00072N-00@usw-sf-web1.sourceforge.net>

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

Category: Build
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: David M. Beazley (beazley)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.1c1 builds strangely on Solaris

Initial Comment:
Python 2.1c1 has problems with its build process on the
following
configuration:

     - Solaris 2.8 SPARC
     - gcc-2.95-2 compilers *AND* Sun Workshop 5.0
compilers
        installed.

Although the interpreter builds without problems, the
process of building various extension modules fails
under gcc, but works under the Sun compilers.  (for
example, I get tons of unresolved symbols in curses,
ncurses, etc. with gcc).

This appears to be a problem related to linker/compiler
options with gcc, but I don't see anything obvious
offhand.   I will post a followup if I am able to make
a fix.








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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-14 20:07

Message:
Logged In: YES 
user_id=6380

David, can you try adding #define _XOPEN_SOURCE_EXTENDED to
the _cursesmodule.c source file?

That worked for the same system on Compaq Tru64.

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

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


From noreply@sourceforge.net  Sun Apr 15 04:24:51 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 14 Apr 2001 20:24:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-416187 ] API problem causes unicode memory leak
Message-ID: <E14od9f-0003Rz-00@usw-sf-web2.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
>Priority: 5
Submitted By: douglas orr (dougbo)
Assigned to: Nobody/Anonymous (nobody)
Summary: API problem causes unicode memory leak

Initial Comment:
The API PyString_ASString returns a pointer to a char 
* representation of its argument.  

PyString_ASStringAndSize tries to convert it to the 
default encoding.  In the process it makes a new 
string object holding the newly encoded buffer, it 
returns a pointer to the buffer (bad idea) and leaks 
the new object and the buffer -- which is the only 
choice since there is no control on how long the 
pointer to the buffer needs to be valid.

It should probably throw an error if you give it a 
unicode string and force you to convert it explicitly, 
before calling the API.

I encountered this problem trying to use XML data.


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-14 20:24

Message:
Logged In: YES 
user_id=6380

Wait a second.  Looking at the comments for
_PyUnicode_AsDefaultEncodedString(), it is supposed to cache
the 8-bit string as part of the Unicode object, hence it is
not strictly speaking leaking (although it may cause the
encoded string to hang around longer than strictly
necessary).

Are you sure that you are experiencing a memory leak?  If
so, please submit a program that shows this!

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-14 20:05

Message:
Logged In: YES 
user_id=6380

Shit!  You're right.  What now?  if I change it to throw an
error, how do I know it won't break some code that depends
on this???

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

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


From noreply@sourceforge.net  Sun Apr 15 04:25:03 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 14 Apr 2001 20:25:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-416187 ] API problem causes unicode memory leak
Message-ID: <E14od9r-0003Ss-00@usw-sf-web2.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: douglas orr (dougbo)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: API problem causes unicode memory leak

Initial Comment:
The API PyString_ASString returns a pointer to a char 
* representation of its argument.  

PyString_ASStringAndSize tries to convert it to the 
default encoding.  In the process it makes a new 
string object holding the newly encoded buffer, it 
returns a pointer to the buffer (bad idea) and leaks 
the new object and the buffer -- which is the only 
choice since there is no control on how long the 
pointer to the buffer needs to be valid.

It should probably throw an error if you give it a 
unicode string and force you to convert it explicitly, 
before calling the API.

I encountered this problem trying to use XML data.


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-14 20:24

Message:
Logged In: YES 
user_id=6380

Wait a second.  Looking at the comments for
_PyUnicode_AsDefaultEncodedString(), it is supposed to cache
the 8-bit string as part of the Unicode object, hence it is
not strictly speaking leaking (although it may cause the
encoded string to hang around longer than strictly
necessary).

Are you sure that you are experiencing a memory leak?  If
so, please submit a program that shows this!

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-14 20:05

Message:
Logged In: YES 
user_id=6380

Shit!  You're right.  What now?  if I change it to throw an
error, how do I know it won't break some code that depends
on this???

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

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


From noreply@sourceforge.net  Sun Apr 15 04:30:17 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 14 Apr 2001 20:30:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-232460 ] SSL Support (Apparently) Broken on Solaris
Message-ID: <E14odEv-0003WE-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: 2
Submitted By: David M. Beazley (beazley)
Assigned to: Nobody/Anonymous (nobody)
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: Guido van Rossum (gvanrossum)
Date: 2001-04-14 20:30

Message:
Logged In: YES 
user_id=6380

David, is this still broken?

On the SourceForge compile farm I can use SSL just fine.

Check out my directory
/home/users/gvanrossum/Python-2.1-solaris on
cf.sourceforge.net.


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 11:55

Message:
Logged In: YES 
user_id=6380

So, David, you still interested in this?

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

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  Sun Apr 15 05:45:42 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 14 Apr 2001 21:45:42 -0700
Subject: [Python-bugs-list] [ python-Bugs-416225 ] os.environ.has_key fails with lower case
Message-ID: <E14oePu-0008LM-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.environ.has_key fails with lower case

Initial Comment:
This looks a bit like #210690. When setting an environ 
variable for a child process on windows has_key will 
let me down if the environ key is lower case
(on win NT and Windows 2k) python 1.5.2.

Let me show an example:
C:\>python
Python 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit 
(Intel)] on win32
Copyright 1991-1995 Stichting Mathematisch Centrum, 
Amsterdam
>>> import os
>>> os.environ['BLAH'] = "blah blah blah"
>>> os.environ['blah1'] = "blah blah blah"
>>> os.environ['BLAH']
'blah blah blah'
>>> os.environ['blah1']
'blah blah blah'
>>> os.environ.has_key("BLAH")
1
>>> os.environ.has_key("blah1")
0
>>>



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

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


From noreply@sourceforge.net  Sun Apr 15 07:28:40 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 14 Apr 2001 23:28:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-416231 ] urllib.basejoin fails to apply some ../
Message-ID: <E14og1Y-0001Hh-00@usw-sf-web1.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Juan M. Bello Rivas (rwxrwxrwx)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib.basejoin fails to apply some ../

Initial Comment:
When performing a urllib.basejoin('http://localhost/',
'../test.html') the function will join it as
http://localhosttest.html.

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

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


From noreply@sourceforge.net  Sun Apr 15 13:32:07 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 15 Apr 2001 05:32:07 -0700
Subject: [Python-bugs-list] [ python-Bugs-416187 ] API problem causes unicode memory leak
Message-ID: <E14olhH-0000fC-00@usw-sf-web2.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: douglas orr (dougbo)
Assigned to: Guido van Rossum (gvanrossum)
Summary: API problem causes unicode memory leak

Initial Comment:
The API PyString_ASString returns a pointer to a char 
* representation of its argument.  

PyString_ASStringAndSize tries to convert it to the 
default encoding.  In the process it makes a new 
string object holding the newly encoded buffer, it 
returns a pointer to the buffer (bad idea) and leaks 
the new object and the buffer -- which is the only 
choice since there is no control on how long the 
pointer to the buffer needs to be valid.

It should probably throw an error if you give it a 
unicode string and force you to convert it explicitly, 
before calling the API.

I encountered this problem trying to use XML data.


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

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

Message:
Logged In: YES 
user_id=38388

This is not a memory leak; it is the intended behaviour and
is
needed not only by PyString_AsString...() but also by the
"s" and
"s#" parser markers.

The Unicode object has an extra buffer which needs to be
there
for just this reason. The buffer is string object which is
created
in a lazy way whenever Python needs to convert that Unicode
object to an 8-bit string using the default encoding and is
then
kept alive until the Unicode object goes away. In that
sense, the
Unicode object shows the same behaviour as a normal string
object
would.

I know that having this extra buffer is a bad idea, but it
was
the only way to integrate string and Unicode objects in a
very seemless way.

Why do think this is a memory leak ?

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-14 20:24

Message:
Logged In: YES 
user_id=6380

Wait a second.  Looking at the comments for
_PyUnicode_AsDefaultEncodedString(), it is supposed to cache
the 8-bit string as part of the Unicode object, hence it is
not strictly speaking leaking (although it may cause the
encoded string to hang around longer than strictly
necessary).

Are you sure that you are experiencing a memory leak?  If
so, please submit a program that shows this!

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-14 20:05

Message:
Logged In: YES 
user_id=6380

Shit!  You're right.  What now?  if I change it to throw an
error, how do I know it won't break some code that depends
on this???

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

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


From noreply@sourceforge.net  Sun Apr 15 14:33:14 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 15 Apr 2001 06:33:14 -0700
Subject: [Python-bugs-list] [ python-Bugs-416199 ] mailbox.py seek problems
Message-ID: <E14omeQ-0001G5-00@usw-sf-web3.sourceforge.net>

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

Category: Python Library
Group: None
>Status: Closed
Priority: 7
Submitted By: Andrew Dalke (dalke)
Assigned to: Guido van Rossum (gvanrossum)
Summary: mailbox.py seek problems

Initial Comment:
Here's some bugs I see in mailbox.py

>>> import mailbox, os
>>> mb = mailbox.UnixMailbox(open(os.environ["MAIL"]))
>>> mb.seek(0)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/home/dalke/local/lib/python2.0/mailbox.py", 
line 20, in seek
    self.pos = self.start + pos
AttributeError: UnixMailbox instance has no 
attribute 'start'
>>> mb.seek(0, whence = 2)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/home/dalke/local/lib/python2.0/mailbox.py", 
line 18, in seek
    self.pos = self.stop + pos
AttributeError: UnixMailbox instance has no 
attribute 'stop'
>>>

Looking at the seek code for mailbox._Mailbox:

    def seek(self, pos, whence=0):
        if whence==1:           # Relative to current 
position
            self.pos = self.pos + pos
        if whence==2:           # Relative to file's 
end
            self.pos = self.stop + pos
        else:                   # Default - absolute 
position
            self.pos = self.start + pos

The values for "self.start" and "self.stop" are never 
defined.  Instead, it appears mailbox._Mailbox.seek 
was copied from mailbox._Subfile.seek without making 
the needed changes.

I also think there needs to be a tell() method
on the _Mailbox if there's a seek() method.  I
needed in since I was trying to index my mailbox.



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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-15 06:33

Message:
Logged In: YES 
user_id=6380

Hm.  The seek() method was never documented and never 
worked!  I'm getting rid of it.  If you want to do random 
access on your mailbox file, you'll have to subclass it and 
use self.fp directly.  Maybe someday we'll support seek() 
and tell(), but not in 2.1.  (Seek was never documented.)

Closing this bug report now.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-14 19:58

Message:
Logged In: YES 
user_id=6380

Sigh.  This module has been riddled with bugs ever since it
was created, it seems.  I'll fix this before releasing
2.1final!

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

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


From noreply@sourceforge.net  Sun Apr 15 16:59:39 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 15 Apr 2001 08:59:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-416187 ] API problem causes unicode memory leak
Message-ID: <E14oow7-0003p9-00@usw-sf-web3.sourceforge.net>

Bugs item #416187, was updated on 2001-04-14 14:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416187&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: douglas orr (dougbo)
Assigned to: Guido van Rossum (gvanrossum)
Summary: API problem causes unicode memory leak

Initial Comment:
The API PyString_ASString returns a pointer to a char 
* representation of its argument.  

PyString_ASStringAndSize tries to convert it to the 
default encoding.  In the process it makes a new 
string object holding the newly encoded buffer, it 
returns a pointer to the buffer (bad idea) and leaks 
the new object and the buffer -- which is the only 
choice since there is no control on how long the 
pointer to the buffer needs to be valid.

It should probably throw an error if you give it a 
unicode string and force you to convert it explicitly, 
before calling the API.

I encountered this problem trying to use XML data.


----------------------------------------------------------------------

>Comment By: douglas orr (dougbo)
Date: 2001-04-15 08:59

Message:
Logged In: YES 
user_id=196404

sure thing, dude... stuff's going to keel over left and 
right if you change it.  

again, the problem is that you have lost control of the 
buffer so you don't know when it's safe to free the new 
object.

my opinion:  let people know it's coming and take the hit.  
do you know how many unicode apps there are, outside of the 
expat world?  (I mean roughly -- is this pretty new stuff?)

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-04-15 05:32

Message:
Logged In: YES 
user_id=38388

This is not a memory leak; it is the intended behaviour and
is
needed not only by PyString_AsString...() but also by the
"s" and
"s#" parser markers.

The Unicode object has an extra buffer which needs to be
there
for just this reason. The buffer is string object which is
created
in a lazy way whenever Python needs to convert that Unicode
object to an 8-bit string using the default encoding and is
then
kept alive until the Unicode object goes away. In that
sense, the
Unicode object shows the same behaviour as a normal string
object
would.

I know that having this extra buffer is a bad idea, but it
was
the only way to integrate string and Unicode objects in a
very seemless way.

Why do think this is a memory leak ?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-14 20:24

Message:
Logged In: YES 
user_id=6380

Wait a second.  Looking at the comments for
_PyUnicode_AsDefaultEncodedString(), it is supposed to cache
the 8-bit string as part of the Unicode object, hence it is
not strictly speaking leaking (although it may cause the
encoded string to hang around longer than strictly
necessary).

Are you sure that you are experiencing a memory leak?  If
so, please submit a program that shows this!

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-14 20:05

Message:
Logged In: YES 
user_id=6380

Shit!  You're right.  What now?  if I change it to throw an
error, how do I know it won't break some code that depends
on this???

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416187&group_id=5470


From noreply@sourceforge.net  Sun Apr 15 17:33:45 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 15 Apr 2001 09:33:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-416187 ] API problem causes unicode memory leak
Message-ID: <E14opT7-0004DP-00@usw-sf-web3.sourceforge.net>

Bugs item #416187, was updated on 2001-04-14 14:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416187&group_id=5470

>Category: Python Interpreter Core
>Group: Not a Bug
>Status: Closed
Priority: 5
Submitted By: douglas orr (dougbo)
Assigned to: Guido van Rossum (gvanrossum)
Summary: API problem causes unicode memory leak

Initial Comment:
The API PyString_ASString returns a pointer to a char 
* representation of its argument.  

PyString_ASStringAndSize tries to convert it to the 
default encoding.  In the process it makes a new 
string object holding the newly encoded buffer, it 
returns a pointer to the buffer (bad idea) and leaks 
the new object and the buffer -- which is the only 
choice since there is no control on how long the 
pointer to the buffer needs to be valid.

It should probably throw an error if you give it a 
unicode string and force you to convert it explicitly, 
before calling the API.

I encountered this problem trying to use XML data.


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-15 09:33

Message:
Logged In: YES 
user_id=6380

Closing this.  It's clearly a non-issue.

----------------------------------------------------------------------

Comment By: douglas orr (dougbo)
Date: 2001-04-15 08:59

Message:
Logged In: YES 
user_id=196404

sure thing, dude... stuff's going to keel over left and 
right if you change it.  

again, the problem is that you have lost control of the 
buffer so you don't know when it's safe to free the new 
object.

my opinion:  let people know it's coming and take the hit.  
do you know how many unicode apps there are, outside of the 
expat world?  (I mean roughly -- is this pretty new stuff?)

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-04-15 05:32

Message:
Logged In: YES 
user_id=38388

This is not a memory leak; it is the intended behaviour and
is
needed not only by PyString_AsString...() but also by the
"s" and
"s#" parser markers.

The Unicode object has an extra buffer which needs to be
there
for just this reason. The buffer is string object which is
created
in a lazy way whenever Python needs to convert that Unicode
object to an 8-bit string using the default encoding and is
then
kept alive until the Unicode object goes away. In that
sense, the
Unicode object shows the same behaviour as a normal string
object
would.

I know that having this extra buffer is a bad idea, but it
was
the only way to integrate string and Unicode objects in a
very seemless way.

Why do think this is a memory leak ?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-14 20:24

Message:
Logged In: YES 
user_id=6380

Wait a second.  Looking at the comments for
_PyUnicode_AsDefaultEncodedString(), it is supposed to cache
the 8-bit string as part of the Unicode object, hence it is
not strictly speaking leaking (although it may cause the
encoded string to hang around longer than strictly
necessary).

Are you sure that you are experiencing a memory leak?  If
so, please submit a program that shows this!

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-14 20:05

Message:
Logged In: YES 
user_id=6380

Shit!  You're right.  What now?  if I change it to throw an
error, how do I know it won't break some code that depends
on this???

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416187&group_id=5470


From noreply@sourceforge.net  Sun Apr 15 18:36:00 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 15 Apr 2001 10:36:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-416288 ] infrequent memory leak in pyexpat
Message-ID: <E14oqRM-0004w4-00@usw-sf-web3.sourceforge.net>

Bugs item #416288, was updated on 2001-04-15 10:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416288&group_id=5470

Category: XML
Group: None
Status: Open
Priority: 5
Submitted By: douglas orr (dougbo)
Assigned to: Nobody/Anonymous (nobody)
Summary: infrequent memory leak in pyexpat

Initial Comment:
In pyexpat.c, the macro call for the handler dispatch 
(my##NAME##Handler) for CharacterHandler allocates an 
object implicitly by calling one of the conversion-to-
unicode routines.  

If there is a problem in the PyBuildValue, resulting 
in args == NULL, that object will be leaked.

Low priority, but the macros probably need some 
reworking to handle this.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416288&group_id=5470


From noreply@sourceforge.net  Sun Apr 15 19:24:13 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 15 Apr 2001 11:24:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-416181 ] 2.1c1 builds strangely on Solaris
Message-ID: <E14orC1-0005Wd-00@usw-sf-web2.sourceforge.net>

Bugs item #416181, was updated on 2001-04-14 13:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416181&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: David M. Beazley (beazley)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.1c1 builds strangely on Solaris

Initial Comment:
Python 2.1c1 has problems with its build process on the
following
configuration:

     - Solaris 2.8 SPARC
     - gcc-2.95-2 compilers *AND* Sun Workshop 5.0
compilers
        installed.

Although the interpreter builds without problems, the
process of building various extension modules fails
under gcc, but works under the Sun compilers.  (for
example, I get tons of unresolved symbols in curses,
ncurses, etc. with gcc).

This appears to be a problem related to linker/compiler
options with gcc, but I don't see anything obvious
offhand.   I will post a followup if I am able to make
a fix.








----------------------------------------------------------------------

>Comment By: David M. Beazley (beazley)
Date: 2001-04-15 11:24

Message:
Logged In: YES 
user_id=7557

Making the _XOPEN_SOURCE_EXTENDED change did not seem to fix
the problem.   I am primarily getting linker errors
(compilation is fine) for Python modules that involves
libraries like ncurses, readline, zlib, etc...
This almost certainly looks like some conflict between
static and shared linking to me.  In fact, I'm fairly
convinced that doing

     gcc -shared  $(OBJS) ...

is completely broken on my machine.  If I change the
Makefile to this, everything suddenly works:

LDSHARED = $(CC) -Xlinker -G
BLDSHARED = $(CC) -Xlinker -G

Caveats:

I'm not sure if there is a general fix to this problem. 
Since I have the Sun Workshop compilers installed, I also
have the Sun linker installed.  I know that this linker does
not recognize the -shared option so this is almost certainly
why gcc -shared doesn't work.  On the other hand, if I only
had the GNU tools installed, I suspect that the GNU linker
would probably work with gcc -shared.   The -Xlinker option
hack above would also fail with the Sun cc compiler (so this
isn't a general solution).

Is anyone else reporting problems with Solaris?  If not, I'd
say don't worry about my peculiar circumstances (maybe I
have a hosed installation of gcc).   

-- Dave



----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-14 20:07

Message:
Logged In: YES 
user_id=6380

David, can you try adding #define _XOPEN_SOURCE_EXTENDED to
the _cursesmodule.c source file?

That worked for the same system on Compaq Tru64.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416181&group_id=5470


From noreply@sourceforge.net  Sun Apr 15 21:49:13 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 15 Apr 2001 13:49:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-416231 ] urllib.basejoin fails to apply some ../
Message-ID: <E14otSL-00070Y-00@usw-sf-web3.sourceforge.net>

Bugs item #416231, was updated on 2001-04-14 23:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416231&group_id=5470

Category: Python Library
Group: None
>Status: Closed
Priority: 5
Submitted By: Juan M. Bello Rivas (rwxrwxrwx)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: urllib.basejoin fails to apply some ../

Initial Comment:
When performing a urllib.basejoin('http://localhost/',
'../test.html') the function will join it as
http://localhosttest.html.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-15 13:49

Message:
Logged In: YES 
user_id=6380

Thanks for the bug report!

I've now fixed this in the CVS tree, just in time for the 
final release.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416231&group_id=5470


From noreply@sourceforge.net  Sun Apr 15 21:50:09 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 15 Apr 2001 13:50:09 -0700
Subject: [Python-bugs-list] [ python-Bugs-416181 ] 2.1c1 builds strangely on Solaris
Message-ID: <E14otTF-0006SB-00@usw-sf-web1.sourceforge.net>

Bugs item #416181, was updated on 2001-04-14 13:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416181&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: David M. Beazley (beazley)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.1c1 builds strangely on Solaris

Initial Comment:
Python 2.1c1 has problems with its build process on the
following
configuration:

     - Solaris 2.8 SPARC
     - gcc-2.95-2 compilers *AND* Sun Workshop 5.0
compilers
        installed.

Although the interpreter builds without problems, the
process of building various extension modules fails
under gcc, but works under the Sun compilers.  (for
example, I get tons of unresolved symbols in curses,
ncurses, etc. with gcc).

This appears to be a problem related to linker/compiler
options with gcc, but I don't see anything obvious
offhand.   I will post a followup if I am able to make
a fix.








----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-15 13:50

Message:
Logged In: YES 
user_id=6380

Jeremy, if Eric fixed this, can you close it?  He doesn't 
appear to know how to use SF.  (Funny, for a VA Linux board 
member. :-)

----------------------------------------------------------------------

Comment By: David M. Beazley (beazley)
Date: 2001-04-15 11:24

Message:
Logged In: YES 
user_id=7557

Making the _XOPEN_SOURCE_EXTENDED change did not seem to fix
the problem.   I am primarily getting linker errors
(compilation is fine) for Python modules that involves
libraries like ncurses, readline, zlib, etc...
This almost certainly looks like some conflict between
static and shared linking to me.  In fact, I'm fairly
convinced that doing

     gcc -shared  $(OBJS) ...

is completely broken on my machine.  If I change the
Makefile to this, everything suddenly works:

LDSHARED = $(CC) -Xlinker -G
BLDSHARED = $(CC) -Xlinker -G

Caveats:

I'm not sure if there is a general fix to this problem. 
Since I have the Sun Workshop compilers installed, I also
have the Sun linker installed.  I know that this linker does
not recognize the -shared option so this is almost certainly
why gcc -shared doesn't work.  On the other hand, if I only
had the GNU tools installed, I suspect that the GNU linker
would probably work with gcc -shared.   The -Xlinker option
hack above would also fail with the Sun cc compiler (so this
isn't a general solution).

Is anyone else reporting problems with Solaris?  If not, I'd
say don't worry about my peculiar circumstances (maybe I
have a hosed installation of gcc).   

-- Dave



----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-14 20:07

Message:
Logged In: YES 
user_id=6380

David, can you try adding #define _XOPEN_SOURCE_EXTENDED to
the _cursesmodule.c source file?

That worked for the same system on Compaq Tru64.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416181&group_id=5470


From noreply@sourceforge.net  Sun Apr 15 21:52:45 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 15 Apr 2001 13:52:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-416225 ] os.environ.has_key fails with lower case
Message-ID: <E14otVl-00072e-00@usw-sf-web3.sourceforge.net>

Bugs item #416225, was updated on 2001-04-14 21:45
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416225&group_id=5470

>Category: Python Library
Group: None
>Status: Closed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: os.environ.has_key fails with lower case

Initial Comment:
This looks a bit like #210690. When setting an environ 
variable for a child process on windows has_key will 
let me down if the environ key is lower case
(on win NT and Windows 2k) python 1.5.2.

Let me show an example:
C:\>python
Python 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit 
(Intel)] on win32
Copyright 1991-1995 Stichting Mathematisch Centrum, 
Amsterdam
>>> import os
>>> os.environ['BLAH'] = "blah blah blah"
>>> os.environ['blah1'] = "blah blah blah"
>>> os.environ['BLAH']
'blah blah blah'
>>> os.environ['blah1']
'blah blah blah'
>>> os.environ.has_key("BLAH")
1
>>> os.environ.has_key("blah1")
0
>>>



----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-15 13:52

Message:
Logged In: YES 
user_id=6380

Thanks; this is a known bug in 1.5.2 that has been fixed in 
2.0 and later versions.  I suggest that you upgrade!

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416225&group_id=5470


From noreply@sourceforge.net  Sun Apr 15 21:53:15 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 15 Apr 2001 13:53:15 -0700
Subject: [Python-bugs-list] [ python-Bugs-416181 ] 2.1c1 builds strangely on Solaris
Message-ID: <E14otWF-0006UO-00@usw-sf-web1.sourceforge.net>

Bugs item #416181, was updated on 2001-04-14 13:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416181&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
>Priority: 2
Submitted By: David M. Beazley (beazley)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.1c1 builds strangely on Solaris

Initial Comment:
Python 2.1c1 has problems with its build process on the
following
configuration:

     - Solaris 2.8 SPARC
     - gcc-2.95-2 compilers *AND* Sun Workshop 5.0
compilers
        installed.

Although the interpreter builds without problems, the
process of building various extension modules fails
under gcc, but works under the Sun compilers.  (for
example, I get tons of unresolved symbols in curses,
ncurses, etc. with gcc).

This appears to be a problem related to linker/compiler
options with gcc, but I don't see anything obvious
offhand.   I will post a followup if I am able to make
a fix.








----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-15 13:50

Message:
Logged In: YES 
user_id=6380

Jeremy, if Eric fixed this, can you close it?  He doesn't 
appear to know how to use SF.  (Funny, for a VA Linux board 
member. :-)

----------------------------------------------------------------------

Comment By: David M. Beazley (beazley)
Date: 2001-04-15 11:24

Message:
Logged In: YES 
user_id=7557

Making the _XOPEN_SOURCE_EXTENDED change did not seem to fix
the problem.   I am primarily getting linker errors
(compilation is fine) for Python modules that involves
libraries like ncurses, readline, zlib, etc...
This almost certainly looks like some conflict between
static and shared linking to me.  In fact, I'm fairly
convinced that doing

     gcc -shared  $(OBJS) ...

is completely broken on my machine.  If I change the
Makefile to this, everything suddenly works:

LDSHARED = $(CC) -Xlinker -G
BLDSHARED = $(CC) -Xlinker -G

Caveats:

I'm not sure if there is a general fix to this problem. 
Since I have the Sun Workshop compilers installed, I also
have the Sun linker installed.  I know that this linker does
not recognize the -shared option so this is almost certainly
why gcc -shared doesn't work.  On the other hand, if I only
had the GNU tools installed, I suspect that the GNU linker
would probably work with gcc -shared.   The -Xlinker option
hack above would also fail with the Sun cc compiler (so this
isn't a general solution).

Is anyone else reporting problems with Solaris?  If not, I'd
say don't worry about my peculiar circumstances (maybe I
have a hosed installation of gcc).   

-- Dave



----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-14 20:07

Message:
Logged In: YES 
user_id=6380

David, can you try adding #define _XOPEN_SOURCE_EXTENDED to
the _cursesmodule.c source file?

That worked for the same system on Compaq Tru64.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416181&group_id=5470


From noreply@sourceforge.net  Mon Apr 16 13:41:15 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 16 Apr 2001 05:41:15 -0700
Subject: [Python-bugs-list] [ python-Bugs-416423 ] Python2.0-Darwin - test_rc failed
Message-ID: <E14p8Jf-00017h-00@usw-sf-web2.sourceforge.net>

Bugs item #416423, was updated on 2001-04-16 05:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416423&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python2.0-Darwin - test_rc failed

Initial Comment:
I have a Apple PBG4 with Mac OS X and the latest 
Updates and 256MB RAM.
I tried to compile Python2.0 and got these output -

hth Pitz
------------------------------
[localhost:~/Documents/src/Python-2.0] % uname -
a
Darwin localhost 1.3 Darwin Kernel Version 1.3: 
Fri Mar 30 20:45:03 PST 2001; root:xnu/xnu-
124.1.obj~1/RELEASE_PPC  Powe
r Macintosh powerpc

[localhost:~/Documents/src/Python-2.0] % ./
configure --with-dyld --with-suffix=.app --with-
threads --with-libdb
[localhost:~/Documents/src/Python-2.0] % make
[localhost:~/Documents/src/Python-2.0] % make 
test

[localhost:~/Documents/src/Python-2.0] % Python/
python ./Lib/test/test_fcntl.py
Status from fnctl with O_NONBLOCK:  0
struct.pack:  '\000\003\000\000\000\000\000\000\
000\000\000\000\000\000\000\000'
Traceback (most recent call last):
  File "./Lib/test/test_fcntl.py", line 31, in ?
    rv = fcntl.fcntl(f.fileno(), FCNTL.F_SETLKW, 
lockdata)
IOError: [Errno 22] Invalid argument
[localhost:~/Documents/src/Python-2.0] % Python/
python ./Lib/test/test_re.py
Running tests on re.search and re.match
Running tests on re.sub
Running tests on symbolic references
Running tests on re.subn
Running tests on re.split
Running tests on re.findall
Running tests on re.match
Running tests on re.escape
Pickling a RegexObject instance
Test engine limitations
Segmentation fault


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416423&group_id=5470


From noreply@sourceforge.net  Mon Apr 16 15:17:31 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 16 Apr 2001 07:17:31 -0700
Subject: [Python-bugs-list] [ python-Bugs-412271 ] licence/license confusion
Message-ID: <E14p9op-0002K8-00@usw-sf-web2.sourceforge.net>

Bugs item #412271, was updated on 2001-03-29 11:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=412271&group_id=5470

Category: Distutils
Group: None
Status: Open
Priority: 7
Submitted By: A.M. Kuchling (akuchling)
Assigned to: A.M. Kuchling (akuchling)
Summary: licence/license confusion

Initial Comment:
Thomas Heller points out:

Playing with the new meta info, I noticed that the
license specified in this way:
 
setup(..., license="MIT/X11", ...)
 
isn't recognized, while it works if one uses:
 
setup(..., licence="MIT/X11", ...)

BTW; according to www.opensource.org the MIT license
seems to be spelled MIT license nowadays, no longer
MIT/X11 license.

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2001-04-16 07:17

Message:
Logged In: YES 
user_id=11375

No, I wasn't planning to.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-13 08:46

Message:
Logged In: YES 
user_id=6380

andrew, were you going to fix this before 2.1?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=412271&group_id=5470


From noreply@sourceforge.net  Mon Apr 16 16:21:23 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 16 Apr 2001 08:21:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-416423 ] Python2.0-Darwin - test_rc failed
Message-ID: <E14pAod-00035w-00@usw-sf-web2.sourceforge.net>

Bugs item #416423, was updated on 2001-04-16 05:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416423&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
>Priority: 3
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python2.0-Darwin - test_rc failed

Initial Comment:
I have a Apple PBG4 with Mac OS X and the latest 
Updates and 256MB RAM.
I tried to compile Python2.0 and got these output -

hth Pitz
------------------------------
[localhost:~/Documents/src/Python-2.0] % uname -
a
Darwin localhost 1.3 Darwin Kernel Version 1.3: 
Fri Mar 30 20:45:03 PST 2001; root:xnu/xnu-
124.1.obj~1/RELEASE_PPC  Powe
r Macintosh powerpc

[localhost:~/Documents/src/Python-2.0] % ./
configure --with-dyld --with-suffix=.app --with-
threads --with-libdb
[localhost:~/Documents/src/Python-2.0] % make
[localhost:~/Documents/src/Python-2.0] % make 
test

[localhost:~/Documents/src/Python-2.0] % Python/
python ./Lib/test/test_fcntl.py
Status from fnctl with O_NONBLOCK:  0
struct.pack:  '\000\003\000\000\000\000\000\000\
000\000\000\000\000\000\000\000'
Traceback (most recent call last):
  File "./Lib/test/test_fcntl.py", line 31, in ?
    rv = fcntl.fcntl(f.fileno(), FCNTL.F_SETLKW, 
lockdata)
IOError: [Errno 22] Invalid argument
[localhost:~/Documents/src/Python-2.0] % Python/
python ./Lib/test/test_re.py
Running tests on re.search and re.match
Running tests on re.sub
Running tests on symbolic references
Running tests on re.subn
Running tests on re.split
Running tests on re.findall
Running tests on re.match
Running tests on re.escape
Pickling a RegexObject instance
Test engine limitations
Segmentation fault


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-16 08:21

Message:
Logged In: YES 
user_id=6380

Please try again with Python 2.1c2, downloadable from
python.org/2.1/.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416423&group_id=5470


From noreply@sourceforge.net  Mon Apr 16 17:01:40 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 16 Apr 2001 09:01:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-416462 ] .pyo files missing in mimetypes.py?
Message-ID: <E14pBRc-0003b7-00@usw-sf-web2.sourceforge.net>

Bugs item #416462, was updated on 2001-04-16 09:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416462&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Priority: 5
Submitted By: David M. Beazley (beazley)
Assigned to: Nobody/Anonymous (nobody)
Summary: .pyo files missing in mimetypes.py?

Initial Comment:
This is a very minor nit caught by Paul Dubois in
reviewing 
Python Essential Reference 2nd Ed.   

The .py and .pyc files are both recognized in the
mimetypes module as :

    '.py': 'text/x-python',
    '.pyc': 'application/x-python-code',

However, no entry appears for '.pyo' files.    Should
they also appear?
    
    '.pyo' : 'application/x-python-code',

Admittedly it's pretty minor---I don't think I would
have noticed this had it not been pointed out.

-- Dave
 

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416462&group_id=5470


From noreply@sourceforge.net  Mon Apr 16 18:44:07 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 16 Apr 2001 10:44:07 -0700
Subject: [Python-bugs-list] [ python-Bugs-416480 ] weakref needs better test suite
Message-ID: <E14pD2l-0004rn-00@usw-sf-web2.sourceforge.net>

Bugs item #416480, was updated on 2001-04-16 10:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416480&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 6
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: weakref needs better test suite

Initial Comment:
The Weak*Dictionary classes need a more complete test suite.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416480&group_id=5470


From noreply@sourceforge.net  Mon Apr 16 21:08:02 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 16 Apr 2001 13:08:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-416508 ] Reproductible parser crash with os.fdopen()
Message-ID: <E14pFI2-0006fT-00@usw-sf-web2.sourceforge.net>

Bugs item #416508, was updated on 2001-04-16 13:08
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416508&group_id=5470

Category: Parser/Compiler
Group: Trash
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Reproductible parser crash with os.fdopen()

Initial Comment:
Hi there!

Just found this bugs, fully reproductible.
They are all the similar, derived from os.fdopen() as you will see.


Copy/paste is much better than any words, so (note: ';' is my bash prompt):

; python
Python 2.0 (#2, Feb  3 2001, 18:06:18)
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> import os
>>> infd = os.fdopen(0)
>>> infd = os.fdopen(0)
>>>
;

You can put it in a try..except, changing fdopen parameters, etc; but the same
happens.
A weird thing also happens if you try to do it with fd 1 instead of 0, it seems
to hung expecting for input... but ^C gives KeyboardInterrupt, see:

; python
Python 2.0 (#2, Feb  3 2001, 18:06:18)
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> import os
>>> infd = os.fdopen(1)
>>> infd = os.fdopen(0)
		<--- ^C, then:
KeyboardInterrupt
		<--- ^C again
KeyboardInterrupt
		<--- ^D (EOF), and got prompt.
;

The same if you try to fdopen(2) any number of times (as opposed with regular
files, when you can do it only two times before the exception, see below), and
then fdopen(1) _TWICE_; except that ^C has no effect here.


Now... if we try with a regular file:

>>> import os
>>> fd = open('/var/log/messages')
>>> fd.fileno()
>>> 3
>>> infd = os.fdopen(3)		# first call, ok
>>> infd = os.fdopen(3)		# second call, ok
>>> infd = os.fdopen(3)		# third call, exception
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   OSError: [Errno 9] Bad file descriptor
>>> infd = os.fdopen(3)
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   OSError: [Errno 9] Bad file descriptor
>>>

And the interpreter is still fully functional, i can even del(infd)
The behaviour with fd 2 is also sane.

Well, any questions or testing you need, just ask me at
albertogli@altavista.net.

Thanks¸
		Alberto



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416508&group_id=5470


From noreply@sourceforge.net  Mon Apr 16 22:02:08 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 16 Apr 2001 14:02:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-416508 ] Reproductible parser crash with os.fdopen()
Message-ID: <E14pG8O-00033q-00@usw-sf-web1.sourceforge.net>

Bugs item #416508, was updated on 2001-04-16 13:08
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416508&group_id=5470

Category: Parser/Compiler
Group: Trash
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Reproductible parser crash with os.fdopen()

Initial Comment:
Hi there!

Just found this bugs, fully reproductible.
They are all the similar, derived from os.fdopen() as you will see.


Copy/paste is much better than any words, so (note: ';' is my bash prompt):

; python
Python 2.0 (#2, Feb  3 2001, 18:06:18)
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> import os
>>> infd = os.fdopen(0)
>>> infd = os.fdopen(0)
>>>
;

You can put it in a try..except, changing fdopen parameters, etc; but the same
happens.
A weird thing also happens if you try to do it with fd 1 instead of 0, it seems
to hung expecting for input... but ^C gives KeyboardInterrupt, see:

; python
Python 2.0 (#2, Feb  3 2001, 18:06:18)
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> import os
>>> infd = os.fdopen(1)
>>> infd = os.fdopen(0)
		<--- ^C, then:
KeyboardInterrupt
		<--- ^C again
KeyboardInterrupt
		<--- ^D (EOF), and got prompt.
;

The same if you try to fdopen(2) any number of times (as opposed with regular
files, when you can do it only two times before the exception, see below), and
then fdopen(1) _TWICE_; except that ^C has no effect here.


Now... if we try with a regular file:

>>> import os
>>> fd = open('/var/log/messages')
>>> fd.fileno()
>>> 3
>>> infd = os.fdopen(3)		# first call, ok
>>> infd = os.fdopen(3)		# second call, ok
>>> infd = os.fdopen(3)		# third call, exception
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   OSError: [Errno 9] Bad file descriptor
>>> infd = os.fdopen(3)
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   OSError: [Errno 9] Bad file descriptor
>>>

And the interpreter is still fully functional, i can even del(infd)
The behaviour with fd 2 is also sane.

Well, any questions or testing you need, just ask me at
albertogli@altavista.net.

Thanks¸
		Alberto



----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2001-04-16 14:02

Message:
Logged In: YES 
user_id=6656

in the first example, the second assignment to infd deletes 
the file object which closes fd 0, i.e. standard input, so 
python thinks you're done and exits.  this only affects 
interactive sessions.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416508&group_id=5470


From noreply@sourceforge.net  Mon Apr 16 22:09:26 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 16 Apr 2001 14:09:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-416526 ] Regular expression tests: SEGV on Mac OS
Message-ID: <E14pGFS-0006Va-00@usw-sf-web3.sourceforge.net>

Bugs item #416526, was updated on 2001-04-16 14:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416526&group_id=5470

Category: Regular Expressions
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Regular expression tests: SEGV on Mac OS

Initial Comment:
The regular expression regression tests 'test_re' 
causes a SEGV failure on Mac OS X version 10.0.1 
when using Python 2.1c2 (and earlier). This is 
caused by the test trying to recurse 50,000 levels 
deep.

Workaround: A workaround is to limit how deep the 
regular expression library can recurse (this is 
already done for Win32). This can be achieved by 
changing file './Modules/_sre.c' using the following 
patch:

--- ./orig/_sre.c   Sun Apr 15 19:00:58 2001
+++ ./new/_sre.c    Mon Apr 16 21:39:29 2001
@@ -75,6 +75,9 @@
    Win64 (MS_WIN64), Linux64 (__LP64__), 
Monterey (64-bit AIX) (_LP64) */
 /* FIXME: maybe the limit should be 40000 / 
sizeof(void*) ? */
 #define USE_RECURSION_LIMIT 7500
+#elif defined(__APPLE_CC__)
+/* Apple 'cc' compiler eg. for Mac OS X */
+#define USE_RECURSION_LIMIT 4000
 #else
 #define USE_RECURSION_LIMIT 10000
 #endif


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416526&group_id=5470


From noreply@sourceforge.net  Mon Apr 16 22:19:30 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 16 Apr 2001 14:19:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-416530 ] No notes for building on Mac OS X 10.0
Message-ID: <E14pGPC-0003KJ-00@usw-sf-web1.sourceforge.net>

Bugs item #416530, was updated on 2001-04-16 14:19
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416530&group_id=5470

Category: Documentation
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: No notes for building on Mac OS X 10.0

Initial Comment:
In the 'README' file for Python-2.1c2, the 'Platform 
specific notes' section for Mac OS X should be 
amended to include notes for building on Mac OS 
10.0 (as opposed to Mac OS X beta). The 
suggested new words are:

Run configure with "OPT='-no-cpp-precomp' ./
configure --with-suffix=.exe --with-dyld".
This generates executable file: 'python.exe' (it 
cannot be named 'python' on an HFS or HFS+
disk as the file name clashes with directory 
'Python'). The '-no-cpp-precomp' option prevents
a large number of compilation warnings.

All the regression tests succeed except for the 
regular expression test 'test_re'
which fails with a SEGV unless file '_sre.c' has a fix 
to limit the depth of recursion used.
This change (and a suggested fix) has been 
submitted as a bug under request id: 416526.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416530&group_id=5470


From noreply@sourceforge.net  Tue Apr 17 02:18:44 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 16 Apr 2001 18:18:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-416573 ] makesockaddr() AF_UNIX ignores sun_len
Message-ID: <E14pK8i-00018K-00@usw-sf-web3.sourceforge.net>

Bugs item #416573, was updated on 2001-04-16 18:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416573&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: makesockaddr() AF_UNIX ignores sun_len

Initial Comment:
On FreeBSD 4.2-RELEASE, bind two AF_UNIX,SOCK_DGRAM
sockets and send a packet over.  The recvfrom() call
returns a corrupted pathname.

This seems to fix the problem:

return PyString_FromStringAndSize (a->sun_path,
a->sun_len - (sizeof a->sun_len + sizeof
a->sun_family));

Another fix would be to zero out the address buffer in
recvfrom() [and any other places that call
makesockaddr]

-Sam


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416573&group_id=5470


From noreply@sourceforge.net  Tue Apr 17 13:31:02 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 17 Apr 2001 05:31:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-416670 ] MatchObjects not deepcopy()able
Message-ID: <E14pUdK-0000j6-00@usw-sf-web2.sourceforge.net>

Bugs item #416670, was updated on 2001-04-17 05:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416670&group_id=5470

Category: Regular Expressions
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Henning Thielemann (amigalemming)
Assigned to: Nobody/Anonymous (nobody)
Summary: MatchObjects not deepcopy()able

Initial Comment:

In the re-Module which come with Python version 2.0
(Nov 28 11:10 re.py) the created MatchObjects cannot be
copied with a deepcopy(). Switching back to the old
"pre.py" as proposed in "re.py" makes everything work
ok.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416670&group_id=5470


From noreply@sourceforge.net  Tue Apr 17 14:01:49 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 17 Apr 2001 06:01:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-416677 ] re.groups misbehaviour
Message-ID: <E14pV77-00018d-00@usw-sf-web2.sourceforge.net>

Bugs item #416677, was updated on 2001-04-17 06:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416677&group_id=5470

Category: Regular Expressions
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Andreas Jung (ajung)
Assigned to: Nobody/Anonymous (nobody)
Summary: re.groups misbehaviour

Initial Comment:
import re
 
pat = "[0-9][0-9]"
s="22 the quick 100 brown fox jumps 44 over the xx lazy 33 dog"
 
r = re.compile(pat)
mo = r.match(s)
print mo.groups()
print mo.group(0)

I expected that mo.groups() returns for this testcase a tuple with  3 elements ('22','44','33)
but instead it returns (). mo.group(0) returns as expected '22'.
Is this a bug or an error in the documentation ?



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416677&group_id=5470


From noreply@sourceforge.net  Tue Apr 17 14:35:28 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 17 Apr 2001 06:35:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-416688 ] Python 2.1c2 build using --with-cxx
Message-ID: <E14pVdg-0001cC-00@usw-sf-web2.sourceforge.net>

Bugs item #416688, was updated on 2001-04-17 06:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416688&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Harri Pasanen (harripasanen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.1c2 build using --with-cxx

Initial Comment:
After configure + build with:

./configure --with-thread --without-gcc
--with-cxx=KCC                          
make

The build fails as it tries to perform the link with
cc, not with KCC.  It has previously build correctly
ccpython using KCC.  Manually performing the linking
using KCC then works:

cc -Ae  -Wl,-E -Wl,+s
-Wl,+b/usr/local/lib/python2.1/lib-dynload -o python \
                Modules/ccpython.o \
                libpython2.1.a -lnsl -ldld    -lm
/usr/ccs/bin/ld: (Warning) At least one PA 2.0 object
file (libpython2.1.a(main.o)) was detected. The linked
output may not run on a PA 1.x system.
/usr/ccs/bin/ld: Unsatisfied symbols:
   _main (first referenced in Modules/ccpython.o)
(code)                       


The above problem seems to be present on Linux and
HP-UX, (probably all platforms using autoconf).

-Harri



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416688&group_id=5470


From noreply@sourceforge.net  Tue Apr 17 15:10:17 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 17 Apr 2001 07:10:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-416696 ] --with-threads fail for 2.1c2 on HPUX 11
Message-ID: <E14pWBN-0001Vf-00@usw-sf-web1.sourceforge.net>

Bugs item #416696, was updated on 2001-04-17 07:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416696&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Harri Pasanen (harripasanen)
Assigned to: Nobody/Anonymous (nobody)
Summary: --with-threads fail for 2.1c2 on HPUX 11

Initial Comment:
 ./configure --with-thread --without-gcc
.
.
.
checking for --with-threads... yes
checking for mach/cthreads.h... no
checking for --with-pth... no
checking for pthread_create in -lpthread... no
checking for pthread_detach... yes
.
.
.
 make test
.
.
.
test_thread
test test_thread crashed -- thread.error: can't start
new thread                
.
.
.

4 tests failed: test_asynchat test_fork1 test_thread
test_threadedtempfile

-- 

The cause here is that at link time -lpthread is not
included.  If I manually relink with -lpthread, then no
tests fail tests pass.
113 tests
OK.                                                                   

-Harri

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416696&group_id=5470


From noreply@sourceforge.net  Tue Apr 17 15:30:19 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 17 Apr 2001 07:30:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-404545 ] frozen package import uses wrong files
Message-ID: <E14pWUl-0001rm-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
Resolution: None
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: Toby Dickenson (htrd)
Date: 2001-04-17 07:30

Message:
Logged In: YES 
user_id=46460

Fix for this (and several other ways to break a frozen 
program) are in patch #416704 

----------------------------------------------------------------------

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  Tue Apr 17 16:27:18 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 17 Apr 2001 08:27:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-411881 ] Use of "except:" in modules
Message-ID: <E14pXNu-00039f-00@usw-sf-web2.sourceforge.net>

Bugs item #411881, was updated on 2001-03-28 04:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411881&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Itamar Shtull-Trauring (itamar)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Use of "except:" in modules

Initial Comment:
A large amount of modules in the standard library use
"except:" instead of specifying the exceptions to be
caught. In some cases this may be correct, but I think
in most cases this not true and this may cause
problems. Here's the list of modules, which I got by
doing:

   grep "except:" *.py | cut -f 1 -d " " | sort | uniq

Bastion.py
CGIHTTPServer.py
Cookie.py
SocketServer.py
anydbm.py
asyncore.py
bdb.py
cgi.py
chunk.py
cmd.py
code.py
compileall.py
doctest.py
fileinput.py
formatter.py
getpass.py
htmllib.py
imaplib.py
inspect.py
locale.py
locale.py
mailcap.py
mhlib.py
mimetools.py
mimify.py
os.py
pdb.py
popen2.py
posixfile.py
pre.py
pstats.py
pty.py
pyclbr.py
pydoc.py
repr.py
rexec.py
rfc822.py
shelve.py
shutil.py
tempfile.py
threading.py
traceback.py
types.py
unittest.py
urllib.py
zipfile.py


----------------------------------------------------------------------

>Comment By: Itamar Shtull-Trauring (itamar)
Date: 2001-04-17 08:27

Message:
Logged In: YES 
user_id=32065

inspect.py uses sys_getframe if it's there, the other code
is for backwards compatibility.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-11 10:24

Message:
Logged In: YES 
user_id=6380

Actually, inspect.py should use sys._getframe()!

And yes, KeyboardError is definitely one of the reasons why
this is such a bad idiom...

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2001-04-11 10:15

Message:
Logged In: YES 
user_id=89016

> Can you identify modules where catching everything 
> is incorrect

If "everything" includes KeyboardInterrupt, it's
definitely incorrect, even in inspect.py's simple

    try:
        raise 'catch me'
    except:
        return sys.exc_traceback.tb_frame.f_back

which should probably be:

    try:
        raise 'catch me'
    except KeyboardInterrupt:
        raise
    except:
        return sys.exc_traceback.tb_frame.f_back


----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2001-04-11 10:13

Message:
Logged In: YES 
user_id=89016

> Can you identify modules where catching everything 
> is incorrect

If "everything" includes KeyboardInterrupt, it's
definitely incorrect, even in inspect.py's simple

    try:
        raise 'catch me'
    except:
        return sys.exc_traceback.tb_frame.f_back

which should probably be:

    try:
        raise 'catch me'
    except KeyboardInterrupt:
        raise
    except:
        return sys.exc_traceback.tb_frame.f_back


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 08:45

Message:
Logged In: YES 
user_id=6380

I've applied the three patches you supplied.

I agree with Martin that to do this right we'll have to
tread carefully. But please go on!

(No way more of this will find its way into 2.1 though.)

----------------------------------------------------------------------

Comment By: Itamar Shtull-Trauring (itamar)
Date: 2001-03-30 02:54

Message:
Logged In: YES 
user_id=32065

inspect.py should be removed from this list, the use is
correct.

In general, I just submitted this bug so that when people
are editing a module they'll notice these things, since in
some cases only someone who knows the code very well can
know if the "expect:" is needed or not.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-03-29 22:59

Message:
Logged In: YES 
user_id=21627

Can you identify modules where catching everything is
incorrect, and propose changes to correct them. This should
be done one-by-one, with careful analysis in each case, and
may take well months or years to complete.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411881&group_id=5470


From noreply@sourceforge.net  Tue Apr 17 16:33:24 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 17 Apr 2001 08:33:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-411881 ] Use of "except:" in modules
Message-ID: <E14pXTo-0003FB-00@usw-sf-web2.sourceforge.net>

Bugs item #411881, was updated on 2001-03-28 04:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411881&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Itamar Shtull-Trauring (itamar)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Use of "except:" in modules

Initial Comment:
A large amount of modules in the standard library use
"except:" instead of specifying the exceptions to be
caught. In some cases this may be correct, but I think
in most cases this not true and this may cause
problems. Here's the list of modules, which I got by
doing:

   grep "except:" *.py | cut -f 1 -d " " | sort | uniq

Bastion.py
CGIHTTPServer.py
Cookie.py
SocketServer.py
anydbm.py
asyncore.py
bdb.py
cgi.py
chunk.py
cmd.py
code.py
compileall.py
doctest.py
fileinput.py
formatter.py
getpass.py
htmllib.py
imaplib.py
inspect.py
locale.py
locale.py
mailcap.py
mhlib.py
mimetools.py
mimify.py
os.py
pdb.py
popen2.py
posixfile.py
pre.py
pstats.py
pty.py
pyclbr.py
pydoc.py
repr.py
rexec.py
rfc822.py
shelve.py
shutil.py
tempfile.py
threading.py
traceback.py
types.py
unittest.py
urllib.py
zipfile.py


----------------------------------------------------------------------

Comment By: Itamar Shtull-Trauring (itamar)
Date: 2001-04-17 08:27

Message:
Logged In: YES 
user_id=32065

inspect.py uses sys_getframe if it's there, the other code
is for backwards compatibility.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-11 10:24

Message:
Logged In: YES 
user_id=6380

Actually, inspect.py should use sys._getframe()!

And yes, KeyboardError is definitely one of the reasons why
this is such a bad idiom...

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2001-04-11 10:15

Message:
Logged In: YES 
user_id=89016

> Can you identify modules where catching everything 
> is incorrect

If "everything" includes KeyboardInterrupt, it's
definitely incorrect, even in inspect.py's simple

    try:
        raise 'catch me'
    except:
        return sys.exc_traceback.tb_frame.f_back

which should probably be:

    try:
        raise 'catch me'
    except KeyboardInterrupt:
        raise
    except:
        return sys.exc_traceback.tb_frame.f_back


----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2001-04-11 10:13

Message:
Logged In: YES 
user_id=89016

> Can you identify modules where catching everything 
> is incorrect

If "everything" includes KeyboardInterrupt, it's
definitely incorrect, even in inspect.py's simple

    try:
        raise 'catch me'
    except:
        return sys.exc_traceback.tb_frame.f_back

which should probably be:

    try:
        raise 'catch me'
    except KeyboardInterrupt:
        raise
    except:
        return sys.exc_traceback.tb_frame.f_back


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 08:45

Message:
Logged In: YES 
user_id=6380

I've applied the three patches you supplied.

I agree with Martin that to do this right we'll have to
tread carefully. But please go on!

(No way more of this will find its way into 2.1 though.)

----------------------------------------------------------------------

Comment By: Itamar Shtull-Trauring (itamar)
Date: 2001-03-30 02:54

Message:
Logged In: YES 
user_id=32065

inspect.py should be removed from this list, the use is
correct.

In general, I just submitted this bug so that when people
are editing a module they'll notice these things, since in
some cases only someone who knows the code very well can
know if the "expect:" is needed or not.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-03-29 22:59

Message:
Logged In: YES 
user_id=21627

Can you identify modules where catching everything is
incorrect, and propose changes to correct them. This should
be done one-by-one, with careful analysis in each case, and
may take well months or years to complete.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411881&group_id=5470


From noreply@sourceforge.net  Tue Apr 17 21:27:15 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 17 Apr 2001 13:27:15 -0700
Subject: [Python-bugs-list] [ python-Bugs-416824 ] Python 2.1 installer freezes on Win 2000
Message-ID: <E14pc4B-0006vI-00@usw-sf-web2.sourceforge.net>

Bugs item #416824, was updated on 2001-04-17 13:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416824&group_id=5470

Category: Windows
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Xavier Lagraula (xlagraula)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.1 installer freezes on Win 2000

Initial Comment:
My aim is to install Python 2.1 on a Windows 2000 
Professionnal (French) workstation.

The windows intaller works well until it show the 
screen where one can choose which parts of the product 
one wants to install (third window).

If one hit the "next" button without touching anything 
else, the installer will definitively freeze. Trying 
to stop it using the pop-up menu in the task bar will 
result in a few seconds pause, followed by an error 
window telling that the 16-bit subsystem has not 
answered in time to the stop request. The possibility 
is then given to kill it, eventually leaving the 16 
bit subsystem unstable.

I tried to download the installer from both the main 
site and sourceforge, to check if it came from a 
corrupted file. Same result.

The workaround is simple: just uncheck at least one of 
the check boxes, click "next", it won't freeze. Now 
click "back", re-check the check boxe, click "next" 
and... tada! It won't freeze neither. Now you can go 
on installing the whole package. Haven't thoroughly 
tested it yet, but seems to be working fine.

This problem is not really serious as one can easily 
bypass it, and as it doesn't involve the langage or 
the interpreter themselves. Nevertheless, it IS a 
bug...

Regards,
  Xavier


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416824&group_id=5470


From noreply@sourceforge.net  Wed Apr 18 00:49:19 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 17 Apr 2001 16:49:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-416423 ] Python2.0-Darwin - test_rc failed
Message-ID: <E14pfDj-00018k-00@usw-sf-web2.sourceforge.net>

Bugs item #416423, was updated on 2001-04-16 05:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416423&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 3
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python2.0-Darwin - test_rc failed

Initial Comment:
I have a Apple PBG4 with Mac OS X and the latest 
Updates and 256MB RAM.
I tried to compile Python2.0 and got these output -

hth Pitz
------------------------------
[localhost:~/Documents/src/Python-2.0] % uname -
a
Darwin localhost 1.3 Darwin Kernel Version 1.3: 
Fri Mar 30 20:45:03 PST 2001; root:xnu/xnu-
124.1.obj~1/RELEASE_PPC  Powe
r Macintosh powerpc

[localhost:~/Documents/src/Python-2.0] % ./
configure --with-dyld --with-suffix=.app --with-
threads --with-libdb
[localhost:~/Documents/src/Python-2.0] % make
[localhost:~/Documents/src/Python-2.0] % make 
test

[localhost:~/Documents/src/Python-2.0] % Python/
python ./Lib/test/test_fcntl.py
Status from fnctl with O_NONBLOCK:  0
struct.pack:  '\000\003\000\000\000\000\000\000\
000\000\000\000\000\000\000\000'
Traceback (most recent call last):
  File "./Lib/test/test_fcntl.py", line 31, in ?
    rv = fcntl.fcntl(f.fileno(), FCNTL.F_SETLKW, 
lockdata)
IOError: [Errno 22] Invalid argument
[localhost:~/Documents/src/Python-2.0] % Python/
python ./Lib/test/test_re.py
Running tests on re.search and re.match
Running tests on re.sub
Running tests on symbolic references
Running tests on re.subn
Running tests on re.split
Running tests on re.findall
Running tests on re.match
Running tests on re.escape
Pickling a RegexObject instance
Test engine limitations
Segmentation fault


----------------------------------------------------------------------

Comment By: Dan Wolfe (dkwolfe)
Date: 2001-04-17 16:49

Message:
Logged In: YES 
user_id=80173

test_re and test_sre will both fail due to the default small 
stacksize (512K) on Darwin/Mac OS X.  The temporary 
workaround is to enter 'limit stacksize 2M' on CL before 
running make tests.

This bug is a dup of 416526.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-16 08:21

Message:
Logged In: YES 
user_id=6380

Please try again with Python 2.1c2, downloadable from
python.org/2.1/.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416423&group_id=5470


From noreply@sourceforge.net  Wed Apr 18 00:52:02 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 17 Apr 2001 16:52:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-416526 ] Regular expression tests: SEGV on Mac OS
Message-ID: <E14pfGM-0001C8-00@usw-sf-web2.sourceforge.net>

Bugs item #416526, was updated on 2001-04-16 14:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416526&group_id=5470

Category: Regular Expressions
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Regular expression tests: SEGV on Mac OS

Initial Comment:
The regular expression regression tests 'test_re' 
causes a SEGV failure on Mac OS X version 10.0.1 
when using Python 2.1c2 (and earlier). This is 
caused by the test trying to recurse 50,000 levels 
deep.

Workaround: A workaround is to limit how deep the 
regular expression library can recurse (this is 
already done for Win32). This can be achieved by 
changing file './Modules/_sre.c' using the following 
patch:

--- ./orig/_sre.c   Sun Apr 15 19:00:58 2001
+++ ./new/_sre.c    Mon Apr 16 21:39:29 2001
@@ -75,6 +75,9 @@
    Win64 (MS_WIN64), Linux64 (__LP64__), 
Monterey (64-bit AIX) (_LP64) */
 /* FIXME: maybe the limit should be 40000 / 
sizeof(void*) ? */
 #define USE_RECURSION_LIMIT 7500
+#elif defined(__APPLE_CC__)
+/* Apple 'cc' compiler eg. for Mac OS X */
+#define USE_RECURSION_LIMIT 4000
 #else
 #define USE_RECURSION_LIMIT 10000
 #endif


----------------------------------------------------------------------

Comment By: Dan Wolfe (dkwolfe)
Date: 2001-04-17 16:52

Message:
Logged In: YES 
user_id=80173

Instead of relying on a compiler variable, we should probably 
set a environment variable as part of the ./configure and use 
that to determine when to reduce the USE_RECURSION_LIMIT.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416526&group_id=5470


From noreply@sourceforge.net  Wed Apr 18 01:42:05 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 17 Apr 2001 17:42:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-416901 ] 2.1 on OpenBSD 2.8: lots of bugs @ build
Message-ID: <E14pg2n-0003T1-00@usw-sf-web1.sourceforge.net>

Bugs item #416901, was updated on 2001-04-17 17:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416901&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Brad Allen (valaulmo)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.1 on OpenBSD 2.8: lots of bugs @ build

Initial Comment:
I am doing a survey of current distributed information
systems, to see
if they are close to what they should be (I figured out
what they should
be in 1984), and am forced to find a Python which Mojo
Nation is compatible
with.  I will probably go back to Python 2.0, but since
the latest released
version (released today!) was 2.1, I just started there
(since the stable
one for OpenBSD 2.8 was way back at Python 1.6 and I
figured anything
past that was experimenting anyway).

--- Python 2.1 on OpenBSD 2.8 with Pentium I:

I'm getting these warnings while compiling Python 2.1
on OpenBSD 2.8:

cc   -o python \
                Modules/python.o \
                libpython2.1.a -lc_r -lutil
-L/usr/local/lib -lz  -lm  
./Modules/posixmodule.c:2995: warning: this program
uses setreuid(), which is deprecated.
./Modules/posixmodule.c:3014: warning: this program
uses setregid(), which is deprecated.
./Modules/posixmodule.c:4147: warning: tempnam()
possibly used unsafely; consider using mkstemp()
./Modules/posixmodule.c:4193: warning: tmpnam()
possibly used unsafely; consider using mkstemp()
ld: libpython2.1.a(fileobject.o): RRS text relocation
at 0x31168 for "_flockfile"
ld: libpython2.1.a(fileobject.o): RRS text relocation
at 0x311af for "_funlockfile"
PYTHONPATH= ./python ./setup.py build
running build


Please consider fixing those things.

---

***   HUNG   test_bufio.py

When running tests as "MAKE=gmake gmake test", it hung
under
test_bufio.  It required a SIGKILL to stop.  I tried
two things:

* Running test as README says manually with "python
...".
     python ./Lib/test/test_bufio.py
  This worked OK and produced no output that I was
aware of
  (unless it was hidden).

* Tried defining DONT_USE_FGETS_IN_GETLINE in the file
where it
  was looked at (./Objects/fileobject.c).  This did not
help;
  it still hung.  Running the test manually again at
this point worked also.


So, I had to find a way to skip that test (hid it in a
subdirectory
called HIDE).

***   HUNG   test_complex.py

The same thing happened with test_complex.py: it hung
during "...make test",
but ran OK manually; then I hid it to skip.  For
test_dl, I got slightly
different results; after the usual hanging, I then
manually ran it and got:

***   HUNG   test_dl.py*

Q:/usr/local/src/python/Python-2.1:2148$ python
Lib/test/test_dl.py
Traceback (most recent call last):
  File "Lib/test/test_dl.py", line 6, in ?
    import dl
ImportError: No module named dl
Q:/usr/local/src/python/Python-2.1:2149$ 

In each case, lots of CPU by the "python" process was
used as its
"hung" state.  I waited approximately three minutes of
CPU.  A
133Megahertz Pentium with a CPU cache on a Dell
computer is extremely
fast, and ought to finish any test within two minutes. 
Tell me if
I just failed to wait long enough for an increadibly
inefficiently
programmed test to complete, and I'll retry it.  The
fact that it did
not respond to signals except KILL also indicates to me
that it was
comotose.  (This discussion reminds me of a date where
the person
told me that the commands in Unix are very violent
sounding and the
names of the principles used by programmers are very
anti-social.
I'm glad someone thinks that way, since English itself
is far, far
worse, according to
http://www.islandnet.com/~edonon/decoding.htm, and
I said to myself "how can anybody use this language?"
in disgust.
Someday we'll fix that, too (and not just for
historical politeness;
for pureness of utility and efficiency -- snowballed
efficiency!).)

---

***   MEMORY FAULT   test_fork1.py

While the tests were running "test_fork1", I got a
Memory Fault.
Rerunning it manually worked, though, and I hid it
also.  (I did not
test rerunning it.)

While waiting for all these tests to hang, I got tired
of it and
now I want to request that you have all the tests run
in parallel.
That way, it is easier to weed out all the hanging ones
in one shot.
This is easy, right?

***   HUNG   test_compile.py

Next to hang was this one:

$ python ./Lib/test/test_compile.py
Running tests on argument handling
testing complex args
1 2
1 2
3 4
1 2 3
1 2 3
2 3 4
$

As you can see, it ran OK manually, and this time I had
some output to
look at.  While looking at it I realized that I do not
know if those
are the expected results, and in the house I'm in, I
have to listen to
too much hollaring to be able to learn Python in a few
minutes like
I am usually able to do in proper environments.

***   HUNG   test_doctest.py

test_doctest.py passed manually but automatically hung,
too.
It had too much output to include it all, but the last
line said
the test passed.


***   HUNG & SEGFAULT test_threadedtempfile.py

For test_threadedtempfile, I got a bad error:

$ python Lib/test/test_threadedtempfile.py 
Creating
Starting
Reaping
Segmentation fault (core dumped)
$ rm *core
$ python Lib/test/test_threadedtempfile.py 
Creating
Starting
Reaping
^C^C^C^Z
^Z^X^C
Killed
$ 
$ jobs
[1]-  Stopped                 less README
[2]+  Stopped                 MAKE=gmake gmake test
$ sync
$ rm Lib/test/test_threadedt

So far, a few tests ran better the second time than the
first.  Is
the compiling working better than the interpreting?

---

Brad Allen <Ulmo@Q.Net>

*

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416901&group_id=5470


From noreply@sourceforge.net  Wed Apr 18 02:09:06 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 17 Apr 2001 18:09:06 -0700
Subject: [Python-bugs-list] [ python-Bugs-416039 ] pstats browser crashes
Message-ID: <E14pgSw-00010P-00@usw-sf-web3.sourceforge.net>

Bugs item #416039, was updated on 2001-04-13 15:55
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416039&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 7
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Eric S. Raymond (esr)
Summary: pstats browser crashes

Initial Comment:
My very first attempt to use the pstats browser failed
immediately.

w221:~/src/python/dist/src/Tools/compiler> python2.1
../../Lib/pstats.py compiler/__init__.py.prof 
Welcome to the profile statistics browser.
% help

Documented commands (type help <topic>):
========================================
EOF             add             callees        
callers         quit           
read            reverse         sort           
stats           strip           

Undocumented commands:
======================
help            

% callers
Traceback (most recent call last):
  File "../../Lib/pstats.py", line 646, in ?
    ProfileBrowser(initprofile).cmdloop()
  File "../../Lib/cmd.py", line 86, in cmdloop
    stop = self.onecmd(line)
  File "../../Lib/cmd.py", line 124, in onecmd
    return func(arg)
  File "../../Lib/pstats.py", line 580, in do_callers
    return self.generic('callers', line)
  File "../../Lib/pstats.py", line 563, in generic
    apply(getattr(self.stats, fn), processed)
AttributeError: Stats instance has no attribute
'callers'

----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-04-17 18:09

Message:
Logged In: YES 
user_id=31392

Eric-- If you fixed the bug, please close the bug report.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416039&group_id=5470


From noreply@sourceforge.net  Wed Apr 18 02:10:23 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 17 Apr 2001 18:10:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-416906 ] readlines() corrupts file opened for 'a'
Message-ID: <E14pgUB-00027Y-00@usw-sf-web2.sourceforge.net>

Bugs item #416906, was updated on 2001-04-17 18:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416906&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: readlines() corrupts file opened for 'a'

Initial Comment:
Version 2.1 final release for Windows (using Idle)
Windows 98 2nd edition

f=open('c:\My Documents\textfile.txt', 'a')
f.write('hello file\n')
f.readlines()

raises the following error - it probably should.

Traceback (most recent call last):
  File "<pyshell#6>", line 1, in ?
    f.readlines()
IOError: [Errno 9] Bad file descriptor

However, the file gets a bunch of garbage appended to 
it.  In some cases, the entire contents of the GUI 
window gets appended.   

In Redhat 6.2 (also with Version 2.1 Final)the same 
code just erases the file.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416906&group_id=5470


From noreply@sourceforge.net  Wed Apr 18 02:23:17 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 17 Apr 2001 18:23:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-412436 ] compileall doesn't notice syntax errors
Message-ID: <E14pggf-00045I-00@usw-sf-web1.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: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Jeremy Hylton (jhylton)
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.


----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-04-17 18:23

Message:
Logged In: YES 
user_id=31392

Fixed in rev 1.9 of compileall.py.  Note that this fix
causes a bunch of changes to the test suite, so that files
containing syntaxerrors are not compiled by compileall.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-04-13 14:16

Message:
Logged In: YES 
user_id=31392

Will fix following the 2.1 release


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-04-13 07:31

Message:
Logged In: YES 
user_id=31392

I think this is easy enough to fix, but I don't know what
unintended side-effects the fix will have.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=412436&group_id=5470


From noreply@sourceforge.net  Wed Apr 18 04:58:40 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 17 Apr 2001 20:58:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-416943 ] 2.1 segfaults on pydoc HTTP
Message-ID: <E14pj72-00043A-00@usw-sf-web2.sourceforge.net>

Bugs item #416943, was updated on 2001-04-17 20:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416943&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Andy Dustman (adustman)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.1 segfaults on pydoc HTTP 

Initial Comment:
Platform info: 2.1 final, Red Hat 7.1 beta for i386.

Run pydoc -p xxx. Pull up info on a C extension module.
Now
recompile that module so that it changes in a
significant way.
Try to pull it up again and segfault occurs.

#0  0x0808db62 in PyString_FromString (str=0x0) at
Objects/stringobject.c:89
84	}
85	
86	PyObject *
87	PyString_FromString(const char *str)
88	{
89		register size_t size = strlen(str);
90		register PyStringObject *op;
91		if (size > INT_MAX) {
92			PyErr_SetString(PyExc_OverflowError,
93				"string is too long for a Python string");
(gdb) frame 1
#1  0x0808d003 in PyObject_GetAttrString (v=0x8164ec0, 
    name=0x80c888c "__name__") at Objects/object.c:1002
1002			return (*v->ob_type->tp_getattr)(v, name);
(gdb) list
997				     v->ob_type->tp_name,
998				     name);
999			return NULL;
1000		}
1001		else {
1002			return (*v->ob_type->tp_getattr)(v, name);
1003		}
1004	}
1005	
1006	int
(gdb) print (*v->ob_type->tp_getattr)
$1 = {PyObject *()} 0x808b3c8 <meth_getattr>
$6 = {ob_refcnt = 3, ob_type = 0x80bb920, ob_size = 0, 
  tp_name = 0x80aa94e "builtin_function_or_method",
tp_basicsize = 16, 
  tp_itemsize = 0, tp_dealloc = 0x808b390
<meth_dealloc>, tp_print = 0, 
  tp_getattr = 0x808b3c8 <meth_getattr>, tp_setattr =
0, 
  tp_compare = 0x808b550 <meth_compare>, tp_repr =
0x808b4ec <meth_repr>, 
  tp_as_number = 0x0, tp_as_sequence = 0x0,
tp_as_mapping = 0x0, 
  tp_hash = 0x808b5a4 <meth_hash>, tp_call = 0, tp_str
= 0, tp_getattro = 0, 
  tp_setattro = 0, tp_as_buffer = 0x0, tp_flags = 0,
tp_doc = 0x0, 
  tp_traverse = 0, tp_clear = 0, tp_richcompare = 0,
tp_weaklistoffset = 0}
(gdb) print ((PyCFunctionObject *)v)->m_ml
$7 = (PyMethodDef *) 0x401c7ecc
(gdb) print
$8 = 0x0
(gdb) list meth_getattr
67		free_list = m;
68	}
69	
70	static PyObject *
71	meth_getattr(PyCFunctionObject *m, char *name)
72	{
73		if (strcmp(name, "__name__") == 0) {
74			return PyString_FromString(m->m_ml->ml_name);
75		}
76		if (strcmp(name, "__doc__") == 0) {

((PyCFunctionObject *)v)->m_ml->ml_name ==
m->m_ml->ml_name == NULL. From what I can tell, all
members of v->m_ml are NULL. Note that name is getting
smashed somewhere, probably after the call at
Objects/object.c:1002.

Feel free to contact me for further information if
necessary. Complete backtrace attached.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416943&group_id=5470


From noreply@sourceforge.net  Wed Apr 18 05:03:21 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 17 Apr 2001 21:03:21 -0700
Subject: [Python-bugs-list] [ python-Bugs-416944 ] 2.0: cum sympt; w/gdb bktr; OBSD2.8.
Message-ID: <E14pjBZ-0006RQ-00@usw-sf-web1.sourceforge.net>

Bugs item #416944, was updated on 2001-04-17 21:03
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416944&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Brad Allen (valaulmo)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.0: cum sympt; w/gdb bktr; OBSD2.8.

Initial Comment:
Reverted to Python 2.0 + all patches on patch pages,
still with OpenBSD 2.8.  Only non-default module set is
zlib (needed for Mojo Nation according to the docs). 
System is Pentium 133MHz.

Ok, I'm getting better at this now.  This time, I ran
GDB on it, since I noticed that one of the bugs may
have cumulative dependent symptoms.  Also, I'm typing
this bug report into the web browser so that it wraps
correctly (I'll cross my fingers that it doesn't crash
though; that's why I prefer Emacs; I suppose I could
try SSL W3 Emacs but that is hard; not now.)

Here is the gdb output where it did die:

[... lots of tests ...]
test_long

Program received signal SIGSEGV, Segmentation fault.
0x4017bc2f in _thread_machdep_switch ()
(gdb) bt
#0  0x4017bc2f in _thread_machdep_switch ()
#1  0x401c8308 in _sigq_check_reqd ()
#2  0x4017ba66 in _thread_kern_sig_undefer ()
#3  0x4017eb68 in pthread_cond_signal ()
#4  0x1510d in PyThread_release_lock (lock=0x27c320) at
thread_pthread.h:344
#5  0x43006 in eval_code2 (co=0x3c7d80,
globals=0x3c104c, locals=0x0, 
    args=0x25cd58, argcount=2, kws=0x25cd60, kwcount=0,
defs=0x0, defcount=0, 
    owner=0x0) at ceval.c:617
#6  0x450b3 in eval_code2 (co=0x3c7f40,
globals=0x3c104c, locals=0x0, 
    args=0x1a4d60, argcount=1, kws=0x1a4d64, kwcount=0,
defs=0x0, defcount=0, 
    owner=0x0) at ceval.c:1850
#7  0x450b3 in eval_code2 (co=0x4221c0,
globals=0x3c104c, locals=0x0, 
    args=0x39a140, argcount=0, kws=0x39a140, kwcount=0,
defs=0x29c1b8, 
    defcount=1, owner=0x0) at ceval.c:1850
#8  0x450b3 in eval_code2 (co=0x41c900,
globals=0x3c104c, locals=0x3c104c, 
    args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0,
defcount=0, owner=0x0)
    at ceval.c:1850
#9  0x42625 in PyEval_EvalCode (co=0x41c900,
globals=0x3c104c, locals=0x3c104c)
    at ceval.c:319
#10 0xacff in PyImport_ExecCodeModuleEx
(name=0xdfbfd180 "test_long", 
    co=0x41c900, pathname=0xdfbfcce0
"./Lib/test/test_long.py") at import.c:495
#11 0xb30a in load_source_module (name=0xdfbfd180
"test_long", 
    pathname=0xdfbfcce0 "./Lib/test/test_long.py",
fp=0x401fa83c)
    at import.c:758
#12 0xbc23 in load_module (name=0xdfbfd180 "test_long",
fp=0x401fa83c, 
    buf=0xdfbfcce0 "./Lib/test/test_long.py", type=1)
at import.c:1227
#13 0xc8fb in import_submodule (mod=0x1140fc,
subname=0xdfbfd180 "test_long", 
    fullname=0xdfbfd180 "test_long") at import.c:1755
#14 0xc4ca in load_next (mod=0x1140fc, altmod=0x1140fc,
p_name=0xdfbfd58c, 
    buf=0xdfbfd180 "test_long", p_buflen=0xdfbfd17c) at
import.c:1611
#15 0xc142 in import_module_ex (name=0x0,
globals=0x14624c, locals=0x1a538c, 
    fromlist=0x29c02c) at import.c:1462
---Type <return> to continue, or q <return> to quit---
#16 0xc277 in PyImport_ImportModuleEx (name=0x19f0d4
"test_long", 
    globals=0x14624c, locals=0x1a538c,
fromlist=0x29c02c) at import.c:1503
#17 0x3ce47 in builtin___import__ (self=0x0,
args=0x3b198c) at bltinmodule.c:31
#18 0x4668d in call_builtin (func=0x141070,
arg=0x3b198c, kw=0x0)
    at ceval.c:2650
#19 0x46507 in PyEval_CallObjectWithKeywords
(func=0x141070, arg=0x3b198c, 
    kw=0x0) at ceval.c:2618
#20 0x453ac in eval_code2 (co=0x1cc240,
globals=0x14624c, locals=0x0, 
    args=0x15fdcc, argcount=5, kws=0x15fde0, kwcount=0,
defs=0x1c4738, 
    defcount=1, owner=0x0) at ceval.c:1951
#21 0x450b3 in eval_code2 (co=0x1c9f00,
globals=0x14624c, locals=0x0, 
    args=0x140f44, argcount=0, kws=0x140f44, kwcount=0,
defs=0x18d918, 
    defcount=10, owner=0x0) at ceval.c:1850
#22 0x450b3 in eval_code2 (co=0x1c9f80,
globals=0x14624c, locals=0x14624c, 
    args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0,
defcount=0, owner=0x0)
    at ceval.c:1850
#23 0x42625 in PyEval_EvalCode (co=0x1c9f80,
globals=0x14624c, locals=0x14624c)
    at ceval.c:319
#24 0x1272f in run_node (n=0x155400, 
    filename=0xdfbfdb5a "./Lib/test/regrtest.py",
globals=0x14624c, 
    locals=0x14624c) at pythonrun.c:886
#25 0x126e8 in run_err_node (n=0x155400, 
    filename=0xdfbfdb5a "./Lib/test/regrtest.py",
globals=0x14624c, 
    locals=0x14624c) at pythonrun.c:874
#26 0x126c4 in PyRun_FileEx (fp=0x401fa7e4, 
    filename=0xdfbfdb5a "./Lib/test/regrtest.py",
start=257, globals=0x14624c, 
    locals=0x14624c, closeit=1) at pythonrun.c:866
#27 0x11cfe in PyRun_SimpleFileEx (fp=0x401fa7e4, 
    filename=0xdfbfdb5a "./Lib/test/regrtest.py",
closeit=1) at pythonrun.c:579
#28 0x118f3 in PyRun_AnyFileEx (fp=0x401fa7e4, 
    filename=0xdfbfdb5a "./Lib/test/regrtest.py",
closeit=1) at pythonrun.c:459
#29 0x24bb in Py_Main (argc=2, argv=0xdfbfdac8) at
main.c:289
---Type <return> to continue, or q <return> to quit---
#30 0x17b5 in main (argc=4, argv=0xdfbfdac8) at
python.c:10
(gdb) 

Once again, I will attach the config.* (config.cache,
etc.) to this in a file.

Brad Allen <Ulmo@Q.Net>

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416944&group_id=5470


From noreply@sourceforge.net  Wed Apr 18 05:16:20 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 17 Apr 2001 21:16:20 -0700
Subject: [Python-bugs-list] [ python-Bugs-416039 ] pstats browser crashes
Message-ID: <E14pjO8-0006eu-00@usw-sf-web1.sourceforge.net>

Bugs item #416039, was updated on 2001-04-13 15:55
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416039&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 7
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Eric S. Raymond (esr)
Summary: pstats browser crashes

Initial Comment:
My very first attempt to use the pstats browser failed
immediately.

w221:~/src/python/dist/src/Tools/compiler> python2.1
../../Lib/pstats.py compiler/__init__.py.prof 
Welcome to the profile statistics browser.
% help

Documented commands (type help <topic>):
========================================
EOF             add             callees        
callers         quit           
read            reverse         sort           
stats           strip           

Undocumented commands:
======================
help            

% callers
Traceback (most recent call last):
  File "../../Lib/pstats.py", line 646, in ?
    ProfileBrowser(initprofile).cmdloop()
  File "../../Lib/cmd.py", line 86, in cmdloop
    stop = self.onecmd(line)
  File "../../Lib/cmd.py", line 124, in onecmd
    return func(arg)
  File "../../Lib/pstats.py", line 580, in do_callers
    return self.generic('callers', line)
  File "../../Lib/pstats.py", line 563, in generic
    apply(getattr(self.stats, fn), processed)
AttributeError: Stats instance has no attribute
'callers'

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-17 21:16

Message:
Logged In: YES 
user_id=6380

Jeremy, since you reported the problem, it is at least
polite to report whether the applied fix made your problem
go away.  Did it? (Eric *did* check something in that
claimed to deal with a reported bug.) 

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-04-17 18:09

Message:
Logged In: YES 
user_id=31392

Eric-- If you fixed the bug, please close the bug report.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416039&group_id=5470


From noreply@sourceforge.net  Wed Apr 18 05:17:57 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 17 Apr 2001 21:17:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-416906 ] readlines() corrupts file opened for 'a'
Message-ID: <E14pjPh-0002xp-00@usw-sf-web3.sourceforge.net>

Bugs item #416906, was updated on 2001-04-17 18:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416906&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: readlines() corrupts file opened for 'a'

Initial Comment:
Version 2.1 final release for Windows (using Idle)
Windows 98 2nd edition

f=open('c:\My Documents\textfile.txt', 'a')
f.write('hello file\n')
f.readlines()

raises the following error - it probably should.

Traceback (most recent call last):
  File "<pyshell#6>", line 1, in ?
    f.readlines()
IOError: [Errno 9] Bad file descriptor

However, the file gets a bunch of garbage appended to 
it.  In some cases, the entire contents of the GUI 
window gets appended.   

In Redhat 6.2 (also with Version 2.1 Final)the same 
code just erases the file.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-17 21:17

Message:
Logged In: YES 
user_id=6380

Assigned to Tim, because he believes that this is a
Microsoft bug.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416906&group_id=5470


From noreply@sourceforge.net  Wed Apr 18 06:29:22 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 17 Apr 2001 22:29:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-416951 ] Problem with dictionary default argument
Message-ID: <E14pkWo-000504-00@usw-sf-web2.sourceforge.net>

Bugs item #416951, was updated on 2001-04-17 22:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416951&group_id=5470

Category: Parser/Compiler
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem with dictionary default argument

Initial Comment:
-- Python 2.0 Win32 --

It seems to be that _default argument values_ can be 
changed permanently if they are dictionaries.

Code sample:

def f(a = 1):
  print a
  a = 2

>>>f()
1
>>>f()
1

--> ok

def g(mydic = {}):
  print mydic
  mydic["test"] = 1

>>>g()
{}
>>>g()
{'test': 1}

--> bad (default argument value for 'mydic' changed)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416951&group_id=5470


From noreply@sourceforge.net  Wed Apr 18 10:08:31 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 18 Apr 2001 02:08:31 -0700
Subject: [Python-bugs-list] [ python-Bugs-416951 ] Problem with dictionary default argument
Message-ID: <E14pnwt-0007T6-00@usw-sf-web2.sourceforge.net>

Bugs item #416951, was updated on 2001-04-17 22:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416951&group_id=5470

Category: Parser/Compiler
>Group: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem with dictionary default argument

Initial Comment:
-- Python 2.0 Win32 --

It seems to be that _default argument values_ can be 
changed permanently if they are dictionaries.

Code sample:

def f(a = 1):
  print a
  a = 2

>>>f()
1
>>>f()
1

--> ok

def g(mydic = {}):
  print mydic
  mydic["test"] = 1

>>>g()
{}
>>>g()
{'test': 1}

--> bad (default argument value for 'mydic' changed)

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-04-18 02:08

Message:
Logged In: YES 
user_id=31435

Not a bug.  Please see the Python FAQ entry 6.25, "Why are 
default values sometimes shared between objects?"

http://www.python.org/cgi-bin/faqw.py?
req=show&file=faq06.025.htp

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416951&group_id=5470


From noreply@sourceforge.net  Wed Apr 18 10:39:03 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 18 Apr 2001 02:39:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-416906 ] readlines() corrupts file opened for 'a'
Message-ID: <E14poQR-0007qh-00@usw-sf-web2.sourceforge.net>

Bugs item #416906, was updated on 2001-04-17 18:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416906&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: readlines() corrupts file opened for 'a'

Initial Comment:
Version 2.1 final release for Windows (using Idle)
Windows 98 2nd edition

f=open('c:\My Documents\textfile.txt', 'a')
f.write('hello file\n')
f.readlines()

raises the following error - it probably should.

Traceback (most recent call last):
  File "<pyshell#6>", line 1, in ?
    f.readlines()
IOError: [Errno 9] Bad file descriptor

However, the file gets a bunch of garbage appended to 
it.  In some cases, the entire contents of the GUI 
window gets appended.   

In Redhat 6.2 (also with Version 2.1 Final)the same 
code just erases the file.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-04-18 02:39

Message:
Logged In: YES 
user_id=31435

Back to you, Guido:  you're the one fond of arguing that MS 
is within its rights to do anything whatsoever when the 
rules for C stdio are broken <wink>.

Seriously, MS won't "fix" this (they'll deny it's broken).  
Same kind of thing happens in straight C under MS.

BTW, note that Anonymous did not claim it's an MS bug:  two 
different bugs were claimed (Win98SE appends crap, RH 6.2 
destroys the whole file).

I don't see a realistic choice here but to say "hmm -- 
tough luck, don't do that".

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-17 21:17

Message:
Logged In: YES 
user_id=6380

Assigned to Tim, because he believes that this is a
Microsoft bug.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416906&group_id=5470


From noreply@sourceforge.net  Wed Apr 18 10:47:06 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 18 Apr 2001 02:47:06 -0700
Subject: [Python-bugs-list] [ python-Bugs-416824 ] Python 2.1 installer freezes on Win 2000
Message-ID: <E14poYE-0007wn-00@usw-sf-web2.sourceforge.net>

Bugs item #416824, was updated on 2001-04-17 13:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416824&group_id=5470

Category: Windows
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Xavier Lagraula (xlagraula)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.1 installer freezes on Win 2000

Initial Comment:
My aim is to install Python 2.1 on a Windows 2000 
Professionnal (French) workstation.

The windows intaller works well until it show the 
screen where one can choose which parts of the product 
one wants to install (third window).

If one hit the "next" button without touching anything 
else, the installer will definitively freeze. Trying 
to stop it using the pop-up menu in the task bar will 
result in a few seconds pause, followed by an error 
window telling that the 16-bit subsystem has not 
answered in time to the stop request. The possibility 
is then given to kill it, eventually leaving the 16 
bit subsystem unstable.

I tried to download the installer from both the main 
site and sourceforge, to check if it came from a 
corrupted file. Same result.

The workaround is simple: just uncheck at least one of 
the check boxes, click "next", it won't freeze. Now 
click "back", re-check the check boxe, click "next" 
and... tada! It won't freeze neither. Now you can go 
on installing the whole package. Haven't thoroughly 
tested it yet, but seems to be working fine.

This problem is not really serious as one can easily 
bypass it, and as it doesn't involve the langage or 
the interpreter themselves. Nevertheless, it IS a 
bug...

Regards,
  Xavier


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-04-18 02:47

Message:
Logged In: YES 
user_id=31435

This is the only freeze report we've seen for Win2K.

Did you do something bizarre <wink>?  For example, we've 
had one-of-a-kind reports from people in the past who tried 
to install on NT or Win2K while logged in to a Restricted 
User account.  Were you?  Or were you logged in to an 
Administrator account?  Or were you logged in as something 
in between?

Could you try it on another Win2K (French) box?  We have a 
poor track record when it comes to fixing Microsoft's bugs 
for them, and in the absence of more info I have to assume 
it's a bug unique to the specific box you used.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416824&group_id=5470


From noreply@sourceforge.net  Wed Apr 18 13:31:06 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 18 Apr 2001 05:31:06 -0700
Subject: [Python-bugs-list] [ python-Bugs-416824 ] Python 2.1 installer freezes on Win 2000
Message-ID: <E14pr6w-0001UE-00@usw-sf-web2.sourceforge.net>

Bugs item #416824, was updated on 2001-04-17 13:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416824&group_id=5470

Category: Windows
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Xavier Lagraula (xlagraula)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.1 installer freezes on Win 2000

Initial Comment:
My aim is to install Python 2.1 on a Windows 2000 
Professionnal (French) workstation.

The windows intaller works well until it show the 
screen where one can choose which parts of the product 
one wants to install (third window).

If one hit the "next" button without touching anything 
else, the installer will definitively freeze. Trying 
to stop it using the pop-up menu in the task bar will 
result in a few seconds pause, followed by an error 
window telling that the 16-bit subsystem has not 
answered in time to the stop request. The possibility 
is then given to kill it, eventually leaving the 16 
bit subsystem unstable.

I tried to download the installer from both the main 
site and sourceforge, to check if it came from a 
corrupted file. Same result.

The workaround is simple: just uncheck at least one of 
the check boxes, click "next", it won't freeze. Now 
click "back", re-check the check boxe, click "next" 
and... tada! It won't freeze neither. Now you can go 
on installing the whole package. Haven't thoroughly 
tested it yet, but seems to be working fine.

This problem is not really serious as one can easily 
bypass it, and as it doesn't involve the langage or 
the interpreter themselves. Nevertheless, it IS a 
bug...

Regards,
  Xavier


----------------------------------------------------------------------

>Comment By: Xavier Lagraula (xlagraula)
Date: 2001-04-18 05:31

Message:
Logged In: YES 
user_id=198402

To answer your question: I was logged using the 
Administrator account ("Administrateur", in fact, on a 
french box). Like most of the time, because many software 
which are not specifically written for NT won't run 
correctly without it. I know this is bad but what else can 
I do?

Anyway I don't have access to another french win2k box. All 
I can do is give you spécific information about my computer:
- PII 400 - 512Mo of PC133 SDRAM
- Asus MB - P3 BF
- Video: GeForce 256 DDR (Hercules) / Hauppauge WinTV
- Sound: SB Live Player!
- Network: 2 SN3200 (PCI, ethernet 10Mbps, ne2000 
compatible)
- SCSI: Diamond Fireport 40 / CDROM x32 (plextor) / CD 
burner (ricoh MP6200s)
- Win2k french SP1 + IE 5.5
- mysql: latest stable version + MyODBC drivers
- apache: latest stable version + PHP
- naviscope (web proxy/dns cache)
- net vampire: v4.0 beta
- ICQ 2000b
- all drivers were up to date 3 weeks ago.

Still, I believe that those symptoms look either like a 
uninitialized variable or a faulty pointer, such bugs that 
can remain hidden except under very specific "context-
specific" circumstances. (Un)checking one of the check 
boxes, by forcing a value in the variable or by allocating 
a memory block would correct the problem and allow the user 
to go on with the installation.

If I can reproduce the bug this evening, I'll try to see if 
the installer eats all CPU while freezed. Could give a clue 
about what's really happenning. I may also try removing 
256Mo of RAM to verify my "pointer hypothesis" (if it makes 
the bug impossible to reproduce, then it has something to 
do with memory allocation. Crude method but quite useful 
sometimes).

Regards,
  Xavier

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-04-18 02:47

Message:
Logged In: YES 
user_id=31435

This is the only freeze report we've seen for Win2K.

Did you do something bizarre <wink>?  For example, we've 
had one-of-a-kind reports from people in the past who tried 
to install on NT or Win2K while logged in to a Restricted 
User account.  Were you?  Or were you logged in to an 
Administrator account?  Or were you logged in as something 
in between?

Could you try it on another Win2K (French) box?  We have a 
poor track record when it comes to fixing Microsoft's bugs 
for them, and in the absence of more info I have to assume 
it's a bug unique to the specific box you used.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416824&group_id=5470


From noreply@sourceforge.net  Wed Apr 18 13:53:04 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 18 Apr 2001 05:53:04 -0700
Subject: [Python-bugs-list] [ python-Bugs-417030 ] print '%*s' fails for unicode string
Message-ID: <E14prSC-0001kH-00@usw-sf-web2.sourceforge.net>

Bugs item #417030, was updated on 2001-04-18 05:53
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417030&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Barry Alan Scott (barry-scott)
Assigned to: Nobody/Anonymous (nobody)
Summary: print '%*s' fails for unicode string

Initial Comment:
Python 2.0 (#8, Dec 13 2000, 09:47:07) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
>>> print '%*s' % (7,u'fred')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: * wants int
>>>


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417030&group_id=5470


From noreply@sourceforge.net  Wed Apr 18 15:00:18 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 18 Apr 2001 07:00:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-416906 ] readlines() corrupts file opened for 'a'
Message-ID: <E14psVG-0002hV-00@usw-sf-web2.sourceforge.net>

Bugs item #416906, was updated on 2001-04-17 18:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416906&group_id=5470

Category: None
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Guido van Rossum (gvanrossum)
Summary: readlines() corrupts file opened for 'a'

Initial Comment:
Version 2.1 final release for Windows (using Idle)
Windows 98 2nd edition

f=open('c:\My Documents\textfile.txt', 'a')
f.write('hello file\n')
f.readlines()

raises the following error - it probably should.

Traceback (most recent call last):
  File "<pyshell#6>", line 1, in ?
    f.readlines()
IOError: [Errno 9] Bad file descriptor

However, the file gets a bunch of garbage appended to 
it.  In some cases, the entire contents of the GUI 
window gets appended.   

In Redhat 6.2 (also with Version 2.1 Final)the same 
code just erases the file.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-18 07:00

Message:
Logged In: YES 
user_id=6380

Writing after reading without an intervening seek() is
illegal in C's stdio, but the Python file object (a thin
wrapper around stdio) doesn't know how to check for this
error condition.  So, we have to say "then don't do this".

Possible point of light: there's discussion on writing a new
I/O library for Python that avoids relying on stdio.  It
could fix this issue, too.

Closing the bug now.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-04-18 02:39

Message:
Logged In: YES 
user_id=31435

Back to you, Guido:  you're the one fond of arguing that MS 
is within its rights to do anything whatsoever when the 
rules for C stdio are broken <wink>.

Seriously, MS won't "fix" this (they'll deny it's broken).  
Same kind of thing happens in straight C under MS.

BTW, note that Anonymous did not claim it's an MS bug:  two 
different bugs were claimed (Win98SE appends crap, RH 6.2 
destroys the whole file).

I don't see a realistic choice here but to say "hmm -- 
tough luck, don't do that".

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-17 21:17

Message:
Logged In: YES 
user_id=6380

Assigned to Tim, because he believes that this is a
Microsoft bug.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416906&group_id=5470


From noreply@sourceforge.net  Wed Apr 18 17:09:38 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 18 Apr 2001 09:09:38 -0700
Subject: [Python-bugs-list] [ python-Bugs-417093 ] Case sensitive import on windows
Message-ID: <E14puWQ-0000sV-00@usw-sf-web1.sourceforge.net>

Bugs item #417093, was updated on 2001-04-18 09:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417093&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Nobody/Anonymous (nobody)
Summary: Case sensitive import on windows

Initial Comment:
Consider the following files in the current directory:

Spam.py
spam/__init__.py

Using python 2.0:

Python 2.0 (#8, Oct 16 2000, 17:27:58) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> import Spam
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
NameError: Case mismatch for module name Spam
(filename spam)
>>> import spam; print spam
<module 'spam' from 'spam\__init__.py'>
>>>

Using python 2.1:

Python 2.1c2 (#14, Apr 15 2001, 21:29:05) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> import Spam
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
SystemError: NULL result without error in call_object
>>> import spam; print spam
<module 'spam' from 'spam\__init__.py'>
>>>


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417093&group_id=5470


From noreply@sourceforge.net  Wed Apr 18 19:24:04 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 18 Apr 2001 11:24:04 -0700
Subject: [Python-bugs-list] [ python-Bugs-416906 ] readlines() corrupts file opened for 'a'
Message-ID: <E14pwcW-00051u-00@usw-sf-web3.sourceforge.net>

Bugs item #416906, was updated on 2001-04-17 18:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416906&group_id=5470

Category: None
Group: None
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Guido van Rossum (gvanrossum)
Summary: readlines() corrupts file opened for 'a'

Initial Comment:
Version 2.1 final release for Windows (using Idle)
Windows 98 2nd edition

f=open('c:\My Documents\textfile.txt', 'a')
f.write('hello file\n')
f.readlines()

raises the following error - it probably should.

Traceback (most recent call last):
  File "<pyshell#6>", line 1, in ?
    f.readlines()
IOError: [Errno 9] Bad file descriptor

However, the file gets a bunch of garbage appended to 
it.  In some cases, the entire contents of the GUI 
window gets appended.   

In Redhat 6.2 (also with Version 2.1 Final)the same 
code just erases the file.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-04-18 11:24

Message:
Logged In: YES 
user_id=31435

Note that the problem isn't *just* output followed by input 
without an intervening positioning operation:  the file was 
opened in append mode ("a"), not append-update mode ("a+"), 
so input isn't "legal" period.  MS can mangle part of the 
file even if there is a seek() in between (but doesn't if 
opened in append-update mode instead).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-18 07:00

Message:
Logged In: YES 
user_id=6380

Writing after reading without an intervening seek() is
illegal in C's stdio, but the Python file object (a thin
wrapper around stdio) doesn't know how to check for this
error condition.  So, we have to say "then don't do this".

Possible point of light: there's discussion on writing a new
I/O library for Python that avoids relying on stdio.  It
could fix this issue, too.

Closing the bug now.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-04-18 02:39

Message:
Logged In: YES 
user_id=31435

Back to you, Guido:  you're the one fond of arguing that MS 
is within its rights to do anything whatsoever when the 
rules for C stdio are broken <wink>.

Seriously, MS won't "fix" this (they'll deny it's broken).  
Same kind of thing happens in straight C under MS.

BTW, note that Anonymous did not claim it's an MS bug:  two 
different bugs were claimed (Win98SE appends crap, RH 6.2 
destroys the whole file).

I don't see a realistic choice here but to say "hmm -- 
tough luck, don't do that".

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-17 21:17

Message:
Logged In: YES 
user_id=6380

Assigned to Tim, because he believes that this is a
Microsoft bug.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416906&group_id=5470


From noreply@sourceforge.net  Wed Apr 18 19:41:05 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 18 Apr 2001 11:41:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-416824 ] Python 2.1 installer freezes on Win 2000
Message-ID: <E14pwsz-000309-00@usw-sf-web1.sourceforge.net>

Bugs item #416824, was updated on 2001-04-17 13:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416824&group_id=5470

Category: Windows
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Xavier Lagraula (xlagraula)
>Assigned to: Tim Peters (tim_one)
Summary: Python 2.1 installer freezes on Win 2000

Initial Comment:
My aim is to install Python 2.1 on a Windows 2000 
Professionnal (French) workstation.

The windows intaller works well until it show the 
screen where one can choose which parts of the product 
one wants to install (third window).

If one hit the "next" button without touching anything 
else, the installer will definitively freeze. Trying 
to stop it using the pop-up menu in the task bar will 
result in a few seconds pause, followed by an error 
window telling that the 16-bit subsystem has not 
answered in time to the stop request. The possibility 
is then given to kill it, eventually leaving the 16 
bit subsystem unstable.

I tried to download the installer from both the main 
site and sourceforge, to check if it came from a 
corrupted file. Same result.

The workaround is simple: just uncheck at least one of 
the check boxes, click "next", it won't freeze. Now 
click "back", re-check the check boxe, click "next" 
and... tada! It won't freeze neither. Now you can go 
on installing the whole package. Haven't thoroughly 
tested it yet, but seems to be working fine.

This problem is not really serious as one can easily 
bypass it, and as it doesn't involve the langage or 
the interpreter themselves. Nevertheless, it IS a 
bug...

Regards,
  Xavier


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-04-18 11:41

Message:
Logged In: YES 
user_id=31435

It's fine that you were logged in as an Administrator.  
Indeed, things probably have the *best* chance of working 
then.

Please note that we didn't write the installer code:  the 
Wise installer is a commercial product, which they kindly 
let Python use for free:

http://www.wisesolutions.com/

We have no access to the source code, either.  So if you 
*do*, for example, find evidence of an uninitialized 
variable, there's nothing we can do about it.  Alas, I 
doubt Wise will do anything about it either, as the version 
of the product we're using is over 5 years old (and looks 
like they stopped supporting it a few years ago).

OTOH, the Windows installer is used many thousands of 
times, and this is the only freeze report we've seen.  If 
we don't see another, the presumption still has to favor 
that there's something flaky about your particular machine.

BTW, I've never tried it on a machine w/ 512Mb of RAM, so 
perhaps that is relevant.  Have tried it on machines w/ 
256Mb.

----------------------------------------------------------------------

Comment By: Xavier Lagraula (xlagraula)
Date: 2001-04-18 05:31

Message:
Logged In: YES 
user_id=198402

To answer your question: I was logged using the 
Administrator account ("Administrateur", in fact, on a 
french box). Like most of the time, because many software 
which are not specifically written for NT won't run 
correctly without it. I know this is bad but what else can 
I do?

Anyway I don't have access to another french win2k box. All 
I can do is give you spécific information about my computer:
- PII 400 - 512Mo of PC133 SDRAM
- Asus MB - P3 BF
- Video: GeForce 256 DDR (Hercules) / Hauppauge WinTV
- Sound: SB Live Player!
- Network: 2 SN3200 (PCI, ethernet 10Mbps, ne2000 
compatible)
- SCSI: Diamond Fireport 40 / CDROM x32 (plextor) / CD 
burner (ricoh MP6200s)
- Win2k french SP1 + IE 5.5
- mysql: latest stable version + MyODBC drivers
- apache: latest stable version + PHP
- naviscope (web proxy/dns cache)
- net vampire: v4.0 beta
- ICQ 2000b
- all drivers were up to date 3 weeks ago.

Still, I believe that those symptoms look either like a 
uninitialized variable or a faulty pointer, such bugs that 
can remain hidden except under very specific "context-
specific" circumstances. (Un)checking one of the check 
boxes, by forcing a value in the variable or by allocating 
a memory block would correct the problem and allow the user 
to go on with the installation.

If I can reproduce the bug this evening, I'll try to see if 
the installer eats all CPU while freezed. Could give a clue 
about what's really happenning. I may also try removing 
256Mo of RAM to verify my "pointer hypothesis" (if it makes 
the bug impossible to reproduce, then it has something to 
do with memory allocation. Crude method but quite useful 
sometimes).

Regards,
  Xavier

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-04-18 02:47

Message:
Logged In: YES 
user_id=31435

This is the only freeze report we've seen for Win2K.

Did you do something bizarre <wink>?  For example, we've 
had one-of-a-kind reports from people in the past who tried 
to install on NT or Win2K while logged in to a Restricted 
User account.  Were you?  Or were you logged in to an 
Administrator account?  Or were you logged in as something 
in between?

Could you try it on another Win2K (French) box?  We have a 
poor track record when it comes to fixing Microsoft's bugs 
for them, and in the absence of more info I have to assume 
it's a bug unique to the specific box you used.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416824&group_id=5470


From noreply@sourceforge.net  Wed Apr 18 23:22:29 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 18 Apr 2001 15:22:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-417176 ] MultiFile.read() includes CRLF boundary
Message-ID: <E14q0LF-0000rD-00@usw-sf-web2.sourceforge.net>

Bugs item #417176, was updated on 2001-04-18 15:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417176&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martijn Pieters (mjpieters)
Assigned to: Nobody/Anonymous (nobody)
Summary: MultiFile.read() includes CRLF boundary

Initial Comment:
multifile.MultiFile.readlines()and .read() will return 
a body of a multipart message including the line 
delimiter that is to be regarded part of the boundary.

In a partial multipart message like:

--BoundaryHere
Content-Type: text/plain

1
2
3
4
--BoundaryHere

the message within the delimiters does not include the 
final line delimiter (CRLF or LF or whatnot) after the 
line reading '4'; it is considered part of the 
boundary. MultiFile however, returns it as part of the 
body.

See RFC2046 section 5.1.1. In the usual text 
formatting of the RFC, you'll find the definition and 
explanation in the first two paragraphs of page 19.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417176&group_id=5470


From noreply@sourceforge.net  Wed Apr 18 23:26:11 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 18 Apr 2001 15:26:11 -0700
Subject: [Python-bugs-list] [ python-Bugs-417178 ] uu.py doesn't close in_file on exception
Message-ID: <E14q0Op-0004ck-00@usw-sf-web1.sourceforge.net>

Bugs item #417178, was updated on 2001-04-18 15:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417178&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: uu.py doesn't close in_file on exception

Initial Comment:
When decoding a uu-encoded file with uu.decode(), the 
given in_file is not closed before a uu.Error is 
raised.

This leads to problems on Win32 when trying to 
os.remove() the file after the exception was raised, 
because the permission to remove the file is denied.

Maybe the same problem is present for out_file.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417178&group_id=5470


From noreply@sourceforge.net  Wed Apr 18 23:30:27 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 18 Apr 2001 15:30:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-416824 ] Python 2.1 installer freezes on Win 2000
Message-ID: <E14q0Sx-00080D-00@usw-sf-web3.sourceforge.net>

Bugs item #416824, was updated on 2001-04-17 13:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416824&group_id=5470

Category: Windows
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Xavier Lagraula (xlagraula)
Assigned to: Tim Peters (tim_one)
Summary: Python 2.1 installer freezes on Win 2000

Initial Comment:
My aim is to install Python 2.1 on a Windows 2000 
Professionnal (French) workstation.

The windows intaller works well until it show the 
screen where one can choose which parts of the product 
one wants to install (third window).

If one hit the "next" button without touching anything 
else, the installer will definitively freeze. Trying 
to stop it using the pop-up menu in the task bar will 
result in a few seconds pause, followed by an error 
window telling that the 16-bit subsystem has not 
answered in time to the stop request. The possibility 
is then given to kill it, eventually leaving the 16 
bit subsystem unstable.

I tried to download the installer from both the main 
site and sourceforge, to check if it came from a 
corrupted file. Same result.

The workaround is simple: just uncheck at least one of 
the check boxes, click "next", it won't freeze. Now 
click "back", re-check the check boxe, click "next" 
and... tada! It won't freeze neither. Now you can go 
on installing the whole package. Haven't thoroughly 
tested it yet, but seems to be working fine.

This problem is not really serious as one can easily 
bypass it, and as it doesn't involve the langage or 
the interpreter themselves. Nevertheless, it IS a 
bug...

Regards,
  Xavier


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-04-18 15:30

Message:
Logged In: NO 

In case it helps, I've got a win2k pro workstation, 128MB 
ram, and it also hangs on the same page during the 
installation.  Oh, and the workaround you mentioned did not 
work for me.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-04-18 11:41

Message:
Logged In: YES 
user_id=31435

It's fine that you were logged in as an Administrator.  
Indeed, things probably have the *best* chance of working 
then.

Please note that we didn't write the installer code:  the 
Wise installer is a commercial product, which they kindly 
let Python use for free:

http://www.wisesolutions.com/

We have no access to the source code, either.  So if you 
*do*, for example, find evidence of an uninitialized 
variable, there's nothing we can do about it.  Alas, I 
doubt Wise will do anything about it either, as the version 
of the product we're using is over 5 years old (and looks 
like they stopped supporting it a few years ago).

OTOH, the Windows installer is used many thousands of 
times, and this is the only freeze report we've seen.  If 
we don't see another, the presumption still has to favor 
that there's something flaky about your particular machine.

BTW, I've never tried it on a machine w/ 512Mb of RAM, so 
perhaps that is relevant.  Have tried it on machines w/ 
256Mb.

----------------------------------------------------------------------

Comment By: Xavier Lagraula (xlagraula)
Date: 2001-04-18 05:31

Message:
Logged In: YES 
user_id=198402

To answer your question: I was logged using the 
Administrator account ("Administrateur", in fact, on a 
french box). Like most of the time, because many software 
which are not specifically written for NT won't run 
correctly without it. I know this is bad but what else can 
I do?

Anyway I don't have access to another french win2k box. All 
I can do is give you spécific information about my computer:
- PII 400 - 512Mo of PC133 SDRAM
- Asus MB - P3 BF
- Video: GeForce 256 DDR (Hercules) / Hauppauge WinTV
- Sound: SB Live Player!
- Network: 2 SN3200 (PCI, ethernet 10Mbps, ne2000 
compatible)
- SCSI: Diamond Fireport 40 / CDROM x32 (plextor) / CD 
burner (ricoh MP6200s)
- Win2k french SP1 + IE 5.5
- mysql: latest stable version + MyODBC drivers
- apache: latest stable version + PHP
- naviscope (web proxy/dns cache)
- net vampire: v4.0 beta
- ICQ 2000b
- all drivers were up to date 3 weeks ago.

Still, I believe that those symptoms look either like a 
uninitialized variable or a faulty pointer, such bugs that 
can remain hidden except under very specific "context-
specific" circumstances. (Un)checking one of the check 
boxes, by forcing a value in the variable or by allocating 
a memory block would correct the problem and allow the user 
to go on with the installation.

If I can reproduce the bug this evening, I'll try to see if 
the installer eats all CPU while freezed. Could give a clue 
about what's really happenning. I may also try removing 
256Mo of RAM to verify my "pointer hypothesis" (if it makes 
the bug impossible to reproduce, then it has something to 
do with memory allocation. Crude method but quite useful 
sometimes).

Regards,
  Xavier

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-04-18 02:47

Message:
Logged In: YES 
user_id=31435

This is the only freeze report we've seen for Win2K.

Did you do something bizarre <wink>?  For example, we've 
had one-of-a-kind reports from people in the past who tried 
to install on NT or Win2K while logged in to a Restricted 
User account.  Were you?  Or were you logged in to an 
Administrator account?  Or were you logged in as something 
in between?

Could you try it on another Win2K (French) box?  We have a 
poor track record when it comes to fixing Microsoft's bugs 
for them, and in the absence of more info I have to assume 
it's a bug unique to the specific box you used.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416824&group_id=5470


From noreply@sourceforge.net  Wed Apr 18 23:56:38 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 18 Apr 2001 15:56:38 -0700
Subject: [Python-bugs-list] [ python-Bugs-417093 ] Case sensitive import on windows
Message-ID: <E14q0sI-0008IL-00@usw-sf-web3.sourceforge.net>

Bugs item #417093, was updated on 2001-04-18 09:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417093&group_id=5470

>Category: Windows
>Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
>Assigned to: Tim Peters (tim_one)
Summary: Case sensitive import on windows

Initial Comment:
Consider the following files in the current directory:

Spam.py
spam/__init__.py

Using python 2.0:

Python 2.0 (#8, Oct 16 2000, 17:27:58) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> import Spam
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
NameError: Case mismatch for module name Spam
(filename spam)
>>> import spam; print spam
<module 'spam' from 'spam\__init__.py'>
>>>

Using python 2.1:

Python 2.1c2 (#14, Apr 15 2001, 21:29:05) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> import Spam
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
SystemError: NULL result without error in call_object
>>> import spam; print spam
<module 'spam' from 'spam\__init__.py'>
>>>


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-04-18 15:56

Message:
Logged In: YES 
user_id=31435

Assigned to me.  Regardless of what should or shouldn't 
happen, a SystemError is *always* "a bug".


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417093&group_id=5470


From noreply@sourceforge.net  Thu Apr 19 00:32:41 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 18 Apr 2001 16:32:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-416677 ] re.groups misbehaviour
Message-ID: <E14q1RB-0001eU-00@usw-sf-web2.sourceforge.net>

Bugs item #416677, was updated on 2001-04-17 06:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416677&group_id=5470

Category: Regular Expressions
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Andreas Jung (ajung)
>Assigned to: Fredrik Lundh (effbot)
Summary: re.groups misbehaviour

Initial Comment:
import re
 
pat = "[0-9][0-9]"
s="22 the quick 100 brown fox jumps 44 over the xx lazy 33 dog"
 
r = re.compile(pat)
mo = r.match(s)
print mo.groups()
print mo.group(0)

I expected that mo.groups() returns for this testcase a tuple with  3 elements ('22','44','33)
but instead it returns (). mo.group(0) returns as expected '22'.
Is this a bug or an error in the documentation ?



----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-04-18 16:32

Message:
Logged In: YES 
user_id=31435

Assigned to effbot for final disposition.

AFAICT, everything here is working as designed and as 
documented.  Since you have no parentheses in your regexp, 
the only group that exists is the implicit group 0, 
representing the whole match.  .groups() is documented as 
returning all the groups in the match "from 1 up to however 
many groups are in the pattern".  Since there are no groups 
with ordinal larger than 0, that's an empty set, so 
mo.groups() returns an empty tuple.

Sounds more like you want re.findall().  But in that case, 
it would return ['22', '10', '44', '33']:  there's nothing 
in your regexp to prevent it from matching the "10" at the 
start of "100".


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416677&group_id=5470


From noreply@sourceforge.net  Thu Apr 19 03:22:26 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 18 Apr 2001 19:22:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-417212 ] curses.newwin can return pads
Message-ID: <E14q45S-0003cP-00@usw-sf-web2.sourceforge.net>

Bugs item #417212, was updated on 2001-04-18 19:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417212&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: David M. Cooke (dmcooke)
Assigned to: Nobody/Anonymous (nobody)
Summary: curses.newwin can return pads

Initial Comment:
In 2.1 (at least), curses.newwin can return a pad
object if it's called with two arguments, i.e.

win = curses.newwin(0,0)

Since this is actually a pad, win.refresh has to be
called with six arguments -- the syntax used for
refreshing a pad -- instead of as just win.refresh()

Looking at the code for _cursesmodule.c, it appears
that only win.refresh() and win.noutrefresh() take
different arguments depending on whether win is
actually a window or a pad.

It looks like there are three options here: 

- document that the two-argument version of
curses.newwin returns a pad (and hence the six-argument
.refresh() must be used)

- make curses.newwin take four arguments only (as the
two argument version is currently equivalent to newpad)

- have win.refresh() and win.noutrefresh() do sensible
things for pads (although I don't know what that would
be...)

I would think #2 is the best.

Hmm, perhaps there should be a separate object type for
pads, so we can tell the difference between pads and
windows.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417212&group_id=5470


From noreply@sourceforge.net  Thu Apr 19 08:16:18 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 19 Apr 2001 00:16:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-417240 ] [Solaris] warning during build
Message-ID: <E14q8fq-0006x2-00@usw-sf-web2.sourceforge.net>

Bugs item #417240, was updated on 2001-04-19 00:16
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417240&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: papadopo (papadopo)
Assigned to: Nobody/Anonymous (nobody)
Summary: [Solaris] warning during build

Initial Comment:
Hi,

While building on Solaris with Sun's compiler I get
this warning:

$ ./configure --prefix=/usr/local/python-2.1
--with-signal-module --with-threads
$make all
[...]
building '_curses_panel' extension
cc -I. -I/tmp/Python-2.1/./Include -I/usr/local/include
-IInclude/ -c /tmp/Python-2.1/Modules/_curses_panel.c
-o build/temp.solaris-2.7-sun4u-2.1/_curses_panel.o -O
-I. -I./Include -DHAVE_CONFIG_H
"/tmp/Python-2.1/Modules/_curses_panel.c", line 307:
warning: argument #2 is incompatible with prototype:
        prototype: pointer to char :
"/usr/include/panel.h", line 51
        argument : pointer to struct _object {int
ob_refcnt, pointer to struct _typeobject {..} ob_type}
[...]

This is only a warning, not very important.

Best Regards,
Dimitri


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417240&group_id=5470


From noreply@sourceforge.net  Thu Apr 19 09:57:17 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 19 Apr 2001 01:57:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-417290 ] [Solaris] errors in _curses extension
Message-ID: <E14qAFZ-0006sB-00@usw-sf-web3.sourceforge.net>

Bugs item #417290, was updated on 2001-04-19 01:57
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417290&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dimitri Papadopoulos (papadopo)
Assigned to: Nobody/Anonymous (nobody)
Summary: [Solaris] errors in _curses extension

Initial Comment:
Hi,

Building with the Sun compiler on Solaris 7:

$ make all
[...]
building '_curses' extension
cc -I. -I/tmp/Python-2.1/./Include -I/usr/local/include
-IInclude/ -c /tmp/Python-2.1/Modules/_cursesmodule.c
-o build/temp.solaris-2.7-sun4u-2.1/_cursesmodule.o -O
-I. -I./Include -DHAVE_CONFIG_H
"/tmp/Python-2.1/Modules/_cursesmodule.c", line 313:
undefined symbol: attr_t
"/tmp/Python-2.1/Modules/_cursesmodule.c", line 313:
syntax error before or at: arg1
"/tmp/Python-2.1/Modules/_cursesmodule.c", line 313:
undefined symbol: arg1
"/tmp/Python-2.1/Modules/_cursesmodule.c", line 314:
undefined symbol: attr_t
"/tmp/Python-2.1/Modules/_cursesmodule.c", line 314:
syntax error before or at: arg1
[...]
$

Solaris 7 has only <curses.h> not <ncurses.h> and
attr_t seems to be specific to <ncurses.h>.

Regards,
Dimitri



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417290&group_id=5470


From noreply@sourceforge.net  Thu Apr 19 09:57:35 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 19 Apr 2001 01:57:35 -0700
Subject: [Python-bugs-list] [ python-Bugs-417291 ] [Solaris] errors in _curses extension
Message-ID: <E14qAFr-0003VX-00@usw-sf-web1.sourceforge.net>

Bugs item #417291, was updated on 2001-04-19 01:57
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417291&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: [Solaris] errors in _curses extension

Initial Comment:
Hi,

Building with the Sun compiler on Solaris 7:

$ make all
[...]
building '_curses' extension
cc -I. -I/tmp/Python-2.1/./Include -I/usr/local/include
-IInclude/ -c /tmp/Python-2.1/Modules/_cursesmodule.c
-o build/temp.solaris-2.7-sun4u-2.1/_cursesmodule.o -O
-I. -I./Include -DHAVE_CONFIG_H
"/tmp/Python-2.1/Modules/_cursesmodule.c", line 313:
undefined symbol: attr_t
"/tmp/Python-2.1/Modules/_cursesmodule.c", line 313:
syntax error before or at: arg1
"/tmp/Python-2.1/Modules/_cursesmodule.c", line 313:
undefined symbol: arg1
"/tmp/Python-2.1/Modules/_cursesmodule.c", line 314:
undefined symbol: attr_t
"/tmp/Python-2.1/Modules/_cursesmodule.c", line 314:
syntax error before or at: arg1
[...]
$

Solaris 7 has only <curses.h> not <ncurses.h> and
attr_t seems to be specific to <ncurses.h>.

Regards,
Dimitri



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417291&group_id=5470


From noreply@sourceforge.net  Thu Apr 19 09:59:57 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 19 Apr 2001 01:59:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-417290 ] [Solaris] errors in _curses extension
Message-ID: <E14qAI9-0003X0-00@usw-sf-web1.sourceforge.net>

Bugs item #417290, was updated on 2001-04-19 01:57
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417290&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dimitri Papadopoulos (papadopo)
Assigned to: Nobody/Anonymous (nobody)
Summary: [Solaris] errors in _curses extension

Initial Comment:
Hi,

Building with the Sun compiler on Solaris 7:

$ make all
[...]
building '_curses' extension
cc -I. -I/tmp/Python-2.1/./Include -I/usr/local/include
-IInclude/ -c /tmp/Python-2.1/Modules/_cursesmodule.c
-o build/temp.solaris-2.7-sun4u-2.1/_cursesmodule.o -O
-I. -I./Include -DHAVE_CONFIG_H
"/tmp/Python-2.1/Modules/_cursesmodule.c", line 313:
undefined symbol: attr_t
"/tmp/Python-2.1/Modules/_cursesmodule.c", line 313:
syntax error before or at: arg1
"/tmp/Python-2.1/Modules/_cursesmodule.c", line 313:
undefined symbol: arg1
"/tmp/Python-2.1/Modules/_cursesmodule.c", line 314:
undefined symbol: attr_t
"/tmp/Python-2.1/Modules/_cursesmodule.c", line 314:
syntax error before or at: arg1
[...]
$

Solaris 7 has only <curses.h> not <ncurses.h> and
attr_t seems to be specific to <ncurses.h>.

Regards,
Dimitri



----------------------------------------------------------------------

>Comment By: Dimitri Papadopoulos (papadopo)
Date: 2001-04-19 01:59

Message:
Logged In: YES 
user_id=52414

This is with Python 2.1 by the way.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417290&group_id=5470


From noreply@sourceforge.net  Thu Apr 19 10:01:33 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 19 Apr 2001 02:01:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-417240 ] [Solaris] warning during build
Message-ID: <E14qAJh-0003Yq-00@usw-sf-web1.sourceforge.net>

Bugs item #417240, was updated on 2001-04-19 00:16
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417240&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dimitri Papadopoulos (papadopo)
Assigned to: Nobody/Anonymous (nobody)
Summary: [Solaris] warning during build

Initial Comment:
Hi,

While building on Solaris with Sun's compiler I get
this warning:

$ ./configure --prefix=/usr/local/python-2.1
--with-signal-module --with-threads
$make all
[...]
building '_curses_panel' extension
cc -I. -I/tmp/Python-2.1/./Include -I/usr/local/include
-IInclude/ -c /tmp/Python-2.1/Modules/_curses_panel.c
-o build/temp.solaris-2.7-sun4u-2.1/_curses_panel.o -O
-I. -I./Include -DHAVE_CONFIG_H
"/tmp/Python-2.1/Modules/_curses_panel.c", line 307:
warning: argument #2 is incompatible with prototype:
        prototype: pointer to char :
"/usr/include/panel.h", line 51
        argument : pointer to struct _object {int
ob_refcnt, pointer to struct _typeobject {..} ob_type}
[...]

This is only a warning, not very important.

Best Regards,
Dimitri


----------------------------------------------------------------------

>Comment By: Dimitri Papadopoulos (papadopo)
Date: 2001-04-19 02:01

Message:
Logged In: YES 
user_id=52414

This is with Python 2.1 by the way.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417240&group_id=5470


From noreply@sourceforge.net  Thu Apr 19 10:15:44 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 19 Apr 2001 02:15:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-411881 ] Use of "except:" in modules
Message-ID: <E14qAXQ-0003pT-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
Resolution: None
Priority: 3
Submitted By: Itamar Shtull-Trauring (itamar)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Use of "except:" in modules

Initial Comment:
A large amount of modules in the standard library use
"except:" instead of specifying the exceptions to be
caught. In some cases this may be correct, but I think
in most cases this not true and this may cause
problems. Here's the list of modules, which I got by
doing:

   grep "except:" *.py | cut -f 1 -d " " | sort | uniq

Bastion.py
CGIHTTPServer.py
Cookie.py
SocketServer.py
anydbm.py
asyncore.py
bdb.py
cgi.py
chunk.py
cmd.py
code.py
compileall.py
doctest.py
fileinput.py
formatter.py
getpass.py
htmllib.py
imaplib.py
inspect.py
locale.py
locale.py
mailcap.py
mhlib.py
mimetools.py
mimify.py
os.py
pdb.py
popen2.py
posixfile.py
pre.py
pstats.py
pty.py
pyclbr.py
pydoc.py
repr.py
rexec.py
rfc822.py
shelve.py
shutil.py
tempfile.py
threading.py
traceback.py
types.py
unittest.py
urllib.py
zipfile.py


----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2001-04-19 02:15

Message:
Logged In: YES 
user_id=44345

I believe the following patch is correct for the try/except
in inspect.currentframe.  Note that it fixes two problems. 
One, it avoids a bare except.  Two, it gets rid of a string
argument to the raise statement (string exceptions are now
deprecated, right?).

*** /tmp/skip/inspect.py	Thu Apr 19 04:13:36 2001
--- /tmp/skip/inspect.py.~1.16~	Thu Apr 19 04:13:36 2001
***************
*** 643,650 ****
  def currentframe():
      """Return the frame object for the caller's stack
frame."""
      try:
!         1/0
!     except ZeroDivisionError:
          return sys.exc_traceback.tb_frame.f_back
  
  if hasattr(sys, '_getframe'): currentframe = sys._getframe
--- 643,650 ----
  def currentframe():
      """Return the frame object for the caller's stack
frame."""
      try:
!         raise 'catch me'
!     except:
          return sys.exc_traceback.tb_frame.f_back
  
  if hasattr(sys, '_getframe'): currentframe = sys._getframe


----------------------------------------------------------------------

Comment By: Itamar Shtull-Trauring (itamar)
Date: 2001-04-17 08:27

Message:
Logged In: YES 
user_id=32065

inspect.py uses sys_getframe if it's there, the other code
is for backwards compatibility.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-11 10:24

Message:
Logged In: YES 
user_id=6380

Actually, inspect.py should use sys._getframe()!

And yes, KeyboardError is definitely one of the reasons why
this is such a bad idiom...

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2001-04-11 10:15

Message:
Logged In: YES 
user_id=89016

> Can you identify modules where catching everything 
> is incorrect

If "everything" includes KeyboardInterrupt, it's
definitely incorrect, even in inspect.py's simple

    try:
        raise 'catch me'
    except:
        return sys.exc_traceback.tb_frame.f_back

which should probably be:

    try:
        raise 'catch me'
    except KeyboardInterrupt:
        raise
    except:
        return sys.exc_traceback.tb_frame.f_back


----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2001-04-11 10:13

Message:
Logged In: YES 
user_id=89016

> Can you identify modules where catching everything 
> is incorrect

If "everything" includes KeyboardInterrupt, it's
definitely incorrect, even in inspect.py's simple

    try:
        raise 'catch me'
    except:
        return sys.exc_traceback.tb_frame.f_back

which should probably be:

    try:
        raise 'catch me'
    except KeyboardInterrupt:
        raise
    except:
        return sys.exc_traceback.tb_frame.f_back


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 08:45

Message:
Logged In: YES 
user_id=6380

I've applied the three patches you supplied.

I agree with Martin that to do this right we'll have to
tread carefully. But please go on!

(No way more of this will find its way into 2.1 though.)

----------------------------------------------------------------------

Comment By: Itamar Shtull-Trauring (itamar)
Date: 2001-03-30 02:54

Message:
Logged In: YES 
user_id=32065

inspect.py should be removed from this list, the use is
correct.

In general, I just submitted this bug so that when people
are editing a module they'll notice these things, since in
some cases only someone who knows the code very well can
know if the "expect:" is needed or not.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-03-29 22:59

Message:
Logged In: YES 
user_id=21627

Can you identify modules where catching everything is
incorrect, and propose changes to correct them. This should
be done one-by-one, with careful analysis in each case, and
may take well months or years to complete.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411881&group_id=5470


From noreply@sourceforge.net  Thu Apr 19 13:21:55 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 19 Apr 2001 05:21:55 -0700
Subject: [Python-bugs-list] [ python-Bugs-411374 ] [Irix] SIGINT causes crash
Message-ID: <E14qDRb-0000pR-00@usw-sf-web3.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
>Resolution: Works For Me
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.

----------------------------------------------------------------------

>Comment By: Sjoerd Mullender (sjoerd)
Date: 2001-04-19 05:21

Message:
Logged In: YES 
user_id=43607

I don't have the versions mentioned here, but 2.2a0 (CVS
version of April 19) on IRIX 6.5.11m works fine.
Can you be more explicit in what you tried, or try a more
up-to-date version?  Also, try compiling without -O in case
it's a problem in the optimizer.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411374&group_id=5470


From noreply@sourceforge.net  Thu Apr 19 13:23:51 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 19 Apr 2001 05:23:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-417340 ] distutils.__version__ is illegal
Message-ID: <E14qDTT-0002S1-00@usw-sf-web2.sourceforge.net>

Bugs item #417340, was updated on 2001-04-19 05:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417340&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Garth T Kidd (gtk23)
Assigned to: Nobody/Anonymous (nobody)
Summary: distutils.__version__ is illegal

Initial Comment:
distutils.__version__ is illegal according to 
distutils.version.StrictVersion()

version.py:
""" ... A version number consists of two or three dot-
separated numeric components, with an optional "pre-
release" tag on the end.  The pre-release tag consists 
of the letter 'a' or 'b' followed by a number. ... """

distutils/__init__.py: 
__version__ = "1.0.2pre"

Oops. Naughty theller! 

Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
>>> import distutils
>>> distutils.__version__
'1.0.2pre'
>>>
>>> from distutils.version import StrictVersion
>>> StrictVersion(distutils.__version__)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "c:\python21\lib\distutils\version.py", line 
42, in __init__
    self.parse(vstring)
  File "c:\python21\lib\distutils\version.py", line 
109, in parse
    raise ValueError, "invalid version number '%s'" % 
vstring
ValueError: invalid version number '1.0.2pre'
>>>

Encountered when building 4Suite, which calls 
distutils.version.StrictVersion on 
distutils.__version__ to make sure that it's at least 
1.0. From admin/DistExt.py: 

def EnsureVersion(version):
    """Checks Distutils version against specified 
version number"""
    dist_version = StrictVersion(distutils.__version__)
    expected = StrictVersion(version)
    if dist_version < expected:
        print
        print 'Requires Distutils v%s or newer.  Found 
version %s.' % (
            expected,
            dist_version,
            )
        print
        sys.exit(1)

EnsureVersion('1.0')


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417340&group_id=5470


From noreply@sourceforge.net  Thu Apr 19 18:40:27 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 19 Apr 2001 10:40:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-417388 ] pythonw.exe will not work
Message-ID: <E14qIPr-0003qi-00@usw-sf-web1.sourceforge.net>

Bugs item #417388, was updated on 2001-04-19 10:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417388&group_id=5470

Category: Windows
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: pythonw.exe will not work

Initial Comment:
I've just finished installing python 2.1 on my MS 
Windows98 laptop.  Everything seems to be fine except 
that when i try to execute the pythonw.exe... it would 
seem like it's executing becuase my mouse pointer 
changes into the sand clock .. but nothing happens.

The python.exe works just fine.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417388&group_id=5470


From noreply@sourceforge.net  Thu Apr 19 19:51:39 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 19 Apr 2001 11:51:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-417418 ] Python 2.1 compile error on HPUX
Message-ID: <E14qJWl-0005Vs-00@usw-sf-web3.sourceforge.net>

Bugs item #417418, was updated on 2001-04-19 11:51
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417418&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Townsend (rptownsend)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.1 compile error on HPUX

Initial Comment:
Compiling Python2.1 on HPUX11.0 gives the following 
errors:

cc: "Modules/termios.c", line 529: error 
1588: "VREPRINT" undefined.
cc: "Modules/termios.c", line 529: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 530: error 
1588: "VDISCARD" undefined.
cc: "Modules/termios.c", line 530: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 747: error 1588: "MDCD" 
undefined.
cc: "Modules/termios.c", line 747: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 750: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 753: error 1588: "MCTS" 
undefined.
cc: "Modules/termios.c", line 753: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 756: error 1588: "MDSR" 
undefined.
cc: "Modules/termios.c", line 756: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 759: error 1588: "MDTR" 
undefined.
cc: "Modules/termios.c", line 759: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 765: error 1588: "MRI" 
undefined.
cc: "Modules/termios.c", line 765: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 768: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 771: error 1588: "MRTS" 
undefined.
cc: "Modules/termios.c", line 771: error 1521: 
Incorrect initialization.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417418&group_id=5470


From noreply@sourceforge.net  Thu Apr 19 23:01:10 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 19 Apr 2001 15:01:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-215026 ] SSL features undocumented
Message-ID: <E14qMUA-0007y4-00@usw-sf-web3.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
Resolution: Later
Priority: 4
Submitted By: Martin v. Löwis (loewis)
>Assigned to: Mark Hammond (mhammond)
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-04-19 15:01

Message:
Logged In: YES 
user_id=31435

Assigned to MarkH on the off chance he runs SSL on 
Windows.  Mark, if you don't either, then nobody who runs 
on Windows cares about this enough to bother, so just 
reassign it to Fred for the doc-issue part of it.

----------------------------------------------------------------------

Comment By: Moshe Zadka (moshez)
Date: 2001-04-09 07:00

Message:
Logged In: YES 
user_id=11645

Test case is trivial:

>>> a = urllib2.urlopen('https://sourceforge.net')
>>> a.read(10)

And see that something comes out.

I can't help any more with that, I haven't seen a windows
machine for longer then Tim hasn't seen a socket...
Assigning back to tim -- if you can't solve it, someone more
qualified them me will have to solve it.

----------------------------------------------------------------------

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  Thu Apr 19 23:07:18 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 19 Apr 2001 15:07:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-417388 ] pythonw.exe will not work
Message-ID: <E14qMa6-00082Q-00@usw-sf-web3.sourceforge.net>

Bugs item #417388, was updated on 2001-04-19 10:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417388&group_id=5470

Category: Windows
>Group: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: pythonw.exe will not work

Initial Comment:
I've just finished installing python 2.1 on my MS 
Windows98 laptop.  Everything seems to be fine except 
that when i try to execute the pythonw.exe... it would 
seem like it's executing becuase my mouse pointer 
changes into the sand clock .. but nothing happens.

The python.exe works just fine.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-04-19 15:07

Message:
Logged In: YES 
user_id=31435

pythonw.exe does not bring up a DOS box -- that's it's 
*purpose* in life (for example, for GUI programs that don't 
*want* to bring up a DOS box).  So "nothing happens" is 
exactly what should happen -- unless you're executing a GUI 
program with pythonw and nothing happens then either.  But 
if so, that's not what you said, so if that's the case open 
another bug report with some concrete information.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417388&group_id=5470


From noreply@sourceforge.net  Thu Apr 19 23:09:32 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 19 Apr 2001 15:09:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-417291 ] [Solaris] errors in _curses extension
Message-ID: <E14qMcG-000848-00@usw-sf-web3.sourceforge.net>

Bugs item #417291, was updated on 2001-04-19 01:57
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417291&group_id=5470

Category: Build
>Group: Platform-specific
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: [Solaris] errors in _curses extension

Initial Comment:
Hi,

Building with the Sun compiler on Solaris 7:

$ make all
[...]
building '_curses' extension
cc -I. -I/tmp/Python-2.1/./Include -I/usr/local/include
-IInclude/ -c /tmp/Python-2.1/Modules/_cursesmodule.c
-o build/temp.solaris-2.7-sun4u-2.1/_cursesmodule.o -O
-I. -I./Include -DHAVE_CONFIG_H
"/tmp/Python-2.1/Modules/_cursesmodule.c", line 313:
undefined symbol: attr_t
"/tmp/Python-2.1/Modules/_cursesmodule.c", line 313:
syntax error before or at: arg1
"/tmp/Python-2.1/Modules/_cursesmodule.c", line 313:
undefined symbol: arg1
"/tmp/Python-2.1/Modules/_cursesmodule.c", line 314:
undefined symbol: attr_t
"/tmp/Python-2.1/Modules/_cursesmodule.c", line 314:
syntax error before or at: arg1
[...]
$

Solaris 7 has only <curses.h> not <ncurses.h> and
attr_t seems to be specific to <ncurses.h>.

Regards,
Dimitri



----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-04-19 15:09

Message:
Logged In: YES 
user_id=31435

This is a duplicate of 417290, so just closing this one.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417291&group_id=5470


From noreply@sourceforge.net  Thu Apr 19 23:16:26 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 19 Apr 2001 15:16:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-416696 ] --with-threads fail for 2.1c2 on HPUX 11
Message-ID: <E14qMiw-00089U-00@usw-sf-web3.sourceforge.net>

Bugs item #416696, was updated on 2001-04-17 07:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416696&group_id=5470

Category: None
>Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Harri Pasanen (harripasanen)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: --with-threads fail for 2.1c2 on HPUX 11

Initial Comment:
 ./configure --with-thread --without-gcc
.
.
.
checking for --with-threads... yes
checking for mach/cthreads.h... no
checking for --with-pth... no
checking for pthread_create in -lpthread... no
checking for pthread_detach... yes
.
.
.
 make test
.
.
.
test_thread
test test_thread crashed -- thread.error: can't start
new thread                
.
.
.

4 tests failed: test_asynchat test_fork1 test_thread
test_threadedtempfile

-- 

The cause here is that at link time -lpthread is not
included.  If I manually relink with -lpthread, then no
tests fail tests pass.
113 tests
OK.                                                                   

-Harri

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-04-19 15:16

Message:
Logged In: YES 
user_id=31435

Assigned to Guido.  Harri, can you supply a patch?  You 
seem to know what you're doing on this box, and nobody else 
does:  every release *something* about threads is broken on 
HPUX, and no patch submitted to date has ever cured this.  
No active Python developer runs HPUX, and I think we've all 
given up trying to sort out the conflicting claims of HP-UX 
users.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416696&group_id=5470


From noreply@sourceforge.net  Thu Apr 19 23:26:55 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 19 Apr 2001 15:26:55 -0700
Subject: [Python-bugs-list] [ python-Bugs-417472 ] Unneccessary warning message
Message-ID: <E14qMt5-0001hS-00@usw-sf-web2.sourceforge.net>

Bugs item #417472, was updated on 2001-04-19 15:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417472&group_id=5470

Category: Installation
Group: Not a Bug
Status: Open
Resolution: None
Priority: 5
Submitted By: Viktor Ferenczi (complex)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unneccessary warning message

Initial Comment:
Unneccessary warning message near to the end of Python
2.1 compilation:

warning: install: modules installed to
'/usr/local/lib/python2.1/lib-dynload/',
which is not in Python's module search path (sys.path)
-- you'll have to change
the search path yourself

The search path contains the
/usr/local/lib/python2.1/lib-dynload directory,
so this warning message is not required.

System: RedHat Linux 7.0 (Kernel 2.2.17, gcc 2.96)

- Complex -

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417472&group_id=5470


From noreply@sourceforge.net  Thu Apr 19 23:38:49 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 19 Apr 2001 15:38:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-417472 ] Unneccessary warning message
Message-ID: <E14qN4b-0001rM-00@usw-sf-web2.sourceforge.net>

Bugs item #417472, was updated on 2001-04-19 15:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417472&group_id=5470

Category: Installation
Group: Not a Bug
Status: Open
Resolution: None
>Priority: 1
Submitted By: Viktor Ferenczi (complex)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unneccessary warning message

Initial Comment:
Unneccessary warning message near to the end of Python
2.1 compilation:

warning: install: modules installed to
'/usr/local/lib/python2.1/lib-dynload/',
which is not in Python's module search path (sys.path)
-- you'll have to change
the search path yourself

The search path contains the
/usr/local/lib/python2.1/lib-dynload directory,
so this warning message is not required.

System: RedHat Linux 7.0 (Kernel 2.2.17, gcc 2.96)

- Complex -

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417472&group_id=5470


From noreply@sourceforge.net  Fri Apr 20 00:25:31 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 19 Apr 2001 16:25:31 -0700
Subject: [Python-bugs-list] [ python-Bugs-417481 ] Python 2.1 build issues on Solaris 8/x86
Message-ID: <E14qNnn-0000qt-00@usw-sf-web1.sourceforge.net>

Bugs item #417481, was updated on 2001-04-19 16:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417481&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Fazal Majid (majid)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.1 build issues on Solaris 8/x86

Initial Comment:
I am building Python 2.1 final on Solaris 8 x86 with gcc 2.95.3 configured to use Solaris ld and GNU 
as.

The new autodetect build process fails to build some dynamically loaded modules such as _socket, 
at least when the OpenSSL autodetection kicks in. I am attaching a compilation build log 
py21log.txt (keep in mind stderr is not buffered, so sometimes the error message precedes the 
command-line).

This linker error message is something that is usually fixed by compiling with -fpic or -fPIC (the two 
are equivalent on x86), but in this case it does not resolve the problem with OpenSSL. Some 
versions of egcs were known to generate incorrect code when -fpic and -O were used together, 
this might be a survival of this bug.

The link process using gcc -shared fails with ld reporting unresolved relocations.

I managed to work around the problem by using LDSHARED="gcc -G" instead of "gcc -shared" ("ld 
-G" builds and installs successfully, but leaves relocations against libgcc). Once again, I am 
attaching the successful build log py21ok.txt.

FYI, this problem didn't occur with Python 2.0 and earlier with the manual Modules/Setup build 
process. This is probably related to:
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403655&group_id=5470


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417481&group_id=5470


From noreply@sourceforge.net  Fri Apr 20 00:40:28 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 19 Apr 2001 16:40:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-417491 ] UnixWare BUILD *STILL* uses ld -G
Message-ID: <E14qO2G-0002cP-00@usw-sf-web2.sourceforge.net>

Bugs item #417491, was updated on 2001-04-19 16:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417491&group_id=5470

Category: Installation
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Larry Rosenman (ler)
Assigned to: Nobody/Anonymous (nobody)
Summary: UnixWare BUILD *STILL* uses ld -G

Initial Comment:
bug 231439 is BACK in the 2.1 final release.  It still
uses ld -G. 

ALL shared objects, ESPECIALLY those using threads,
should be compiled  *AND* linked using cc -G. 

I'm very disappointed in that the bug was closed but
the QA process dropped the fix(es). 


ALSO, when doing the initial build using Shared
Objects, you need to set -R and/or set LD_LIBRARY_PATH
to suit. 



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417491&group_id=5470


From noreply@sourceforge.net  Fri Apr 20 03:11:44 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 19 Apr 2001 19:11:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-417508 ] 'hypot' not found with Borland C++Builde
Message-ID: <E14qQOe-0003E7-00@usw-sf-web1.sourceforge.net>

Bugs item #417508, was updated on 2001-04-19 19:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417508&group_id=5470

Category: Build
Group: Not a Bug
Status: Open
Resolution: None
Priority: 5
Submitted By: Stephen Hansen (ixokai)
Assigned to: Nobody/Anonymous (nobody)
Summary: 'hypot' not found with Borland C++Builde

Initial Comment:
I'm working on getting Python to build in Borland 
C++Builder, and the first problem i've run into is 
that 'hypot' is undefined in mathmodule.c and thus 
raises an error.
<br>
Adding the following to the top seems to fix it:
<pre>
#ifdef __BORLANDC__
extern double hypot (double, double);
#endif
</pre>
This should likely be a patch, I know. Sorry. :)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417508&group_id=5470


From noreply@sourceforge.net  Fri Apr 20 03:48:32 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 19 Apr 2001 19:48:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-417508 ] 'hypot' not found with Borland C++Builde
Message-ID: <E14qQyG-0002mQ-00@usw-sf-web3.sourceforge.net>

Bugs item #417508, was updated on 2001-04-19 19:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417508&group_id=5470

Category: Build
>Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Stephen Hansen (ixokai)
>Assigned to: Tim Peters (tim_one)
Summary: 'hypot' not found with Borland C++Builde

Initial Comment:
I'm working on getting Python to build in Borland 
C++Builder, and the first problem i've run into is 
that 'hypot' is undefined in mathmodule.c and thus 
raises an error.
<br>
Adding the following to the top seems to fix it:
<pre>
#ifdef __BORLANDC__
extern double hypot (double, double);
#endif
</pre>
This should likely be a patch, I know. Sorry. :)

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-04-19 19:48

Message:
Logged In: YES 
user_id=31435

Which version of Python are you using?  Try 2.1 first.

If it fails there, this must be solved in pyport.h rather 
than by cluttering mathmodule.c with platform-specific 
#ifdefs.  Note that pyport.h already contains

#ifndef HAVE_HYPOT
extern double hypot(double, double);
...
#endif

So the real question appears to be why HAVE_HYPOT is 
defined on your platform when it shouldn't be.  Could you 
please find out?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417508&group_id=5470


From noreply@sourceforge.net  Fri Apr 20 04:07:41 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 19 Apr 2001 20:07:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-417508 ] 'hypot' not found with Borland C++Builde
Message-ID: <E14qRGn-00041p-00@usw-sf-web1.sourceforge.net>

Bugs item #417508, was updated on 2001-04-19 19:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417508&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Stephen Hansen (ixokai)
Assigned to: Tim Peters (tim_one)
Summary: 'hypot' not found with Borland C++Builde

Initial Comment:
I'm working on getting Python to build in Borland 
C++Builder, and the first problem i've run into is 
that 'hypot' is undefined in mathmodule.c and thus 
raises an error.
<br>
Adding the following to the top seems to fix it:
<pre>
#ifdef __BORLANDC__
extern double hypot (double, double);
#endif
</pre>
This should likely be a patch, I know. Sorry. :)

----------------------------------------------------------------------

>Comment By: Stephen Hansen (ixokai)
Date: 2001-04-19 20:07

Message:
Logged In: YES 
user_id=200343

I am using Python 2.1, as just downloaded this morning. 
PC/config.h defines HAVE_HYPOT at the top of the file, and 
it is never undefined or modified in the rest. Apparently 
this is not appropriate for the latest Borland compiler.

Since pyport.h already has the needed statement, adding 
an '#undef HAVE_HYPORT' into the __BORLANDC__ section of 
config.h will fix the problem. 

BTW, I'm using the latest C++Builder5, which sets the value 
of __BORLANDC__ to 0x055, if you wished to make the change 
specific to this version and beyond of the compiler -- I 
don't know if this problem existed in prior versions or not.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-04-19 19:48

Message:
Logged In: YES 
user_id=31435

Which version of Python are you using?  Try 2.1 first.

If it fails there, this must be solved in pyport.h rather 
than by cluttering mathmodule.c with platform-specific 
#ifdefs.  Note that pyport.h already contains

#ifndef HAVE_HYPOT
extern double hypot(double, double);
...
#endif

So the real question appears to be why HAVE_HYPOT is 
defined on your platform when it shouldn't be.  Could you 
please find out?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417508&group_id=5470


From noreply@sourceforge.net  Fri Apr 20 10:42:11 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 20 Apr 2001 02:42:11 -0700
Subject: [Python-bugs-list] [ python-Bugs-417587 ] compiler warnings compiling 2.1
Message-ID: <E14qXQZ-0007NG-00@usw-sf-web3.sourceforge.net>

Bugs item #417587, was updated on 2001-04-20 02:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417587&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Sjoerd Mullender (sjoerd)
Assigned to: Nobody/Anonymous (nobody)
Summary: compiler warnings compiling 2.1

Initial Comment:
I get a whole bunch of compiler warnings when compiling 
the stock Python-2.1 on SGI IRIX 6.5.11m.  These 
warnings are innocuous, but I feel that many of them 
should be fixed anyway.  I particularly dislike code 
where a goto or return is immediately followed by 
break.  There is just *no way* the flow of control can 
get to that break and I feel that it betrays 
uncertainty in the programmer.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417587&group_id=5470


From noreply@sourceforge.net  Fri Apr 20 15:20:17 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 20 Apr 2001 07:20:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-417634 ] configuring without C++ compiler name
Message-ID: <E14qblh-0002JC-00@usw-sf-web3.sourceforge.net>

Bugs item #417634, was updated on 2001-04-20 07:20
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417634&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: configuring without C++ compiler name

Initial Comment:
If you check out a clean copy of Python 2.1 on a 
Solaris 5.8 machine, and run:

    ./configure -with-cxx

rather than:

    ./configure -with-cxx=g++

It generates a makefile with "CXX=yes", so "make" 
produces:
 
    bash-2.03$ make
    yes -c -g -O2 -Wall -Wstrict-prototypes -I. \
        -I./Include -DHAVE_CONFIG_H \
        -o Modules/ccpython.o \
        ./Modules/ccpython.cc
    make: yes: Command not found


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417634&group_id=5470


From noreply@sourceforge.net  Sat Apr 21 02:03:19 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 20 Apr 2001 18:03:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-417779 ] Fails to build
Message-ID: <E14qlnz-00035i-00@usw-sf-web2.sourceforge.net>

Bugs item #417779, was updated on 2001-04-20 18:03
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417779&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fails to build

Initial Comment:
Im trying to build and install on RH 5.1
i get the following errors.

gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -
I./Include -DHAVE_CONFIG_H  -o Objects/fileobject.o 
Objects/fileobject.c
Objects/fileobject.c: In function `_portable_fseek':
Objects/fileobject.c:229: warning: implicit 
declaration of function `fseeko'

gcc -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H   -c ./Modules/posixmodule.c -o 
Modules/posixmodule.o
./Modules/posixmodule.c:4032: sys/statvfs.h: No such 
file or directory
./Modules/posixmodule.c:4081: sys/statvfs.h: No such 
file or directory

Am i missing something?

Regards
Andrew



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417779&group_id=5470


From noreply@sourceforge.net  Sat Apr 21 03:47:37 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 20 Apr 2001 19:47:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-417587 ] compiler warnings compiling 2.1
Message-ID: <E14qnQv-0002oR-00@usw-sf-web3.sourceforge.net>

Bugs item #417587, was updated on 2001-04-20 02:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417587&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Sjoerd Mullender (sjoerd)
Assigned to: Nobody/Anonymous (nobody)
Summary: compiler warnings compiling 2.1

Initial Comment:
I get a whole bunch of compiler warnings when compiling 
the stock Python-2.1 on SGI IRIX 6.5.11m.  These 
warnings are innocuous, but I feel that many of them 
should be fixed anyway.  I particularly dislike code 
where a goto or return is immediately followed by 
break.  There is just *no way* the flow of control can 
get to that break and I feel that it betrays 
uncertainty in the programmer.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-04-20 19:47

Message:
Logged In: YES 
user_id=31435

Sjoerd, it would be much more helpful if you submitted a 
patch.  We don't have an SGI IRIX 6.5.11m box to compile 
on, so can't tell whether we've fixed anything.  We have 
a "no compiler warnings!" policy that I enforce under the 
Windows build, and so I don't see *any* warnings in the 2.1 
build.

I fixed the most egregious ones where fixes were obviously 
harmless, checked in as

mmapmodule.c new revision: 2.28
unicodeobject.c new revision: 2.86
tokenizer.c new revision: 2.50
ceval.c new revision: 2.240


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417587&group_id=5470


From noreply@sourceforge.net  Sat Apr 21 04:22:22 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 20 Apr 2001 20:22:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-417508 ] 'hypot' not found with Borland C++Builde
Message-ID: <E14qnyY-0003AM-00@usw-sf-web3.sourceforge.net>

Bugs item #417508, was updated on 2001-04-19 19:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417508&group_id=5470

Category: Build
Group: Platform-specific
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Stephen Hansen (ixokai)
Assigned to: Tim Peters (tim_one)
Summary: 'hypot' not found with Borland C++Builde

Initial Comment:
I'm working on getting Python to build in Borland 
C++Builder, and the first problem i've run into is 
that 'hypot' is undefined in mathmodule.c and thus 
raises an error.
<br>
Adding the following to the top seems to fix it:
<pre>
#ifdef __BORLANDC__
extern double hypot (double, double);
#endif
</pre>
This should likely be a patch, I know. Sorry. :)

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-04-20 20:22

Message:
Logged In: YES 
user_id=31435

OK, I #undef'ed HAVE_HYPOT in the __BORLANDC__ section of 
PC/config.h.  I have even less ability to guess which 
versions of Borland C need this than you do <wink>, so made 
it an unconditional #undef.  Any further refinements will 
have to be made via contributed patches from a Borland C 
user.  Thanks for the help!

Misc/ACKS new revision: 1.95
PC/config.h new revision: 1.51


----------------------------------------------------------------------

Comment By: Stephen Hansen (ixokai)
Date: 2001-04-19 20:07

Message:
Logged In: YES 
user_id=200343

I am using Python 2.1, as just downloaded this morning. 
PC/config.h defines HAVE_HYPOT at the top of the file, and 
it is never undefined or modified in the rest. Apparently 
this is not appropriate for the latest Borland compiler.

Since pyport.h already has the needed statement, adding 
an '#undef HAVE_HYPORT' into the __BORLANDC__ section of 
config.h will fix the problem. 

BTW, I'm using the latest C++Builder5, which sets the value 
of __BORLANDC__ to 0x055, if you wished to make the change 
specific to this version and beyond of the compiler -- I 
don't know if this problem existed in prior versions or not.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-04-19 19:48

Message:
Logged In: YES 
user_id=31435

Which version of Python are you using?  Try 2.1 first.

If it fails there, this must be solved in pyport.h rather 
than by cluttering mathmodule.c with platform-specific 
#ifdefs.  Note that pyport.h already contains

#ifndef HAVE_HYPOT
extern double hypot(double, double);
...
#endif

So the real question appears to be why HAVE_HYPOT is 
defined on your platform when it shouldn't be.  Could you 
please find out?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417508&group_id=5470


From noreply@sourceforge.net  Sat Apr 21 05:24:15 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 20 Apr 2001 21:24:15 -0700
Subject: [Python-bugs-list] [ python-Bugs-417796 ] illegal version 1.0.2pre
Message-ID: <E14qowR-0002BY-00@usw-sf-web1.sourceforge.net>

Bugs item #417796, was updated on 2001-04-20 21:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417796&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Garth T Kidd (gtk)
Assigned to: Nobody/Anonymous (nobody)
Summary: illegal version 1.0.2pre

Initial Comment:
Description: 

The version in distutils/__init__ doesn't conform to 
the strict versioning guidelines in distutils/version, 
resulting in failure when trying to use distutils to 
install 4Suite (and perhaps other modules). 

Workaround: 

Hand-edit distutils/__init__.py to remove "pre". 

Pointers to vital stuff in code: 

Lib/distutils/__init__.py: 
__version__ = "1.0.2pre"

Lib/distutils/version.py:
A version number consists of two or three dot-
separated numeric components, with an optional "pre-
release" tag on the end. The pre-release tag consists 
of the letter 'a' or 'b' followed by a number.  

Demonstration of problem: 

Python 2.1 (#1, Apr 18 2001, 10:49:25)
[GCC 2.95.2 19991024 (release)] on sunos5
Type "copyright", "credits" or "license" for more 
information.
>>> import distutils
>>> import distutils.version
>>> v = distutils.version.StrictVersion
(distutils.__version__)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  
File "/usr/local/lib/python2.1/distutils/version.py", 
line 42, in __init__
    self.parse(vstring)
  
File "/usr/local/lib/python2.1/distutils/version.py", 
line 109, in parse
    raise ValueError, "invalid version number '%s'" % 
vstring
ValueError: invalid version number '1.0.2pre'
>>>




----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417796&group_id=5470


From noreply@sourceforge.net  Sat Apr 21 06:49:55 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 20 Apr 2001 22:49:55 -0700
Subject: [Python-bugs-list] [ python-Bugs-417802 ] mode_t not appropriate for chmod in BCC
Message-ID: <E14qqHL-0005ui-00@usw-sf-web2.sourceforge.net>

Bugs item #417802, was updated on 2001-04-20 22:49
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417802&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Stephen Hansen (ixokai)
Assigned to: Nobody/Anonymous (nobody)
Summary: mode_t not appropriate for chmod in BCC

Initial Comment:
In reference to the 'chmod' definition in 
posixmodule.c (~line 155). Under Borland 
C++5.5, 'mode_t' is defined in sys/types.h as a short, 
and yet io.h defines 'chmod' as taking char* and an 
int, so the compiler gives an error of, "Type mismatch 
in redeclaration of 'chmod'" here.

Since sys/types.h is going to redefine mode_t after 
anything we put into pyport/config, the only way I can 
see to fix this would be to put an #ifdef __BORLANDC__ 
in there.

Now, to go fix all the other errors BC is spitting out 
in that file. <le sigh>

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417802&group_id=5470


From noreply@sourceforge.net  Sat Apr 21 13:37:06 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 21 Apr 2001 05:37:06 -0700
Subject: [Python-bugs-list] [ python-Bugs-416288 ] infrequent memory leak in pyexpat
Message-ID: <E14qwdO-0000Vz-00@usw-sf-web3.sourceforge.net>

Bugs item #416288, was updated on 2001-04-15 10:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416288&group_id=5470

Category: XML
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: douglas orr (dougbo)
>Assigned to: Martin v. Löwis (loewis)
Summary: infrequent memory leak in pyexpat

Initial Comment:
In pyexpat.c, the macro call for the handler dispatch 
(my##NAME##Handler) for CharacterHandler allocates an 
object implicitly by calling one of the conversion-to-
unicode routines.  

If there is a problem in the PyBuildValue, resulting 
in args == NULL, that object will be leaked.

Low priority, but the macros probably need some 
reworking to handle this.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416288&group_id=5470


From noreply@sourceforge.net  Sat Apr 21 13:43:53 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 21 Apr 2001 05:43:53 -0700
Subject: [Python-bugs-list] [ python-Bugs-416530 ] No notes for building on Mac OS X 10.0
Message-ID: <E14qwjx-0000aF-00@usw-sf-web3.sourceforge.net>

Bugs item #416530, was updated on 2001-04-16 14:19
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416530&group_id=5470

Category: Documentation
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: No notes for building on Mac OS X 10.0

Initial Comment:
In the 'README' file for Python-2.1c2, the 'Platform 
specific notes' section for Mac OS X should be 
amended to include notes for building on Mac OS 
10.0 (as opposed to Mac OS X beta). The 
suggested new words are:

Run configure with "OPT='-no-cpp-precomp' ./
configure --with-suffix=.exe --with-dyld".
This generates executable file: 'python.exe' (it 
cannot be named 'python' on an HFS or HFS+
disk as the file name clashes with directory 
'Python'). The '-no-cpp-precomp' option prevents
a large number of compilation warnings.

All the regression tests succeed except for the 
regular expression test 'test_re'
which fails with a SEGV unless file '_sre.c' has a fix 
to limit the depth of recursion used.
This change (and a suggested fix) has been 
submitted as a bug under request id: 416526.

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2001-04-21 05:43

Message:
Logged In: YES 
user_id=21627

I think that configure.in should be corrected to
automatically use the right options, instead of documenting
how to manually pass them.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416530&group_id=5470


From noreply@sourceforge.net  Sat Apr 21 13:55:10 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 21 Apr 2001 05:55:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-417491 ] UnixWare BUILD *STILL* uses ld -G
Message-ID: <E14qwus-0000hf-00@usw-sf-web3.sourceforge.net>

Bugs item #417491, was updated on 2001-04-19 16:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417491&group_id=5470

Category: Installation
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Larry Rosenman (ler)
Assigned to: Nobody/Anonymous (nobody)
Summary: UnixWare BUILD *STILL* uses ld -G

Initial Comment:
bug 231439 is BACK in the 2.1 final release.  It still
uses ld -G. 

ALL shared objects, ESPECIALLY those using threads,
should be compiled  *AND* linked using cc -G. 

I'm very disappointed in that the bug was closed but
the QA process dropped the fix(es). 


ALSO, when doing the initial build using Shared
Objects, you need to set -R and/or set LD_LIBRARY_PATH
to suit. 



----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2001-04-21 05:55

Message:
Logged In: YES 
user_id=21627

I agree this is very unfortunate. Please have a look at
patch 413011, which was committed as 1.215 of configure.in.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417491&group_id=5470


From noreply@sourceforge.net  Sat Apr 21 15:10:35 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 21 Apr 2001 07:10:35 -0700
Subject: [Python-bugs-list] [ python-Bugs-417833 ] pydoc HTTP reload failure
Message-ID: <E14qy5r-0001b2-00@usw-sf-web3.sourceforge.net>

Bugs item #417833, was updated on 2001-04-21 07:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417833&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Garth T Kidd (gtk)
Assigned to: Nobody/Anonymous (nobody)
Summary: pydoc HTTP reload failure

Initial Comment:
pydoc, when run as a web server, can't cope with 
reloads of modules which use 'from Package import 
Module' syntax for imports. 

To reproduce: 

* extract the attached DemonstratePydocBug tarchive 
into your Python 2.1 directory

* python -c Lib\pydoc.py -p 8192

* visit http://localhost:8192/DemonstratePydocBug.html

The rest of the instructions are there. 

Demonstrated on Python 2.1 (#15, Apr 16 2001, 
18:25:49) [MSC 32 bit (Intel)] on win32. 

Funnily enough, there's no problem with trying the 
following under Python interactively: 

Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
>>> import DemonstratePydocBug.ReloadFails
>>> import DemonstratePydocBug.ReloadFails
>>> import DemonstratePydocBug.ReloadFails
>>> import DemonstratePydocBug.ReloadFails

Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
>>> from DemonstratePydocBug import ReloadFails
>>> from DemonstratePydocBug import ReloadFails
>>> from DemonstratePydocBug import ReloadFails
>>> from DemonstratePydocBug import ReloadFails

I'm dropping additional debugging code into pydoc.py 
to see if I can figure out what's going on. 

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417833&group_id=5470


From noreply@sourceforge.net  Sat Apr 21 15:14:46 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 21 Apr 2001 07:14:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-417833 ] pydoc HTTP reload failure
Message-ID: <E14qy9u-0001dl-00@usw-sf-web3.sourceforge.net>

Bugs item #417833, was updated on 2001-04-21 07:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417833&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Garth T Kidd (gtk)
>Assigned to: Ka-Ping Yee (ping)
Summary: pydoc HTTP reload failure

Initial Comment:
pydoc, when run as a web server, can't cope with 
reloads of modules which use 'from Package import 
Module' syntax for imports. 

To reproduce: 

* extract the attached DemonstratePydocBug tarchive 
into your Python 2.1 directory

* python -c Lib\pydoc.py -p 8192

* visit http://localhost:8192/DemonstratePydocBug.html

The rest of the instructions are there. 

Demonstrated on Python 2.1 (#15, Apr 16 2001, 
18:25:49) [MSC 32 bit (Intel)] on win32. 

Funnily enough, there's no problem with trying the 
following under Python interactively: 

Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
>>> import DemonstratePydocBug.ReloadFails
>>> import DemonstratePydocBug.ReloadFails
>>> import DemonstratePydocBug.ReloadFails
>>> import DemonstratePydocBug.ReloadFails

Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
>>> from DemonstratePydocBug import ReloadFails
>>> from DemonstratePydocBug import ReloadFails
>>> from DemonstratePydocBug import ReloadFails
>>> from DemonstratePydocBug import ReloadFails

I'm dropping additional debugging code into pydoc.py 
to see if I can figure out what's going on. 

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417833&group_id=5470


From noreply@sourceforge.net  Sat Apr 21 15:15:38 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 21 Apr 2001 07:15:38 -0700
Subject: [Python-bugs-list] [ python-Bugs-417796 ] illegal version 1.0.2pre
Message-ID: <E14qyAk-0001ew-00@usw-sf-web3.sourceforge.net>

Bugs item #417796, was updated on 2001-04-20 21:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417796&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Garth T Kidd (gtk)
>Assigned to: Thomas Heller (theller)
Summary: illegal version 1.0.2pre

Initial Comment:
Description: 

The version in distutils/__init__ doesn't conform to 
the strict versioning guidelines in distutils/version, 
resulting in failure when trying to use distutils to 
install 4Suite (and perhaps other modules). 

Workaround: 

Hand-edit distutils/__init__.py to remove "pre". 

Pointers to vital stuff in code: 

Lib/distutils/__init__.py: 
__version__ = "1.0.2pre"

Lib/distutils/version.py:
A version number consists of two or three dot-
separated numeric components, with an optional "pre-
release" tag on the end. The pre-release tag consists 
of the letter 'a' or 'b' followed by a number.  

Demonstration of problem: 

Python 2.1 (#1, Apr 18 2001, 10:49:25)
[GCC 2.95.2 19991024 (release)] on sunos5
Type "copyright", "credits" or "license" for more 
information.
>>> import distutils
>>> import distutils.version
>>> v = distutils.version.StrictVersion
(distutils.__version__)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  
File "/usr/local/lib/python2.1/distutils/version.py", 
line 42, in __init__
    self.parse(vstring)
  
File "/usr/local/lib/python2.1/distutils/version.py", 
line 109, in parse
    raise ValueError, "invalid version number '%s'" % 
vstring
ValueError: invalid version number '1.0.2pre'
>>>




----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417796&group_id=5470


From noreply@sourceforge.net  Sat Apr 21 15:43:47 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 21 Apr 2001 07:43:47 -0700
Subject: [Python-bugs-list] [ python-Bugs-417833 ] pydoc HTTP reload failure
Message-ID: <E14qybz-00020j-00@usw-sf-web3.sourceforge.net>

Bugs item #417833, was updated on 2001-04-21 07:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417833&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Garth T Kidd (gtk)
Assigned to: Ka-Ping Yee (ping)
Summary: pydoc HTTP reload failure

Initial Comment:
pydoc, when run as a web server, can't cope with 
reloads of modules which use 'from Package import 
Module' syntax for imports. 

To reproduce: 

* extract the attached DemonstratePydocBug tarchive 
into your Python 2.1 directory

* python -c Lib\pydoc.py -p 8192

* visit http://localhost:8192/DemonstratePydocBug.html

The rest of the instructions are there. 

Demonstrated on Python 2.1 (#15, Apr 16 2001, 
18:25:49) [MSC 32 bit (Intel)] on win32. 

Funnily enough, there's no problem with trying the 
following under Python interactively: 

Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
>>> import DemonstratePydocBug.ReloadFails
>>> import DemonstratePydocBug.ReloadFails
>>> import DemonstratePydocBug.ReloadFails
>>> import DemonstratePydocBug.ReloadFails

Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
>>> from DemonstratePydocBug import ReloadFails
>>> from DemonstratePydocBug import ReloadFails
>>> from DemonstratePydocBug import ReloadFails
>>> from DemonstratePydocBug import ReloadFails

I'm dropping additional debugging code into pydoc.py 
to see if I can figure out what's going on. 

----------------------------------------------------------------------

>Comment By: Garth T Kidd (gtk)
Date: 2001-04-21 07:43

Message:
Logged In: YES 
user_id=59803

I've found another demonstration case. Noting that 

    from package import module

gives you a variable called 'module', whilst 

    import package.module

gives you a variable called 'package', I thought I'd try 
out another import syntax which wouldn't break code that 
was trying out the first option: 

    import package.module as module

This also works under the Python 2.1 interpreter but breaks 
pydoc 1.38. I've attached an updated demonstration 
tarchive. 

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417833&group_id=5470


From noreply@sourceforge.net  Sat Apr 21 15:55:21 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 21 Apr 2001 07:55:21 -0700
Subject: [Python-bugs-list] [ python-Bugs-417833 ] pydoc HTTP reload failure
Message-ID: <E14qynB-00029d-00@usw-sf-web3.sourceforge.net>

Bugs item #417833, was updated on 2001-04-21 07:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417833&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Garth T Kidd (gtk)
Assigned to: Ka-Ping Yee (ping)
Summary: pydoc HTTP reload failure

Initial Comment:
pydoc, when run as a web server, can't cope with 
reloads of modules which use 'from Package import 
Module' syntax for imports. 

To reproduce: 

* extract the attached DemonstratePydocBug tarchive 
into your Python 2.1 directory

* python -c Lib\pydoc.py -p 8192

* visit http://localhost:8192/DemonstratePydocBug.html

The rest of the instructions are there. 

Demonstrated on Python 2.1 (#15, Apr 16 2001, 
18:25:49) [MSC 32 bit (Intel)] on win32. 

Funnily enough, there's no problem with trying the 
following under Python interactively: 

Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
>>> import DemonstratePydocBug.ReloadFails
>>> import DemonstratePydocBug.ReloadFails
>>> import DemonstratePydocBug.ReloadFails
>>> import DemonstratePydocBug.ReloadFails

Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
>>> from DemonstratePydocBug import ReloadFails
>>> from DemonstratePydocBug import ReloadFails
>>> from DemonstratePydocBug import ReloadFails
>>> from DemonstratePydocBug import ReloadFails

I'm dropping additional debugging code into pydoc.py 
to see if I can figure out what's going on. 

----------------------------------------------------------------------

>Comment By: Garth T Kidd (gtk)
Date: 2001-04-21 07:55

Message:
Logged In: YES 
user_id=59803

>>> import pydoc
>>> import DemonstratePydocBug
>>> pydoc.help(DemonstratePydocBug.Target)

... we get good stuff...

>>> print DemonstratePydocBug.ReloadFails2
<module 'DemonstratePydocBug.ReloadFails2' 
from 'DemonstratePydocBug\ReloadFails2.py'>
>>> pydoc.help(DemonstratePydocBug.ReloadFails2)

... we get good stuff...


----------------------------------------------------------------------

Comment By: Garth T Kidd (gtk)
Date: 2001-04-21 07:43

Message:
Logged In: YES 
user_id=59803

I've found another demonstration case. Noting that 

    from package import module

gives you a variable called 'module', whilst 

    import package.module

gives you a variable called 'package', I thought I'd try 
out another import syntax which wouldn't break code that 
was trying out the first option: 

    import package.module as module

This also works under the Python 2.1 interpreter but breaks 
pydoc 1.38. I've attached an updated demonstration 
tarchive. 

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417833&group_id=5470


From noreply@sourceforge.net  Sat Apr 21 15:58:21 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 21 Apr 2001 07:58:21 -0700
Subject: [Python-bugs-list] [ python-Bugs-417833 ] pydoc HTTP reload failure
Message-ID: <E14qyq5-00034r-00@usw-sf-web2.sourceforge.net>

Bugs item #417833, was updated on 2001-04-21 07:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417833&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Garth T Kidd (gtk)
Assigned to: Ka-Ping Yee (ping)
Summary: pydoc HTTP reload failure

Initial Comment:
pydoc, when run as a web server, can't cope with 
reloads of modules which use 'from Package import 
Module' syntax for imports. 

To reproduce: 

* extract the attached DemonstratePydocBug tarchive 
into your Python 2.1 directory

* python -c Lib\pydoc.py -p 8192

* visit http://localhost:8192/DemonstratePydocBug.html

The rest of the instructions are there. 

Demonstrated on Python 2.1 (#15, Apr 16 2001, 
18:25:49) [MSC 32 bit (Intel)] on win32. 

Funnily enough, there's no problem with trying the 
following under Python interactively: 

Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
>>> import DemonstratePydocBug.ReloadFails
>>> import DemonstratePydocBug.ReloadFails
>>> import DemonstratePydocBug.ReloadFails
>>> import DemonstratePydocBug.ReloadFails

Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
>>> from DemonstratePydocBug import ReloadFails
>>> from DemonstratePydocBug import ReloadFails
>>> from DemonstratePydocBug import ReloadFails
>>> from DemonstratePydocBug import ReloadFails

I'm dropping additional debugging code into pydoc.py 
to see if I can figure out what's going on. 

----------------------------------------------------------------------

>Comment By: Garth T Kidd (gtk)
Date: 2001-04-21 07:58

Message:
Logged In: YES 
user_id=59803

WHOA. Belay that. I screwed up trying to run too many tests 
in a row without shutting down the interpreter. 

Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
>>> import pydoc
>>> import DemonstratePydocBug
>>> pydoc.help(DemonstratePydocBug.Target)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
AttributeError: 'DemonstratePydocBug' module has no 
attribute 'Target'

Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
>>> import pydoc
>>> import DemonstratePydocBug
>>> DemonstratePydocBug.Target
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
AttributeError: 'DemonstratePydocBug' module has no 
attribute 'Target'
>>> import DemonstratePydocBug.Target
>>> DemonstratePydocBug.Target
<module 'DemonstratePydocBug.Target' from 'c:\python21
\lib\DemonstratePydocBug\Target.pyc'>
>>> pydoc.help(DemonstratePydocBug.Target)
Help on module DemonstratePydocBug.Target:

NAME
    DemonstratePydocBug.Target

FILE
    c:\python21\lib\demonstratepydocbug\target.py

DESCRIPTION
    Target: module to help demonstrate the pydoc reload bug.
    See the docstring in __init__.py for full details.

    Reloading the description of this module in pydoc 
should work,
    but that's hardly unusual because it doesn't import 
*anything*.
    Try ReloadWorks and ReloadFails, instead.

DATA
    __file__ = r'c:\python21
\lib\DemonstratePydocBug\Target.pyc'
    __name__ = 'DemonstratePydocBug.Target'


>>> pydoc.help(DemonstratePydocBug.Target)
Help on module DemonstratePydocBug.Target:

NAME
    DemonstratePydocBug.Target
...

----------------------------------------------------------------------

Comment By: Garth T Kidd (gtk)
Date: 2001-04-21 07:55

Message:
Logged In: YES 
user_id=59803

>>> import pydoc
>>> import DemonstratePydocBug
>>> pydoc.help(DemonstratePydocBug.Target)

... we get good stuff...

>>> print DemonstratePydocBug.ReloadFails2
<module 'DemonstratePydocBug.ReloadFails2' 
from 'DemonstratePydocBug\ReloadFails2.py'>
>>> pydoc.help(DemonstratePydocBug.ReloadFails2)

... we get good stuff...


----------------------------------------------------------------------

Comment By: Garth T Kidd (gtk)
Date: 2001-04-21 07:43

Message:
Logged In: YES 
user_id=59803

I've found another demonstration case. Noting that 

    from package import module

gives you a variable called 'module', whilst 

    import package.module

gives you a variable called 'package', I thought I'd try 
out another import syntax which wouldn't break code that 
was trying out the first option: 

    import package.module as module

This also works under the Python 2.1 interpreter but breaks 
pydoc 1.38. I've attached an updated demonstration 
tarchive. 

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417833&group_id=5470


From noreply@sourceforge.net  Sat Apr 21 16:09:04 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 21 Apr 2001 08:09:04 -0700
Subject: [Python-bugs-list] [ python-Bugs-417833 ] pydoc HTTP reload failure
Message-ID: <E14qz0S-0003Ct-00@usw-sf-web2.sourceforge.net>

Bugs item #417833, was updated on 2001-04-21 07:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417833&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Garth T Kidd (gtk)
Assigned to: Ka-Ping Yee (ping)
Summary: pydoc HTTP reload failure

Initial Comment:
pydoc, when run as a web server, can't cope with 
reloads of modules which use 'from Package import 
Module' syntax for imports. 

To reproduce: 

* extract the attached DemonstratePydocBug tarchive 
into your Python 2.1 directory

* python -c Lib\pydoc.py -p 8192

* visit http://localhost:8192/DemonstratePydocBug.html

The rest of the instructions are there. 

Demonstrated on Python 2.1 (#15, Apr 16 2001, 
18:25:49) [MSC 32 bit (Intel)] on win32. 

Funnily enough, there's no problem with trying the 
following under Python interactively: 

Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
>>> import DemonstratePydocBug.ReloadFails
>>> import DemonstratePydocBug.ReloadFails
>>> import DemonstratePydocBug.ReloadFails
>>> import DemonstratePydocBug.ReloadFails

Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
>>> from DemonstratePydocBug import ReloadFails
>>> from DemonstratePydocBug import ReloadFails
>>> from DemonstratePydocBug import ReloadFails
>>> from DemonstratePydocBug import ReloadFails

I'm dropping additional debugging code into pydoc.py 
to see if I can figure out what's going on. 

----------------------------------------------------------------------

>Comment By: Garth T Kidd (gtk)
Date: 2001-04-21 08:09

Message:
Logged In: YES 
user_id=59803

Yet another demonstration case: 

DemonstratePydocBug/TryThis.py: 

    import DemonstratePydocBug.Target 
    Target = DemonstratePydocBug.Target

This gives us a local Target variable, same as 'from 
DemonstratePydocBug import Target'. Pydoc barfs on this on 
the very first load. The traceback I hacked into pydoc 
claims:

Traceback (most recent call last):

  File "C:\Python21\Lib\pydoc.py", line 223, in safeimport
    module = __import__(path)

  File "c:\python21\lib\DemonstratePydocBug\TryThis.py", 
line 9, in ?
    Target = DemonstratePydocBug.Target

AttributeError: 'DemonstratePydocBug' module has no 
attribute 'Target'

In the interpreter, everything's fine with both techniques 
for getting Target: 

C:\Python21\thirdparty\MoinMoin>python
Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
>>> from DemonstratePydocBug import Target
>>> Target
<module 'DemonstratePydocBug.Target' from 'c:\python21
\lib\DemonstratePydocBug\Target.pyc'>
>>> 

C:\Python21\thirdparty\MoinMoin>python
Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
>>> import DemonstratePydocBug.Target
>>> Target = DemonstratePydocBug.Target
>>> Target
<module 'DemonstratePydocBug.Target' from 'c:\python21
\lib\DemonstratePydocBug\Target.pyc'>
>>> 


----------------------------------------------------------------------

Comment By: Garth T Kidd (gtk)
Date: 2001-04-21 07:58

Message:
Logged In: YES 
user_id=59803

WHOA. Belay that. I screwed up trying to run too many tests 
in a row without shutting down the interpreter. 

Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
>>> import pydoc
>>> import DemonstratePydocBug
>>> pydoc.help(DemonstratePydocBug.Target)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
AttributeError: 'DemonstratePydocBug' module has no 
attribute 'Target'

Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
>>> import pydoc
>>> import DemonstratePydocBug
>>> DemonstratePydocBug.Target
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
AttributeError: 'DemonstratePydocBug' module has no 
attribute 'Target'
>>> import DemonstratePydocBug.Target
>>> DemonstratePydocBug.Target
<module 'DemonstratePydocBug.Target' from 'c:\python21
\lib\DemonstratePydocBug\Target.pyc'>
>>> pydoc.help(DemonstratePydocBug.Target)
Help on module DemonstratePydocBug.Target:

NAME
    DemonstratePydocBug.Target

FILE
    c:\python21\lib\demonstratepydocbug\target.py

DESCRIPTION
    Target: module to help demonstrate the pydoc reload bug.
    See the docstring in __init__.py for full details.

    Reloading the description of this module in pydoc 
should work,
    but that's hardly unusual because it doesn't import 
*anything*.
    Try ReloadWorks and ReloadFails, instead.

DATA
    __file__ = r'c:\python21
\lib\DemonstratePydocBug\Target.pyc'
    __name__ = 'DemonstratePydocBug.Target'


>>> pydoc.help(DemonstratePydocBug.Target)
Help on module DemonstratePydocBug.Target:

NAME
    DemonstratePydocBug.Target
...

----------------------------------------------------------------------

Comment By: Garth T Kidd (gtk)
Date: 2001-04-21 07:55

Message:
Logged In: YES 
user_id=59803

>>> import pydoc
>>> import DemonstratePydocBug
>>> pydoc.help(DemonstratePydocBug.Target)

... we get good stuff...

>>> print DemonstratePydocBug.ReloadFails2
<module 'DemonstratePydocBug.ReloadFails2' 
from 'DemonstratePydocBug\ReloadFails2.py'>
>>> pydoc.help(DemonstratePydocBug.ReloadFails2)

... we get good stuff...


----------------------------------------------------------------------

Comment By: Garth T Kidd (gtk)
Date: 2001-04-21 07:43

Message:
Logged In: YES 
user_id=59803

I've found another demonstration case. Noting that 

    from package import module

gives you a variable called 'module', whilst 

    import package.module

gives you a variable called 'package', I thought I'd try 
out another import syntax which wouldn't break code that 
was trying out the first option: 

    import package.module as module

This also works under the Python 2.1 interpreter but breaks 
pydoc 1.38. I've attached an updated demonstration 
tarchive. 

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417833&group_id=5470


From noreply@sourceforge.net  Sat Apr 21 16:28:50 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 21 Apr 2001 08:28:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-417845 ] Python 2.1: SocketServer.ThreadingMixIn
Message-ID: <E14qzJa-0002Wj-00@usw-sf-web3.sourceforge.net>

Bugs item #417845, was updated on 2001-04-21 08:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417845&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.1: SocketServer.ThreadingMixIn

Initial Comment:
SocketServer.ThreadingMixIn does not work properly
since it tries to close the socket of a request two
times.

Workaround for using SocketServer.ThreadingMixIn under
Python 2.1:

class MyThreadingHTTPServer(
  SocketServer.ThreadingMixIn,
  MyHTTPServer
):
  def close_request(self, request):
    pass



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417845&group_id=5470


From noreply@sourceforge.net  Sat Apr 21 17:15:03 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 21 Apr 2001 09:15:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-417833 ] pydoc HTTP reload failure
Message-ID: <E14r02J-00046T-00@usw-sf-web1.sourceforge.net>

Bugs item #417833, was updated on 2001-04-21 07:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417833&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Garth T Kidd (gtk)
Assigned to: Ka-Ping Yee (ping)
Summary: pydoc HTTP reload failure

Initial Comment:
pydoc, when run as a web server, can't cope with 
reloads of modules which use 'from Package import 
Module' syntax for imports. 

To reproduce: 

* extract the attached DemonstratePydocBug tarchive 
into your Python 2.1 directory

* python -c Lib\pydoc.py -p 8192

* visit http://localhost:8192/DemonstratePydocBug.html

The rest of the instructions are there. 

Demonstrated on Python 2.1 (#15, Apr 16 2001, 
18:25:49) [MSC 32 bit (Intel)] on win32. 

Funnily enough, there's no problem with trying the 
following under Python interactively: 

Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
>>> import DemonstratePydocBug.ReloadFails
>>> import DemonstratePydocBug.ReloadFails
>>> import DemonstratePydocBug.ReloadFails
>>> import DemonstratePydocBug.ReloadFails

Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
>>> from DemonstratePydocBug import ReloadFails
>>> from DemonstratePydocBug import ReloadFails
>>> from DemonstratePydocBug import ReloadFails
>>> from DemonstratePydocBug import ReloadFails

I'm dropping additional debugging code into pydoc.py 
to see if I can figure out what's going on. 

----------------------------------------------------------------------

>Comment By: Garth T Kidd (gtk)
Date: 2001-04-21 09:15

Message:
Logged In: YES 
user_id=59803

Using pydoc in the interpreter doesn't tickle any of these 
bugs, so hopefully I can narrow my focus down to the 
difference in handling between serve() and help(). 

Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
>>> import pydoc
>>> pydoc.help

Welcome to Python 2.1!  This is the online help utility.
[...]

help> modules
Please wait a moment while I gather a list of all available 
modules...

[list of modules] 

Enter any module name to get more help.  Or, type "modules 
spam" to search for modules whose descriptions contain the 
word "spam".

help> DemonstratePydocBug.ReloadFails
Help on module DemonstratePydocBug.ReloadFails in 
DemonstratePydocBug:

NAME
    DemonstratePydocBug.ReloadFails

FILE
    c:\python21\lib\demonstratepydocbug\reloadfails.py
[...]

help> DemonstratePydocBug.TryThis
Help on module DemonstratePydocBug.TryThis in 
DemonstratePydocBug:

NAME
    DemonstratePydocBug.TryThis
[...]


----------------------------------------------------------------------

Comment By: Garth T Kidd (gtk)
Date: 2001-04-21 08:09

Message:
Logged In: YES 
user_id=59803

Yet another demonstration case: 

DemonstratePydocBug/TryThis.py: 

    import DemonstratePydocBug.Target 
    Target = DemonstratePydocBug.Target

This gives us a local Target variable, same as 'from 
DemonstratePydocBug import Target'. Pydoc barfs on this on 
the very first load. The traceback I hacked into pydoc 
claims:

Traceback (most recent call last):

  File "C:\Python21\Lib\pydoc.py", line 223, in safeimport
    module = __import__(path)

  File "c:\python21\lib\DemonstratePydocBug\TryThis.py", 
line 9, in ?
    Target = DemonstratePydocBug.Target

AttributeError: 'DemonstratePydocBug' module has no 
attribute 'Target'

In the interpreter, everything's fine with both techniques 
for getting Target: 

C:\Python21\thirdparty\MoinMoin>python
Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
>>> from DemonstratePydocBug import Target
>>> Target
<module 'DemonstratePydocBug.Target' from 'c:\python21
\lib\DemonstratePydocBug\Target.pyc'>
>>> 

C:\Python21\thirdparty\MoinMoin>python
Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
>>> import DemonstratePydocBug.Target
>>> Target = DemonstratePydocBug.Target
>>> Target
<module 'DemonstratePydocBug.Target' from 'c:\python21
\lib\DemonstratePydocBug\Target.pyc'>
>>> 


----------------------------------------------------------------------

Comment By: Garth T Kidd (gtk)
Date: 2001-04-21 07:58

Message:
Logged In: YES 
user_id=59803

WHOA. Belay that. I screwed up trying to run too many tests 
in a row without shutting down the interpreter. 

Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
>>> import pydoc
>>> import DemonstratePydocBug
>>> pydoc.help(DemonstratePydocBug.Target)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
AttributeError: 'DemonstratePydocBug' module has no 
attribute 'Target'

Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
>>> import pydoc
>>> import DemonstratePydocBug
>>> DemonstratePydocBug.Target
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
AttributeError: 'DemonstratePydocBug' module has no 
attribute 'Target'
>>> import DemonstratePydocBug.Target
>>> DemonstratePydocBug.Target
<module 'DemonstratePydocBug.Target' from 'c:\python21
\lib\DemonstratePydocBug\Target.pyc'>
>>> pydoc.help(DemonstratePydocBug.Target)
Help on module DemonstratePydocBug.Target:

NAME
    DemonstratePydocBug.Target

FILE
    c:\python21\lib\demonstratepydocbug\target.py

DESCRIPTION
    Target: module to help demonstrate the pydoc reload bug.
    See the docstring in __init__.py for full details.

    Reloading the description of this module in pydoc 
should work,
    but that's hardly unusual because it doesn't import 
*anything*.
    Try ReloadWorks and ReloadFails, instead.

DATA
    __file__ = r'c:\python21
\lib\DemonstratePydocBug\Target.pyc'
    __name__ = 'DemonstratePydocBug.Target'


>>> pydoc.help(DemonstratePydocBug.Target)
Help on module DemonstratePydocBug.Target:

NAME
    DemonstratePydocBug.Target
...

----------------------------------------------------------------------

Comment By: Garth T Kidd (gtk)
Date: 2001-04-21 07:55

Message:
Logged In: YES 
user_id=59803

>>> import pydoc
>>> import DemonstratePydocBug
>>> pydoc.help(DemonstratePydocBug.Target)

... we get good stuff...

>>> print DemonstratePydocBug.ReloadFails2
<module 'DemonstratePydocBug.ReloadFails2' 
from 'DemonstratePydocBug\ReloadFails2.py'>
>>> pydoc.help(DemonstratePydocBug.ReloadFails2)

... we get good stuff...


----------------------------------------------------------------------

Comment By: Garth T Kidd (gtk)
Date: 2001-04-21 07:43

Message:
Logged In: YES 
user_id=59803

I've found another demonstration case. Noting that 

    from package import module

gives you a variable called 'module', whilst 

    import package.module

gives you a variable called 'package', I thought I'd try 
out another import syntax which wouldn't break code that 
was trying out the first option: 

    import package.module as module

This also works under the Python 2.1 interpreter but breaks 
pydoc 1.38. I've attached an updated demonstration 
tarchive. 

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417833&group_id=5470


From noreply@sourceforge.net  Sat Apr 21 17:20:24 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 21 Apr 2001 09:20:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-417853 ] pydoc uses deprecated regex module
Message-ID: <E14r07U-0004Bt-00@usw-sf-web1.sourceforge.net>

Bugs item #417853, was updated on 2001-04-21 09:20
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417853&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Garth T Kidd (gtk)
Assigned to: Nobody/Anonymous (nobody)
Summary: pydoc uses deprecated regex module

Initial Comment:
C:\Python21\Lib>python pydoc.py -g

[Tk gui pops up. Enter a search expression and hit 
Enter.]

pydoc.py:1496: DeprecationWarning: the regex module is 
deprecated; please use the re module
  desc = split(__import__(modname).__doc__ or '', '\n')
[0]


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417853&group_id=5470


From noreply@sourceforge.net  Sat Apr 21 22:57:15 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 21 Apr 2001 14:57:15 -0700
Subject: [Python-bugs-list] [ python-Bugs-417913 ] odd behavior when reloading "exceptions"
Message-ID: <E14r5NT-0006tB-00@usw-sf-web3.sourceforge.net>

Bugs item #417913, was updated on 2001-04-21 14:57
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417913&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Klatt (michaelklatt)
Assigned to: Nobody/Anonymous (nobody)
Summary: odd behavior when reloading "exceptions"

Initial Comment:

After reloading the "exceptions" module, "exceptions.OSError" is not the same object as "os.error".

Let me illustrate by example:


# ./python
Python 2.1 (#1, Apr 20 2001, 23:16:45) 
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> import os, exceptions
>>> os.error == exceptions.OSError
1
>>> reload(exceptions)
<module 'exceptions' (built-in)>
>>> os.error == exceptions.OSError
0
>>>


Here's an example of how this could wreak havoc in a python script:

# ./python
Python 2.1 (#1, Apr 20 2001, 23:16:45) 
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> import os
>>> import exceptions
>>> 
>>> try:
...    os.stat("dummy")
... except os.error, e:
...     print "exception caught"
... 
exception caught
>>> reload(exceptions)
<module 'exceptions' (built-in)>
>>> 
>>> try:
...    os.stat("dummy")
... except os.error, e:
...     print "exception caught"
... 
Traceback (most recent call last):
  File "<stdin>", line 2, in ?
OSError: [Errno 2] No such file or directory: 'dummy'
>>> 


A quick test shows that this problem also occurred in python 1.5.2 and python 2.0.  I believe I 
understand why this is happening (when the exceptions module is reloaded, a new object for 
OSError is created), but I'm hoping someone has a creative solution.  

This will cause problems in any application which calls Py_NewInterpreter() (like mod_python).  
To verify this, add the following lines to Demo/embed/demo.c at line 36:

 
        PyRun_SimpleString("import os,exceptions\n");
        PyRun_SimpleString("print os.error == exceptions.OSError\n");
 
        Py_NewInterpreter(); 
        PyRun_SimpleString("import os,exceptions\n");
        PyRun_SimpleString("print os.error == exceptions.OSError\n");

The first comparison will result in 1, and the second will result in 0. 

Thanks!

Mike



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417913&group_id=5470


From noreply@sourceforge.net  Sat Apr 21 23:23:16 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 21 Apr 2001 15:23:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-417491 ] UnixWare BUILD *STILL* uses ld -G
Message-ID: <E14r5me-0007wm-00@usw-sf-web2.sourceforge.net>

Bugs item #417491, was updated on 2001-04-19 16:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417491&group_id=5470

Category: Installation
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Larry Rosenman (ler)
Assigned to: Nobody/Anonymous (nobody)
Summary: UnixWare BUILD *STILL* uses ld -G

Initial Comment:
bug 231439 is BACK in the 2.1 final release.  It still
uses ld -G. 

ALL shared objects, ESPECIALLY those using threads,
should be compiled  *AND* linked using cc -G. 

I'm very disappointed in that the bug was closed but
the QA process dropped the fix(es). 


ALSO, when doing the initial build using Shared
Objects, you need to set -R and/or set LD_LIBRARY_PATH
to suit. 



----------------------------------------------------------------------

>Comment By: Larry Rosenman (ler)
Date: 2001-04-21 15:23

Message:
Logged In: YES 
user_id=36452

OK, why the H*LL didn't the release .tar get RE-ROLLED?  The
last comments on this patch are telling.  

I'm *NOT* impressed, and the bug reported here is mentioned
in that stream, so why wasn't the RELEASE held for this? 
the port is PROMINENTLY mentioned in the release notes, but
it's BROKE in the RELEASE.  How can I get a new tarball from
y'all? 



----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-04-21 05:55

Message:
Logged In: YES 
user_id=21627

I agree this is very unfortunate. Please have a look at
patch 413011, which was committed as 1.215 of configure.in.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417491&group_id=5470


From noreply@sourceforge.net  Sat Apr 21 23:45:28 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 21 Apr 2001 15:45:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-417491 ] UnixWare BUILD *STILL* uses ld -G
Message-ID: <E14r688-0001f1-00@usw-sf-web1.sourceforge.net>

Bugs item #417491, was updated on 2001-04-19 16:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417491&group_id=5470

Category: Installation
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Larry Rosenman (ler)
Assigned to: Nobody/Anonymous (nobody)
Summary: UnixWare BUILD *STILL* uses ld -G

Initial Comment:
bug 231439 is BACK in the 2.1 final release.  It still
uses ld -G. 

ALL shared objects, ESPECIALLY those using threads,
should be compiled  *AND* linked using cc -G. 

I'm very disappointed in that the bug was closed but
the QA process dropped the fix(es). 


ALSO, when doing the initial build using Shared
Objects, you need to set -R and/or set LD_LIBRARY_PATH
to suit. 



----------------------------------------------------------------------

>Comment By: Larry Rosenman (ler)
Date: 2001-04-21 15:45

Message:
Logged In: YES 
user_id=36452

Oh, and 1.215 is *BROKE*, as it spec's ld -G, not CC -G,
around line 615 or so.

PLEASE fix. 

PLEASE generate a FIX RELEASE for the 2.1 RELEASE.

This is *NOT* a good sign that a broken PORT didn't stop the
release process. 



----------------------------------------------------------------------

Comment By: Larry Rosenman (ler)
Date: 2001-04-21 15:23

Message:
Logged In: YES 
user_id=36452

OK, why the H*LL didn't the release .tar get RE-ROLLED?  The
last comments on this patch are telling.  

I'm *NOT* impressed, and the bug reported here is mentioned
in that stream, so why wasn't the RELEASE held for this? 
the port is PROMINENTLY mentioned in the release notes, but
it's BROKE in the RELEASE.  How can I get a new tarball from
y'all? 



----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-04-21 05:55

Message:
Logged In: YES 
user_id=21627

I agree this is very unfortunate. Please have a look at
patch 413011, which was committed as 1.215 of configure.in.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417491&group_id=5470


From noreply@sourceforge.net  Sun Apr 22 00:25:51 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 21 Apr 2001 16:25:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-417930 ] += not assigning to same var it reads
Message-ID: <E14r6lD-00007R-00@usw-sf-web2.sourceforge.net>

Bugs item #417930, was updated on 2001-04-21 16:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417930&group_id=5470

Category: Parser/Compiler
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Edward Loper (edloper)
Assigned to: Nobody/Anonymous (nobody)
Summary: += not assigning to same var it reads

Initial Comment:
My understanding of the augmented assignment 
statements is that they should always assign to the 
variable that they read from.  However, consider the 
following Python session:
  >>> class A: x = 1  
  ...  
  >>> a=A()
  >>> a.x += 1
  >>> a.x, A.x
  (2, 1)

Here, the expression "a.x += 1" read from a class 
variable, and wrote to an instance variable.  A 
similar effect can occur within a member function:
  >>> class A:
  ...     x = 1
  ...     def f(s): s.x += 1
  ... 
  >>> a = A()
  >>> a.f()
  >>> a.x, A.x
  (2, 1)

I have elicited this behavior in Python 2.0 and 2.1 
under Linux (Redhat 6.0), and Python 2.0 on sunos5.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417930&group_id=5470


From noreply@sourceforge.net  Sun Apr 22 01:34:16 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 21 Apr 2001 17:34:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-417491 ] UnixWare BUILD *STILL* uses ld -G
Message-ID: <E14r7pQ-00009v-00@usw-sf-web3.sourceforge.net>

Bugs item #417491, was updated on 2001-04-19 16:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417491&group_id=5470

Category: Installation
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Larry Rosenman (ler)
Assigned to: Nobody/Anonymous (nobody)
Summary: UnixWare BUILD *STILL* uses ld -G

Initial Comment:
bug 231439 is BACK in the 2.1 final release.  It still
uses ld -G. 

ALL shared objects, ESPECIALLY those using threads,
should be compiled  *AND* linked using cc -G. 

I'm very disappointed in that the bug was closed but
the QA process dropped the fix(es). 


ALSO, when doing the initial build using Shared
Objects, you need to set -R and/or set LD_LIBRARY_PATH
to suit. 



----------------------------------------------------------------------

>Comment By: Larry Rosenman (ler)
Date: 2001-04-21 17:34

Message:
Logged In: YES 
user_id=36452

OK, here is a patch I wrote to configure.in to fix this. 
regen configure and config.h.in 

Let me know if this is acceptable.  THis is against the
2.1-RELEASE version. 

Larry 

----------------------------------------------------------------------

Comment By: Larry Rosenman (ler)
Date: 2001-04-21 15:45

Message:
Logged In: YES 
user_id=36452

Oh, and 1.215 is *BROKE*, as it spec's ld -G, not CC -G,
around line 615 or so.

PLEASE fix. 

PLEASE generate a FIX RELEASE for the 2.1 RELEASE.

This is *NOT* a good sign that a broken PORT didn't stop the
release process. 



----------------------------------------------------------------------

Comment By: Larry Rosenman (ler)
Date: 2001-04-21 15:23

Message:
Logged In: YES 
user_id=36452

OK, why the H*LL didn't the release .tar get RE-ROLLED?  The
last comments on this patch are telling.  

I'm *NOT* impressed, and the bug reported here is mentioned
in that stream, so why wasn't the RELEASE held for this? 
the port is PROMINENTLY mentioned in the release notes, but
it's BROKE in the RELEASE.  How can I get a new tarball from
y'all? 



----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-04-21 05:55

Message:
Logged In: YES 
user_id=21627

I agree this is very unfortunate. Please have a look at
patch 413011, which was committed as 1.215 of configure.in.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417491&group_id=5470


From noreply@sourceforge.net  Sun Apr 22 02:10:09 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 21 Apr 2001 18:10:09 -0700
Subject: [Python-bugs-list] [ python-Bugs-417943 ] xreadlines documented twice for file obj
Message-ID: <E14r8O9-0003jo-00@usw-sf-web1.sourceforge.net>

Bugs item #417943, was updated on 2001-04-21 18:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417943&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michel Pelletier (michel)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: xreadlines documented twice for file obj

Initial Comment:
http://www.python.org/doc/current/lib/bltin-file-objects.html

Documents xreadlines twice.

-Michel

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417943&group_id=5470


From noreply@sourceforge.net  Sun Apr 22 02:58:52 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 21 Apr 2001 18:58:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-417943 ] xreadlines documented twice for file obj
Message-ID: <E14r99I-00013b-00@usw-sf-web3.sourceforge.net>

Bugs item #417943, was updated on 2001-04-21 18:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417943&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Michel Pelletier (michel)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: xreadlines documented twice for file obj

Initial Comment:
http://www.python.org/doc/current/lib/bltin-file-objects.html

Documents xreadlines twice.

-Michel

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-04-21 18:58

Message:
Logged In: YES 
user_id=3066

Fixed in Doc/lib/libstdtypes.tex revision 1.55 (1.52.4.2 in the maintenance branch).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417943&group_id=5470


From noreply@sourceforge.net  Sun Apr 22 03:30:34 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 21 Apr 2001 19:30:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-417491 ] UnixWare BUILD *STILL* uses ld -G
Message-ID: <E14r9dy-0001OZ-00@usw-sf-web3.sourceforge.net>

Bugs item #417491, was updated on 2001-04-19 16:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417491&group_id=5470

Category: Installation
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Larry Rosenman (ler)
Assigned to: Nobody/Anonymous (nobody)
Summary: UnixWare BUILD *STILL* uses ld -G

Initial Comment:
bug 231439 is BACK in the 2.1 final release.  It still
uses ld -G. 

ALL shared objects, ESPECIALLY those using threads,
should be compiled  *AND* linked using cc -G. 

I'm very disappointed in that the bug was closed but
the QA process dropped the fix(es). 


ALSO, when doing the initial build using Shared
Objects, you need to set -R and/or set LD_LIBRARY_PATH
to suit. 



----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-04-21 19:30

Message:
Logged In: YES 
user_id=31435

LARRY, there's REALLY no need to SCREAM on *EACH* word in 
THREE <wink>.

You're not impressed by QA -- join the club.  Testing is 
done by volunteers, and if there are no volunteers *trying* 
the release candidates on a new platform, we have no way to 
know whether they work.  Linux and Windows and Mac Classic 
are pretty well covered by volunteers, but that's about 
it.  If UnixWare is important enough to you, volunteer to 
test release candidates there yourself, or even pay someone 
to do it.  But don't go honking on Martin!  That's out of 
line.

About your "The last comments on this patch are telling.", 
the last comments on that patch were made *after* the 
release.  Before the release, Guido checked in the patch 
that the UnixWare user said was needed.  He can't guess 
whether a patch actually works on a platform he doesn't 
use.  The last patch comment by a UnixWare user *before* 
the release reads

"""Every thing looks fine (as far as I can tell)."""

WRT "why the H*LL didn't the release .tar get RE-ROLLED?", 
it's because nobody said anything was broken until after 
the release shipped (your bug report here was 2 days after 
the release).

----------------------------------------------------------------------

Comment By: Larry Rosenman (ler)
Date: 2001-04-21 17:34

Message:
Logged In: YES 
user_id=36452

OK, here is a patch I wrote to configure.in to fix this. 
regen configure and config.h.in 

Let me know if this is acceptable.  THis is against the
2.1-RELEASE version. 

Larry 

----------------------------------------------------------------------

Comment By: Larry Rosenman (ler)
Date: 2001-04-21 15:45

Message:
Logged In: YES 
user_id=36452

Oh, and 1.215 is *BROKE*, as it spec's ld -G, not CC -G,
around line 615 or so.

PLEASE fix. 

PLEASE generate a FIX RELEASE for the 2.1 RELEASE.

This is *NOT* a good sign that a broken PORT didn't stop the
release process. 



----------------------------------------------------------------------

Comment By: Larry Rosenman (ler)
Date: 2001-04-21 15:23

Message:
Logged In: YES 
user_id=36452

OK, why the H*LL didn't the release .tar get RE-ROLLED?  The
last comments on this patch are telling.  

I'm *NOT* impressed, and the bug reported here is mentioned
in that stream, so why wasn't the RELEASE held for this? 
the port is PROMINENTLY mentioned in the release notes, but
it's BROKE in the RELEASE.  How can I get a new tarball from
y'all? 



----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-04-21 05:55

Message:
Logged In: YES 
user_id=21627

I agree this is very unfortunate. Please have a look at
patch 413011, which was committed as 1.215 of configure.in.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417491&group_id=5470


From noreply@sourceforge.net  Sun Apr 22 03:35:25 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 21 Apr 2001 19:35:25 -0700
Subject: [Python-bugs-list] [ python-Bugs-417491 ] UnixWare BUILD *STILL* uses ld -G
Message-ID: <E14r9if-00021V-00@usw-sf-web2.sourceforge.net>

Bugs item #417491, was updated on 2001-04-19 16:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417491&group_id=5470

Category: Installation
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Larry Rosenman (ler)
Assigned to: Nobody/Anonymous (nobody)
Summary: UnixWare BUILD *STILL* uses ld -G

Initial Comment:
bug 231439 is BACK in the 2.1 final release.  It still
uses ld -G. 

ALL shared objects, ESPECIALLY those using threads,
should be compiled  *AND* linked using cc -G. 

I'm very disappointed in that the bug was closed but
the QA process dropped the fix(es). 


ALSO, when doing the initial build using Shared
Objects, you need to set -R and/or set LD_LIBRARY_PATH
to suit. 



----------------------------------------------------------------------

>Comment By: Larry Rosenman (ler)
Date: 2001-04-21 19:35

Message:
Logged In: YES 
user_id=36452

Ok. Sorry for the screaming, but the CVS sources are STILL
broken.

Can someone look at the patch I generated, and see if it can
be integrated 
into current CVS? 

I've built 2.1 with it on UnixWare 7 7.1.1 with the UDK FS
7.1.1b compiler. 

It works. 



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-04-21 19:30

Message:
Logged In: YES 
user_id=31435

LARRY, there's REALLY no need to SCREAM on *EACH* word in 
THREE <wink>.

You're not impressed by QA -- join the club.  Testing is 
done by volunteers, and if there are no volunteers *trying* 
the release candidates on a new platform, we have no way to 
know whether they work.  Linux and Windows and Mac Classic 
are pretty well covered by volunteers, but that's about 
it.  If UnixWare is important enough to you, volunteer to 
test release candidates there yourself, or even pay someone 
to do it.  But don't go honking on Martin!  That's out of 
line.

About your "The last comments on this patch are telling.", 
the last comments on that patch were made *after* the 
release.  Before the release, Guido checked in the patch 
that the UnixWare user said was needed.  He can't guess 
whether a patch actually works on a platform he doesn't 
use.  The last patch comment by a UnixWare user *before* 
the release reads

"""Every thing looks fine (as far as I can tell)."""

WRT "why the H*LL didn't the release .tar get RE-ROLLED?", 
it's because nobody said anything was broken until after 
the release shipped (your bug report here was 2 days after 
the release).

----------------------------------------------------------------------

Comment By: Larry Rosenman (ler)
Date: 2001-04-21 17:34

Message:
Logged In: YES 
user_id=36452

OK, here is a patch I wrote to configure.in to fix this. 
regen configure and config.h.in 

Let me know if this is acceptable.  THis is against the
2.1-RELEASE version. 

Larry 

----------------------------------------------------------------------

Comment By: Larry Rosenman (ler)
Date: 2001-04-21 15:45

Message:
Logged In: YES 
user_id=36452

Oh, and 1.215 is *BROKE*, as it spec's ld -G, not CC -G,
around line 615 or so.

PLEASE fix. 

PLEASE generate a FIX RELEASE for the 2.1 RELEASE.

This is *NOT* a good sign that a broken PORT didn't stop the
release process. 



----------------------------------------------------------------------

Comment By: Larry Rosenman (ler)
Date: 2001-04-21 15:23

Message:
Logged In: YES 
user_id=36452

OK, why the H*LL didn't the release .tar get RE-ROLLED?  The
last comments on this patch are telling.  

I'm *NOT* impressed, and the bug reported here is mentioned
in that stream, so why wasn't the RELEASE held for this? 
the port is PROMINENTLY mentioned in the release notes, but
it's BROKE in the RELEASE.  How can I get a new tarball from
y'all? 



----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-04-21 05:55

Message:
Logged In: YES 
user_id=21627

I agree this is very unfortunate. Please have a look at
patch 413011, which was committed as 1.215 of configure.in.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417491&group_id=5470


From noreply@sourceforge.net  Sun Apr 22 03:36:22 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 21 Apr 2001 19:36:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-417949 ] BorlandC55 needs #def HAVE_UTIME_H
Message-ID: <E14r9ja-0001SC-00@usw-sf-web3.sourceforge.net>

Bugs item #417949, was updated on 2001-04-21 19:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417949&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Stephen Hansen (ixokai)
Assigned to: Nobody/Anonymous (nobody)
Summary: BorlandC55 needs #def HAVE_UTIME_H

Initial Comment:
Under Python2.1:

PC/config.h globally defines HAVE_SYS_UTIME_H at ~line 
597, but the Borland C++Builder/compiler needs 
HAVE_UTIME_H instead; this is used in other files 
(posixmodule.c, specifically) to #include <utime.h> 
instead of <sys/utime.h>.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417949&group_id=5470


From noreply@sourceforge.net  Sun Apr 22 03:36:54 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 21 Apr 2001 19:36:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-417802 ] mode_t not appropriate for chmod in BCC
Message-ID: <E14r9k6-0001SV-00@usw-sf-web3.sourceforge.net>

Bugs item #417802, was updated on 2001-04-20 22:49
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417802&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Stephen Hansen (ixokai)
Assigned to: Nobody/Anonymous (nobody)
Summary: mode_t not appropriate for chmod in BCC

Initial Comment:
In reference to the 'chmod' definition in 
posixmodule.c (~line 155). Under Borland 
C++5.5, 'mode_t' is defined in sys/types.h as a short, 
and yet io.h defines 'chmod' as taking char* and an 
int, so the compiler gives an error of, "Type mismatch 
in redeclaration of 'chmod'" here.

Since sys/types.h is going to redefine mode_t after 
anything we put into pyport/config, the only way I can 
see to fix this would be to put an #ifdef __BORLANDC__ 
in there.

Now, to go fix all the other errors BC is spitting out 
in that file. <le sigh>

----------------------------------------------------------------------

>Comment By: Stephen Hansen (ixokai)
Date: 2001-04-21 19:36

Message:
Logged In: YES 
user_id=200343

The below is Python 2.1final, btw. I keep forgetting to 
include that.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417802&group_id=5470


From noreply@sourceforge.net  Sun Apr 22 03:46:59 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 21 Apr 2001 19:46:59 -0700
Subject: [Python-bugs-list] [ python-Bugs-417930 ] += not assigning to same var it reads
Message-ID: <E14r9tr-000520-00@usw-sf-web1.sourceforge.net>

Bugs item #417930, was updated on 2001-04-21 16:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417930&group_id=5470

>Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Edward Loper (edloper)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: += not assigning to same var it reads

Initial Comment:
My understanding of the augmented assignment 
statements is that they should always assign to the 
variable that they read from.  However, consider the 
following Python session:
  >>> class A: x = 1  
  ...  
  >>> a=A()
  >>> a.x += 1
  >>> a.x, A.x
  (2, 1)

Here, the expression "a.x += 1" read from a class 
variable, and wrote to an instance variable.  A 
similar effect can occur within a member function:
  >>> class A:
  ...     x = 1
  ...     def f(s): s.x += 1
  ... 
  >>> a = A()
  >>> a.f()
  >>> a.x, A.x
  (2, 1)

I have elicited this behavior in Python 2.0 and 2.1 
under Linux (Redhat 6.0), and Python 2.0 on sunos5.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-04-21 19:46

Message:
Logged In: YES 
user_id=31435

Sorry, but your understanding is flawed.  Changed the 
category to Documentation and assigned to Fred, because I 
agree the Ref Man isn't clear enough here:  "The target is 
evaluated only once" is certainly how Guido *thinks* of it, 
but it really needs a by-cases explanation:

For an attributeref target, the primary expression in the 
reference is evaluated only once, but a getattr is done on 
the RHS and a setattr on the LHS.  That is,

    e1.attr op= e2

acts like

    temp1 = e1
    temp2 = e2
    temp1.attr = temp1.attr op temp2

Etc.  It's going to take some real work to write this up so 
they're comprehensible!  I recommend skipping most words 
and presenting "workalike" pseudo-code sequences instead.  
That will take some sessions with the disassembler to be 
sure the pseudo-code is 100% accurate.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417930&group_id=5470


From noreply@sourceforge.net  Sun Apr 22 03:55:15 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 21 Apr 2001 19:55:15 -0700
Subject: [Python-bugs-list] [ python-Bugs-417491 ] UnixWare BUILD *STILL* uses ld -G
Message-ID: <E14rA1r-0001eY-00@usw-sf-web3.sourceforge.net>

Bugs item #417491, was updated on 2001-04-19 16:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417491&group_id=5470

Category: Installation
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Larry Rosenman (ler)
Assigned to: Nobody/Anonymous (nobody)
Summary: UnixWare BUILD *STILL* uses ld -G

Initial Comment:
bug 231439 is BACK in the 2.1 final release.  It still
uses ld -G. 

ALL shared objects, ESPECIALLY those using threads,
should be compiled  *AND* linked using cc -G. 

I'm very disappointed in that the bug was closed but
the QA process dropped the fix(es). 


ALSO, when doing the initial build using Shared
Objects, you need to set -R and/or set LD_LIBRARY_PATH
to suit. 



----------------------------------------------------------------------

>Comment By: Larry Rosenman (ler)
Date: 2001-04-21 19:55

Message:
Logged In: YES 
user_id=36452

Oh, and I'm VERY willing to test RC's. I didn't realize it
was close to release.....



----------------------------------------------------------------------

Comment By: Larry Rosenman (ler)
Date: 2001-04-21 19:35

Message:
Logged In: YES 
user_id=36452

Ok. Sorry for the screaming, but the CVS sources are STILL
broken.

Can someone look at the patch I generated, and see if it can
be integrated 
into current CVS? 

I've built 2.1 with it on UnixWare 7 7.1.1 with the UDK FS
7.1.1b compiler. 

It works. 



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-04-21 19:30

Message:
Logged In: YES 
user_id=31435

LARRY, there's REALLY no need to SCREAM on *EACH* word in 
THREE <wink>.

You're not impressed by QA -- join the club.  Testing is 
done by volunteers, and if there are no volunteers *trying* 
the release candidates on a new platform, we have no way to 
know whether they work.  Linux and Windows and Mac Classic 
are pretty well covered by volunteers, but that's about 
it.  If UnixWare is important enough to you, volunteer to 
test release candidates there yourself, or even pay someone 
to do it.  But don't go honking on Martin!  That's out of 
line.

About your "The last comments on this patch are telling.", 
the last comments on that patch were made *after* the 
release.  Before the release, Guido checked in the patch 
that the UnixWare user said was needed.  He can't guess 
whether a patch actually works on a platform he doesn't 
use.  The last patch comment by a UnixWare user *before* 
the release reads

"""Every thing looks fine (as far as I can tell)."""

WRT "why the H*LL didn't the release .tar get RE-ROLLED?", 
it's because nobody said anything was broken until after 
the release shipped (your bug report here was 2 days after 
the release).

----------------------------------------------------------------------

Comment By: Larry Rosenman (ler)
Date: 2001-04-21 17:34

Message:
Logged In: YES 
user_id=36452

OK, here is a patch I wrote to configure.in to fix this. 
regen configure and config.h.in 

Let me know if this is acceptable.  THis is against the
2.1-RELEASE version. 

Larry 

----------------------------------------------------------------------

Comment By: Larry Rosenman (ler)
Date: 2001-04-21 15:45

Message:
Logged In: YES 
user_id=36452

Oh, and 1.215 is *BROKE*, as it spec's ld -G, not CC -G,
around line 615 or so.

PLEASE fix. 

PLEASE generate a FIX RELEASE for the 2.1 RELEASE.

This is *NOT* a good sign that a broken PORT didn't stop the
release process. 



----------------------------------------------------------------------

Comment By: Larry Rosenman (ler)
Date: 2001-04-21 15:23

Message:
Logged In: YES 
user_id=36452

OK, why the H*LL didn't the release .tar get RE-ROLLED?  The
last comments on this patch are telling.  

I'm *NOT* impressed, and the bug reported here is mentioned
in that stream, so why wasn't the RELEASE held for this? 
the port is PROMINENTLY mentioned in the release notes, but
it's BROKE in the RELEASE.  How can I get a new tarball from
y'all? 



----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-04-21 05:55

Message:
Logged In: YES 
user_id=21627

I agree this is very unfortunate. Please have a look at
patch 413011, which was committed as 1.215 of configure.in.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417491&group_id=5470


From noreply@sourceforge.net  Sun Apr 22 04:09:17 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 21 Apr 2001 20:09:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-417949 ] BorlandC55 needs #def HAVE_UTIME_H
Message-ID: <E14rAFR-0005Lk-00@usw-sf-web1.sourceforge.net>

Bugs item #417949, was updated on 2001-04-21 19:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417949&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Stephen Hansen (ixokai)
Assigned to: Nobody/Anonymous (nobody)
Summary: BorlandC55 needs #def HAVE_UTIME_H

Initial Comment:
Under Python2.1:

PC/config.h globally defines HAVE_SYS_UTIME_H at ~line 
597, but the Borland C++Builder/compiler needs 
HAVE_UTIME_H instead; this is used in other files 
(posixmodule.c, specifically) to #include <utime.h> 
instead of <sys/utime.h>.



----------------------------------------------------------------------

>Comment By: Stephen Hansen (ixokai)
Date: 2001-04-21 20:09

Message:
Logged In: YES 
user_id=200343

Additionally, Borland also requires a '#define 
HAVE_DIRENT_H' in the config.h file to get BCC to finally 
compile through Posixmodule before it crashes into 
timemodule. *grin* :)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417949&group_id=5470


From noreply@sourceforge.net  Sun Apr 22 04:09:52 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 21 Apr 2001 20:09:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-417949 ] Missing #defines for Borland compiler
Message-ID: <E14rAG0-0005Lx-00@usw-sf-web1.sourceforge.net>

Bugs item #417949, was updated on 2001-04-21 19:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417949&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Stephen Hansen (ixokai)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Missing #defines for Borland compiler

Initial Comment:
Under Python2.1:

PC/config.h globally defines HAVE_SYS_UTIME_H at ~line 
597, but the Borland C++Builder/compiler needs 
HAVE_UTIME_H instead; this is used in other files 
(posixmodule.c, specifically) to #include <utime.h> 
instead of <sys/utime.h>.



----------------------------------------------------------------------

Comment By: Stephen Hansen (ixokai)
Date: 2001-04-21 20:09

Message:
Logged In: YES 
user_id=200343

Additionally, Borland also requires a '#define 
HAVE_DIRENT_H' in the config.h file to get BCC to finally 
compile through Posixmodule before it crashes into 
timemodule. *grin* :)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417949&group_id=5470


From noreply@sourceforge.net  Sun Apr 22 04:34:08 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 21 Apr 2001 20:34:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-417952 ] Borland spells timezone as _timezone
Message-ID: <E14rAdU-00023c-00@usw-sf-web3.sourceforge.net>

Bugs item #417952, was updated on 2001-04-21 20:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417952&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Stephen Hansen (ixokai)
Assigned to: Nobody/Anonymous (nobody)
Summary: Borland spells timezone as _timezone

Initial Comment:
Borland (to be difficult, I 'spose :)) 
spells 'timezone' 'daylight' and 'tzname' with an 
underscore at the begenning. These errors are in the 
inittime function.

The fix I used on my machine (just until I see how 
ya'll do it officially) was to add the following lines 
under '#include <time.h>' in pyport.h:

#ifdef __BORLANDC__
#  define timezone _timezone
#  define daylight _daylight
#  define tzname _tzname
#endif

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417952&group_id=5470


From noreply@sourceforge.net  Sun Apr 22 04:45:06 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 21 Apr 2001 20:45:06 -0700
Subject: [Python-bugs-list] [ python-Bugs-215026 ] SSL features undocumented
Message-ID: <E14rAo6-0005qI-00@usw-sf-web1.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
Resolution: Later
Priority: 4
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: Mark Hammond (mhammond)
Date: 2001-04-21 20:45

Message:
Logged In: YES 
user_id=14198

Sorry, but I don't use SSL at all, so back to Fred.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-04-19 15:01

Message:
Logged In: YES 
user_id=31435

Assigned to MarkH on the off chance he runs SSL on 
Windows.  Mark, if you don't either, then nobody who runs 
on Windows cares about this enough to bother, so just 
reassign it to Fred for the doc-issue part of it.

----------------------------------------------------------------------

Comment By: Moshe Zadka (moshez)
Date: 2001-04-09 07:00

Message:
Logged In: YES 
user_id=11645

Test case is trivial:

>>> a = urllib2.urlopen('https://sourceforge.net')
>>> a.read(10)

And see that something comes out.

I can't help any more with that, I haven't seen a windows
machine for longer then Tim hasn't seen a socket...
Assigning back to tim -- if you can't solve it, someone more
qualified them me will have to solve it.

----------------------------------------------------------------------

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 Apr 22 07:44:16 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 21 Apr 2001 23:44:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-417913 ] odd behavior when reloading "exceptions"
Message-ID: <E14rDbU-0003vr-00@usw-sf-web3.sourceforge.net>

Bugs item #417913, was updated on 2001-04-21 14:57
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417913&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Klatt (michaelklatt)
Assigned to: Nobody/Anonymous (nobody)
>Summary: odd behavior when reloading "exceptions"

Initial Comment:

After reloading the "exceptions" module, "exceptions.OSError" is not the same object as "os.error".

Let me illustrate by example:


# ./python
Python 2.1 (#1, Apr 20 2001, 23:16:45) 
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> import os, exceptions
>>> os.error == exceptions.OSError
1
>>> reload(exceptions)
<module 'exceptions' (built-in)>
>>> os.error == exceptions.OSError
0
>>>


Here's an example of how this could wreak havoc in a python script:

# ./python
Python 2.1 (#1, Apr 20 2001, 23:16:45) 
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> import os
>>> import exceptions
>>> 
>>> try:
...    os.stat("dummy")
... except os.error, e:
...     print "exception caught"
... 
exception caught
>>> reload(exceptions)
<module 'exceptions' (built-in)>
>>> 
>>> try:
...    os.stat("dummy")
... except os.error, e:
...     print "exception caught"
... 
Traceback (most recent call last):
  File "<stdin>", line 2, in ?
OSError: [Errno 2] No such file or directory: 'dummy'
>>> 


A quick test shows that this problem also occurred in python 1.5.2 and python 2.0.  I believe I 
understand why this is happening (when the exceptions module is reloaded, a new object for 
OSError is created), but I'm hoping someone has a creative solution.  

This will cause problems in any application which calls Py_NewInterpreter() (like mod_python).  
To verify this, add the following lines to Demo/embed/demo.c at line 36:

 
        PyRun_SimpleString("import os,exceptions\n");
        PyRun_SimpleString("print os.error == exceptions.OSError\n");
 
        Py_NewInterpreter(); 
        PyRun_SimpleString("import os,exceptions\n");
        PyRun_SimpleString("print os.error == exceptions.OSError\n");

The first comparison will result in 1, and the second will result in 0. 

Thanks!

Mike



----------------------------------------------------------------------

>Comment By: Michael Klatt (michaelklatt)
Date: 2001-04-21 23:44

Message:
Logged In: YES 
user_id=201661


I did find a workaround for mod_python (and any application that uses Py_NewInterpreter()...).  I modified it 
to add this line after *every* call to Py_NewInterpreter()

PyRun_SimpleString("__import__(\os\).error = __import__(\exceptions\).OSError\n");

This is ugly, but it's a works.

Mike


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417913&group_id=5470


From noreply@sourceforge.net  Sun Apr 22 15:52:37 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 22 Apr 2001 07:52:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-411881 ] Use of "except:" in modules
Message-ID: <E14rLE5-0002UP-00@usw-sf-web2.sourceforge.net>

Bugs item #411881, was updated on 2001-03-28 04:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411881&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Itamar Shtull-Trauring (itamar)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Use of "except:" in modules

Initial Comment:
A large amount of modules in the standard library use
"except:" instead of specifying the exceptions to be
caught. In some cases this may be correct, but I think
in most cases this not true and this may cause
problems. Here's the list of modules, which I got by
doing:

   grep "except:" *.py | cut -f 1 -d " " | sort | uniq

Bastion.py
CGIHTTPServer.py
Cookie.py
SocketServer.py
anydbm.py
asyncore.py
bdb.py
cgi.py
chunk.py
cmd.py
code.py
compileall.py
doctest.py
fileinput.py
formatter.py
getpass.py
htmllib.py
imaplib.py
inspect.py
locale.py
locale.py
mailcap.py
mhlib.py
mimetools.py
mimify.py
os.py
pdb.py
popen2.py
posixfile.py
pre.py
pstats.py
pty.py
pyclbr.py
pydoc.py
repr.py
rexec.py
rfc822.py
shelve.py
shutil.py
tempfile.py
threading.py
traceback.py
types.py
unittest.py
urllib.py
zipfile.py


----------------------------------------------------------------------

>Comment By: Itamar Shtull-Trauring (itamar)
Date: 2001-04-22 07:52

Message:
Logged In: YES 
user_id=32065

I submitted a 4th patch. I'm starting to run out of easy
cases...

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2001-04-19 02:15

Message:
Logged In: YES 
user_id=44345

I believe the following patch is correct for the try/except
in inspect.currentframe.  Note that it fixes two problems. 
One, it avoids a bare except.  Two, it gets rid of a string
argument to the raise statement (string exceptions are now
deprecated, right?).

*** /tmp/skip/inspect.py	Thu Apr 19 04:13:36 2001
--- /tmp/skip/inspect.py.~1.16~	Thu Apr 19 04:13:36 2001
***************
*** 643,650 ****
  def currentframe():
      """Return the frame object for the caller's stack
frame."""
      try:
!         1/0
!     except ZeroDivisionError:
          return sys.exc_traceback.tb_frame.f_back
  
  if hasattr(sys, '_getframe'): currentframe = sys._getframe
--- 643,650 ----
  def currentframe():
      """Return the frame object for the caller's stack
frame."""
      try:
!         raise 'catch me'
!     except:
          return sys.exc_traceback.tb_frame.f_back
  
  if hasattr(sys, '_getframe'): currentframe = sys._getframe


----------------------------------------------------------------------

Comment By: Itamar Shtull-Trauring (itamar)
Date: 2001-04-17 08:27

Message:
Logged In: YES 
user_id=32065

inspect.py uses sys_getframe if it's there, the other code
is for backwards compatibility.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-11 10:24

Message:
Logged In: YES 
user_id=6380

Actually, inspect.py should use sys._getframe()!

And yes, KeyboardError is definitely one of the reasons why
this is such a bad idiom...

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2001-04-11 10:15

Message:
Logged In: YES 
user_id=89016

> Can you identify modules where catching everything 
> is incorrect

If "everything" includes KeyboardInterrupt, it's
definitely incorrect, even in inspect.py's simple

    try:
        raise 'catch me'
    except:
        return sys.exc_traceback.tb_frame.f_back

which should probably be:

    try:
        raise 'catch me'
    except KeyboardInterrupt:
        raise
    except:
        return sys.exc_traceback.tb_frame.f_back


----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2001-04-11 10:13

Message:
Logged In: YES 
user_id=89016

> Can you identify modules where catching everything 
> is incorrect

If "everything" includes KeyboardInterrupt, it's
definitely incorrect, even in inspect.py's simple

    try:
        raise 'catch me'
    except:
        return sys.exc_traceback.tb_frame.f_back

which should probably be:

    try:
        raise 'catch me'
    except KeyboardInterrupt:
        raise
    except:
        return sys.exc_traceback.tb_frame.f_back


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 08:45

Message:
Logged In: YES 
user_id=6380

I've applied the three patches you supplied.

I agree with Martin that to do this right we'll have to
tread carefully. But please go on!

(No way more of this will find its way into 2.1 though.)

----------------------------------------------------------------------

Comment By: Itamar Shtull-Trauring (itamar)
Date: 2001-03-30 02:54

Message:
Logged In: YES 
user_id=32065

inspect.py should be removed from this list, the use is
correct.

In general, I just submitted this bug so that when people
are editing a module they'll notice these things, since in
some cases only someone who knows the code very well can
know if the "expect:" is needed or not.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-03-29 22:59

Message:
Logged In: YES 
user_id=21627

Can you identify modules where catching everything is
incorrect, and propose changes to correct them. This should
be done one-by-one, with careful analysis in each case, and
may take well months or years to complete.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411881&group_id=5470


From noreply@sourceforge.net  Mon Apr 23 08:32:31 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 23 Apr 2001 00:32:31 -0700
Subject: [Python-bugs-list] [ python-Bugs-411881 ] Use of "except:" in modules
Message-ID: <E14rapj-00059E-00@usw-sf-web2.sourceforge.net>

Bugs item #411881, was updated on 2001-03-28 04:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411881&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Itamar Shtull-Trauring (itamar)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Use of "except:" in modules

Initial Comment:
A large amount of modules in the standard library use
"except:" instead of specifying the exceptions to be
caught. In some cases this may be correct, but I think
in most cases this not true and this may cause
problems. Here's the list of modules, which I got by
doing:

   grep "except:" *.py | cut -f 1 -d " " | sort | uniq

Bastion.py
CGIHTTPServer.py
Cookie.py
SocketServer.py
anydbm.py
asyncore.py
bdb.py
cgi.py
chunk.py
cmd.py
code.py
compileall.py
doctest.py
fileinput.py
formatter.py
getpass.py
htmllib.py
imaplib.py
inspect.py
locale.py
locale.py
mailcap.py
mhlib.py
mimetools.py
mimify.py
os.py
pdb.py
popen2.py
posixfile.py
pre.py
pstats.py
pty.py
pyclbr.py
pydoc.py
repr.py
rexec.py
rfc822.py
shelve.py
shutil.py
tempfile.py
threading.py
traceback.py
types.py
unittest.py
urllib.py
zipfile.py


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2001-04-23 00:32

Message:
Logged In: YES 
user_id=21627

For inspect.py, why is it necessary to keep the old code at
all? My proposal: remove currentframe altogether, and do
currentframe = sys._getframe
unconditionally.

----------------------------------------------------------------------

Comment By: Itamar Shtull-Trauring (itamar)
Date: 2001-04-22 07:52

Message:
Logged In: YES 
user_id=32065

I submitted a 4th patch. I'm starting to run out of easy
cases...

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2001-04-19 02:15

Message:
Logged In: YES 
user_id=44345

I believe the following patch is correct for the try/except
in inspect.currentframe.  Note that it fixes two problems. 
One, it avoids a bare except.  Two, it gets rid of a string
argument to the raise statement (string exceptions are now
deprecated, right?).

*** /tmp/skip/inspect.py	Thu Apr 19 04:13:36 2001
--- /tmp/skip/inspect.py.~1.16~	Thu Apr 19 04:13:36 2001
***************
*** 643,650 ****
  def currentframe():
      """Return the frame object for the caller's stack
frame."""
      try:
!         1/0
!     except ZeroDivisionError:
          return sys.exc_traceback.tb_frame.f_back
  
  if hasattr(sys, '_getframe'): currentframe = sys._getframe
--- 643,650 ----
  def currentframe():
      """Return the frame object for the caller's stack
frame."""
      try:
!         raise 'catch me'
!     except:
          return sys.exc_traceback.tb_frame.f_back
  
  if hasattr(sys, '_getframe'): currentframe = sys._getframe


----------------------------------------------------------------------

Comment By: Itamar Shtull-Trauring (itamar)
Date: 2001-04-17 08:27

Message:
Logged In: YES 
user_id=32065

inspect.py uses sys_getframe if it's there, the other code
is for backwards compatibility.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-11 10:24

Message:
Logged In: YES 
user_id=6380

Actually, inspect.py should use sys._getframe()!

And yes, KeyboardError is definitely one of the reasons why
this is such a bad idiom...

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2001-04-11 10:15

Message:
Logged In: YES 
user_id=89016

> Can you identify modules where catching everything 
> is incorrect

If "everything" includes KeyboardInterrupt, it's
definitely incorrect, even in inspect.py's simple

    try:
        raise 'catch me'
    except:
        return sys.exc_traceback.tb_frame.f_back

which should probably be:

    try:
        raise 'catch me'
    except KeyboardInterrupt:
        raise
    except:
        return sys.exc_traceback.tb_frame.f_back


----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2001-04-11 10:13

Message:
Logged In: YES 
user_id=89016

> Can you identify modules where catching everything 
> is incorrect

If "everything" includes KeyboardInterrupt, it's
definitely incorrect, even in inspect.py's simple

    try:
        raise 'catch me'
    except:
        return sys.exc_traceback.tb_frame.f_back

which should probably be:

    try:
        raise 'catch me'
    except KeyboardInterrupt:
        raise
    except:
        return sys.exc_traceback.tb_frame.f_back


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 08:45

Message:
Logged In: YES 
user_id=6380

I've applied the three patches you supplied.

I agree with Martin that to do this right we'll have to
tread carefully. But please go on!

(No way more of this will find its way into 2.1 though.)

----------------------------------------------------------------------

Comment By: Itamar Shtull-Trauring (itamar)
Date: 2001-03-30 02:54

Message:
Logged In: YES 
user_id=32065

inspect.py should be removed from this list, the use is
correct.

In general, I just submitted this bug so that when people
are editing a module they'll notice these things, since in
some cases only someone who knows the code very well can
know if the "expect:" is needed or not.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-03-29 22:59

Message:
Logged In: YES 
user_id=21627

Can you identify modules where catching everything is
incorrect, and propose changes to correct them. This should
be done one-by-one, with careful analysis in each case, and
may take well months or years to complete.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411881&group_id=5470


From noreply@sourceforge.net  Mon Apr 23 09:01:01 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 23 Apr 2001 01:01:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-418156 ] V2.1 installer not working on NT4 SP5
Message-ID: <E14rbHJ-00063g-00@usw-sf-web1.sourceforge.net>

Bugs item #418156, was updated on 2001-04-23 01:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418156&group_id=5470

Category: Windows
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Xavier Lagraula (xlagraula)
Assigned to: Nobody/Anonymous (nobody)
Summary: V2.1 installer not working on NT4 SP5

Initial Comment:
Hello.

I have a windows NT server (Nec PowerMate VT, 128Mo 
RAM) with quite a lot of products installed. During 
the installation, I always get a "corrupt installation 
detected" pop-up, whereas the files can correctly be 
extracted from the archive by winzip 8 or winrar 
2.80b2.

The products installed are
- Business Bridge V2.3.16 & V3.0.6 servers (SYSTAR)
- MySQL 3.23.32 server (+ODBC driver)
- Naviscope
- I.I.S. 4.0
- Winzip 8 french
- WinRAR 2.80b2
- Cygwin 1.1
- MS SQL/Server 6.5 client (+ODBC driver)
- MouseWare 9.00.99
- Office 97
- Oracle 7.3.4 & 8i clients (+ODBC drivers)
- UltraEdit 8
- TNG Remote Control Option

I'd like to know if there are any incompatibilities 
between the installer and any of these products, and 
I'd like to be given a manual procedure that would 
allow me to install python on my workstation.

Moreover, seeing that:
- I am not the only one having installation problems 
on windows
- I have had problems every time I have tried to 
install Python 2.1 on windows (both NT and 2000)
- The Python windows installer is a 16 bit technology 
that is not supported anymore if I can believe what 
tim_one told me (see request ID 416824)
My conclusion is that we all should consider using 
another windows installer.

Regards,
  Xavier

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418156&group_id=5470


From noreply@sourceforge.net  Mon Apr 23 09:14:47 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 23 Apr 2001 01:14:47 -0700
Subject: [Python-bugs-list] [ python-Bugs-411881 ] Use of "except:" in modules
Message-ID: <E14rbUd-0005j8-00@usw-sf-web2.sourceforge.net>

Bugs item #411881, was updated on 2001-03-28 04:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411881&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Itamar Shtull-Trauring (itamar)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Use of "except:" in modules

Initial Comment:
A large amount of modules in the standard library use
"except:" instead of specifying the exceptions to be
caught. In some cases this may be correct, but I think
in most cases this not true and this may cause
problems. Here's the list of modules, which I got by
doing:

   grep "except:" *.py | cut -f 1 -d " " | sort | uniq

Bastion.py
CGIHTTPServer.py
Cookie.py
SocketServer.py
anydbm.py
asyncore.py
bdb.py
cgi.py
chunk.py
cmd.py
code.py
compileall.py
doctest.py
fileinput.py
formatter.py
getpass.py
htmllib.py
imaplib.py
inspect.py
locale.py
locale.py
mailcap.py
mhlib.py
mimetools.py
mimify.py
os.py
pdb.py
popen2.py
posixfile.py
pre.py
pstats.py
pty.py
pyclbr.py
pydoc.py
repr.py
rexec.py
rfc822.py
shelve.py
shutil.py
tempfile.py
threading.py
traceback.py
types.py
unittest.py
urllib.py
zipfile.py


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-04-23 01:14

Message:
Logged In: YES 
user_id=31435

Ping's intent is that pydoc work under versions of Python 
as early as 1.5.2, so that sys._getframe is off-limits in 
pydoc and its supporting code (like inspect.py).

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-04-23 00:32

Message:
Logged In: YES 
user_id=21627

For inspect.py, why is it necessary to keep the old code at
all? My proposal: remove currentframe altogether, and do
currentframe = sys._getframe
unconditionally.

----------------------------------------------------------------------

Comment By: Itamar Shtull-Trauring (itamar)
Date: 2001-04-22 07:52

Message:
Logged In: YES 
user_id=32065

I submitted a 4th patch. I'm starting to run out of easy
cases...

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2001-04-19 02:15

Message:
Logged In: YES 
user_id=44345

I believe the following patch is correct for the try/except
in inspect.currentframe.  Note that it fixes two problems. 
One, it avoids a bare except.  Two, it gets rid of a string
argument to the raise statement (string exceptions are now
deprecated, right?).

*** /tmp/skip/inspect.py	Thu Apr 19 04:13:36 2001
--- /tmp/skip/inspect.py.~1.16~	Thu Apr 19 04:13:36 2001
***************
*** 643,650 ****
  def currentframe():
      """Return the frame object for the caller's stack
frame."""
      try:
!         1/0
!     except ZeroDivisionError:
          return sys.exc_traceback.tb_frame.f_back
  
  if hasattr(sys, '_getframe'): currentframe = sys._getframe
--- 643,650 ----
  def currentframe():
      """Return the frame object for the caller's stack
frame."""
      try:
!         raise 'catch me'
!     except:
          return sys.exc_traceback.tb_frame.f_back
  
  if hasattr(sys, '_getframe'): currentframe = sys._getframe


----------------------------------------------------------------------

Comment By: Itamar Shtull-Trauring (itamar)
Date: 2001-04-17 08:27

Message:
Logged In: YES 
user_id=32065

inspect.py uses sys_getframe if it's there, the other code
is for backwards compatibility.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-11 10:24

Message:
Logged In: YES 
user_id=6380

Actually, inspect.py should use sys._getframe()!

And yes, KeyboardError is definitely one of the reasons why
this is such a bad idiom...

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2001-04-11 10:15

Message:
Logged In: YES 
user_id=89016

> Can you identify modules where catching everything 
> is incorrect

If "everything" includes KeyboardInterrupt, it's
definitely incorrect, even in inspect.py's simple

    try:
        raise 'catch me'
    except:
        return sys.exc_traceback.tb_frame.f_back

which should probably be:

    try:
        raise 'catch me'
    except KeyboardInterrupt:
        raise
    except:
        return sys.exc_traceback.tb_frame.f_back


----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2001-04-11 10:13

Message:
Logged In: YES 
user_id=89016

> Can you identify modules where catching everything 
> is incorrect

If "everything" includes KeyboardInterrupt, it's
definitely incorrect, even in inspect.py's simple

    try:
        raise 'catch me'
    except:
        return sys.exc_traceback.tb_frame.f_back

which should probably be:

    try:
        raise 'catch me'
    except KeyboardInterrupt:
        raise
    except:
        return sys.exc_traceback.tb_frame.f_back


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 08:45

Message:
Logged In: YES 
user_id=6380

I've applied the three patches you supplied.

I agree with Martin that to do this right we'll have to
tread carefully. But please go on!

(No way more of this will find its way into 2.1 though.)

----------------------------------------------------------------------

Comment By: Itamar Shtull-Trauring (itamar)
Date: 2001-03-30 02:54

Message:
Logged In: YES 
user_id=32065

inspect.py should be removed from this list, the use is
correct.

In general, I just submitted this bug so that when people
are editing a module they'll notice these things, since in
some cases only someone who knows the code very well can
know if the "expect:" is needed or not.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-03-29 22:59

Message:
Logged In: YES 
user_id=21627

Can you identify modules where catching everything is
incorrect, and propose changes to correct them. This should
be done one-by-one, with careful analysis in each case, and
may take well months or years to complete.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411881&group_id=5470


From noreply@sourceforge.net  Mon Apr 23 09:42:06 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 23 Apr 2001 01:42:06 -0700
Subject: [Python-bugs-list] [ python-Bugs-418156 ] V2.1 installer not working on NT4 SP5
Message-ID: <E14rbv4-0006kB-00@usw-sf-web1.sourceforge.net>

Bugs item #418156, was updated on 2001-04-23 01:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418156&group_id=5470

Category: Windows
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Xavier Lagraula (xlagraula)
>Assigned to: Tim Peters (tim_one)
Summary: V2.1 installer not working on NT4 SP5

Initial Comment:
Hello.

I have a windows NT server (Nec PowerMate VT, 128Mo 
RAM) with quite a lot of products installed. During 
the installation, I always get a "corrupt installation 
detected" pop-up, whereas the files can correctly be 
extracted from the archive by winzip 8 or winrar 
2.80b2.

The products installed are
- Business Bridge V2.3.16 & V3.0.6 servers (SYSTAR)
- MySQL 3.23.32 server (+ODBC driver)
- Naviscope
- I.I.S. 4.0
- Winzip 8 french
- WinRAR 2.80b2
- Cygwin 1.1
- MS SQL/Server 6.5 client (+ODBC driver)
- MouseWare 9.00.99
- Office 97
- Oracle 7.3.4 & 8i clients (+ODBC drivers)
- UltraEdit 8
- TNG Remote Control Option

I'd like to know if there are any incompatibilities 
between the installer and any of these products, and 
I'd like to be given a manual procedure that would 
allow me to install python on my workstation.

Moreover, seeing that:
- I am not the only one having installation problems 
on windows
- I have had problems every time I have tried to 
install Python 2.1 on windows (both NT and 2000)
- The Python windows installer is a 16 bit technology 
that is not supported anymore if I can believe what 
tim_one told me (see request ID 416824)
My conclusion is that we all should consider using 
another windows installer.

Regards,
  Xavier

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-04-23 01:42

Message:
Logged In: YES 
user_id=31435

We are having more reports of installer problems under 2.1 
than under previous releases, but I can still count the 
total on one hand.  Since we don't have the installer 
source code, and reports are still so rare (notwithstanding 
your particular bad luck) there's not much we can do to 
track them down.

Did you use the MD5 checksum program to verify your binary 
is valid?  Go to http://www.python.org/2.1/, go down to 
the "MD5 checksums" section, and click on the "MD5" part of 
the section heading to get a Python program for computing 
the MD5 digest.

In *almost* all past cases of "corrupt installation 
detected" messages, further investigation has revealed that 
the binary *was* corrupt.  The MD5 digest is a very 
powerful check on that (much stronger than a CRC):  if the 
checksum you get doesn't match the one on the web page 
above, your installer is definitely corrupt.  If it 
matches, the chance that it's corrupt anyway is too small 
to entertain.  So do that.  That you've had *repeated* 
installation failures is unprecedented in Python's history, 
so my top guess has to be you have a flaky binary.

There is only one other cause I've ever heard of for 
a "corrupt installation detected" message under NT:  the 
user was logged in to a Restricted account when they tried 
to install.  In that case, the Wise installer apparently 
can't even get at the system components it needs to compute 
its own internal checksums, and interprets that failure as 
a bad checksum.

So, what were you logged in as?  If the MD5 digest matches, 
and you're logged in to an Administrator account when it 
fails, then you've got a problem never reported before.  Do 
you?

As to using another Windows installer, I'm in favor of 
that, but so are you <wink>:  who's going to do the work?  
I can tell you I don't have time for it.  BTW, have you 
tried ActiveState's Python installer for Windows?  That's 
built with entirely different, and up-to-date, technology.  
Maybe it will work better for you.  But the terms of the 
ActiveState license don't allow us to use it too (fine by 
me -- they paid for it).

As to believing me, you don't have to:  ask Wise 
Solutions.  It's their product, version 5.0a.  You can't 
even find it mentioned on their web site anymore -- it's 
that old!  They're on version 8 now, and even their 
newsgroups only back to version 6.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418156&group_id=5470


From noreply@sourceforge.net  Mon Apr 23 10:41:05 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 23 Apr 2001 02:41:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-418173 ] Unicode problem in Tkinter under Windows
Message-ID: <E14rcq9-000693-00@usw-sf-web3.sourceforge.net>

Bugs item #418173, was updated on 2001-04-23 02:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418173&group_id=5470

Category: Tkinter
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unicode problem in Tkinter under Windows

Initial Comment:
Unicode problem in Tkinter under Windows 2000
Keyboard-entered chars in ascii range > 128 mess up 
internal unicode encoding in text-widget leading to 
unicode errors

The following example should reproduce the bug:

>>> import Tkinter
>>> t=Tkinter.Text()
>>> t.pack()
>>> t.insert("1.0",u'\xe2\xee\xfb')

Now set the focus to the text-widget and via the 
keyboard enter an a umlaut into the text-widget 
(alternatively press ALT and enter 0228 on the Numpad 
of your Keyboard to simulate this)
Then test the result:
>>> t.get("1.0","end")
u'\xe2\xee\xfb\xe4\n'
This is what you get under Linux (I was told) and what 
it should be.
However, under Windows 2000 I get:
'\xc3\xa2\xc3\xae\xc3\xbb\xe4\n'
which is a mixture of UTF-8 and cp1252(?) leading to 
an Unicode-error, if I try e.g. to save it as a file.
(All characters of an 8-bit value > 128 (e.g. latin-1 
or cp1252) entered via keyboard into a text-widget 
cause such a weird behaviour, not just the a umlaut.)

A simple workaround (not thoroughly tested) could look 
like this:

def badkey(self, event):
    try:
        if ord(event.char) > 127:
            txt.insert("insert", unicode
(event.char,"cp1252"))
            return "break"
    except:
        pass

`txt` being the instance of a text-widget, that is 
bound to a callback for the key-press-event:

if sys.platform == "win32":
         txt.bind("<KeyPress>",badkey)


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418173&group_id=5470


From noreply@sourceforge.net  Mon Apr 23 11:04:29 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 23 Apr 2001 03:04:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-418156 ] V2.1 installer not working on NT4 SP5
Message-ID: <E14rdCn-00078c-00@usw-sf-web2.sourceforge.net>

Bugs item #418156, was updated on 2001-04-23 01:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418156&group_id=5470

Category: Windows
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Xavier Lagraula (xlagraula)
Assigned to: Tim Peters (tim_one)
Summary: V2.1 installer not working on NT4 SP5

Initial Comment:
Hello.

I have a windows NT server (Nec PowerMate VT, 128Mo 
RAM) with quite a lot of products installed. During 
the installation, I always get a "corrupt installation 
detected" pop-up, whereas the files can correctly be 
extracted from the archive by winzip 8 or winrar 
2.80b2.

The products installed are
- Business Bridge V2.3.16 & V3.0.6 servers (SYSTAR)
- MySQL 3.23.32 server (+ODBC driver)
- Naviscope
- I.I.S. 4.0
- Winzip 8 french
- WinRAR 2.80b2
- Cygwin 1.1
- MS SQL/Server 6.5 client (+ODBC driver)
- MouseWare 9.00.99
- Office 97
- Oracle 7.3.4 & 8i clients (+ODBC drivers)
- UltraEdit 8
- TNG Remote Control Option

I'd like to know if there are any incompatibilities 
between the installer and any of these products, and 
I'd like to be given a manual procedure that would 
allow me to install python on my workstation.

Moreover, seeing that:
- I am not the only one having installation problems 
on windows
- I have had problems every time I have tried to 
install Python 2.1 on windows (both NT and 2000)
- The Python windows installer is a 16 bit technology 
that is not supported anymore if I can believe what 
tim_one told me (see request ID 416824)
My conclusion is that we all should consider using 
another windows installer.

Regards,
  Xavier

----------------------------------------------------------------------

>Comment By: Xavier Lagraula (xlagraula)
Date: 2001-04-23 03:04

Message:
Logged In: YES 
user_id=198402

OK... Here are the news: I have installed ActiveState 
version without problems. I had to: how the hell could I 
compute a MD5 digest of the Python installer with a Python 
script, if I can't have Python installed, hm?

Anyway the digest proved to be perfectly correct. After 
all, I tried downloading the file for 2 different sources, 
and this was not a copy of the file I used on Win2k (see 
request ID 416824). But computing this digest allowed me to 
find the origin of the problem. I realized that I had saved 
the installer on a remote drive (windows shared directory 
on our file server), when I had to type "V:Python-21.exe" :)

My guess is that the SYSTEM account must have the right to 
read the directory containing the installer, and it was not 
the case. Once copied locally, it seems to work (I didn't 
go through the entire process, though, as I already had 
Python installed before).

I don't know if using the msi format is free or not. 
Another way for M$ to make money with a new mandatory 
installation format? If it's free, then it's the obvious 
choice for a future version of the windows installer. I'll 
try to gather some informations about it.

And "as to believing you", I must apologize to you: this 
sentence was a dumb litteral transcription of a french 
idiom which doesn't have exactly the sense it seems to 
have. This was just a way to tell readers that this 
information did came from you, so having a look at what you 
said may be of interest. No harm intended, really.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-04-23 01:42

Message:
Logged In: YES 
user_id=31435

We are having more reports of installer problems under 2.1 
than under previous releases, but I can still count the 
total on one hand.  Since we don't have the installer 
source code, and reports are still so rare (notwithstanding 
your particular bad luck) there's not much we can do to 
track them down.

Did you use the MD5 checksum program to verify your binary 
is valid?  Go to http://www.python.org/2.1/, go down to 
the "MD5 checksums" section, and click on the "MD5" part of 
the section heading to get a Python program for computing 
the MD5 digest.

In *almost* all past cases of "corrupt installation 
detected" messages, further investigation has revealed that 
the binary *was* corrupt.  The MD5 digest is a very 
powerful check on that (much stronger than a CRC):  if the 
checksum you get doesn't match the one on the web page 
above, your installer is definitely corrupt.  If it 
matches, the chance that it's corrupt anyway is too small 
to entertain.  So do that.  That you've had *repeated* 
installation failures is unprecedented in Python's history, 
so my top guess has to be you have a flaky binary.

There is only one other cause I've ever heard of for 
a "corrupt installation detected" message under NT:  the 
user was logged in to a Restricted account when they tried 
to install.  In that case, the Wise installer apparently 
can't even get at the system components it needs to compute 
its own internal checksums, and interprets that failure as 
a bad checksum.

So, what were you logged in as?  If the MD5 digest matches, 
and you're logged in to an Administrator account when it 
fails, then you've got a problem never reported before.  Do 
you?

As to using another Windows installer, I'm in favor of 
that, but so are you <wink>:  who's going to do the work?  
I can tell you I don't have time for it.  BTW, have you 
tried ActiveState's Python installer for Windows?  That's 
built with entirely different, and up-to-date, technology.  
Maybe it will work better for you.  But the terms of the 
ActiveState license don't allow us to use it too (fine by 
me -- they paid for it).

As to believing me, you don't have to:  ask Wise 
Solutions.  It's their product, version 5.0a.  You can't 
even find it mentioned on their web site anymore -- it's 
that old!  They're on version 8 now, and even their 
newsgroups only back to version 6.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418156&group_id=5470


From noreply@sourceforge.net  Mon Apr 23 11:06:00 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 23 Apr 2001 03:06:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-418156 ] V2.1 installer not working on NT4 SP5
Message-ID: <E14rdEG-0007AE-00@usw-sf-web2.sourceforge.net>

Bugs item #418156, was updated on 2001-04-23 01:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418156&group_id=5470

Category: Windows
>Group: Not a Bug
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Xavier Lagraula (xlagraula)
Assigned to: Tim Peters (tim_one)
Summary: V2.1 installer not working on NT4 SP5

Initial Comment:
Hello.

I have a windows NT server (Nec PowerMate VT, 128Mo 
RAM) with quite a lot of products installed. During 
the installation, I always get a "corrupt installation 
detected" pop-up, whereas the files can correctly be 
extracted from the archive by winzip 8 or winrar 
2.80b2.

The products installed are
- Business Bridge V2.3.16 & V3.0.6 servers (SYSTAR)
- MySQL 3.23.32 server (+ODBC driver)
- Naviscope
- I.I.S. 4.0
- Winzip 8 french
- WinRAR 2.80b2
- Cygwin 1.1
- MS SQL/Server 6.5 client (+ODBC driver)
- MouseWare 9.00.99
- Office 97
- Oracle 7.3.4 & 8i clients (+ODBC drivers)
- UltraEdit 8
- TNG Remote Control Option

I'd like to know if there are any incompatibilities 
between the installer and any of these products, and 
I'd like to be given a manual procedure that would 
allow me to install python on my workstation.

Moreover, seeing that:
- I am not the only one having installation problems 
on windows
- I have had problems every time I have tried to 
install Python 2.1 on windows (both NT and 2000)
- The Python windows installer is a 16 bit technology 
that is not supported anymore if I can believe what 
tim_one told me (see request ID 416824)
My conclusion is that we all should consider using 
another windows installer.

Regards,
  Xavier

----------------------------------------------------------------------

Comment By: Xavier Lagraula (xlagraula)
Date: 2001-04-23 03:04

Message:
Logged In: YES 
user_id=198402

OK... Here are the news: I have installed ActiveState 
version without problems. I had to: how the hell could I 
compute a MD5 digest of the Python installer with a Python 
script, if I can't have Python installed, hm?

Anyway the digest proved to be perfectly correct. After 
all, I tried downloading the file for 2 different sources, 
and this was not a copy of the file I used on Win2k (see 
request ID 416824). But computing this digest allowed me to 
find the origin of the problem. I realized that I had saved 
the installer on a remote drive (windows shared directory 
on our file server), when I had to type "V:Python-21.exe" :)

My guess is that the SYSTEM account must have the right to 
read the directory containing the installer, and it was not 
the case. Once copied locally, it seems to work (I didn't 
go through the entire process, though, as I already had 
Python installed before).

I don't know if using the msi format is free or not. 
Another way for M$ to make money with a new mandatory 
installation format? If it's free, then it's the obvious 
choice for a future version of the windows installer. I'll 
try to gather some informations about it.

And "as to believing you", I must apologize to you: this 
sentence was a dumb litteral transcription of a french 
idiom which doesn't have exactly the sense it seems to 
have. This was just a way to tell readers that this 
information did came from you, so having a look at what you 
said may be of interest. No harm intended, really.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-04-23 01:42

Message:
Logged In: YES 
user_id=31435

We are having more reports of installer problems under 2.1 
than under previous releases, but I can still count the 
total on one hand.  Since we don't have the installer 
source code, and reports are still so rare (notwithstanding 
your particular bad luck) there's not much we can do to 
track them down.

Did you use the MD5 checksum program to verify your binary 
is valid?  Go to http://www.python.org/2.1/, go down to 
the "MD5 checksums" section, and click on the "MD5" part of 
the section heading to get a Python program for computing 
the MD5 digest.

In *almost* all past cases of "corrupt installation 
detected" messages, further investigation has revealed that 
the binary *was* corrupt.  The MD5 digest is a very 
powerful check on that (much stronger than a CRC):  if the 
checksum you get doesn't match the one on the web page 
above, your installer is definitely corrupt.  If it 
matches, the chance that it's corrupt anyway is too small 
to entertain.  So do that.  That you've had *repeated* 
installation failures is unprecedented in Python's history, 
so my top guess has to be you have a flaky binary.

There is only one other cause I've ever heard of for 
a "corrupt installation detected" message under NT:  the 
user was logged in to a Restricted account when they tried 
to install.  In that case, the Wise installer apparently 
can't even get at the system components it needs to compute 
its own internal checksums, and interprets that failure as 
a bad checksum.

So, what were you logged in as?  If the MD5 digest matches, 
and you're logged in to an Administrator account when it 
fails, then you've got a problem never reported before.  Do 
you?

As to using another Windows installer, I'm in favor of 
that, but so are you <wink>:  who's going to do the work?  
I can tell you I don't have time for it.  BTW, have you 
tried ActiveState's Python installer for Windows?  That's 
built with entirely different, and up-to-date, technology.  
Maybe it will work better for you.  But the terms of the 
ActiveState license don't allow us to use it too (fine by 
me -- they paid for it).

As to believing me, you don't have to:  ask Wise 
Solutions.  It's their product, version 5.0a.  You can't 
even find it mentioned on their web site anymore -- it's 
that old!  They're on version 8 now, and even their 
newsgroups only back to version 6.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418156&group_id=5470


From noreply@sourceforge.net  Mon Apr 23 12:29:09 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 23 Apr 2001 04:29:09 -0700
Subject: [Python-bugs-list] [ python-Bugs-418173 ] Unicode problem in Tkinter under Windows
Message-ID: <E14reWj-0008C1-00@usw-sf-web2.sourceforge.net>

Bugs item #418173, was updated on 2001-04-23 02:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418173&group_id=5470

Category: Tkinter
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unicode problem in Tkinter under Windows

Initial Comment:
Unicode problem in Tkinter under Windows 2000
Keyboard-entered chars in ascii range > 128 mess up 
internal unicode encoding in text-widget leading to 
unicode errors

The following example should reproduce the bug:

>>> import Tkinter
>>> t=Tkinter.Text()
>>> t.pack()
>>> t.insert("1.0",u'\xe2\xee\xfb')

Now set the focus to the text-widget and via the 
keyboard enter an a umlaut into the text-widget 
(alternatively press ALT and enter 0228 on the Numpad 
of your Keyboard to simulate this)
Then test the result:
>>> t.get("1.0","end")
u'\xe2\xee\xfb\xe4\n'
This is what you get under Linux (I was told) and what 
it should be.
However, under Windows 2000 I get:
'\xc3\xa2\xc3\xae\xc3\xbb\xe4\n'
which is a mixture of UTF-8 and cp1252(?) leading to 
an Unicode-error, if I try e.g. to save it as a file.
(All characters of an 8-bit value > 128 (e.g. latin-1 
or cp1252) entered via keyboard into a text-widget 
cause such a weird behaviour, not just the a umlaut.)

A simple workaround (not thoroughly tested) could look 
like this:

def badkey(self, event):
    try:
        if ord(event.char) > 127:
            txt.insert("insert", unicode
(event.char,"cp1252"))
            return "break"
    except:
        pass

`txt` being the instance of a text-widget, that is 
bound to a callback for the key-press-event:

if sys.platform == "win32":
         txt.bind("<KeyPress>",badkey)


----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2001-04-23 04:29

Message:
Logged In: YES 
user_id=38388

I believe that this is a TCL bug. Could someone with more
Tcl/tk knowledge please review this ? If it is Unicode
related, then you can assign it back to me.

Thanks.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418173&group_id=5470


From noreply@sourceforge.net  Mon Apr 23 12:59:37 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 23 Apr 2001 04:59:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-418156 ] V2.1 installer not working on NT4 SP5
Message-ID: <E14rf0D-0001W0-00@usw-sf-web1.sourceforge.net>

Bugs item #418156, was updated on 2001-04-23 01:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418156&group_id=5470

Category: Windows
Group: Not a Bug
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Xavier Lagraula (xlagraula)
Assigned to: Tim Peters (tim_one)
Summary: V2.1 installer not working on NT4 SP5

Initial Comment:
Hello.

I have a windows NT server (Nec PowerMate VT, 128Mo 
RAM) with quite a lot of products installed. During 
the installation, I always get a "corrupt installation 
detected" pop-up, whereas the files can correctly be 
extracted from the archive by winzip 8 or winrar 
2.80b2.

The products installed are
- Business Bridge V2.3.16 & V3.0.6 servers (SYSTAR)
- MySQL 3.23.32 server (+ODBC driver)
- Naviscope
- I.I.S. 4.0
- Winzip 8 french
- WinRAR 2.80b2
- Cygwin 1.1
- MS SQL/Server 6.5 client (+ODBC driver)
- MouseWare 9.00.99
- Office 97
- Oracle 7.3.4 & 8i clients (+ODBC drivers)
- UltraEdit 8
- TNG Remote Control Option

I'd like to know if there are any incompatibilities 
between the installer and any of these products, and 
I'd like to be given a manual procedure that would 
allow me to install python on my workstation.

Moreover, seeing that:
- I am not the only one having installation problems 
on windows
- I have had problems every time I have tried to 
install Python 2.1 on windows (both NT and 2000)
- The Python windows installer is a 16 bit technology 
that is not supported anymore if I can believe what 
tim_one told me (see request ID 416824)
My conclusion is that we all should consider using 
another windows installer.

Regards,
  Xavier

----------------------------------------------------------------------

>Comment By: Xavier Lagraula (xlagraula)
Date: 2001-04-23 04:59

Message:
Logged In: YES 
user_id=198402

Oops... Another mistake from a french speaking english: I 
said 'sense' but I meant 'meaning' in the last paragraph.

----------------------------------------------------------------------

Comment By: Xavier Lagraula (xlagraula)
Date: 2001-04-23 03:04

Message:
Logged In: YES 
user_id=198402

OK... Here are the news: I have installed ActiveState 
version without problems. I had to: how the hell could I 
compute a MD5 digest of the Python installer with a Python 
script, if I can't have Python installed, hm?

Anyway the digest proved to be perfectly correct. After 
all, I tried downloading the file for 2 different sources, 
and this was not a copy of the file I used on Win2k (see 
request ID 416824). But computing this digest allowed me to 
find the origin of the problem. I realized that I had saved 
the installer on a remote drive (windows shared directory 
on our file server), when I had to type "V:Python-21.exe" :)

My guess is that the SYSTEM account must have the right to 
read the directory containing the installer, and it was not 
the case. Once copied locally, it seems to work (I didn't 
go through the entire process, though, as I already had 
Python installed before).

I don't know if using the msi format is free or not. 
Another way for M$ to make money with a new mandatory 
installation format? If it's free, then it's the obvious 
choice for a future version of the windows installer. I'll 
try to gather some informations about it.

And "as to believing you", I must apologize to you: this 
sentence was a dumb litteral transcription of a french 
idiom which doesn't have exactly the sense it seems to 
have. This was just a way to tell readers that this 
information did came from you, so having a look at what you 
said may be of interest. No harm intended, really.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-04-23 01:42

Message:
Logged In: YES 
user_id=31435

We are having more reports of installer problems under 2.1 
than under previous releases, but I can still count the 
total on one hand.  Since we don't have the installer 
source code, and reports are still so rare (notwithstanding 
your particular bad luck) there's not much we can do to 
track them down.

Did you use the MD5 checksum program to verify your binary 
is valid?  Go to http://www.python.org/2.1/, go down to 
the "MD5 checksums" section, and click on the "MD5" part of 
the section heading to get a Python program for computing 
the MD5 digest.

In *almost* all past cases of "corrupt installation 
detected" messages, further investigation has revealed that 
the binary *was* corrupt.  The MD5 digest is a very 
powerful check on that (much stronger than a CRC):  if the 
checksum you get doesn't match the one on the web page 
above, your installer is definitely corrupt.  If it 
matches, the chance that it's corrupt anyway is too small 
to entertain.  So do that.  That you've had *repeated* 
installation failures is unprecedented in Python's history, 
so my top guess has to be you have a flaky binary.

There is only one other cause I've ever heard of for 
a "corrupt installation detected" message under NT:  the 
user was logged in to a Restricted account when they tried 
to install.  In that case, the Wise installer apparently 
can't even get at the system components it needs to compute 
its own internal checksums, and interprets that failure as 
a bad checksum.

So, what were you logged in as?  If the MD5 digest matches, 
and you're logged in to an Administrator account when it 
fails, then you've got a problem never reported before.  Do 
you?

As to using another Windows installer, I'm in favor of 
that, but so are you <wink>:  who's going to do the work?  
I can tell you I don't have time for it.  BTW, have you 
tried ActiveState's Python installer for Windows?  That's 
built with entirely different, and up-to-date, technology.  
Maybe it will work better for you.  But the terms of the 
ActiveState license don't allow us to use it too (fine by 
me -- they paid for it).

As to believing me, you don't have to:  ask Wise 
Solutions.  It's their product, version 5.0a.  You can't 
even find it mentioned on their web site anymore -- it's 
that old!  They're on version 8 now, and even their 
newsgroups only back to version 6.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418156&group_id=5470


From noreply@sourceforge.net  Mon Apr 23 13:09:30 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 23 Apr 2001 05:09:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-229998 ] "Corrupt installation" when installed without admin privs
Message-ID: <E14rf9m-0000Li-00@usw-sf-web2.sourceforge.net>

Bugs item #229998, was updated on 2001-01-24 17:57
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=229998&group_id=5470

Category: Windows
Group: 3rd Party
Status: Closed
Resolution: Wont Fix
Priority: 1
Submitted By: Tessa Lau (tlau)
Assigned to: Tim Peters (tim_one)
Summary: "Corrupt installation" when installed without admin privs

Initial Comment:
On Windows 2000, when logged in a user without administrator privileges, attempting to run the Python 2.0 installer results in a single dialog box saying "Corrupt installation detected" and then the installer exits.

This should be a more informative error message.  I downloaded the 5MB installer three times before suspecting the correct cause of the problem.  When the same binary is run as a user with the correct privileges, it correctly begins the installation process.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-04-23 05:09

Message:
Logged In: NO 

I have the same problem with Windows NT TSE.

I use the admin to install Python. 

Python 1.5.2 ok !

But Python 1.6, 2.0, 2.1 => "Corrupt installation detected"

Sylvain FAUVEAU

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-01-25 23:06

Message:
tlau, thanks a lot for helping us here!  I wish we could help you in return, but Guido is right, there's really nothing we can do about it now.  Well, a long-term plan is to move to a more recent Windows installation program (the one we're using was developed before Win2K was even a rumor!), but that's not going to happen soon.

For a good time, download ActiveState's Python Windows installer, and see whether it blows up too:  no reason you can't be disappointed by all of us <wink>.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-01-25 14:27

Message:
Then this is most likely a bug we can't fix.  The"Corrupt installation" check is made AFAIK by the WISE installer code before it runs any of the script.  One of the system checks it does must be using something that's disallowed by Win2K in Restricted User mode.

We have control over the script -- it tests for Administrator privileges and offers to proceed; but we have no control over the system check before it runs.  I haven't seen this complaint before, so I presume it's unlikely to happen (Restricted Users typically won't want to install software :-).

I'll leave it up to Tim, but personally, I'd just close the report as "Won't Fix" and "3rd party".

----------------------------------------------------------------------

Comment By: Tessa Lau (tlau)
Date: 2001-01-25 13:22

Message:
I did some more investigating.  Python prints the correct md5 checksum for the installer; but that's a red herring.

In the "Users and Passwords" control panel, my account is set up as a "Restricted user" (Users Group) account.  When I change this setting to "Standard user" (Power Users Group), then launching the installer prompts me to proceed with a weaker installation (as expected).  Changing the setting back to "Restricted user" and re-running the installer produces the "corrupt installation detected" message yet again.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-01-25 04:52

Message:
I recall explicitly testing whether that installer worked on Win2000 without admin privileges.  So I suspect it's something to do with tlau's set-up, and I don't think we will be able to get much further with this.  (It doesn't help that we don't have the source code for the WISE installer generator, of course. :-( )


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-01-25 02:10

Message:
Curious!  That's the right MD5 checksum.  Yours is the only report of this we've ever gotten, though, while you're certainly not the only 2.0 Win2K user.  It's possible that you're the only one who wasn't logged on to an admin account, though.

Since you have Python running on Windows now, we can use it to compute the MD5 digest:

>>> # change to path of your installer; "rb" is crucial
>>> f = open("/updates/beopen-python-2.0.exe", "rb")
>>> import md5
>>> print md5.md5(f.read()).hexdigest()
05f93fc81247dfb993f2e946016264c0
>>>

If you still get the right checksum, we can rule out the file transfer, but then I'm stumped.  Guess we'll have to report it as a bug to Wise, then (we're not generating the error msg you're seeing -- that's all an automatic function of the Wise installer).


----------------------------------------------------------------------

Comment By: Tessa Lau (tlau)
Date: 2001-01-24 20:46

Message:
I downloaded it using this link:
http://www.python.org/ftp/python/2.0/BeOpen-Python-2.0.exe
The first two times I used IE to click on the link.  I didn't save those copies; I know the file size was around 5.8MB, but I don't know exactly.

For the third try, I used ncftp on a Linux machine to get this file:
ftp://ftp.python.org/pub/python/2.0/BeOpen-Python-2.0.exe
I then used Samba to copy the file from my Linux home directory to the Win2k machine.

I got the same error message (corrupt installation) for all three attempts.  I then logged in as a user with admin privs, ran the third copy, and installation proceeded correctly.

I don't know how to compute the checksum on Windows, but this is what I get from the copy I saved on my Linux system:
% md5sum BeOpen-Python-2.0.exe
05f93fc81247dfb993f2e946016264c0  BeOpen-Python-2.0.exe


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-01-24 20:07

Message:
I need someone else to confirm this (don't have W2K myself).  Mark?  If not, assign back to me.  tlau, from where did you obtain the installer?  Exactly how large is it?  (If it's not exactly 5811039 bytes, it's definitely corrupt -- if it is that size, say so and we'll try an MD5 checksum next.)

The Wise installer produces the "Corrupt installation  detected" msg itself, when it gets a CRC mismatch after checksumming its internal components.  We have no control over that, and in every previous case of this I know of it *did* mean the installer was corrupt.

If you're not logged in with admin privileges, what's supposed to happen is that a box pops up telling you so, and asking whether you want to proceed with a weaker installation, or abort the installation.  Testers reported that the 2.0 installer did exactly that, on NT and W2K (it's not an issue on 95, 98 or ME).


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=229998&group_id=5470


From noreply@sourceforge.net  Mon Apr 23 13:14:13 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 23 Apr 2001 05:14:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-418211 ] makesetup and "-Wl,-rpath=..."
Message-ID: <E14rfEL-0001nE-00@usw-sf-web1.sourceforge.net>

Bugs item #418211, was updated on 2001-04-23 05:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418211&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: makesetup and "-Wl,-rpath=..."

Initial Comment:
appending -Wl,-rpath='...' to the _tkinter entry in 
Modules/Setup to not have to deal with the
LD_LIBRARY_PATH breaks makesetup :(

Modules/Setup:
_tkinter _tkinter.c tkappinit.c -DWITH_APPINIT \
        -L/usr/local/tcltk8.2/lib
-Wl,-rpath=/usr/local/tcltk8.2/lib \



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418211&group_id=5470


From noreply@sourceforge.net  Mon Apr 23 13:14:28 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 23 Apr 2001 05:14:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-418212 ] makesetup and "-Wl,-rpath=..."
Message-ID: <E14rfEa-000827-00@usw-sf-web3.sourceforge.net>

Bugs item #418212, was updated on 2001-04-23 05:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418212&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: makesetup and "-Wl,-rpath=..."

Initial Comment:
appending -Wl,-rpath='...' to the _tkinter entry in 
Modules/Setup to not have to deal with the
LD_LIBRARY_PATH breaks makesetup :(

Modules/Setup:
_tkinter _tkinter.c tkappinit.c -DWITH_APPINIT \
        -L/usr/local/tcltk8.2/lib
-Wl,-rpath=/usr/local/tcltk8.2/lib \



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418212&group_id=5470


From noreply@sourceforge.net  Mon Apr 23 15:15:13 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 23 Apr 2001 07:15:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-418156 ] V2.1 installer not working on NT4 SP5
Message-ID: <E14rh7R-0002Aw-00@usw-sf-web2.sourceforge.net>

Bugs item #418156, was updated on 2001-04-23 01:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418156&group_id=5470

Category: Windows
Group: Not a Bug
Status: Open
Resolution: Accepted
>Priority: 1
Submitted By: Xavier Lagraula (xlagraula)
Assigned to: Tim Peters (tim_one)
Summary: V2.1 installer not working on NT4 SP5

Initial Comment:
Hello.

I have a windows NT server (Nec PowerMate VT, 128Mo 
RAM) with quite a lot of products installed. During 
the installation, I always get a "corrupt installation 
detected" pop-up, whereas the files can correctly be 
extracted from the archive by winzip 8 or winrar 
2.80b2.

The products installed are
- Business Bridge V2.3.16 & V3.0.6 servers (SYSTAR)
- MySQL 3.23.32 server (+ODBC driver)
- Naviscope
- I.I.S. 4.0
- Winzip 8 french
- WinRAR 2.80b2
- Cygwin 1.1
- MS SQL/Server 6.5 client (+ODBC driver)
- MouseWare 9.00.99
- Office 97
- Oracle 7.3.4 & 8i clients (+ODBC drivers)
- UltraEdit 8
- TNG Remote Control Option

I'd like to know if there are any incompatibilities 
between the installer and any of these products, and 
I'd like to be given a manual procedure that would 
allow me to install python on my workstation.

Moreover, seeing that:
- I am not the only one having installation problems 
on windows
- I have had problems every time I have tried to 
install Python 2.1 on windows (both NT and 2000)
- The Python windows installer is a 16 bit technology 
that is not supported anymore if I can believe what 
tim_one told me (see request ID 416824)
My conclusion is that we all should consider using 
another windows installer.

Regards,
  Xavier

----------------------------------------------------------------------

Comment By: Xavier Lagraula (xlagraula)
Date: 2001-04-23 04:59

Message:
Logged In: YES 
user_id=198402

Oops... Another mistake from a french speaking english: I 
said 'sense' but I meant 'meaning' in the last paragraph.

----------------------------------------------------------------------

Comment By: Xavier Lagraula (xlagraula)
Date: 2001-04-23 03:04

Message:
Logged In: YES 
user_id=198402

OK... Here are the news: I have installed ActiveState 
version without problems. I had to: how the hell could I 
compute a MD5 digest of the Python installer with a Python 
script, if I can't have Python installed, hm?

Anyway the digest proved to be perfectly correct. After 
all, I tried downloading the file for 2 different sources, 
and this was not a copy of the file I used on Win2k (see 
request ID 416824). But computing this digest allowed me to 
find the origin of the problem. I realized that I had saved 
the installer on a remote drive (windows shared directory 
on our file server), when I had to type "V:Python-21.exe" :)

My guess is that the SYSTEM account must have the right to 
read the directory containing the installer, and it was not 
the case. Once copied locally, it seems to work (I didn't 
go through the entire process, though, as I already had 
Python installed before).

I don't know if using the msi format is free or not. 
Another way for M$ to make money with a new mandatory 
installation format? If it's free, then it's the obvious 
choice for a future version of the windows installer. I'll 
try to gather some informations about it.

And "as to believing you", I must apologize to you: this 
sentence was a dumb litteral transcription of a french 
idiom which doesn't have exactly the sense it seems to 
have. This was just a way to tell readers that this 
information did came from you, so having a look at what you 
said may be of interest. No harm intended, really.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-04-23 01:42

Message:
Logged In: YES 
user_id=31435

We are having more reports of installer problems under 2.1 
than under previous releases, but I can still count the 
total on one hand.  Since we don't have the installer 
source code, and reports are still so rare (notwithstanding 
your particular bad luck) there's not much we can do to 
track them down.

Did you use the MD5 checksum program to verify your binary 
is valid?  Go to http://www.python.org/2.1/, go down to 
the "MD5 checksums" section, and click on the "MD5" part of 
the section heading to get a Python program for computing 
the MD5 digest.

In *almost* all past cases of "corrupt installation 
detected" messages, further investigation has revealed that 
the binary *was* corrupt.  The MD5 digest is a very 
powerful check on that (much stronger than a CRC):  if the 
checksum you get doesn't match the one on the web page 
above, your installer is definitely corrupt.  If it 
matches, the chance that it's corrupt anyway is too small 
to entertain.  So do that.  That you've had *repeated* 
installation failures is unprecedented in Python's history, 
so my top guess has to be you have a flaky binary.

There is only one other cause I've ever heard of for 
a "corrupt installation detected" message under NT:  the 
user was logged in to a Restricted account when they tried 
to install.  In that case, the Wise installer apparently 
can't even get at the system components it needs to compute 
its own internal checksums, and interprets that failure as 
a bad checksum.

So, what were you logged in as?  If the MD5 digest matches, 
and you're logged in to an Administrator account when it 
fails, then you've got a problem never reported before.  Do 
you?

As to using another Windows installer, I'm in favor of 
that, but so are you <wink>:  who's going to do the work?  
I can tell you I don't have time for it.  BTW, have you 
tried ActiveState's Python installer for Windows?  That's 
built with entirely different, and up-to-date, technology.  
Maybe it will work better for you.  But the terms of the 
ActiveState license don't allow us to use it too (fine by 
me -- they paid for it).

As to believing me, you don't have to:  ask Wise 
Solutions.  It's their product, version 5.0a.  You can't 
even find it mentioned on their web site anymore -- it's 
that old!  They're on version 8 now, and even their 
newsgroups only back to version 6.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418156&group_id=5470


From noreply@sourceforge.net  Mon Apr 23 17:46:51 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 23 Apr 2001 09:46:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-417853 ] pydoc uses deprecated regex module
Message-ID: <E14rjUB-0004HI-00@usw-sf-web2.sourceforge.net>

Bugs item #417853, was updated on 2001-04-21 09:20
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417853&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Garth T Kidd (gtk)
>Assigned to: Ka-Ping Yee (ping)
Summary: pydoc uses deprecated regex module

Initial Comment:
C:\Python21\Lib>python pydoc.py -g

[Tk gui pops up. Enter a search expression and hit 
Enter.]

pydoc.py:1496: DeprecationWarning: the regex module is 
deprecated; please use the re module
  desc = split(__import__(modname).__doc__ or '', '\n')
[0]


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417853&group_id=5470


From noreply@sourceforge.net  Mon Apr 23 18:50:53 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 23 Apr 2001 10:50:53 -0700
Subject: [Python-bugs-list] [ python-Bugs-418296 ] WinMain.c should use WIN32_LEAN_AND_MEAN
Message-ID: <E14rkU9-0007es-00@usw-sf-web1.sourceforge.net>

Bugs item #418296, was updated on 2001-04-23 10:50
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418296&group_id=5470

Category: Windows
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Kevin Rodgers (krodgers)
Assigned to: Nobody/Anonymous (nobody)
Summary: WinMain.c should use WIN32_LEAN_AND_MEAN

Initial Comment:
WinMain.c defines WINDOWS_LEAN_AND_MEAN prior to
including windows.h.  In VC++ 6.0, this is incorrect;
it should be WIN32_LEAN_AND_MEAN.  I don't have access
to VC++ 5.0, so I don't know if this is something that
changed between VC++ versions or not.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418296&group_id=5470


From noreply@sourceforge.net  Mon Apr 23 19:36:10 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 23 Apr 2001 11:36:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-418314 ] __eprintf undefined on Sun-OS 5.6
Message-ID: <E14rlBy-0005tW-00@usw-sf-web2.sourceforge.net>

Bugs item #418314, was updated on 2001-04-23 11:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418314&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: __eprintf undefined on Sun-OS 5.6

Initial Comment:
I downloaded python-2.1, configured, built and
installed it. When I try to use the C-API, I get this
error:

Undefined                       first referenced
 symbol                             in file
__eprintf                          
/home/aalen/python/lib/python2.1/config/libpython2.1.a(classobject.o)

Program (interp.C):

#include <Python.h>

main () {
   Py_Initialize();
}

Linking:
/opt/SUNWspro4.2/bin/CC -o ./interp interp.o
-L/wherever/python/lib/python2.1/config 
-R/wherever/python/lib/python2.1/config  -lpython2.1
-ldl

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418314&group_id=5470


From noreply@sourceforge.net  Mon Apr 23 22:08:34 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 23 Apr 2001 14:08:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-418369 ] Typo in distutils (1.5 and 2.1)
Message-ID: <E14rnZS-0006zY-00@usw-sf-web3.sourceforge.net>

Bugs item #418369, was updated on 2001-04-23 14:08
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418369&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Typo in distutils (1.5 and 2.1)

Initial Comment:
If README or README.txt are not specified in
doc_files, then bdist_rpm attempts to locate them. If
they exist, bdist_rpm adds them, erroneously, to
self.doc, instead of (correctly) to self.doc_files

self.doc does not exists, which then throws an
AttributeError

The offending code in Python 1.5 Distutils is
at or around line 192 of bdist_rpm.py

In Python 2.1 it is also at line 192 of bdist_rpm.py

Thanks!



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418369&group_id=5470


From noreply@sourceforge.net  Tue Apr 24 00:02:32 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 23 Apr 2001 16:02:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-418392 ] METH_OLDARGS allows bogus keywords
Message-ID: <E14rpLk-0004VA-00@usw-sf-web1.sourceforge.net>

Bugs item #418392, was updated on 2001-04-23 16:02
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418392&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Barry Warsaw (bwarsaw)
Assigned to: Barry Warsaw (bwarsaw)
Summary: METH_OLDARGS allows bogus keywords

Initial Comment:
fileobj.close() is a method that's implemented using
PyArg_NoArgs() and METH_OLDARGS.  It allows bogus
keyword arguments, which are ignored, e.g.:

>>> fp = open('/tmp/foo', 'w')
>>> fp.close(bogus=1)

Also,

>>> fp = open('/tmp/foo', 'w')
>>> fp.write('hello', bogus=1)
TypeError: argument must be string or read-only
character buffer, not int
>>> fp.write('hello', bogus='world')
>>> ^D
% cat /tmp/foo
hello

The fix is to convert these to use METH_VARARGS.  I'm
submitting this bug report so it doesn't get forgotten. 


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418392&group_id=5470


From noreply@sourceforge.net  Tue Apr 24 06:19:59 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 23 Apr 2001 22:19:59 -0700
Subject: [Python-bugs-list] [ python-Bugs-418296 ] WinMain.c should use WIN32_LEAN_AND_MEAN
Message-ID: <E14rvF1-0004bq-00@usw-sf-web3.sourceforge.net>

Bugs item #418296, was updated on 2001-04-23 10:50
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418296&group_id=5470

Category: Windows
Group: Platform-specific
Status: Open
>Resolution: Fixed
Priority: 5
Submitted By: Kevin Rodgers (krodgers)
>Assigned to: Mark Hammond (mhammond)
Summary: WinMain.c should use WIN32_LEAN_AND_MEAN

Initial Comment:
WinMain.c defines WINDOWS_LEAN_AND_MEAN prior to
including windows.h.  In VC++ 6.0, this is incorrect;
it should be WIN32_LEAN_AND_MEAN.  I don't have access
to VC++ 5.0, so I don't know if this is something that
changed between VC++ versions or not.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-04-23 22:19

Message:
Logged In: YES 
user_id=31435

Wow!  I found no evidence that WINDOWS_LEAN_AND_MEAN has 
ever meant anything to MS, and gobs of evidence that it 
should have been WIN32_LEAN_AND_MEAN all along.  Thanks!

Checked in as

Misc/ACKS new revision: 1.96
PC/WinMain.c new revision: 1.7

Marked as Fixed but left Open, and assigned to MarkH in 
case we're both missing something subtle here:  Mark, if 
you agree with the change, just mark this Closed.  Else 
feel encouraged to scream at me.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418296&group_id=5470


From noreply@sourceforge.net  Tue Apr 24 06:23:12 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 23 Apr 2001 22:23:12 -0700
Subject: [Python-bugs-list] [ python-Bugs-418296 ] WinMain.c should use WIN32_LEAN_AND_MEAN
Message-ID: <E14rvI8-0005li-00@usw-sf-web2.sourceforge.net>

Bugs item #418296, was updated on 2001-04-23 10:50
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418296&group_id=5470

Category: Windows
Group: Platform-specific
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Kevin Rodgers (krodgers)
Assigned to: Mark Hammond (mhammond)
Summary: WinMain.c should use WIN32_LEAN_AND_MEAN

Initial Comment:
WinMain.c defines WINDOWS_LEAN_AND_MEAN prior to
including windows.h.  In VC++ 6.0, this is incorrect;
it should be WIN32_LEAN_AND_MEAN.  I don't have access
to VC++ 5.0, so I don't know if this is something that
changed between VC++ versions or not.

----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2001-04-23 22:23

Message:
Logged In: YES 
user_id=14198

yes, this is certainly correct!

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-04-23 22:19

Message:
Logged In: YES 
user_id=31435

Wow!  I found no evidence that WINDOWS_LEAN_AND_MEAN has 
ever meant anything to MS, and gobs of evidence that it 
should have been WIN32_LEAN_AND_MEAN all along.  Thanks!

Checked in as

Misc/ACKS new revision: 1.96
PC/WinMain.c new revision: 1.7

Marked as Fixed but left Open, and assigned to MarkH in 
case we're both missing something subtle here:  Mark, if 
you agree with the change, just mark this Closed.  Else 
feel encouraged to scream at me.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418296&group_id=5470


From noreply@sourceforge.net  Tue Apr 24 11:32:25 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 24 Apr 2001 03:32:25 -0700
Subject: [Python-bugs-list] [ python-Bugs-417853 ] pydoc uses deprecated regex module
Message-ID: <E14s07N-0008P0-00@usw-sf-web3.sourceforge.net>

Bugs item #417853, was updated on 2001-04-21 09:20
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417853&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Garth T Kidd (gtk)
Assigned to: Ka-Ping Yee (ping)
Summary: pydoc uses deprecated regex module

Initial Comment:
C:\Python21\Lib>python pydoc.py -g

[Tk gui pops up. Enter a search expression and hit 
Enter.]

pydoc.py:1496: DeprecationWarning: the regex module is 
deprecated; please use the re module
  desc = split(__import__(modname).__doc__ or '', '\n')
[0]


----------------------------------------------------------------------

>Comment By: Ka-Ping Yee (ping)
Date: 2001-04-24 03:32

Message:
Logged In: YES 
user_id=45338

pydoc doesn't use the deprecated regex module.
The warning appears because regex happens to be among
the available modules to be searched.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417853&group_id=5470


From noreply@sourceforge.net  Tue Apr 24 18:11:02 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 24 Apr 2001 10:11:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-418314 ] __eprintf undefined on Sun-OS 5.6
Message-ID: <E14s6L8-0004xU-00@usw-sf-web3.sourceforge.net>

Bugs item #418314, was updated on 2001-04-23 11:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418314&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Martin v. Löwis (loewis)
Summary: __eprintf undefined on Sun-OS 5.6

Initial Comment:
I downloaded python-2.1, configured, built and
installed it. When I try to use the C-API, I get this
error:

Undefined                       first referenced
 symbol                             in file
__eprintf                          
/home/aalen/python/lib/python2.1/config/libpython2.1.a(classobject.o)

Program (interp.C):

#include <Python.h>

main () {
   Py_Initialize();
}

Linking:
/opt/SUNWspro4.2/bin/CC -o ./interp interp.o
-L/wherever/python/lib/python2.1/config 
-R/wherever/python/lib/python2.1/config  -lpython2.1
-ldl

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2001-04-24 10:10

Message:
Logged In: YES 
user_id=21627

Could it be that you have been using gcc to build Python?
If so, you also need to use gcc to link your executables, or
explicitly link libgcc.a.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418314&group_id=5470


From noreply@sourceforge.net  Tue Apr 24 18:13:05 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 24 Apr 2001 10:13:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-418212 ] makesetup and "-Wl,-rpath=..."
Message-ID: <E14s6N7-0004yj-00@usw-sf-web3.sourceforge.net>

Bugs item #418212, was updated on 2001-04-23 05:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418212&group_id=5470

Category: Build
Group: None
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
>Summary: makesetup and "-Wl,-rpath=..."

Initial Comment:
appending -Wl,-rpath='...' to the _tkinter entry in 
Modules/Setup to not have to deal with the
LD_LIBRARY_PATH breaks makesetup :(

Modules/Setup:
_tkinter _tkinter.c tkappinit.c -DWITH_APPINIT \
        -L/usr/local/tcltk8.2/lib
-Wl,-rpath=/usr/local/tcltk8.2/lib \



----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2001-04-24 10:13

Message:
Logged In: YES 
user_id=21627

Duplicate of 418211.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418212&group_id=5470


From noreply@sourceforge.net  Tue Apr 24 18:18:50 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 24 Apr 2001 10:18:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-418211 ] makesetup and "-Wl,-rpath=..."
Message-ID: <E14s6Sg-00056U-00@usw-sf-web3.sourceforge.net>

Bugs item #418211, was updated on 2001-04-23 05:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418211&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
>Summary: makesetup and "-Wl,-rpath=..."

Initial Comment:
appending -Wl,-rpath='...' to the _tkinter entry in 
Modules/Setup to not have to deal with the
LD_LIBRARY_PATH breaks makesetup :(

Modules/Setup:
_tkinter _tkinter.c tkappinit.c -DWITH_APPINIT \
        -L/usr/local/tcltk8.2/lib
-Wl,-rpath=/usr/local/tcltk8.2/lib \



----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2001-04-24 10:18

Message:
Logged In: YES 
user_id=21627

You can work around this limitation by writing
RPATH="-Wl,-rpath=/usr/local/tcltk8.2/lib"
_tkinter ... $(RPATH)

Alternatively, you can use
-Xlinker -rpath=/usr/local/tcltk8.2/lib

if your compiler supports that.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418211&group_id=5470


From noreply@sourceforge.net  Tue Apr 24 18:44:40 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 24 Apr 2001 10:44:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-416944 ] 2.0: cum sympt; w/gdb bktr; OBSD2.8.
Message-ID: <E14s6rg-0005Ok-00@usw-sf-web3.sourceforge.net>

Bugs item #416944, was updated on 2001-04-17 21:03
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416944&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Brad Allen (valaulmo)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.0: cum sympt; w/gdb bktr; OBSD2.8.

Initial Comment:
Reverted to Python 2.0 + all patches on patch pages,
still with OpenBSD 2.8.  Only non-default module set is
zlib (needed for Mojo Nation according to the docs). 
System is Pentium 133MHz.

Ok, I'm getting better at this now.  This time, I ran
GDB on it, since I noticed that one of the bugs may
have cumulative dependent symptoms.  Also, I'm typing
this bug report into the web browser so that it wraps
correctly (I'll cross my fingers that it doesn't crash
though; that's why I prefer Emacs; I suppose I could
try SSL W3 Emacs but that is hard; not now.)

Here is the gdb output where it did die:

[... lots of tests ...]
test_long

Program received signal SIGSEGV, Segmentation fault.
0x4017bc2f in _thread_machdep_switch ()
(gdb) bt
#0  0x4017bc2f in _thread_machdep_switch ()
#1  0x401c8308 in _sigq_check_reqd ()
#2  0x4017ba66 in _thread_kern_sig_undefer ()
#3  0x4017eb68 in pthread_cond_signal ()
#4  0x1510d in PyThread_release_lock (lock=0x27c320) at
thread_pthread.h:344
#5  0x43006 in eval_code2 (co=0x3c7d80,
globals=0x3c104c, locals=0x0, 
    args=0x25cd58, argcount=2, kws=0x25cd60, kwcount=0,
defs=0x0, defcount=0, 
    owner=0x0) at ceval.c:617
#6  0x450b3 in eval_code2 (co=0x3c7f40,
globals=0x3c104c, locals=0x0, 
    args=0x1a4d60, argcount=1, kws=0x1a4d64, kwcount=0,
defs=0x0, defcount=0, 
    owner=0x0) at ceval.c:1850
#7  0x450b3 in eval_code2 (co=0x4221c0,
globals=0x3c104c, locals=0x0, 
    args=0x39a140, argcount=0, kws=0x39a140, kwcount=0,
defs=0x29c1b8, 
    defcount=1, owner=0x0) at ceval.c:1850
#8  0x450b3 in eval_code2 (co=0x41c900,
globals=0x3c104c, locals=0x3c104c, 
    args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0,
defcount=0, owner=0x0)
    at ceval.c:1850
#9  0x42625 in PyEval_EvalCode (co=0x41c900,
globals=0x3c104c, locals=0x3c104c)
    at ceval.c:319
#10 0xacff in PyImport_ExecCodeModuleEx
(name=0xdfbfd180 "test_long", 
    co=0x41c900, pathname=0xdfbfcce0
"./Lib/test/test_long.py") at import.c:495
#11 0xb30a in load_source_module (name=0xdfbfd180
"test_long", 
    pathname=0xdfbfcce0 "./Lib/test/test_long.py",
fp=0x401fa83c)
    at import.c:758
#12 0xbc23 in load_module (name=0xdfbfd180 "test_long",
fp=0x401fa83c, 
    buf=0xdfbfcce0 "./Lib/test/test_long.py", type=1)
at import.c:1227
#13 0xc8fb in import_submodule (mod=0x1140fc,
subname=0xdfbfd180 "test_long", 
    fullname=0xdfbfd180 "test_long") at import.c:1755
#14 0xc4ca in load_next (mod=0x1140fc, altmod=0x1140fc,
p_name=0xdfbfd58c, 
    buf=0xdfbfd180 "test_long", p_buflen=0xdfbfd17c) at
import.c:1611
#15 0xc142 in import_module_ex (name=0x0,
globals=0x14624c, locals=0x1a538c, 
    fromlist=0x29c02c) at import.c:1462
---Type <return> to continue, or q <return> to quit---
#16 0xc277 in PyImport_ImportModuleEx (name=0x19f0d4
"test_long", 
    globals=0x14624c, locals=0x1a538c,
fromlist=0x29c02c) at import.c:1503
#17 0x3ce47 in builtin___import__ (self=0x0,
args=0x3b198c) at bltinmodule.c:31
#18 0x4668d in call_builtin (func=0x141070,
arg=0x3b198c, kw=0x0)
    at ceval.c:2650
#19 0x46507 in PyEval_CallObjectWithKeywords
(func=0x141070, arg=0x3b198c, 
    kw=0x0) at ceval.c:2618
#20 0x453ac in eval_code2 (co=0x1cc240,
globals=0x14624c, locals=0x0, 
    args=0x15fdcc, argcount=5, kws=0x15fde0, kwcount=0,
defs=0x1c4738, 
    defcount=1, owner=0x0) at ceval.c:1951
#21 0x450b3 in eval_code2 (co=0x1c9f00,
globals=0x14624c, locals=0x0, 
    args=0x140f44, argcount=0, kws=0x140f44, kwcount=0,
defs=0x18d918, 
    defcount=10, owner=0x0) at ceval.c:1850
#22 0x450b3 in eval_code2 (co=0x1c9f80,
globals=0x14624c, locals=0x14624c, 
    args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0,
defcount=0, owner=0x0)
    at ceval.c:1850
#23 0x42625 in PyEval_EvalCode (co=0x1c9f80,
globals=0x14624c, locals=0x14624c)
    at ceval.c:319
#24 0x1272f in run_node (n=0x155400, 
    filename=0xdfbfdb5a "./Lib/test/regrtest.py",
globals=0x14624c, 
    locals=0x14624c) at pythonrun.c:886
#25 0x126e8 in run_err_node (n=0x155400, 
    filename=0xdfbfdb5a "./Lib/test/regrtest.py",
globals=0x14624c, 
    locals=0x14624c) at pythonrun.c:874
#26 0x126c4 in PyRun_FileEx (fp=0x401fa7e4, 
    filename=0xdfbfdb5a "./Lib/test/regrtest.py",
start=257, globals=0x14624c, 
    locals=0x14624c, closeit=1) at pythonrun.c:866
#27 0x11cfe in PyRun_SimpleFileEx (fp=0x401fa7e4, 
    filename=0xdfbfdb5a "./Lib/test/regrtest.py",
closeit=1) at pythonrun.c:579
#28 0x118f3 in PyRun_AnyFileEx (fp=0x401fa7e4, 
    filename=0xdfbfdb5a "./Lib/test/regrtest.py",
closeit=1) at pythonrun.c:459
#29 0x24bb in Py_Main (argc=2, argv=0xdfbfdac8) at
main.c:289
---Type <return> to continue, or q <return> to quit---
#30 0x17b5 in main (argc=4, argv=0xdfbfdac8) at
python.c:10
(gdb) 

Once again, I will attach the config.* (config.cache,
etc.) to this in a file.

Brad Allen <Ulmo@Q.Net>

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2001-04-24 10:44

Message:
Logged In: YES 
user_id=21627

To me, this likes like a bug in the multithread support of
your operating system. To work around this bug, you should
configure python with --disable-threads.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416944&group_id=5470


From noreply@sourceforge.net  Tue Apr 24 18:49:40 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 24 Apr 2001 10:49:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-416181 ] 2.1c1 builds strangely on Solaris
Message-ID: <E14s6wW-0005SI-00@usw-sf-web3.sourceforge.net>

Bugs item #416181, was updated on 2001-04-14 13:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416181&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 2
Submitted By: David M. Beazley (beazley)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.1c1 builds strangely on Solaris

Initial Comment:
Python 2.1c1 has problems with its build process on the
following
configuration:

     - Solaris 2.8 SPARC
     - gcc-2.95-2 compilers *AND* Sun Workshop 5.0
compilers
        installed.

Although the interpreter builds without problems, the
process of building various extension modules fails
under gcc, but works under the Sun compilers.  (for
example, I get tons of unresolved symbols in curses,
ncurses, etc. with gcc).

This appears to be a problem related to linker/compiler
options with gcc, but I don't see anything obvious
offhand.   I will post a followup if I am able to make
a fix.








----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2001-04-24 10:49

Message:
Logged In: YES 
user_id=21627

I also have both gcc and the workshop installed, and it
works fine for me. Can you report one of the gcc invocation
lines to build a dynamically-loaded module? Also, can you
try invoking this gcc command manually, passing the -v
option?

ld does not need to support -shared, since gcc *should*
translate that option into -G when invoking the linker.
It would be also interesting to know what errors exactly you
get, since, when building a shared library, you should not
get reports of missing symbols - only when you try to open
the shared library.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-15 13:50

Message:
Logged In: YES 
user_id=6380

Jeremy, if Eric fixed this, can you close it?  He doesn't 
appear to know how to use SF.  (Funny, for a VA Linux board 
member. :-)

----------------------------------------------------------------------

Comment By: David M. Beazley (beazley)
Date: 2001-04-15 11:24

Message:
Logged In: YES 
user_id=7557

Making the _XOPEN_SOURCE_EXTENDED change did not seem to fix
the problem.   I am primarily getting linker errors
(compilation is fine) for Python modules that involves
libraries like ncurses, readline, zlib, etc...
This almost certainly looks like some conflict between
static and shared linking to me.  In fact, I'm fairly
convinced that doing

     gcc -shared  $(OBJS) ...

is completely broken on my machine.  If I change the
Makefile to this, everything suddenly works:

LDSHARED = $(CC) -Xlinker -G
BLDSHARED = $(CC) -Xlinker -G

Caveats:

I'm not sure if there is a general fix to this problem. 
Since I have the Sun Workshop compilers installed, I also
have the Sun linker installed.  I know that this linker does
not recognize the -shared option so this is almost certainly
why gcc -shared doesn't work.  On the other hand, if I only
had the GNU tools installed, I suspect that the GNU linker
would probably work with gcc -shared.   The -Xlinker option
hack above would also fail with the Sun cc compiler (so this
isn't a general solution).

Is anyone else reporting problems with Solaris?  If not, I'd
say don't worry about my peculiar circumstances (maybe I
have a hosed installation of gcc).   

-- Dave



----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-14 20:07

Message:
Logged In: YES 
user_id=6380

David, can you try adding #define _XOPEN_SOURCE_EXTENDED to
the _cursesmodule.c source file?

That worked for the same system on Compaq Tru64.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416181&group_id=5470


From noreply@sourceforge.net  Tue Apr 24 18:57:16 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 24 Apr 2001 10:57:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-417481 ] Python 2.1 build issues on Solaris 8/x86
Message-ID: <E14s73s-0005Y8-00@usw-sf-web3.sourceforge.net>

Bugs item #417481, was updated on 2001-04-19 16:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417481&group_id=5470

Category: Build
Group: Platform-specific
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Fazal Majid (majid)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.1 build issues on Solaris 8/x86

Initial Comment:
I am building Python 2.1 final on Solaris 8 x86 with gcc 2.95.3 configured to use Solaris ld and GNU 
as.

The new autodetect build process fails to build some dynamically loaded modules such as _socket, 
at least when the OpenSSL autodetection kicks in. I am attaching a compilation build log 
py21log.txt (keep in mind stderr is not buffered, so sometimes the error message precedes the 
command-line).

This linker error message is something that is usually fixed by compiling with -fpic or -fPIC (the two 
are equivalent on x86), but in this case it does not resolve the problem with OpenSSL. Some 
versions of egcs were known to generate incorrect code when -fpic and -O were used together, 
this might be a survival of this bug.

The link process using gcc -shared fails with ld reporting unresolved relocations.

I managed to work around the problem by using LDSHARED="gcc -G" instead of "gcc -shared" ("ld 
-G" builds and installs successfully, but leaves relocations against libgcc). Once again, I am 
attaching the successful build log py21ok.txt.

FYI, this problem didn't occur with Python 2.0 and earlier with the manual Modules/Setup build 
process. This is probably related to:
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403655&group_id=5470


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2001-04-24 10:57

Message:
Logged In: YES 
user_id=21627

This is not a bug, gcc rightfully requires that libraries
linked into a shared library (such as _socket.so) must not
have relocations - otherwise, the text segment would need to
be writable, which causes a performance drop.

There are a number of solutions:
- build the libraries that you link into _socket (such as
libcrypto) as shared libraries.
- build them as static libraries, with -fPIC
- statically build _socket into the Python interpreter, by
putting it into Modules/Setup
- use gcc's -mimpure-text option
Do not change -shared to -G, since that drops a few
desirable side-effects of -shared.

To sum up, this is not a configuration problem, but one with
your local system installation. There are a number of
solutions to it (linking _socket statically being the best
one), so there is no need to change the configuration
process.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417481&group_id=5470


From noreply@sourceforge.net  Tue Apr 24 20:23:33 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 24 Apr 2001 12:23:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-418626 ] maximum recursion limit exceeded (2.1)
Message-ID: <E14s8PN-00005N-00@usw-sf-web2.sourceforge.net>

Bugs item #418626, was updated on 2001-04-24 12:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418626&group_id=5470

Category: Regular Expressions
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: maximum recursion limit exceeded (2.1)

Initial Comment:
% /usr/bin/env python2.1 
Python 2.1 (#2, Apr 24 2001, 11:33:06) 
[GCC 2.95.3 20010315 (release)] on hp-uxB
Type "copyright", "credits" or "license" for more
information.
>>> 

% uname -a
HP-UX wshelley B.11.00 A 9000/785 2014123772 two-user
license
% rebug.py 
Traceback (most recent call last):
  File "rebug.py", line 205, in ?
    re.search("== Data Table ==\n(.*?)\n(.*?)\s*$",
output, re.S)
  File "/usr/local/lib/python2.1/sre.py", line 57, in
search
    return _compile(pattern, flags).search(string)
RuntimeError: maximum recursion limit exceeded


rebug.py script works correctly using python1.5.2

I submitted this bug as a followup to [ #215696 ] sre
RuntimeError when .*? matches >16K string




##### The following is the rebug.py file
#!/usr/bin/env python2.1
import re

output = """Using 

== Data Table ==
s       m:d     mb
3.300000        0.000104772187944365   
-1.23330767339032e-15
3.200000        0.000103862130408037   
-1.23481086168441e-15
3.100000        0.000102831826202984   
-1.23643366708223e-15
3.000000        0.000101671354638586   
-1.23819069775402e-15
2.900000        0.000100370082245968   
-1.24009908383179e-15
2.800000        9.89166376398503e-05   
-1.24217904419247e-15
2.700000        9.72988932844521e-05   
-1.24445461136295e-15
2.600000        9.55039568198016e-05   
-1.24695456774457e-15
2.500000        9.3518175238995e-05    
-1.24971366756711e-15
2.400000        9.13271559565959e-05   
-1.25277425005882e-15
2.300000        8.89158096852735e-05   
-1.25618839559713e-15
2.200000        8.62684210547775e-05   
-1.26002084671538e-15
2.100000        8.33687540802062e-05   
-1.26435302405962e-15
2.000000        8.02002009414518e-05   
-1.26928863786894e-15
1.900000        7.67459841300842e-05   
-1.27496167015724e-15
1.800000        7.29894239935539e-05   
-1.28154795600633e-15
1.700000        6.89142864097651e-05   
-1.28928236065365e-15
1.600000        6.45052296412595e-05   
-1.29848488989922e-15
1.500000        5.97483776126083e-05   
-1.30960148694006e-15
1.400000        5.46320649249439e-05   
-1.32326977154928e-15
1.300000        4.91478435825781e-05   
-1.3404286750276e-15
1.200000        4.32919623998454e-05   
-1.36250830892367e-15
1.100000        3.70678871330223e-05   
-1.39177202537724e-15
1.000000        3.04915786576429e-05   
-1.43195494399345e-15
0.900000        2.36052666077545e-05   
-1.48947100843164e-15
0.800000        1.65202853321069e-05   
-1.57551564136398e-15
0.700000        9.56073716566518e-06   
-1.70791288744525e-15
0.600000        3.67125710597e-06      
-1.89923336361812e-15
0.500000        6.00021904261974e-07   
-2.08381565027337e-15
0.400000        4.27864345038415e-08   
-2.14973379503184e-15
0.300000        2.5741570279509e-09    
-2.15852923041729e-15
0.200000        1.60325700603365e-10   
-2.15762110254924e-15
0.100000        1.10181009347061e-11   
-2.15430351925385e-15
0.000000        9.18460199298261e-13   
-2.14607756126421e-15
-0.100000       8.2907448480307e-14    
-2.13154544128925e-15
-0.200000       9.49291906644266e-15   
-2.09562596113738e-15
-0.300000       2.57398712712903e-15   
-1.89144055818718e-15
-0.400000       1.23896929747012e-15   
-1.18482371296596e-15
-0.500000       4.77088843470797e-16   
-4.74259070979461e-16
3.300000        0.000725333230235404   
-1.60279744215745e-14
3.200000        0.000698989627849489   
-1.57983897758426e-14
3.100000        0.000672395787137216   
-1.55721529060957e-14
3.000000        0.000645566845212758   
-1.53549883971193e-14
2.900000        0.000618516906916818   
-1.51624220311135e-14
2.800000        0.000591259277466284   
-1.50347782956977e-14
2.700000        0.000563806714724985   
-1.5069525306854e-14
2.600000        0.000536171704020601   
-1.54848062262748e-14
2.500000        0.000508366761845922   
-1.67334737461837e-14
2.400000        0.000480404778779427   
-1.96904798125589e-14
2.300000        0.00045229941701671    
-2.59347024715496e-14
2.200000        0.000424065584744255   
-3.81354821168744e-14
2.100000        0.000395720019338978   
-6.05316531752639e-14
2.000000        0.000367282025836478   
-9.9457021513997e-14
1.900000        0.000338774439198852   
-1.63825993533288e-13
1.800000        0.000310224913488982   
-2.65456611717139e-13
1.700000        0.000281667696431468   
-4.19089961445906e-13
1.600000        0.000253146138686846   
-6.4197984099406e-13
1.500000        0.000224716340367884   
-9.52983499747302e-13
1.400000        0.00019645260393449    
-1.37117106753005e-12
1.300000        0.000168455842857815   
-1.9140171376089e-12
1.200000        0.000140866992561325   
-2.5949957749272e-12
1.100000        0.000113889209694637   
-3.419066099784e-12
1.000000        8.78261401150504e-05   
-4.36958009251635e-12
0.900000        6.31506490822963e-05   
-5.36461118003355e-12
0.800000        4.06312963119592e-05   
-6.12577475587495e-12
0.700000        2.15481889941145e-05   
-5.92418822150058e-12
0.600000        7.87604367966821e-06   
-3.80859906972703e-12
0.500000        1.3904896761789e-06    
-9.79870732426348e-13
0.400000        1.06064890626322e-07   
-9.39992702457847e-14
0.300000        6.34950130197645e-09   
-1.65503941397823e-14
0.200000        3.88292805625561e-10   
-1.16204226732226e-14
0.100000        2.57865399432747e-11   
-1.11870703136006e-14
0.000000        2.05458930149398e-12   
-1.09482596289954e-14
-0.100000       1.85578779234532e-13   
-1.06729449780495e-14
-0.200000       2.5577583052963e-14    
-1.02232392679007e-14
-0.300000       1.05769385343133e-14   
-9.2322860676878e-15
-0.400000       8.00273522170935e-15   
-7.88228414475344e-15
-0.500000       6.51965630664677e-15   
-6.50815076902941e-15
3.300000        0.000778073989265561   
-1.65574096734398e-07
3.200000        0.00074963150963251    
-1.92244746339178e-07
3.100000        0.000721015586364691   
-2.21197891556889e-07
3.000000        0.000692226507232058   
-2.52254070463242e-07
2.900000        0.000663264988754168   
-2.85152554002688e-07
2.800000        0.000634132321079485   
-3.19546222567145e-07
2.700000        0.000604830546549725   
-3.54998299569146e-07
2.600000        0.000575362679604795   
-3.90981285317844e-07
2.500000        0.000545732977654778   
-4.26878409205096e-07
2.400000        0.000515947275272665   
-4.61987879332959e-07
2.300000        0.000486013397947319   
-4.95530155074015e-07
2.200000        0.000455941677304999   
-5.26658398699649e-07
2.100000        0.000425745598153737   
-5.54472176489517e-07
2.000000        0.000395442620520435   
-5.78034377120716e-07
1.900000        0.000365055239615154   
-5.96391194651538e-07
1.800000        0.000334612377612625   
-6.0859488246625e-07
1.700000        0.000304151250425071   
-6.13728816719563e-07
1.600000        0.000273719932661724   
-6.1093419812057e-07
1.500000        0.000243380977243086   
-5.99437433988553e-07
1.400000        0.000213216675616044   
-5.78576796961394e-07
1.300000        0.000183336956663227   
-5.47826196051382e-07
1.200000        0.000153891700661593   
-5.06812695554088e-07
1.100000        0.000125090796710056   
-4.55323667088038e-07
1.000000        9.7238530664174e-05    
-3.9330616509577e-07
0.900000        7.07959411929754e-05   
-3.20910962327376e-07
0.800000        4.64992533700793e-05   
-2.38877973057319e-07
0.700000        2.55795422135307e-05   
-1.50458199069334e-07
0.600000        1.00314893206752e-05   
-6.74343626580743e-08
0.500000        2.00947524041218e-06   
-1.48839482947924e-08
0.400000        1.67232105200131e-07   
-1.2816627677716e-09
0.300000        1.00809637284154e-08   
-7.82708572696571e-11
0.200000        6.12196843592758e-10   
-4.83619605089934e-12
0.100000        4.0027953235145e-11    
-3.39466185939354e-13
0.000000        3.1163322565507e-12    
-4.38427713973686e-14
-0.100000       2.82036148373174e-13   
-2.01235539818538e-14
-0.200000       4.04726306794353e-14   
-1.75747562532315e-14
-0.300000       1.83397331593843e-14   
-1.63366924660679e-14
-0.400000       1.50709750319906e-14   
-1.48901998089388e-14
-0.500000       1.34240392889815e-14   
-1.34063683071726e-14
3.300000        0.000104772187944365   
-1.23330767339032e-15
3.200000        0.000103862130408037   
-1.23481086168441e-15
3.100000        0.000102831826202984   
-1.23643366708223e-15
3.000000        0.000101671354638586   
-1.23819069775402e-15
2.900000        0.000100370082245968   
-1.24009908383179e-15
2.800000        9.89166376398503e-05   
-1.24217904419247e-15
2.700000        9.72988932844521e-05   
-1.24445461136295e-15
2.600000        9.55039568198016e-05   
-1.24695456774457e-15
2.500000        9.3518175238995e-05    
-1.24971366756711e-15
2.400000        9.13271559565959e-05   
-1.25277425005882e-15
2.300000        8.89158096852735e-05   
-1.25618839559713e-15
2.200000        8.62684210547775e-05   
-1.26002084671538e-15
2.100000        8.33687540802062e-05   
-1.26435302405962e-15
2.000000        8.02002009414518e-05   
-1.26928863786894e-15
1.900000        7.67459841300842e-05   
-1.27496167015724e-15
1.800000        7.29894239935539e-05   
-1.28154795600633e-15
1.700000        6.89142864097651e-05   
-1.28928236065365e-15
1.600000        6.45052296412595e-05   
-1.29848488989922e-15
1.500000        5.97483776126083e-05   
-1.30960148694006e-15
1.400000        5.46320649249439e-05   
-1.32326977154928e-15
1.300000        4.91478435825781e-05   
-1.3404286750276e-15
1.200000        4.32919623998454e-05   
-1.36250830892367e-15
1.100000        3.70678871330223e-05   
-1.39177202537724e-15
1.000000        3.04915786576429e-05   
-1.43195494399345e-15
0.900000        2.36052666077545e-05   
-1.48947100843164e-15
0.800000        1.65202853321069e-05   
-1.57551564136398e-15
0.700000        9.56073716566518e-06   
-1.70791288744525e-15
0.600000        3.67125710597e-06      
-1.89923336361812e-15
0.500000        6.00021904261974e-07   
-2.08381565027337e-15
0.400000        4.27864345038415e-08   
-2.14973379503184e-15
0.300000        2.5741570279509e-09    
-2.15852923041729e-15
0.200000        1.60325700603365e-10   
-2.15762110254924e-15
0.100000        1.10181009347061e-11   
-2.15430351925385e-15
0.000000        9.18460199298261e-13   
-2.14607756126421e-15
-0.100000       8.2907448480307e-14    
-2.13154544128925e-15
-0.200000       9.49291906644266e-15   
-2.09562596113738e-15
-0.300000       2.57398712712903e-15   
-1.89144055818718e-15
-0.400000       1.23896929747012e-15   
-1.18482371296596e-15
-0.500000       4.77088843470797e-16   
-4.74259070979461e-16
3.300000        0.000725333230235404   
-1.60279744215745e-14
3.200000        0.000698989627849489   
-1.57983897758426e-14
3.100000        0.000672395787137216   
-1.55721529060957e-14
3.000000        0.000645566845212758   
-1.53549883971193e-14
2.900000        0.000618516906916818   
-1.51624220311135e-14
2.800000        0.000591259277466284   
-1.50347782956977e-14
2.700000        0.000563806714724985   
-1.5069525306854e-14
2.600000        0.000536171704020601   
-1.54848062262748e-14
2.500000        0.000508366761845922   
-1.67334737461837e-14
2.400000        0.000480404778779427   
-1.96904798125589e-14
2.300000        0.00045229941701671    
-2.59347024715496e-14
2.200000        0.000424065584744255   
-3.81354821168744e-14
2.100000        0.000395720019338978   
-6.05316531752639e-14
2.000000        0.000367282025836478   
-9.9457021513997e-14
1.900000        0.000338774439198852   
-1.63825993533288e-13
1.800000        0.000310224913488982   
-2.65456611717139e-13
1.700000        0.000281667696431468   
-4.19089961445906e-13
1.600000        0.000253146138686846   
-6.4197984099406e-13
1.500000        0.000224716340367884   
-9.52983499747302e-13
1.400000        0.00019645260393449    
-1.37117106753005e-12
1.300000        0.000168455842857815   
-1.9140171376089e-12
1.200000        0.000140866992561325   
-2.5949957749272e-12
1.100000        0.000113889209694637   
-3.419066099784e-12
1.000000        8.78261401150504e-05   
-4.36958009251635e-12
0.900000        6.31506490822963e-05   
-5.36461118003355e-12
0.800000        4.06312963119592e-05   
-6.12577475587495e-12
0.700000        2.15481889941145e-05   
-5.92418822150058e-12
0.600000        7.87604367966821e-06   
-3.80859906972703e-12
0.500000        1.3904896761789e-06    
-9.79870732426348e-13
0.400000        1.06064890626322e-07   
-9.39992702457847e-14
0.300000        6.34950130197645e-09   
-1.65503941397823e-14
0.200000        3.88292805625561e-10   
-1.16204226732226e-14
0.100000        2.57865399432747e-11   
-1.11870703136006e-14
0.000000        2.05458930149398e-12   
-1.09482596289954e-14
-0.100000       1.85578779234532e-13   
-1.06729449780495e-14
-0.200000       2.5577583052963e-14    
-1.02232392679007e-14
-0.300000       1.05769385343133e-14   
-9.2322860676878e-15
-0.400000       8.00273522170935e-15   
-7.88228414475344e-15
-0.500000       6.51965630664677e-15   
-6.50815076902941e-15
"""

re.search("== Data Table ==\n(.*?)\n(.*?)\s*$", output,
re.S)



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418626&group_id=5470


From noreply@sourceforge.net  Wed Apr 25 00:27:19 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 24 Apr 2001 16:27:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-417853 ] pydoc uses deprecated regex module
Message-ID: <E14sCDH-0001DW-00@usw-sf-web3.sourceforge.net>

Bugs item #417853, was updated on 2001-04-21 09:20
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417853&group_id=5470

Category: Python Library
Group: None
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Garth T Kidd (gtk)
Assigned to: Ka-Ping Yee (ping)
Summary: pydoc uses deprecated regex module

Initial Comment:
C:\Python21\Lib>python pydoc.py -g

[Tk gui pops up. Enter a search expression and hit 
Enter.]

pydoc.py:1496: DeprecationWarning: the regex module is 
deprecated; please use the re module
  desc = split(__import__(modname).__doc__ or '', '\n')
[0]


----------------------------------------------------------------------

>Comment By: Garth T Kidd (gtk)
Date: 2001-04-24 16:27

Message:
Logged In: YES 
user_id=59803

I was about to suggest using the warnings filter to catch 
it and add it to the documentation, but there aren't any 
callbacks. Which isn't to say they can't be added... 

----------------------------------------------------------------------

Comment By: Ka-Ping Yee (ping)
Date: 2001-04-24 03:32

Message:
Logged In: YES 
user_id=45338

pydoc doesn't use the deprecated regex module.
The warning appears because regex happens to be among
the available modules to be searched.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417853&group_id=5470


From noreply@sourceforge.net  Wed Apr 25 00:47:01 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 24 Apr 2001 16:47:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-229810 ] Memore leak in pickle and cPickle
Message-ID: <E14sCWL-0003no-00@usw-sf-web1.sourceforge.net>

Bugs item #229810, was updated on 2001-01-23 07:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=229810&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Vladimir Kralik (vlk)
Assigned to: Barry Warsaw (bwarsaw)
Summary: Memore leak in pickle and cPickle

Initial Comment:
# When Pickler.object is used for dump typles into file and Unpickler for 
# load from files. A loaded object are not garbage collected.
# When function dump(object,file) is used Unpickler works fine.
# Problem is in pickle and cPickle module
# tested on Python 2.0 Red Hat Linux 6.2

import cPickle			
#import pickle			 
import gc

f=open("xxx","w")
pic=cPickle.Pickler(f,1)	# ERROR
#pic=pickle.Pickler(f,1)	# ERROR
for i in range(100):
	#cPickle.dump(([long(i),long(i),long(i),long(i)],i),f)	
		# this is OK
	#pickle.dump(([long(i),long(i),long(i),long(i)],i),f)	
		# this is OK
	pic.dump(([long(i),long(i),long(i),long(i)],i))		
		# Memory leak

f.close()
gc.set_debug(gc.DEBUG_STATS)
f=open("xxx","r")
u=cPickle.Unpickler(f)
try:
	while 1:
		gc.collect()
		print u.load()
except EOFError:
	pass
f.close()

----------------------------------------------------------------------

Comment By: Naris Siamwalla (naris)
Date: 2001-04-24 16:47

Message:
Logged In: YES 
user_id=67995

barry's python snippet memory leaks on python 2.1 final
on rh6.2.

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-02-23 10:59

Message:
# When Pickler.object is used for dump typles into file and Unpickler for load
# from files. A loaded object are not garbage collected.  When function
# dump(object,file) is used Unpickler works fine.  Problem is in pickle and
# cPickle module tested on Python 2.0 Red Hat Linux 6.2

import gc 

def main():
    fp = open('/tmp/xxx', 'w') 
    pic = pickle.Pickler(fp, 1)                   # ERROR 

    for i in range(10000):
        pickle.dump(([long(i), long(i), long(i), long(i)], i), fp) 
        # this is OK 
        pic.dump(([long(i), long(i), long(i), long(i)], i))
        # Memory leak 

    fp.close() 
    gc.set_debug(gc.DEBUG_STATS) 

    fp = open('/tmp/xxx')

    upic = pickle.Unpickler(fp)
    try: 
        while 1: 
            gc.collect() 
            print upic.load() 
    except EOFError: 
        pass

    fp.close()


if __name__ == '__main__':
    import sys
    if len(sys.argv) > 1:
        import cPickle
        pickle = cPickle
    else:
        import pickle

    main()


----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-02-23 10:58

Message:
When cranking up the number of objects placed in the pickle to 10000, I do see some memory growth when unpickling as clocked by top.  The cPickle growth is much smaller than the pickle growth, which already appears fairly minimal.

I will investigate further with Insure++.

I don't see how the problem could be related to __del__ since the only thing we're dumping and loading are builtin objects (tuples, lists, longs, and ints).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-01-23 19:28

Message:
Barry, can you look into this?  I would first see if this is really reproducable without using Insure++; somehow it looks a bit fishy.  Could also be fixed in 2.1 because now modules participate in gc.  Or could have to do with a __del__?  Also, I doubt the claim that this is a leak with both pickle and cPickle.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=229810&group_id=5470


From noreply@sourceforge.net  Wed Apr 25 07:30:06 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 24 Apr 2001 23:30:06 -0700
Subject: [Python-bugs-list] [ python-Bugs-417853 ] pydoc uses deprecated regex module
Message-ID: <E14sIoQ-0006EA-00@usw-sf-web3.sourceforge.net>

Bugs item #417853, was updated on 2001-04-21 09:20
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417853&group_id=5470

Category: Python Library
Group: None
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Garth T Kidd (gtk)
Assigned to: Ka-Ping Yee (ping)
Summary: pydoc uses deprecated regex module

Initial Comment:
C:\Python21\Lib>python pydoc.py -g

[Tk gui pops up. Enter a search expression and hit 
Enter.]

pydoc.py:1496: DeprecationWarning: the regex module is 
deprecated; please use the re module
  desc = split(__import__(modname).__doc__ or '', '\n')
[0]


----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2001-04-24 23:30

Message:
Logged In: YES 
user_id=44345

perhaps pydoc should explicitly suppress the
DeprecationWarning?


----------------------------------------------------------------------

Comment By: Garth T Kidd (gtk)
Date: 2001-04-24 16:27

Message:
Logged In: YES 
user_id=59803

I was about to suggest using the warnings filter to catch 
it and add it to the documentation, but there aren't any 
callbacks. Which isn't to say they can't be added... 

----------------------------------------------------------------------

Comment By: Ka-Ping Yee (ping)
Date: 2001-04-24 03:32

Message:
Logged In: YES 
user_id=45338

pydoc doesn't use the deprecated regex module.
The warning appears because regex happens to be among
the available modules to be searched.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417853&group_id=5470


From noreply@sourceforge.net  Wed Apr 25 04:28:20 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 24 Apr 2001 20:28:20 -0700
Subject: [Python-bugs-list] [ python-Bugs-418626 ] maximum recursion limit exceeded (2.1)
Message-ID: <E14sFyW-0007Um-00@usw-sf-web1.sourceforge.net>

Bugs item #418626, was updated on 2001-04-24 12:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418626&group_id=5470

Category: Regular Expressions
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Fredrik Lundh (effbot)
Summary: maximum recursion limit exceeded (2.1)

Initial Comment:
% /usr/bin/env python2.1 
Python 2.1 (#2, Apr 24 2001, 11:33:06) 
[GCC 2.95.3 20010315 (release)] on hp-uxB
Type "copyright", "credits" or "license" for more
information.
>>> 

% uname -a
HP-UX wshelley B.11.00 A 9000/785 2014123772 two-user
license
% rebug.py 
Traceback (most recent call last):
  File "rebug.py", line 205, in ?
    re.search("== Data Table ==\n(.*?)\n(.*?)\s*$",
output, re.S)
  File "/usr/local/lib/python2.1/sre.py", line 57, in
search
    return _compile(pattern, flags).search(string)
RuntimeError: maximum recursion limit exceeded


rebug.py script works correctly using python1.5.2

I submitted this bug as a followup to [ #215696 ] sre
RuntimeError when .*? matches >16K string




##### The following is the rebug.py file
#!/usr/bin/env python2.1
import re

output = """Using 

== Data Table ==
s       m:d     mb
3.300000        0.000104772187944365   
-1.23330767339032e-15
3.200000        0.000103862130408037   
-1.23481086168441e-15
3.100000        0.000102831826202984   
-1.23643366708223e-15
3.000000        0.000101671354638586   
-1.23819069775402e-15
2.900000        0.000100370082245968   
-1.24009908383179e-15
2.800000        9.89166376398503e-05   
-1.24217904419247e-15
2.700000        9.72988932844521e-05   
-1.24445461136295e-15
2.600000        9.55039568198016e-05   
-1.24695456774457e-15
2.500000        9.3518175238995e-05    
-1.24971366756711e-15
2.400000        9.13271559565959e-05   
-1.25277425005882e-15
2.300000        8.89158096852735e-05   
-1.25618839559713e-15
2.200000        8.62684210547775e-05   
-1.26002084671538e-15
2.100000        8.33687540802062e-05   
-1.26435302405962e-15
2.000000        8.02002009414518e-05   
-1.26928863786894e-15
1.900000        7.67459841300842e-05   
-1.27496167015724e-15
1.800000        7.29894239935539e-05   
-1.28154795600633e-15
1.700000        6.89142864097651e-05   
-1.28928236065365e-15
1.600000        6.45052296412595e-05   
-1.29848488989922e-15
1.500000        5.97483776126083e-05   
-1.30960148694006e-15
1.400000        5.46320649249439e-05   
-1.32326977154928e-15
1.300000        4.91478435825781e-05   
-1.3404286750276e-15
1.200000        4.32919623998454e-05   
-1.36250830892367e-15
1.100000        3.70678871330223e-05   
-1.39177202537724e-15
1.000000        3.04915786576429e-05   
-1.43195494399345e-15
0.900000        2.36052666077545e-05   
-1.48947100843164e-15
0.800000        1.65202853321069e-05   
-1.57551564136398e-15
0.700000        9.56073716566518e-06   
-1.70791288744525e-15
0.600000        3.67125710597e-06      
-1.89923336361812e-15
0.500000        6.00021904261974e-07   
-2.08381565027337e-15
0.400000        4.27864345038415e-08   
-2.14973379503184e-15
0.300000        2.5741570279509e-09    
-2.15852923041729e-15
0.200000        1.60325700603365e-10   
-2.15762110254924e-15
0.100000        1.10181009347061e-11   
-2.15430351925385e-15
0.000000        9.18460199298261e-13   
-2.14607756126421e-15
-0.100000       8.2907448480307e-14    
-2.13154544128925e-15
-0.200000       9.49291906644266e-15   
-2.09562596113738e-15
-0.300000       2.57398712712903e-15   
-1.89144055818718e-15
-0.400000       1.23896929747012e-15   
-1.18482371296596e-15
-0.500000       4.77088843470797e-16   
-4.74259070979461e-16
3.300000        0.000725333230235404   
-1.60279744215745e-14
3.200000        0.000698989627849489   
-1.57983897758426e-14
3.100000        0.000672395787137216   
-1.55721529060957e-14
3.000000        0.000645566845212758   
-1.53549883971193e-14
2.900000        0.000618516906916818   
-1.51624220311135e-14
2.800000        0.000591259277466284   
-1.50347782956977e-14
2.700000        0.000563806714724985   
-1.5069525306854e-14
2.600000        0.000536171704020601   
-1.54848062262748e-14
2.500000        0.000508366761845922   
-1.67334737461837e-14
2.400000        0.000480404778779427   
-1.96904798125589e-14
2.300000        0.00045229941701671    
-2.59347024715496e-14
2.200000        0.000424065584744255   
-3.81354821168744e-14
2.100000        0.000395720019338978   
-6.05316531752639e-14
2.000000        0.000367282025836478   
-9.9457021513997e-14
1.900000        0.000338774439198852   
-1.63825993533288e-13
1.800000        0.000310224913488982   
-2.65456611717139e-13
1.700000        0.000281667696431468   
-4.19089961445906e-13
1.600000        0.000253146138686846   
-6.4197984099406e-13
1.500000        0.000224716340367884   
-9.52983499747302e-13
1.400000        0.00019645260393449    
-1.37117106753005e-12
1.300000        0.000168455842857815   
-1.9140171376089e-12
1.200000        0.000140866992561325   
-2.5949957749272e-12
1.100000        0.000113889209694637   
-3.419066099784e-12
1.000000        8.78261401150504e-05   
-4.36958009251635e-12
0.900000        6.31506490822963e-05   
-5.36461118003355e-12
0.800000        4.06312963119592e-05   
-6.12577475587495e-12
0.700000        2.15481889941145e-05   
-5.92418822150058e-12
0.600000        7.87604367966821e-06   
-3.80859906972703e-12
0.500000        1.3904896761789e-06    
-9.79870732426348e-13
0.400000        1.06064890626322e-07   
-9.39992702457847e-14
0.300000        6.34950130197645e-09   
-1.65503941397823e-14
0.200000        3.88292805625561e-10   
-1.16204226732226e-14
0.100000        2.57865399432747e-11   
-1.11870703136006e-14
0.000000        2.05458930149398e-12   
-1.09482596289954e-14
-0.100000       1.85578779234532e-13   
-1.06729449780495e-14
-0.200000       2.5577583052963e-14    
-1.02232392679007e-14
-0.300000       1.05769385343133e-14   
-9.2322860676878e-15
-0.400000       8.00273522170935e-15   
-7.88228414475344e-15
-0.500000       6.51965630664677e-15   
-6.50815076902941e-15
3.300000        0.000778073989265561   
-1.65574096734398e-07
3.200000        0.00074963150963251    
-1.92244746339178e-07
3.100000        0.000721015586364691   
-2.21197891556889e-07
3.000000        0.000692226507232058   
-2.52254070463242e-07
2.900000        0.000663264988754168   
-2.85152554002688e-07
2.800000        0.000634132321079485   
-3.19546222567145e-07
2.700000        0.000604830546549725   
-3.54998299569146e-07
2.600000        0.000575362679604795   
-3.90981285317844e-07
2.500000        0.000545732977654778   
-4.26878409205096e-07
2.400000        0.000515947275272665   
-4.61987879332959e-07
2.300000        0.000486013397947319   
-4.95530155074015e-07
2.200000        0.000455941677304999   
-5.26658398699649e-07
2.100000        0.000425745598153737   
-5.54472176489517e-07
2.000000        0.000395442620520435   
-5.78034377120716e-07
1.900000        0.000365055239615154   
-5.96391194651538e-07
1.800000        0.000334612377612625   
-6.0859488246625e-07
1.700000        0.000304151250425071   
-6.13728816719563e-07
1.600000        0.000273719932661724   
-6.1093419812057e-07
1.500000        0.000243380977243086   
-5.99437433988553e-07
1.400000        0.000213216675616044   
-5.78576796961394e-07
1.300000        0.000183336956663227   
-5.47826196051382e-07
1.200000        0.000153891700661593   
-5.06812695554088e-07
1.100000        0.000125090796710056   
-4.55323667088038e-07
1.000000        9.7238530664174e-05    
-3.9330616509577e-07
0.900000        7.07959411929754e-05   
-3.20910962327376e-07
0.800000        4.64992533700793e-05   
-2.38877973057319e-07
0.700000        2.55795422135307e-05   
-1.50458199069334e-07
0.600000        1.00314893206752e-05   
-6.74343626580743e-08
0.500000        2.00947524041218e-06   
-1.48839482947924e-08
0.400000        1.67232105200131e-07   
-1.2816627677716e-09
0.300000        1.00809637284154e-08   
-7.82708572696571e-11
0.200000        6.12196843592758e-10   
-4.83619605089934e-12
0.100000        4.0027953235145e-11    
-3.39466185939354e-13
0.000000        3.1163322565507e-12    
-4.38427713973686e-14
-0.100000       2.82036148373174e-13   
-2.01235539818538e-14
-0.200000       4.04726306794353e-14   
-1.75747562532315e-14
-0.300000       1.83397331593843e-14   
-1.63366924660679e-14
-0.400000       1.50709750319906e-14   
-1.48901998089388e-14
-0.500000       1.34240392889815e-14   
-1.34063683071726e-14
3.300000        0.000104772187944365   
-1.23330767339032e-15
3.200000        0.000103862130408037   
-1.23481086168441e-15
3.100000        0.000102831826202984   
-1.23643366708223e-15
3.000000        0.000101671354638586   
-1.23819069775402e-15
2.900000        0.000100370082245968   
-1.24009908383179e-15
2.800000        9.89166376398503e-05   
-1.24217904419247e-15
2.700000        9.72988932844521e-05   
-1.24445461136295e-15
2.600000        9.55039568198016e-05   
-1.24695456774457e-15
2.500000        9.3518175238995e-05    
-1.24971366756711e-15
2.400000        9.13271559565959e-05   
-1.25277425005882e-15
2.300000        8.89158096852735e-05   
-1.25618839559713e-15
2.200000        8.62684210547775e-05   
-1.26002084671538e-15
2.100000        8.33687540802062e-05   
-1.26435302405962e-15
2.000000        8.02002009414518e-05   
-1.26928863786894e-15
1.900000        7.67459841300842e-05   
-1.27496167015724e-15
1.800000        7.29894239935539e-05   
-1.28154795600633e-15
1.700000        6.89142864097651e-05   
-1.28928236065365e-15
1.600000        6.45052296412595e-05   
-1.29848488989922e-15
1.500000        5.97483776126083e-05   
-1.30960148694006e-15
1.400000        5.46320649249439e-05   
-1.32326977154928e-15
1.300000        4.91478435825781e-05   
-1.3404286750276e-15
1.200000        4.32919623998454e-05   
-1.36250830892367e-15
1.100000        3.70678871330223e-05   
-1.39177202537724e-15
1.000000        3.04915786576429e-05   
-1.43195494399345e-15
0.900000        2.36052666077545e-05   
-1.48947100843164e-15
0.800000        1.65202853321069e-05   
-1.57551564136398e-15
0.700000        9.56073716566518e-06   
-1.70791288744525e-15
0.600000        3.67125710597e-06      
-1.89923336361812e-15
0.500000        6.00021904261974e-07   
-2.08381565027337e-15
0.400000        4.27864345038415e-08   
-2.14973379503184e-15
0.300000        2.5741570279509e-09    
-2.15852923041729e-15
0.200000        1.60325700603365e-10   
-2.15762110254924e-15
0.100000        1.10181009347061e-11   
-2.15430351925385e-15
0.000000        9.18460199298261e-13   
-2.14607756126421e-15
-0.100000       8.2907448480307e-14    
-2.13154544128925e-15
-0.200000       9.49291906644266e-15   
-2.09562596113738e-15
-0.300000       2.57398712712903e-15   
-1.89144055818718e-15
-0.400000       1.23896929747012e-15   
-1.18482371296596e-15
-0.500000       4.77088843470797e-16   
-4.74259070979461e-16
3.300000        0.000725333230235404   
-1.60279744215745e-14
3.200000        0.000698989627849489   
-1.57983897758426e-14
3.100000        0.000672395787137216   
-1.55721529060957e-14
3.000000        0.000645566845212758   
-1.53549883971193e-14
2.900000        0.000618516906916818   
-1.51624220311135e-14
2.800000        0.000591259277466284   
-1.50347782956977e-14
2.700000        0.000563806714724985   
-1.5069525306854e-14
2.600000        0.000536171704020601   
-1.54848062262748e-14
2.500000        0.000508366761845922   
-1.67334737461837e-14
2.400000        0.000480404778779427   
-1.96904798125589e-14
2.300000        0.00045229941701671    
-2.59347024715496e-14
2.200000        0.000424065584744255   
-3.81354821168744e-14
2.100000        0.000395720019338978   
-6.05316531752639e-14
2.000000        0.000367282025836478   
-9.9457021513997e-14
1.900000        0.000338774439198852   
-1.63825993533288e-13
1.800000        0.000310224913488982   
-2.65456611717139e-13
1.700000        0.000281667696431468   
-4.19089961445906e-13
1.600000        0.000253146138686846   
-6.4197984099406e-13
1.500000        0.000224716340367884   
-9.52983499747302e-13
1.400000        0.00019645260393449    
-1.37117106753005e-12
1.300000        0.000168455842857815   
-1.9140171376089e-12
1.200000        0.000140866992561325   
-2.5949957749272e-12
1.100000        0.000113889209694637   
-3.419066099784e-12
1.000000        8.78261401150504e-05   
-4.36958009251635e-12
0.900000        6.31506490822963e-05   
-5.36461118003355e-12
0.800000        4.06312963119592e-05   
-6.12577475587495e-12
0.700000        2.15481889941145e-05   
-5.92418822150058e-12
0.600000        7.87604367966821e-06   
-3.80859906972703e-12
0.500000        1.3904896761789e-06    
-9.79870732426348e-13
0.400000        1.06064890626322e-07   
-9.39992702457847e-14
0.300000        6.34950130197645e-09   
-1.65503941397823e-14
0.200000        3.88292805625561e-10   
-1.16204226732226e-14
0.100000        2.57865399432747e-11   
-1.11870703136006e-14
0.000000        2.05458930149398e-12   
-1.09482596289954e-14
-0.100000       1.85578779234532e-13   
-1.06729449780495e-14
-0.200000       2.5577583052963e-14    
-1.02232392679007e-14
-0.300000       1.05769385343133e-14   
-9.2322860676878e-15
-0.400000       8.00273522170935e-15   
-7.88228414475344e-15
-0.500000       6.51965630664677e-15   
-6.50815076902941e-15
"""

re.search("== Data Table ==\n(.*?)\n(.*?)\s*$", output,
re.S)



----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-04-24 20:28

Message:
Logged In: YES 
user_id=31435

Assigned to /F.  Works for me on Win98 under 2.1.  Binding 
m to the re result and then printing

print m.span(), len(output), m.span(1), m.span(2)

yields

(8, 12112) 12112 (25, 43) (44, 12111)

Anonymous, this is a poor use for regexps:  the code would 
be clearer, simpler and faster (plus it wouldn't blow up 
<wink>) if you used basic string operations instead.  The 
(.*?)\s*$ at the end is especially wasteful:  you're 
teilling the regexp engine to do 12,000+ useless match 
attempts there, when all you *want* is the entire tail end 
of the string stripped of trailing whitespace.  So just 
grab the tail end of the string directly and do 
string.rstrip() on it; saves 12,000+ useless matching 
attempts.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418626&group_id=5470


From noreply@sourceforge.net  Wed Apr 25 14:16:27 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 25 Apr 2001 06:16:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-418817 ] path separator constant
Message-ID: <E14sP9f-0008AZ-00@usw-sf-web1.sourceforge.net>

Bugs item #418817, was updated on 2001-04-25 06:16
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418817&group_id=5470

Category: Extension Modules
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Grant Griffin (dspguru)
Assigned to: Nobody/Anonymous (nobody)
Summary: path separator constant

Initial Comment:
I would like to request that os.path provide a 
constant to convey the platform's path separator 
character, to help make certain manual path 
manipulations more platform-independent.  I would 
recommend:

   os.path.separator = '\'  for Windows and DOS
   os.path.separator = '/'   for others

Currently, users can obtain the separator character 
using os.path.normcase('/'), so, unfortunately, 
providing a special constant for this creates the 
dreaded "more than one way to do it".  However, I 
don't regard the normcase construct as being at 
all "obvious": I discovered it only after looking at 
the os.path source.

Therefore, if the current method via os.path.normcase
('/') is deemed to be adequate (and so eliminates any 
need for a special constant), I would recommend adding 
a description of this special use to os.path's 
documentation.

thanks much-ly,

=g2


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418817&group_id=5470


From noreply@sourceforge.net  Wed Apr 25 14:32:34 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 25 Apr 2001 06:32:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-418817 ] path separator constant
Message-ID: <E14sPPG-0005GC-00@usw-sf-web2.sourceforge.net>

Bugs item #418817, was updated on 2001-04-25 06:16
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418817&group_id=5470

Category: Extension Modules
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Grant Griffin (dspguru)
Assigned to: Nobody/Anonymous (nobody)
Summary: path separator constant

Initial Comment:
I would like to request that os.path provide a 
constant to convey the platform's path separator 
character, to help make certain manual path 
manipulations more platform-independent.  I would 
recommend:

   os.path.separator = '\'  for Windows and DOS
   os.path.separator = '/'   for others

Currently, users can obtain the separator character 
using os.path.normcase('/'), so, unfortunately, 
providing a special constant for this creates the 
dreaded "more than one way to do it".  However, I 
don't regard the normcase construct as being at 
all "obvious": I discovered it only after looking at 
the os.path source.

Therefore, if the current method via os.path.normcase
('/') is deemed to be adequate (and so eliminates any 
need for a special constant), I would recommend adding 
a description of this special use to os.path's 
documentation.

thanks much-ly,

=g2


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2001-04-25 06:32

Message:
Logged In: YES 
user_id=6656

do you know about os.sep?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418817&group_id=5470


From noreply@sourceforge.net  Wed Apr 25 14:59:47 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 25 Apr 2001 06:59:47 -0700
Subject: [Python-bugs-list] [ python-Bugs-418817 ] path separator constant
Message-ID: <E14sPpb-0000Sn-00@usw-sf-web1.sourceforge.net>

Bugs item #418817, was updated on 2001-04-25 06:16
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418817&group_id=5470

Category: Extension Modules
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Grant Griffin (dspguru)
Assigned to: Nobody/Anonymous (nobody)
Summary: path separator constant

Initial Comment:
I would like to request that os.path provide a 
constant to convey the platform's path separator 
character, to help make certain manual path 
manipulations more platform-independent.  I would 
recommend:

   os.path.separator = '\'  for Windows and DOS
   os.path.separator = '/'   for others

Currently, users can obtain the separator character 
using os.path.normcase('/'), so, unfortunately, 
providing a special constant for this creates the 
dreaded "more than one way to do it".  However, I 
don't regard the normcase construct as being at 
all "obvious": I discovered it only after looking at 
the os.path source.

Therefore, if the current method via os.path.normcase
('/') is deemed to be adequate (and so eliminates any 
need for a special constant), I would recommend adding 
a description of this special use to os.path's 
documentation.

thanks much-ly,

=g2


----------------------------------------------------------------------

>Comment By: Grant Griffin (dspguru)
Date: 2001-04-25 06:59

Message:
Logged In: YES 
user_id=70844

Ooops!  I guess os.sep covers that.

I think the reason I didn't find it is that it's a "path" thing, yet it's not in "os.path".  But I guess it's too late 
to change that...

=g2

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2001-04-25 06:32

Message:
Logged In: YES 
user_id=6656

do you know about os.sep?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418817&group_id=5470


From noreply@sourceforge.net  Wed Apr 25 15:57:33 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 25 Apr 2001 07:57:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-416824 ] Python 2.1 installer freezes on Win 2000
Message-ID: <E14sQjV-0001Su-00@usw-sf-web1.sourceforge.net>

Bugs item #416824, was updated on 2001-04-17 13:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416824&group_id=5470

Category: Windows
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Xavier Lagraula (xlagraula)
Assigned to: Tim Peters (tim_one)
Summary: Python 2.1 installer freezes on Win 2000

Initial Comment:
My aim is to install Python 2.1 on a Windows 2000 
Professionnal (French) workstation.

The windows intaller works well until it show the 
screen where one can choose which parts of the product 
one wants to install (third window).

If one hit the "next" button without touching anything 
else, the installer will definitively freeze. Trying 
to stop it using the pop-up menu in the task bar will 
result in a few seconds pause, followed by an error 
window telling that the 16-bit subsystem has not 
answered in time to the stop request. The possibility 
is then given to kill it, eventually leaving the 16 
bit subsystem unstable.

I tried to download the installer from both the main 
site and sourceforge, to check if it came from a 
corrupted file. Same result.

The workaround is simple: just uncheck at least one of 
the check boxes, click "next", it won't freeze. Now 
click "back", re-check the check boxe, click "next" 
and... tada! It won't freeze neither. Now you can go 
on installing the whole package. Haven't thoroughly 
tested it yet, but seems to be working fine.

This problem is not really serious as one can easily 
bypass it, and as it doesn't involve the langage or 
the interpreter themselves. Nevertheless, it IS a 
bug...

Regards,
  Xavier


----------------------------------------------------------------------

>Comment By: Xavier Lagraula (xlagraula)
Date: 2001-04-25 07:57

Message:
Logged In: YES 
user_id=198402

Well, it is not a bugfix, but a solution is to use the 
ActivePython distribution instead, as suggested by tim_one
(cf. #418156). Even after managing to work around the 
problem of the first distribution (as I've said), I tried 
to install it on my win2k workstation (sheer curiosity) and 
it worked without problem.

It comes as a .msi file, the new standard. You may need to 
download the installer on microsoft.com. Everything is 
explained on the ActiveState web site:
http://www.activestate.com/ASPN/Downloads/ActivePython/

I'll soon have a look at the availability of this msi 
format: if the old version of the Wise Solution installer 
starts to make problems, we might as well start to look for 
a replacement.

--
Xavier

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-04-18 15:30

Message:
Logged In: NO 

In case it helps, I've got a win2k pro workstation, 128MB 
ram, and it also hangs on the same page during the 
installation.  Oh, and the workaround you mentioned did not 
work for me.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-04-18 11:41

Message:
Logged In: YES 
user_id=31435

It's fine that you were logged in as an Administrator.  
Indeed, things probably have the *best* chance of working 
then.

Please note that we didn't write the installer code:  the 
Wise installer is a commercial product, which they kindly 
let Python use for free:

http://www.wisesolutions.com/

We have no access to the source code, either.  So if you 
*do*, for example, find evidence of an uninitialized 
variable, there's nothing we can do about it.  Alas, I 
doubt Wise will do anything about it either, as the version 
of the product we're using is over 5 years old (and looks 
like they stopped supporting it a few years ago).

OTOH, the Windows installer is used many thousands of 
times, and this is the only freeze report we've seen.  If 
we don't see another, the presumption still has to favor 
that there's something flaky about your particular machine.

BTW, I've never tried it on a machine w/ 512Mb of RAM, so 
perhaps that is relevant.  Have tried it on machines w/ 
256Mb.

----------------------------------------------------------------------

Comment By: Xavier Lagraula (xlagraula)
Date: 2001-04-18 05:31

Message:
Logged In: YES 
user_id=198402

To answer your question: I was logged using the 
Administrator account ("Administrateur", in fact, on a 
french box). Like most of the time, because many software 
which are not specifically written for NT won't run 
correctly without it. I know this is bad but what else can 
I do?

Anyway I don't have access to another french win2k box. All 
I can do is give you spécific information about my computer:
- PII 400 - 512Mo of PC133 SDRAM
- Asus MB - P3 BF
- Video: GeForce 256 DDR (Hercules) / Hauppauge WinTV
- Sound: SB Live Player!
- Network: 2 SN3200 (PCI, ethernet 10Mbps, ne2000 
compatible)
- SCSI: Diamond Fireport 40 / CDROM x32 (plextor) / CD 
burner (ricoh MP6200s)
- Win2k french SP1 + IE 5.5
- mysql: latest stable version + MyODBC drivers
- apache: latest stable version + PHP
- naviscope (web proxy/dns cache)
- net vampire: v4.0 beta
- ICQ 2000b
- all drivers were up to date 3 weeks ago.

Still, I believe that those symptoms look either like a 
uninitialized variable or a faulty pointer, such bugs that 
can remain hidden except under very specific "context-
specific" circumstances. (Un)checking one of the check 
boxes, by forcing a value in the variable or by allocating 
a memory block would correct the problem and allow the user 
to go on with the installation.

If I can reproduce the bug this evening, I'll try to see if 
the installer eats all CPU while freezed. Could give a clue 
about what's really happenning. I may also try removing 
256Mo of RAM to verify my "pointer hypothesis" (if it makes 
the bug impossible to reproduce, then it has something to 
do with memory allocation. Crude method but quite useful 
sometimes).

Regards,
  Xavier

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-04-18 02:47

Message:
Logged In: YES 
user_id=31435

This is the only freeze report we've seen for Win2K.

Did you do something bizarre <wink>?  For example, we've 
had one-of-a-kind reports from people in the past who tried 
to install on NT or Win2K while logged in to a Restricted 
User account.  Were you?  Or were you logged in to an 
Administrator account?  Or were you logged in as something 
in between?

Could you try it on another Win2K (French) box?  We have a 
poor track record when it comes to fixing Microsoft's bugs 
for them, and in the absence of more info I have to assume 
it's a bug unique to the specific box you used.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416824&group_id=5470


From noreply@sourceforge.net  Wed Apr 25 18:27:49 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 25 Apr 2001 10:27:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-229810 ] Memore leak in pickle and cPickle
Message-ID: <E14sT4v-00043u-00@usw-sf-web1.sourceforge.net>

Bugs item #229810, was updated on 2001-01-23 07:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=229810&group_id=5470

Category: Python Library
>Group: Not a Bug
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Vladimir Kralik (vlk)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: Memore leak in pickle and cPickle

Initial Comment:
# When Pickler.object is used for dump typles into file and Unpickler for 
# load from files. A loaded object are not garbage collected.
# When function dump(object,file) is used Unpickler works fine.
# Problem is in pickle and cPickle module
# tested on Python 2.0 Red Hat Linux 6.2

import cPickle			
#import pickle			 
import gc

f=open("xxx","w")
pic=cPickle.Pickler(f,1)	# ERROR
#pic=pickle.Pickler(f,1)	# ERROR
for i in range(100):
	#cPickle.dump(([long(i),long(i),long(i),long(i)],i),f)	
		# this is OK
	#pickle.dump(([long(i),long(i),long(i),long(i)],i),f)	
		# this is OK
	pic.dump(([long(i),long(i),long(i),long(i)],i))		
		# Memory leak

f.close()
gc.set_debug(gc.DEBUG_STATS)
f=open("xxx","r")
u=cPickle.Unpickler(f)
try:
	while 1:
		gc.collect()
		print u.load()
except EOFError:
	pass
f.close()

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-25 10:27

Message:
Logged In: YES 
user_id=6380

I think I know why this is.  It is a false alarm, or at
least something that we cannot fix -- it falls in the
category "don't do this".

The Pickler instance keeps a memory of each of the lists
dumped alive, so that if you later pickle a reference to the
same list (or other mutable object) again, it can pickle a
reference rather than a copy of the value. This is a
feature.

By using the same Pickler instance to dump 10,000 unrelated
lists, you simply grow the memo data structure beyond
reason. So just don't do this!

Closing this now.


----------------------------------------------------------------------

Comment By: Naris Siamwalla (naris)
Date: 2001-04-24 16:47

Message:
Logged In: YES 
user_id=67995

barry's python snippet memory leaks on python 2.1 final
on rh6.2.

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-02-23 10:59

Message:
# When Pickler.object is used for dump typles into file and Unpickler for load
# from files. A loaded object are not garbage collected.  When function
# dump(object,file) is used Unpickler works fine.  Problem is in pickle and
# cPickle module tested on Python 2.0 Red Hat Linux 6.2

import gc 

def main():
    fp = open('/tmp/xxx', 'w') 
    pic = pickle.Pickler(fp, 1)                   # ERROR 

    for i in range(10000):
        pickle.dump(([long(i), long(i), long(i), long(i)], i), fp) 
        # this is OK 
        pic.dump(([long(i), long(i), long(i), long(i)], i))
        # Memory leak 

    fp.close() 
    gc.set_debug(gc.DEBUG_STATS) 

    fp = open('/tmp/xxx')

    upic = pickle.Unpickler(fp)
    try: 
        while 1: 
            gc.collect() 
            print upic.load() 
    except EOFError: 
        pass

    fp.close()


if __name__ == '__main__':
    import sys
    if len(sys.argv) > 1:
        import cPickle
        pickle = cPickle
    else:
        import pickle

    main()


----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-02-23 10:58

Message:
When cranking up the number of objects placed in the pickle to 10000, I do see some memory growth when unpickling as clocked by top.  The cPickle growth is much smaller than the pickle growth, which already appears fairly minimal.

I will investigate further with Insure++.

I don't see how the problem could be related to __del__ since the only thing we're dumping and loading are builtin objects (tuples, lists, longs, and ints).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-01-23 19:28

Message:
Barry, can you look into this?  I would first see if this is really reproducable without using Insure++; somehow it looks a bit fishy.  Could also be fixed in 2.1 because now modules participate in gc.  Or could have to do with a __del__?  Also, I doubt the claim that this is a leak with both pickle and cPickle.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=229810&group_id=5470


From noreply@sourceforge.net  Wed Apr 25 19:01:52 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 25 Apr 2001 11:01:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-418898 ] __debug__ assignment via setattr
Message-ID: <E14sTbs-0000hn-00@usw-sf-web2.sourceforge.net>

Bugs item #418898, was updated on 2001-04-25 11:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418898&group_id=5470

Category: Parser/Compiler
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: __debug__ assignment via setattr

Initial Comment:
assignment to __debug__ via setattr does not raise a
warning:

Python 2.1 (#1, Apr 17 2001, 17:26:34)
[GCC 2.96 20000731 (Red Hat Linux 7.0)] on linux2
Type "copyright", "credits" or "license" for more
information
>>> import __builtin__
>>> __debug__
1
>>> setattr(__builtin__, '__debug__', 0)
>>> __debug__
0
>>> __debug__ = 1
<stdin>:0: SyntaxWarning: can not assign to __debug__
>>> 

As long as this behavior is going in, it ought to go in
wholesale.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418898&group_id=5470


From noreply@sourceforge.net  Wed Apr 25 23:22:41 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 25 Apr 2001 15:22:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-418977 ] Access Violation in PyCell_Set
Message-ID: <E14sXgH-00014h-00@usw-sf-web1.sourceforge.net>

Bugs item #418977, was updated on 2001-04-25 15:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418977&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Access Violation in PyCell_Set

Initial Comment:
While stepping through a program using the Pythonwin 
debugger, I got an access violation which appears to 
be taking place in PyCell_Set (I'm not using the debug 
libraries).  Specifically, it appears that the op 
parameter is NULL, so the PyCell_Check(op) results in 
the AV.  I believe the call stack at this point was:

  PyCell_Set
  dict_to_map
  PyFrame_LocalsToFast (line 366 of frameobject.c?)
  call_trace
  SET_LINENO (case of eval_code2)

Please let me know if it would be helpful to see the 
python file I was stepping through and I'll upload it.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418977&group_id=5470


From noreply@sourceforge.net  Wed Apr 25 23:29:51 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 25 Apr 2001 15:29:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-418977 ] Access Violation in PyCell_Set
Message-ID: <E14sXnD-0004rk-00@usw-sf-web2.sourceforge.net>

Bugs item #418977, was updated on 2001-04-25 15:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418977&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Access Violation in PyCell_Set

Initial Comment:
While stepping through a program using the Pythonwin 
debugger, I got an access violation which appears to 
be taking place in PyCell_Set (I'm not using the debug 
libraries).  Specifically, it appears that the op 
parameter is NULL, so the PyCell_Check(op) results in 
the AV.  I believe the call stack at this point was:

  PyCell_Set
  dict_to_map
  PyFrame_LocalsToFast (line 366 of frameobject.c?)
  call_trace
  SET_LINENO (case of eval_code2)

Please let me know if it would be helpful to see the 
python file I was stepping through and I'll upload it.


----------------------------------------------------------------------

>Comment By: Greg Chapman (glchapman)
Date: 2001-04-25 15:29

Message:
Logged In: YES 
user_id=86307

I apologize -- I forgot to add that I'm using Python 2.1 
final (binaries downloaded from Sourceforge) and the latest 
win32_all binaries under Windows 2000.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418977&group_id=5470


From noreply@sourceforge.net  Thu Apr 26 01:59:47 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 25 Apr 2001 17:59:47 -0700
Subject: [Python-bugs-list] [ python-Bugs-229998 ] "Corrupt installation" when installed without admin privs
Message-ID: <E14sa8J-0004im-00@usw-sf-web3.sourceforge.net>

Bugs item #229998, was updated on 2001-01-24 17:57
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=229998&group_id=5470

Category: Windows
Group: 3rd Party
Status: Closed
Resolution: Wont Fix
Priority: 1
Submitted By: Tessa Lau (tlau)
Assigned to: Tim Peters (tim_one)
>Summary: "Corrupt installation" when installed without admin privs

Initial Comment:
On Windows 2000, when logged in a user without administrator privileges, attempting to run the Python 2.0 installer results in a single dialog box saying "Corrupt installation detected" and then the installer exits.

This should be a more informative error message.  I downloaded the 5MB installer three times before suspecting the correct cause of the problem.  When the same binary is run as a user with the correct privileges, it correctly begins the installation process.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-04-25 17:59

Message:
Logged In: YES 
user_id=31435

Sylvain, note that another cause was identified later:  
people trying to install Python over a network have also 
gotten bogus "Corrupt installation detected" msgs.  Move 
the installer to your home drive (probably C:) first?


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-04-23 05:09

Message:
Logged In: NO 

I have the same problem with Windows NT TSE.

I use the admin to install Python. 

Python 1.5.2 ok !

But Python 1.6, 2.0, 2.1 => "Corrupt installation detected"

Sylvain FAUVEAU

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-01-25 23:06

Message:
tlau, thanks a lot for helping us here!  I wish we could help you in return, but Guido is right, there's really nothing we can do about it now.  Well, a long-term plan is to move to a more recent Windows installation program (the one we're using was developed before Win2K was even a rumor!), but that's not going to happen soon.

For a good time, download ActiveState's Python Windows installer, and see whether it blows up too:  no reason you can't be disappointed by all of us <wink>.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-01-25 14:27

Message:
Then this is most likely a bug we can't fix.  The"Corrupt installation" check is made AFAIK by the WISE installer code before it runs any of the script.  One of the system checks it does must be using something that's disallowed by Win2K in Restricted User mode.

We have control over the script -- it tests for Administrator privileges and offers to proceed; but we have no control over the system check before it runs.  I haven't seen this complaint before, so I presume it's unlikely to happen (Restricted Users typically won't want to install software :-).

I'll leave it up to Tim, but personally, I'd just close the report as "Won't Fix" and "3rd party".

----------------------------------------------------------------------

Comment By: Tessa Lau (tlau)
Date: 2001-01-25 13:22

Message:
I did some more investigating.  Python prints the correct md5 checksum for the installer; but that's a red herring.

In the "Users and Passwords" control panel, my account is set up as a "Restricted user" (Users Group) account.  When I change this setting to "Standard user" (Power Users Group), then launching the installer prompts me to proceed with a weaker installation (as expected).  Changing the setting back to "Restricted user" and re-running the installer produces the "corrupt installation detected" message yet again.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-01-25 04:52

Message:
I recall explicitly testing whether that installer worked on Win2000 without admin privileges.  So I suspect it's something to do with tlau's set-up, and I don't think we will be able to get much further with this.  (It doesn't help that we don't have the source code for the WISE installer generator, of course. :-( )


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-01-25 02:10

Message:
Curious!  That's the right MD5 checksum.  Yours is the only report of this we've ever gotten, though, while you're certainly not the only 2.0 Win2K user.  It's possible that you're the only one who wasn't logged on to an admin account, though.

Since you have Python running on Windows now, we can use it to compute the MD5 digest:

>>> # change to path of your installer; "rb" is crucial
>>> f = open("/updates/beopen-python-2.0.exe", "rb")
>>> import md5
>>> print md5.md5(f.read()).hexdigest()
05f93fc81247dfb993f2e946016264c0
>>>

If you still get the right checksum, we can rule out the file transfer, but then I'm stumped.  Guess we'll have to report it as a bug to Wise, then (we're not generating the error msg you're seeing -- that's all an automatic function of the Wise installer).


----------------------------------------------------------------------

Comment By: Tessa Lau (tlau)
Date: 2001-01-24 20:46

Message:
I downloaded it using this link:
http://www.python.org/ftp/python/2.0/BeOpen-Python-2.0.exe
The first two times I used IE to click on the link.  I didn't save those copies; I know the file size was around 5.8MB, but I don't know exactly.

For the third try, I used ncftp on a Linux machine to get this file:
ftp://ftp.python.org/pub/python/2.0/BeOpen-Python-2.0.exe
I then used Samba to copy the file from my Linux home directory to the Win2k machine.

I got the same error message (corrupt installation) for all three attempts.  I then logged in as a user with admin privs, ran the third copy, and installation proceeded correctly.

I don't know how to compute the checksum on Windows, but this is what I get from the copy I saved on my Linux system:
% md5sum BeOpen-Python-2.0.exe
05f93fc81247dfb993f2e946016264c0  BeOpen-Python-2.0.exe


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-01-24 20:07

Message:
I need someone else to confirm this (don't have W2K myself).  Mark?  If not, assign back to me.  tlau, from where did you obtain the installer?  Exactly how large is it?  (If it's not exactly 5811039 bytes, it's definitely corrupt -- if it is that size, say so and we'll try an MD5 checksum next.)

The Wise installer produces the "Corrupt installation  detected" msg itself, when it gets a CRC mismatch after checksumming its internal components.  We have no control over that, and in every previous case of this I know of it *did* mean the installer was corrupt.

If you're not logged in with admin privileges, what's supposed to happen is that a box pops up telling you so, and asking whether you want to proceed with a weaker installation, or abort the installation.  Testers reported that the 2.0 installer did exactly that, on NT and W2K (it's not an issue on 95, 98 or ME).


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=229998&group_id=5470


From noreply@sourceforge.net  Thu Apr 26 02:08:44 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 25 Apr 2001 18:08:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-419012 ] #define collision: LONG_BIT
Message-ID: <E14saGy-0003vp-00@usw-sf-web1.sourceforge.net>

Bugs item #419012, was updated on 2001-04-25 18:08
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=419012&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Viktor Ferenczi (complex)
Assigned to: Nobody/Anonymous (nobody)
Summary: #define collision: LONG_BIT

Initial Comment:
Platform: RedHat Linux 7.0, Linux kernel 2.2.17

When building Python 2.1 final release after

./configure --prefix=/usr/local

LONG_BIT definition found in
/usr/local/include/bits/xopen_lim.h causes an error
message originated from LONG_BIT size test in Python.h.

Workaround (only an ugly hack): Insert "#define
LONG_BIT 32" in Python.h before the #ifndef LONG_BIT
line. This causes a #define collision warning, but
Python 2.1 compiles successfully and works.

- Complex -

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=419012&group_id=5470


From noreply@sourceforge.net  Thu Apr 26 02:31:10 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 25 Apr 2001 18:31:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-419012 ] #define collision: LONG_BIT
Message-ID: <E14sacg-00055h-00@usw-sf-web3.sourceforge.net>

Bugs item #419012, was updated on 2001-04-25 18:08
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=419012&group_id=5470

Category: Build
Group: Platform-specific
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Viktor Ferenczi (complex)
Assigned to: Nobody/Anonymous (nobody)
Summary: #define collision: LONG_BIT

Initial Comment:
Platform: RedHat Linux 7.0, Linux kernel 2.2.17

When building Python 2.1 final release after

./configure --prefix=/usr/local

LONG_BIT definition found in
/usr/local/include/bits/xopen_lim.h causes an error
message originated from LONG_BIT size test in Python.h.

Workaround (only an ugly hack): Insert "#define
LONG_BIT 32" in Python.h before the #ifndef LONG_BIT
line. This causes a #define collision warning, but
Python 2.1 compiles successfully and works.

- Complex -

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-04-25 18:31

Message:
Logged In: YES 
user_id=31435

The GCC version that comes with Red Hat 7.0 is not fit for
distribution.

In particular, it defines LONG_BIT as 64 on 32-bit machines under
certain circumstances, and letting this go unchecked would cause
it to generate bad code for various Python arithmetic operations.

The solution is to download a valid version of GCC.

See

http://www.python.org/cgi-
bin/moinmoin/FrequentlyAskedQuestions#line53

for more information.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=419012&group_id=5470


From noreply@sourceforge.net  Thu Apr 26 07:59:45 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 25 Apr 2001 23:59:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-419062 ] python 2.1 :  building pbs on AIX 4.3.2
Message-ID: <E14sfkf-0000QZ-00@usw-sf-web3.sourceforge.net>

Bugs item #419062, was updated on 2001-04-25 23:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=419062&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: python 2.1 :  building pbs on AIX 4.3.2

Initial Comment:
I met what could be called "regression"? problems : 
the "make all" process stopped at the beginning of the 
building of the shared modules under AIX 4.3.2.

1. it is looking for a "ld_so_aix" under the 
destination directory (${prefix}/lib/python2.1}) ... 
which, for an obvious reason is not there during the 
compiling phase 

2. if you try to force the process by creating the 
directory and putting the "so needed" program in it, a 
new stop occurs : it is unable to find 
the "Python.exp" or whatever other *.exp file needed 
by the linking process

Those problems didn't occur during the build of python 
2.0 wich has been compiled fine under AIX 4.3.2


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=419062&group_id=5470


From noreply@sourceforge.net  Thu Apr 26 08:19:45 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 26 Apr 2001 00:19:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-418977 ] Access Violation in PyCell_Set
Message-ID: <E14sg41-00017g-00@usw-sf-web1.sourceforge.net>

Bugs item #418977, was updated on 2001-04-25 15:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418977&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Access Violation in PyCell_Set

Initial Comment:
While stepping through a program using the Pythonwin 
debugger, I got an access violation which appears to 
be taking place in PyCell_Set (I'm not using the debug 
libraries).  Specifically, it appears that the op 
parameter is NULL, so the PyCell_Check(op) results in 
the AV.  I believe the call stack at this point was:

  PyCell_Set
  dict_to_map
  PyFrame_LocalsToFast (line 366 of frameobject.c?)
  call_trace
  SET_LINENO (case of eval_code2)

Please let me know if it would be helpful to see the 
python file I was stepping through and I'll upload it.


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2001-04-26 00:19

Message:
Logged In: YES 
user_id=21627

I think it would be definitely helpful to see the sources;
it would be even better if you could reduce them to a small
test case. Please attach them to this report.

----------------------------------------------------------------------

Comment By: Greg Chapman (glchapman)
Date: 2001-04-25 15:29

Message:
Logged In: YES 
user_id=86307

I apologize -- I forgot to add that I'm using Python 2.1 
final (binaries downloaded from Sourceforge) and the latest 
win32_all binaries under Windows 2000.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418977&group_id=5470


From noreply@sourceforge.net  Thu Apr 26 08:23:13 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 26 Apr 2001 00:23:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-418817 ] path separator constant
Message-ID: <E14sg7N-0001BM-00@usw-sf-web1.sourceforge.net>

Bugs item #418817, was updated on 2001-04-25 06:16
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418817&group_id=5470

Category: Extension Modules
Group: Feature Request
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Grant Griffin (dspguru)
Assigned to: Nobody/Anonymous (nobody)
Summary: path separator constant

Initial Comment:
I would like to request that os.path provide a 
constant to convey the platform's path separator 
character, to help make certain manual path 
manipulations more platform-independent.  I would 
recommend:

   os.path.separator = '\'  for Windows and DOS
   os.path.separator = '/'   for others

Currently, users can obtain the separator character 
using os.path.normcase('/'), so, unfortunately, 
providing a special constant for this creates the 
dreaded "more than one way to do it".  However, I 
don't regard the normcase construct as being at 
all "obvious": I discovered it only after looking at 
the os.path source.

Therefore, if the current method via os.path.normcase
('/') is deemed to be adequate (and so eliminates any 
need for a special constant), I would recommend adding 
a description of this special use to os.path's 
documentation.

thanks much-ly,

=g2


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2001-04-26 00:23

Message:
Logged In: YES 
user_id=21627

Grant, it appears that you accept the state of matters as
sufficient, so I close this. If you disagree, please let me
know so I'll reopen it.

----------------------------------------------------------------------

Comment By: Grant Griffin (dspguru)
Date: 2001-04-25 06:59

Message:
Logged In: YES 
user_id=70844

Ooops!  I guess os.sep covers that.

I think the reason I didn't find it is that it's a "path" thing, yet it's not in "os.path".  But I guess it's too late 
to change that...

=g2

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2001-04-25 06:32

Message:
Logged In: YES 
user_id=6656

do you know about os.sep?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418817&group_id=5470


From noreply@sourceforge.net  Thu Apr 26 09:01:24 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 26 Apr 2001 01:01:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-416670 ] MatchObjects not deepcopy()able
Message-ID: <E14sgiK-0001nM-00@usw-sf-web1.sourceforge.net>

Bugs item #416670, was updated on 2001-04-17 05:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416670&group_id=5470

Category: Regular Expressions
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Henning Thielemann (amigalemming)
Assigned to: Nobody/Anonymous (nobody)
Summary: MatchObjects not deepcopy()able

Initial Comment:

In the re-Module which come with Python version 2.0
(Nov 28 11:10 re.py) the created MatchObjects cannot be
copied with a deepcopy(). Switching back to the old
"pre.py" as proposed in "re.py" makes everything work
ok.



----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2001-04-26 01:01

Message:
Logged In: YES 
user_id=21627

A patch for that problem is in
http://sourceforge.net/tracker/index.php?func=detail&aid=419070&group_id=5470&atid=305470

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416670&group_id=5470


From noreply@sourceforge.net  Thu Apr 26 12:11:35 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 26 Apr 2001 04:11:35 -0700
Subject: [Python-bugs-list] [ python-Bugs-417845 ] Python 2.1: SocketServer.ThreadingMixIn
Message-ID: <E14sjgN-0005ZA-00@usw-sf-web2.sourceforge.net>

Bugs item #417845, was updated on 2001-04-21 08:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417845&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.1: SocketServer.ThreadingMixIn

Initial Comment:
SocketServer.ThreadingMixIn does not work properly
since it tries to close the socket of a request two
times.

Workaround for using SocketServer.ThreadingMixIn under
Python 2.1:

class MyThreadingHTTPServer(
  SocketServer.ThreadingMixIn,
  MyHTTPServer
):
  def close_request(self, request):
    pass



----------------------------------------------------------------------

Comment By: Luke Kenneth Casson Leighton (lkcl)
Date: 2001-04-26 04:11

Message:
Logged In: YES 
user_id=80200

hi there,

i'm the person who wrote the BaseServer class.  guido
contacted me about it: could you please send me or post here
a working test example that demonstrates the problem.

i assume, but you do not state, that you have tested your
MyHTTPServer with python 2.0, please let us know, here, if
that is a correct assumption.

thanks!

luke

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417845&group_id=5470


From noreply@sourceforge.net  Thu Apr 26 13:19:23 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 26 Apr 2001 05:19:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-418977 ] Access Violation in PyCell_Set
Message-ID: <E14skjz-0006O4-00@usw-sf-web2.sourceforge.net>

Bugs item #418977, was updated on 2001-04-25 15:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418977&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Access Violation in PyCell_Set

Initial Comment:
While stepping through a program using the Pythonwin 
debugger, I got an access violation which appears to 
be taking place in PyCell_Set (I'm not using the debug 
libraries).  Specifically, it appears that the op 
parameter is NULL, so the PyCell_Check(op) results in 
the AV.  I believe the call stack at this point was:

  PyCell_Set
  dict_to_map
  PyFrame_LocalsToFast (line 366 of frameobject.c?)
  call_trace
  SET_LINENO (case of eval_code2)

Please let me know if it would be helpful to see the 
python file I was stepping through and I'll upload it.


----------------------------------------------------------------------

>Comment By: Greg Chapman (glchapman)
Date: 2001-04-26 05:19

Message:
Logged In: YES 
user_id=86307

As requested, I've stripped down the code to a fairly 
simple test case.  There's a comment indicating the line on 
which the AV occurs (it occurs when you press the key to 
single step off that line to the next).  No AV occurs if 
you simply run the script under PythonWin.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-04-26 00:19

Message:
Logged In: YES 
user_id=21627

I think it would be definitely helpful to see the sources;
it would be even better if you could reduce them to a small
test case. Please attach them to this report.

----------------------------------------------------------------------

Comment By: Greg Chapman (glchapman)
Date: 2001-04-25 15:29

Message:
Logged In: YES 
user_id=86307

I apologize -- I forgot to add that I'm using Python 2.1 
final (binaries downloaded from Sourceforge) and the latest 
win32_all binaries under Windows 2000.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418977&group_id=5470


From noreply@sourceforge.net  Thu Apr 26 13:41:27 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 26 Apr 2001 05:41:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-417845 ] Python 2.1: SocketServer.ThreadingMixIn
Message-ID: <E14sl5L-0004d2-00@usw-sf-web3.sourceforge.net>

Bugs item #417845, was updated on 2001-04-21 08:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417845&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.1: SocketServer.ThreadingMixIn

Initial Comment:
SocketServer.ThreadingMixIn does not work properly
since it tries to close the socket of a request two
times.

Workaround for using SocketServer.ThreadingMixIn under
Python 2.1:

class MyThreadingHTTPServer(
  SocketServer.ThreadingMixIn,
  MyHTTPServer
):
  def close_request(self, request):
    pass



----------------------------------------------------------------------

Comment By: Luke Kenneth Casson Leighton (lkcl)
Date: 2001-04-26 05:41

Message:
Logged In: YES 
user_id=80200

follow-up.  i took a look at the differences between
SocketServer.py
in 2.0 and 2.1.  there is one small change by guido to the
ThreadingMixIn.process_request() function that calls
self.server_close() instead of explicitly calling
self.socket.close(),
where TCPServer.server_close() calls self.socket.close().

if mr anonymous (hi!) has over-ridden server_close() and
explicitly closes the *request* socket, then of course the
socket will get closed twice.

the rest of the code-mods is a straightforward code-shuffle
moving code from TCPServer into BaseServer: from
examining the diff, i really don't see how bypassing
close_request(), as shown above with the Workaround
in the original bug-report, will help: that will in fact
cause the request _never_ to be closed!

the rest of this report is part of an email exchange with
guido, quoted here:

"the bug-report doesn't state whether python 2.0 worked and
2.1 didn't:
it also doesn't give enough info.

for all we know, he's calling close_request() himself or
request.close()
directly somewhere in his code, and hasn't told anybody,
which
is why he has to over-ride close_request() and tell it to do
nothing.
or he's closing the socket in the HandlerClass, in finish(),
or
something.

we just don't know.

either that, or his HandlerClass creates a socket once and
only
once, with the result that close_request() closes the one
socket, and he's _completely_ stuffed, then :)"



----------------------------------------------------------------------

Comment By: Luke Kenneth Casson Leighton (lkcl)
Date: 2001-04-26 04:11

Message:
Logged In: YES 
user_id=80200

hi there,

i'm the person who wrote the BaseServer class.  guido
contacted me about it: could you please send me or post here
a working test example that demonstrates the problem.

i assume, but you do not state, that you have tested your
MyHTTPServer with python 2.0, please let us know, here, if
that is a correct assumption.

thanks!

luke

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417845&group_id=5470


From noreply@sourceforge.net  Thu Apr 26 16:46:00 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 26 Apr 2001 08:46:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-418977 ] Access Violation in PyCell_Set
Message-ID: <E14snxw-0007BA-00@usw-sf-web3.sourceforge.net>

Bugs item #418977, was updated on 2001-04-25 15:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418977&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Access Violation in PyCell_Set

Initial Comment:
While stepping through a program using the Pythonwin 
debugger, I got an access violation which appears to 
be taking place in PyCell_Set (I'm not using the debug 
libraries).  Specifically, it appears that the op 
parameter is NULL, so the PyCell_Check(op) results in 
the AV.  I believe the call stack at this point was:

  PyCell_Set
  dict_to_map
  PyFrame_LocalsToFast (line 366 of frameobject.c?)
  call_trace
  SET_LINENO (case of eval_code2)

Please let me know if it would be helpful to see the 
python file I was stepping through and I'll upload it.


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2001-04-26 08:46

Message:
Logged In: YES 
user_id=21627

It turns out that the error is caused by the tracing. The
example t2.py will cause this error in Python 2.1 even
without running under a debugger.

----------------------------------------------------------------------

Comment By: Greg Chapman (glchapman)
Date: 2001-04-26 05:19

Message:
Logged In: YES 
user_id=86307

As requested, I've stripped down the code to a fairly 
simple test case.  There's a comment indicating the line on 
which the AV occurs (it occurs when you press the key to 
single step off that line to the next).  No AV occurs if 
you simply run the script under PythonWin.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-04-26 00:19

Message:
Logged In: YES 
user_id=21627

I think it would be definitely helpful to see the sources;
it would be even better if you could reduce them to a small
test case. Please attach them to this report.

----------------------------------------------------------------------

Comment By: Greg Chapman (glchapman)
Date: 2001-04-25 15:29

Message:
Logged In: YES 
user_id=86307

I apologize -- I forgot to add that I'm using Python 2.1 
final (binaries downloaded from Sourceforge) and the latest 
win32_all binaries under Windows 2000.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418977&group_id=5470


From noreply@sourceforge.net  Thu Apr 26 16:51:37 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 26 Apr 2001 08:51:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-418977 ] Access Violation in PyCell_Set
Message-ID: <E14so3N-000137-00@usw-sf-web1.sourceforge.net>

Bugs item #418977, was updated on 2001-04-25 15:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418977&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Access Violation in PyCell_Set

Initial Comment:
While stepping through a program using the Pythonwin 
debugger, I got an access violation which appears to 
be taking place in PyCell_Set (I'm not using the debug 
libraries).  Specifically, it appears that the op 
parameter is NULL, so the PyCell_Check(op) results in 
the AV.  I believe the call stack at this point was:

  PyCell_Set
  dict_to_map
  PyFrame_LocalsToFast (line 366 of frameobject.c?)
  call_trace
  SET_LINENO (case of eval_code2)

Please let me know if it would be helpful to see the 
python file I was stepping through and I'll upload it.


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2001-04-26 08:51

Message:
Logged In: YES 
user_id=21627

There is a patch for this bug in
http://sourceforge.net/tracker/index.php?func=detail&aid=419176&group_id=5470&atid=305470

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-04-26 08:46

Message:
Logged In: YES 
user_id=21627

It turns out that the error is caused by the tracing. The
example t2.py will cause this error in Python 2.1 even
without running under a debugger.

----------------------------------------------------------------------

Comment By: Greg Chapman (glchapman)
Date: 2001-04-26 05:19

Message:
Logged In: YES 
user_id=86307

As requested, I've stripped down the code to a fairly 
simple test case.  There's a comment indicating the line on 
which the AV occurs (it occurs when you press the key to 
single step off that line to the next).  No AV occurs if 
you simply run the script under PythonWin.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-04-26 00:19

Message:
Logged In: YES 
user_id=21627

I think it would be definitely helpful to see the sources;
it would be even better if you could reduce them to a small
test case. Please attach them to this report.

----------------------------------------------------------------------

Comment By: Greg Chapman (glchapman)
Date: 2001-04-25 15:29

Message:
Logged In: YES 
user_id=86307

I apologize -- I forgot to add that I'm using Python 2.1 
final (binaries downloaded from Sourceforge) and the latest 
win32_all binaries under Windows 2000.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418977&group_id=5470


From noreply@sourceforge.net  Thu Apr 26 17:25:01 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 26 Apr 2001 09:25:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-417418 ] Python 2.1 compile error on HPUX
Message-ID: <E14soZh-0001Zl-00@usw-sf-web1.sourceforge.net>

Bugs item #417418, was updated on 2001-04-19 11:51
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417418&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Townsend (rptownsend)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.1 compile error on HPUX

Initial Comment:
Compiling Python2.1 on HPUX11.0 gives the following 
errors:

cc: "Modules/termios.c", line 529: error 
1588: "VREPRINT" undefined.
cc: "Modules/termios.c", line 529: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 530: error 
1588: "VDISCARD" undefined.
cc: "Modules/termios.c", line 530: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 747: error 1588: "MDCD" 
undefined.
cc: "Modules/termios.c", line 747: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 750: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 753: error 1588: "MCTS" 
undefined.
cc: "Modules/termios.c", line 753: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 756: error 1588: "MDSR" 
undefined.
cc: "Modules/termios.c", line 756: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 759: error 1588: "MDTR" 
undefined.
cc: "Modules/termios.c", line 759: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 765: error 1588: "MRI" 
undefined.
cc: "Modules/termios.c", line 765: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 768: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 771: error 1588: "MRTS" 
undefined.
cc: "Modules/termios.c", line 771: error 1521: 
Incorrect initialization.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-04-26 09:25

Message:
Logged In: NO 

The build also failes with HPUX B.10.20 A

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417418&group_id=5470


From noreply@sourceforge.net  Thu Apr 26 18:32:31 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 26 Apr 2001 10:32:31 -0700
Subject: [Python-bugs-list] [ python-Bugs-419201 ] sys.setdefaultencoding() missing
Message-ID: <E14spd1-0002Is-00@usw-sf-web2.sourceforge.net>

Bugs item #419201, was updated on 2001-04-26 10:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=419201&group_id=5470

Category: Unicode
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Andreas Jung (ajung)
Assigned to: Nobody/Anonymous (nobody)
Summary: sys.setdefaultencoding() missing 

Initial Comment:
yetix@/usr/home/ajung/new/Python-2.1/Python(253)% python2.1
Python 2.1 (#1, Apr 24 2001, 19:56:49)
[GCC 2.95.3 20010315 (release)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.setdefaultencoding('iso-8859-1')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
AttributeError: 'sys' module has no attribute 'setdefaultencoding'

Where has it gone ?

Andreas

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=419201&group_id=5470


From noreply@sourceforge.net  Thu Apr 26 18:53:21 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 26 Apr 2001 10:53:21 -0700
Subject: [Python-bugs-list] [ python-Bugs-418898 ] __debug__ assignment via setattr
Message-ID: <E14spxB-0000PY-00@usw-sf-web3.sourceforge.net>

Bugs item #418898, was updated on 2001-04-25 11:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418898&group_id=5470

Category: Parser/Compiler
Group: None
Status: Open
Resolution: None
>Priority: 7
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Jeremy Hylton (jhylton)
Summary: __debug__ assignment via setattr

Initial Comment:
assignment to __debug__ via setattr does not raise a
warning:

Python 2.1 (#1, Apr 17 2001, 17:26:34)
[GCC 2.96 20000731 (Red Hat Linux 7.0)] on linux2
Type "copyright", "credits" or "license" for more
information
>>> import __builtin__
>>> __debug__
1
>>> setattr(__builtin__, '__debug__', 0)
>>> __debug__
0
>>> __debug__ = 1
<stdin>:0: SyntaxWarning: can not assign to __debug__
>>> 

As long as this behavior is going in, it ought to go in
wholesale.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418898&group_id=5470


From noreply@sourceforge.net  Thu Apr 26 18:54:03 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 26 Apr 2001 10:54:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-418977 ] Access Violation in PyCell_Set
Message-ID: <E14spxr-0000Qb-00@usw-sf-web3.sourceforge.net>

Bugs item #418977, was updated on 2001-04-25 15:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418977&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
>Priority: 8
Submitted By: Greg Chapman (glchapman)
>Assigned to: Jeremy Hylton (jhylton)
Summary: Access Violation in PyCell_Set

Initial Comment:
While stepping through a program using the Pythonwin 
debugger, I got an access violation which appears to 
be taking place in PyCell_Set (I'm not using the debug 
libraries).  Specifically, it appears that the op 
parameter is NULL, so the PyCell_Check(op) results in 
the AV.  I believe the call stack at this point was:

  PyCell_Set
  dict_to_map
  PyFrame_LocalsToFast (line 366 of frameobject.c?)
  call_trace
  SET_LINENO (case of eval_code2)

Please let me know if it would be helpful to see the 
python file I was stepping through and I'll upload it.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-04-26 08:51

Message:
Logged In: YES 
user_id=21627

There is a patch for this bug in
http://sourceforge.net/tracker/index.php?func=detail&aid=419176&group_id=5470&atid=305470

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-04-26 08:46

Message:
Logged In: YES 
user_id=21627

It turns out that the error is caused by the tracing. The
example t2.py will cause this error in Python 2.1 even
without running under a debugger.

----------------------------------------------------------------------

Comment By: Greg Chapman (glchapman)
Date: 2001-04-26 05:19

Message:
Logged In: YES 
user_id=86307

As requested, I've stripped down the code to a fairly 
simple test case.  There's a comment indicating the line on 
which the AV occurs (it occurs when you press the key to 
single step off that line to the next).  No AV occurs if 
you simply run the script under PythonWin.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-04-26 00:19

Message:
Logged In: YES 
user_id=21627

I think it would be definitely helpful to see the sources;
it would be even better if you could reduce them to a small
test case. Please attach them to this report.

----------------------------------------------------------------------

Comment By: Greg Chapman (glchapman)
Date: 2001-04-25 15:29

Message:
Logged In: YES 
user_id=86307

I apologize -- I forgot to add that I'm using Python 2.1 
final (binaries downloaded from Sourceforge) and the latest 
win32_all binaries under Windows 2000.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418977&group_id=5470


From noreply@sourceforge.net  Thu Apr 26 18:55:10 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 26 Apr 2001 10:55:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-418369 ] Typo in distutils (1.5 and 2.1)
Message-ID: <E14spyw-0000Rs-00@usw-sf-web3.sourceforge.net>

Bugs item #418369, was updated on 2001-04-23 14:08
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418369&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: A.M. Kuchling (akuchling)
Summary: Typo in distutils (1.5 and 2.1)

Initial Comment:
If README or README.txt are not specified in
doc_files, then bdist_rpm attempts to locate them. If
they exist, bdist_rpm adds them, erroneously, to
self.doc, instead of (correctly) to self.doc_files

self.doc does not exists, which then throws an
AttributeError

The offending code in Python 1.5 Distutils is
at or around line 192 of bdist_rpm.py

In Python 2.1 it is also at line 192 of bdist_rpm.py

Thanks!



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418369&group_id=5470


From noreply@sourceforge.net  Thu Apr 26 18:55:57 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 26 Apr 2001 10:55:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-417845 ] Python 2.1: SocketServer.ThreadingMixIn
Message-ID: <E14spzh-0000SR-00@usw-sf-web3.sourceforge.net>

Bugs item #417845, was updated on 2001-04-21 08:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417845&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: Python 2.1: SocketServer.ThreadingMixIn

Initial Comment:
SocketServer.ThreadingMixIn does not work properly
since it tries to close the socket of a request two
times.

Workaround for using SocketServer.ThreadingMixIn under
Python 2.1:

class MyThreadingHTTPServer(
  SocketServer.ThreadingMixIn,
  MyHTTPServer
):
  def close_request(self, request):
    pass



----------------------------------------------------------------------

Comment By: Luke Kenneth Casson Leighton (lkcl)
Date: 2001-04-26 05:41

Message:
Logged In: YES 
user_id=80200

follow-up.  i took a look at the differences between
SocketServer.py
in 2.0 and 2.1.  there is one small change by guido to the
ThreadingMixIn.process_request() function that calls
self.server_close() instead of explicitly calling
self.socket.close(),
where TCPServer.server_close() calls self.socket.close().

if mr anonymous (hi!) has over-ridden server_close() and
explicitly closes the *request* socket, then of course the
socket will get closed twice.

the rest of the code-mods is a straightforward code-shuffle
moving code from TCPServer into BaseServer: from
examining the diff, i really don't see how bypassing
close_request(), as shown above with the Workaround
in the original bug-report, will help: that will in fact
cause the request _never_ to be closed!

the rest of this report is part of an email exchange with
guido, quoted here:

"the bug-report doesn't state whether python 2.0 worked and
2.1 didn't:
it also doesn't give enough info.

for all we know, he's calling close_request() himself or
request.close()
directly somewhere in his code, and hasn't told anybody,
which
is why he has to over-ride close_request() and tell it to do
nothing.
or he's closing the socket in the HandlerClass, in finish(),
or
something.

we just don't know.

either that, or his HandlerClass creates a socket once and
only
once, with the result that close_request() closes the one
socket, and he's _completely_ stuffed, then :)"



----------------------------------------------------------------------

Comment By: Luke Kenneth Casson Leighton (lkcl)
Date: 2001-04-26 04:11

Message:
Logged In: YES 
user_id=80200

hi there,

i'm the person who wrote the BaseServer class.  guido
contacted me about it: could you please send me or post here
a working test example that demonstrates the problem.

i assume, but you do not state, that you have tested your
MyHTTPServer with python 2.0, please let us know, here, if
that is a correct assumption.

thanks!

luke

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417845&group_id=5470


From noreply@sourceforge.net  Thu Apr 26 18:58:17 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 26 Apr 2001 10:58:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-416526 ] Regular expression tests: SEGV on Mac OS
Message-ID: <E14sq1x-0000Uj-00@usw-sf-web3.sourceforge.net>

Bugs item #416526, was updated on 2001-04-16 14:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416526&group_id=5470

Category: Regular Expressions
Group: Platform-specific
Status: Open
Resolution: None
>Priority: 7
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Fredrik Lundh (effbot)
Summary: Regular expression tests: SEGV on Mac OS

Initial Comment:
The regular expression regression tests 'test_re' 
causes a SEGV failure on Mac OS X version 10.0.1 
when using Python 2.1c2 (and earlier). This is 
caused by the test trying to recurse 50,000 levels 
deep.

Workaround: A workaround is to limit how deep the 
regular expression library can recurse (this is 
already done for Win32). This can be achieved by 
changing file './Modules/_sre.c' using the following 
patch:

--- ./orig/_sre.c   Sun Apr 15 19:00:58 2001
+++ ./new/_sre.c    Mon Apr 16 21:39:29 2001
@@ -75,6 +75,9 @@
    Win64 (MS_WIN64), Linux64 (__LP64__), 
Monterey (64-bit AIX) (_LP64) */
 /* FIXME: maybe the limit should be 40000 / 
sizeof(void*) ? */
 #define USE_RECURSION_LIMIT 7500
+#elif defined(__APPLE_CC__)
+/* Apple 'cc' compiler eg. for Mac OS X */
+#define USE_RECURSION_LIMIT 4000
 #else
 #define USE_RECURSION_LIMIT 10000
 #endif


----------------------------------------------------------------------

Comment By: Dan Wolfe (dkwolfe)
Date: 2001-04-17 16:52

Message:
Logged In: YES 
user_id=80173

Instead of relying on a compiler variable, we should probably 
set a environment variable as part of the ./configure and use 
that to determine when to reduce the USE_RECURSION_LIMIT.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416526&group_id=5470


From noreply@sourceforge.net  Thu Apr 26 19:00:24 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 26 Apr 2001 11:00:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-416508 ] Reproductible parser crash with os.fdopen()
Message-ID: <E14sq40-0000Wd-00@usw-sf-web3.sourceforge.net>

Bugs item #416508, was updated on 2001-04-16 13:08
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416508&group_id=5470

>Category: Extension Modules
>Group: Not a Bug
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Reproductible parser crash with os.fdopen()

Initial Comment:
Hi there!

Just found this bugs, fully reproductible.
They are all the similar, derived from os.fdopen() as you will see.


Copy/paste is much better than any words, so (note: ';' is my bash prompt):

; python
Python 2.0 (#2, Feb  3 2001, 18:06:18)
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> import os
>>> infd = os.fdopen(0)
>>> infd = os.fdopen(0)
>>>
;

You can put it in a try..except, changing fdopen parameters, etc; but the same
happens.
A weird thing also happens if you try to do it with fd 1 instead of 0, it seems
to hung expecting for input... but ^C gives KeyboardInterrupt, see:

; python
Python 2.0 (#2, Feb  3 2001, 18:06:18)
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> import os
>>> infd = os.fdopen(1)
>>> infd = os.fdopen(0)
		<--- ^C, then:
KeyboardInterrupt
		<--- ^C again
KeyboardInterrupt
		<--- ^D (EOF), and got prompt.
;

The same if you try to fdopen(2) any number of times (as opposed with regular
files, when you can do it only two times before the exception, see below), and
then fdopen(1) _TWICE_; except that ^C has no effect here.


Now... if we try with a regular file:

>>> import os
>>> fd = open('/var/log/messages')
>>> fd.fileno()
>>> 3
>>> infd = os.fdopen(3)		# first call, ok
>>> infd = os.fdopen(3)		# second call, ok
>>> infd = os.fdopen(3)		# third call, exception
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   OSError: [Errno 9] Bad file descriptor
>>> infd = os.fdopen(3)
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   OSError: [Errno 9] Bad file descriptor
>>>

And the interpreter is still fully functional, i can even del(infd)
The behaviour with fd 2 is also sane.

Well, any questions or testing you need, just ask me at
albertogli@altavista.net.

Thanks¸
		Alberto



----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2001-04-16 14:02

Message:
Logged In: YES 
user_id=6656

in the first example, the second assignment to infd deletes 
the file object which closes fd 0, i.e. standard input, so 
python thinks you're done and exits.  this only affects 
interactive sessions.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416508&group_id=5470


From noreply@sourceforge.net  Thu Apr 26 19:01:01 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 26 Apr 2001 11:01:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-416943 ] 2.1 segfaults on pydoc HTTP
Message-ID: <E14sq4b-0000X3-00@usw-sf-web3.sourceforge.net>

Bugs item #416943, was updated on 2001-04-17 20:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416943&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
>Priority: 7
Submitted By: Andy Dustman (adustman)
>Assigned to: Ka-Ping Yee (ping)
Summary: 2.1 segfaults on pydoc HTTP 

Initial Comment:
Platform info: 2.1 final, Red Hat 7.1 beta for i386.

Run pydoc -p xxx. Pull up info on a C extension module.
Now
recompile that module so that it changes in a
significant way.
Try to pull it up again and segfault occurs.

#0  0x0808db62 in PyString_FromString (str=0x0) at
Objects/stringobject.c:89
84	}
85	
86	PyObject *
87	PyString_FromString(const char *str)
88	{
89		register size_t size = strlen(str);
90		register PyStringObject *op;
91		if (size > INT_MAX) {
92			PyErr_SetString(PyExc_OverflowError,
93				"string is too long for a Python string");
(gdb) frame 1
#1  0x0808d003 in PyObject_GetAttrString (v=0x8164ec0, 
    name=0x80c888c "__name__") at Objects/object.c:1002
1002			return (*v->ob_type->tp_getattr)(v, name);
(gdb) list
997				     v->ob_type->tp_name,
998				     name);
999			return NULL;
1000		}
1001		else {
1002			return (*v->ob_type->tp_getattr)(v, name);
1003		}
1004	}
1005	
1006	int
(gdb) print (*v->ob_type->tp_getattr)
$1 = {PyObject *()} 0x808b3c8 <meth_getattr>
$6 = {ob_refcnt = 3, ob_type = 0x80bb920, ob_size = 0, 
  tp_name = 0x80aa94e "builtin_function_or_method",
tp_basicsize = 16, 
  tp_itemsize = 0, tp_dealloc = 0x808b390
<meth_dealloc>, tp_print = 0, 
  tp_getattr = 0x808b3c8 <meth_getattr>, tp_setattr =
0, 
  tp_compare = 0x808b550 <meth_compare>, tp_repr =
0x808b4ec <meth_repr>, 
  tp_as_number = 0x0, tp_as_sequence = 0x0,
tp_as_mapping = 0x0, 
  tp_hash = 0x808b5a4 <meth_hash>, tp_call = 0, tp_str
= 0, tp_getattro = 0, 
  tp_setattro = 0, tp_as_buffer = 0x0, tp_flags = 0,
tp_doc = 0x0, 
  tp_traverse = 0, tp_clear = 0, tp_richcompare = 0,
tp_weaklistoffset = 0}
(gdb) print ((PyCFunctionObject *)v)->m_ml
$7 = (PyMethodDef *) 0x401c7ecc
(gdb) print
$8 = 0x0
(gdb) list meth_getattr
67		free_list = m;
68	}
69	
70	static PyObject *
71	meth_getattr(PyCFunctionObject *m, char *name)
72	{
73		if (strcmp(name, "__name__") == 0) {
74			return PyString_FromString(m->m_ml->ml_name);
75		}
76		if (strcmp(name, "__doc__") == 0) {

((PyCFunctionObject *)v)->m_ml->ml_name ==
m->m_ml->ml_name == NULL. From what I can tell, all
members of v->m_ml are NULL. Note that name is getting
smashed somewhere, probably after the call at
Objects/object.c:1002.

Feel free to contact me for further information if
necessary. Complete backtrace attached.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416943&group_id=5470


From noreply@sourceforge.net  Thu Apr 26 19:01:48 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 26 Apr 2001 11:01:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-416944 ] 2.0: cum sympt; w/gdb bktr; OBSD2.8.
Message-ID: <E14sq5M-0000Xz-00@usw-sf-web3.sourceforge.net>

Bugs item #416944, was updated on 2001-04-17 21:03
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416944&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
>Priority: 3
Submitted By: Brad Allen (valaulmo)
>Assigned to: Martin v. Löwis (loewis)
Summary: 2.0: cum sympt; w/gdb bktr; OBSD2.8.

Initial Comment:
Reverted to Python 2.0 + all patches on patch pages,
still with OpenBSD 2.8.  Only non-default module set is
zlib (needed for Mojo Nation according to the docs). 
System is Pentium 133MHz.

Ok, I'm getting better at this now.  This time, I ran
GDB on it, since I noticed that one of the bugs may
have cumulative dependent symptoms.  Also, I'm typing
this bug report into the web browser so that it wraps
correctly (I'll cross my fingers that it doesn't crash
though; that's why I prefer Emacs; I suppose I could
try SSL W3 Emacs but that is hard; not now.)

Here is the gdb output where it did die:

[... lots of tests ...]
test_long

Program received signal SIGSEGV, Segmentation fault.
0x4017bc2f in _thread_machdep_switch ()
(gdb) bt
#0  0x4017bc2f in _thread_machdep_switch ()
#1  0x401c8308 in _sigq_check_reqd ()
#2  0x4017ba66 in _thread_kern_sig_undefer ()
#3  0x4017eb68 in pthread_cond_signal ()
#4  0x1510d in PyThread_release_lock (lock=0x27c320) at
thread_pthread.h:344
#5  0x43006 in eval_code2 (co=0x3c7d80,
globals=0x3c104c, locals=0x0, 
    args=0x25cd58, argcount=2, kws=0x25cd60, kwcount=0,
defs=0x0, defcount=0, 
    owner=0x0) at ceval.c:617
#6  0x450b3 in eval_code2 (co=0x3c7f40,
globals=0x3c104c, locals=0x0, 
    args=0x1a4d60, argcount=1, kws=0x1a4d64, kwcount=0,
defs=0x0, defcount=0, 
    owner=0x0) at ceval.c:1850
#7  0x450b3 in eval_code2 (co=0x4221c0,
globals=0x3c104c, locals=0x0, 
    args=0x39a140, argcount=0, kws=0x39a140, kwcount=0,
defs=0x29c1b8, 
    defcount=1, owner=0x0) at ceval.c:1850
#8  0x450b3 in eval_code2 (co=0x41c900,
globals=0x3c104c, locals=0x3c104c, 
    args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0,
defcount=0, owner=0x0)
    at ceval.c:1850
#9  0x42625 in PyEval_EvalCode (co=0x41c900,
globals=0x3c104c, locals=0x3c104c)
    at ceval.c:319
#10 0xacff in PyImport_ExecCodeModuleEx
(name=0xdfbfd180 "test_long", 
    co=0x41c900, pathname=0xdfbfcce0
"./Lib/test/test_long.py") at import.c:495
#11 0xb30a in load_source_module (name=0xdfbfd180
"test_long", 
    pathname=0xdfbfcce0 "./Lib/test/test_long.py",
fp=0x401fa83c)
    at import.c:758
#12 0xbc23 in load_module (name=0xdfbfd180 "test_long",
fp=0x401fa83c, 
    buf=0xdfbfcce0 "./Lib/test/test_long.py", type=1)
at import.c:1227
#13 0xc8fb in import_submodule (mod=0x1140fc,
subname=0xdfbfd180 "test_long", 
    fullname=0xdfbfd180 "test_long") at import.c:1755
#14 0xc4ca in load_next (mod=0x1140fc, altmod=0x1140fc,
p_name=0xdfbfd58c, 
    buf=0xdfbfd180 "test_long", p_buflen=0xdfbfd17c) at
import.c:1611
#15 0xc142 in import_module_ex (name=0x0,
globals=0x14624c, locals=0x1a538c, 
    fromlist=0x29c02c) at import.c:1462
---Type <return> to continue, or q <return> to quit---
#16 0xc277 in PyImport_ImportModuleEx (name=0x19f0d4
"test_long", 
    globals=0x14624c, locals=0x1a538c,
fromlist=0x29c02c) at import.c:1503
#17 0x3ce47 in builtin___import__ (self=0x0,
args=0x3b198c) at bltinmodule.c:31
#18 0x4668d in call_builtin (func=0x141070,
arg=0x3b198c, kw=0x0)
    at ceval.c:2650
#19 0x46507 in PyEval_CallObjectWithKeywords
(func=0x141070, arg=0x3b198c, 
    kw=0x0) at ceval.c:2618
#20 0x453ac in eval_code2 (co=0x1cc240,
globals=0x14624c, locals=0x0, 
    args=0x15fdcc, argcount=5, kws=0x15fde0, kwcount=0,
defs=0x1c4738, 
    defcount=1, owner=0x0) at ceval.c:1951
#21 0x450b3 in eval_code2 (co=0x1c9f00,
globals=0x14624c, locals=0x0, 
    args=0x140f44, argcount=0, kws=0x140f44, kwcount=0,
defs=0x18d918, 
    defcount=10, owner=0x0) at ceval.c:1850
#22 0x450b3 in eval_code2 (co=0x1c9f80,
globals=0x14624c, locals=0x14624c, 
    args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0,
defcount=0, owner=0x0)
    at ceval.c:1850
#23 0x42625 in PyEval_EvalCode (co=0x1c9f80,
globals=0x14624c, locals=0x14624c)
    at ceval.c:319
#24 0x1272f in run_node (n=0x155400, 
    filename=0xdfbfdb5a "./Lib/test/regrtest.py",
globals=0x14624c, 
    locals=0x14624c) at pythonrun.c:886
#25 0x126e8 in run_err_node (n=0x155400, 
    filename=0xdfbfdb5a "./Lib/test/regrtest.py",
globals=0x14624c, 
    locals=0x14624c) at pythonrun.c:874
#26 0x126c4 in PyRun_FileEx (fp=0x401fa7e4, 
    filename=0xdfbfdb5a "./Lib/test/regrtest.py",
start=257, globals=0x14624c, 
    locals=0x14624c, closeit=1) at pythonrun.c:866
#27 0x11cfe in PyRun_SimpleFileEx (fp=0x401fa7e4, 
    filename=0xdfbfdb5a "./Lib/test/regrtest.py",
closeit=1) at pythonrun.c:579
#28 0x118f3 in PyRun_AnyFileEx (fp=0x401fa7e4, 
    filename=0xdfbfdb5a "./Lib/test/regrtest.py",
closeit=1) at pythonrun.c:459
#29 0x24bb in Py_Main (argc=2, argv=0xdfbfdac8) at
main.c:289
---Type <return> to continue, or q <return> to quit---
#30 0x17b5 in main (argc=4, argv=0xdfbfdac8) at
python.c:10
(gdb) 

Once again, I will attach the config.* (config.cache,
etc.) to this in a file.

Brad Allen <Ulmo@Q.Net>

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-04-24 10:44

Message:
Logged In: YES 
user_id=21627

To me, this likes like a bug in the multithread support of
your operating system. To work around this bug, you should
configure python with --disable-threads.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416944&group_id=5470


From noreply@sourceforge.net  Thu Apr 26 19:02:19 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 26 Apr 2001 11:02:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-416462 ] .pyo files missing in mimetypes.py?
Message-ID: <E14sq5r-0000YP-00@usw-sf-web3.sourceforge.net>

Bugs item #416462, was updated on 2001-04-16 09:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416462&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: David M. Beazley (beazley)
>Assigned to: Barry Warsaw (bwarsaw)
Summary: .pyo files missing in mimetypes.py?

Initial Comment:
This is a very minor nit caught by Paul Dubois in
reviewing 
Python Essential Reference 2nd Ed.   

The .py and .pyc files are both recognized in the
mimetypes module as :

    '.py': 'text/x-python',
    '.pyc': 'application/x-python-code',

However, no entry appears for '.pyo' files.    Should
they also appear?
    
    '.pyo' : 'application/x-python-code',

Admittedly it's pretty minor---I don't think I would
have noticed this had it not been pointed out.

-- Dave
 

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416462&group_id=5470


From noreply@sourceforge.net  Thu Apr 26 19:02:44 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 26 Apr 2001 11:02:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-417178 ] uu.py doesn't close in_file on exception
Message-ID: <E14sq6G-0000Yg-00@usw-sf-web3.sourceforge.net>

Bugs item #417178, was updated on 2001-04-18 15:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417178&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Tim Peters (tim_one)
Summary: uu.py doesn't close in_file on exception

Initial Comment:
When decoding a uu-encoded file with uu.decode(), the 
given in_file is not closed before a uu.Error is 
raised.

This leads to problems on Win32 when trying to 
os.remove() the file after the exception was raised, 
because the permission to remove the file is denied.

Maybe the same problem is present for out_file.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417178&group_id=5470


From noreply@sourceforge.net  Thu Apr 26 18:57:38 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 26 Apr 2001 10:57:38 -0700
Subject: [Python-bugs-list] [ python-Bugs-417030 ] print '%*s' fails for unicode string
Message-ID: <E14sq1K-0000U3-00@usw-sf-web3.sourceforge.net>

Bugs item #417030, was updated on 2001-04-18 05:53
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417030&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
>Priority: 6
Submitted By: Barry Alan Scott (barry-scott)
>Assigned to: M.-A. Lemburg (lemburg)
Summary: print '%*s' fails for unicode string

Initial Comment:
Python 2.0 (#8, Dec 13 2000, 09:47:07) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
>>> print '%*s' % (7,u'fred')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: * wants int
>>>


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417030&group_id=5470


From noreply@sourceforge.net  Thu Apr 26 19:03:30 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 26 Apr 2001 11:03:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-416508 ] Reproductible parser crash with os.fdopen()
Message-ID: <E14sq70-0000ZY-00@usw-sf-web3.sourceforge.net>

Bugs item #416508, was updated on 2001-04-16 13:08
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416508&group_id=5470

Category: Extension Modules
Group: Not a Bug
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Reproductible parser crash with os.fdopen()

Initial Comment:
Hi there!

Just found this bugs, fully reproductible.
They are all the similar, derived from os.fdopen() as you will see.


Copy/paste is much better than any words, so (note: ';' is my bash prompt):

; python
Python 2.0 (#2, Feb  3 2001, 18:06:18)
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> import os
>>> infd = os.fdopen(0)
>>> infd = os.fdopen(0)
>>>
;

You can put it in a try..except, changing fdopen parameters, etc; but the same
happens.
A weird thing also happens if you try to do it with fd 1 instead of 0, it seems
to hung expecting for input... but ^C gives KeyboardInterrupt, see:

; python
Python 2.0 (#2, Feb  3 2001, 18:06:18)
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> import os
>>> infd = os.fdopen(1)
>>> infd = os.fdopen(0)
		<--- ^C, then:
KeyboardInterrupt
		<--- ^C again
KeyboardInterrupt
		<--- ^D (EOF), and got prompt.
;

The same if you try to fdopen(2) any number of times (as opposed with regular
files, when you can do it only two times before the exception, see below), and
then fdopen(1) _TWICE_; except that ^C has no effect here.


Now... if we try with a regular file:

>>> import os
>>> fd = open('/var/log/messages')
>>> fd.fileno()
>>> 3
>>> infd = os.fdopen(3)		# first call, ok
>>> infd = os.fdopen(3)		# second call, ok
>>> infd = os.fdopen(3)		# third call, exception
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   OSError: [Errno 9] Bad file descriptor
>>> infd = os.fdopen(3)
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   OSError: [Errno 9] Bad file descriptor
>>>

And the interpreter is still fully functional, i can even del(infd)
The behaviour with fd 2 is also sane.

Well, any questions or testing you need, just ask me at
albertogli@altavista.net.

Thanks¸
		Alberto



----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2001-04-16 14:02

Message:
Logged In: YES 
user_id=6656

in the first example, the second assignment to infd deletes 
the file object which closes fd 0, i.e. standard input, so 
python thinks you're done and exits.  this only affects 
interactive sessions.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416508&group_id=5470


From noreply@sourceforge.net  Thu Apr 26 19:03:16 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 26 Apr 2001 11:03:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-415950 ] Problem with SSL and socketmodule
Message-ID: <E14sq6m-0000ZP-00@usw-sf-web3.sourceforge.net>

Bugs item #415950, was updated on 2001-04-13 10:55
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=415950&group_id=5470

Category: Extension Modules
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
>Assigned to: Moshe Zadka (moshez)
Summary: Problem with SSL and socketmodule

Initial Comment:
Subject: [Python-Dev] Problem with SSL and socketmodule
on Debian Potato?
From: Neil Schemenauer <nas@python.ca>
To: python-dev@python.org
Cc: Moshe Zadka <moshez@zadka.site.co.il>
Date: Thu, 12 Apr 2001 14:39:37 -0700

Fresh CVS tree:

Python 2.1c1 (#2, Apr 12 2001, 17:23:20) 
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import socket
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File
"/scratch/nascheme/py_cvs/dist/src/Lib/socket.py", line
41, in ?
    from _socket import *
ImportError:
/scratch/nascheme/py_cvs/dist/src/linux/build/lib.linux-i686-2.1/_socket.so:
undefined symbol: RAND_status

socketmodule is linked thusly:

gcc -shared build/temp.linux-i686-2.1/socketmodule.o
-L/usr/local/lib -lssl -lcrypto -o
build/lib.linux-i686-2.1/_socket.so

The SSL package is:

    libssl09-dev 0.9.4-5

I've no time to dig into the details right now but I
should have
time tonight.  I will be gone on holiday tomorrow.

  Neil

_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-13 13:56

Message:
Logged In: YES 
user_id=6380

I've checked in a tentative fix, provided by Martin von
Loewis.

I'm keeping this bug report open because Moshe thought that
Martin's fix was broken, but failed to give a better fix
that Martin could agree to.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=415950&group_id=5470


From noreply@sourceforge.net  Thu Apr 26 19:03:47 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 26 Apr 2001 11:03:47 -0700
Subject: [Python-bugs-list] [ python-Bugs-416670 ] MatchObjects not deepcopy()able
Message-ID: <E14sq7H-0000Zk-00@usw-sf-web3.sourceforge.net>

Bugs item #416670, was updated on 2001-04-17 05:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416670&group_id=5470

Category: Regular Expressions
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Henning Thielemann (amigalemming)
>Assigned to: Fredrik Lundh (effbot)
Summary: MatchObjects not deepcopy()able

Initial Comment:

In the re-Module which come with Python version 2.0
(Nov 28 11:10 re.py) the created MatchObjects cannot be
copied with a deepcopy(). Switching back to the old
"pre.py" as proposed in "re.py" makes everything work
ok.



----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-04-26 01:01

Message:
Logged In: YES 
user_id=21627

A patch for that problem is in
http://sourceforge.net/tracker/index.php?func=detail&aid=419070&group_id=5470&atid=305470

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416670&group_id=5470


From noreply@sourceforge.net  Thu Apr 26 19:22:28 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 26 Apr 2001 11:22:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-419213 ] win32all: combrowse.py causes crash/`95
Message-ID: <E14sqPM-0000pS-00@usw-sf-web3.sourceforge.net>

Bugs item #419213, was updated on 2001-04-26 11:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=419213&group_id=5470

Category: Extension Modules
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Douglas Shawhan (lysdexia)
Assigned to: Nobody/Anonymous (nobody)
Summary: win32all: combrowse.py causes crash/`95

Initial Comment:
Attempting to run 
C:\python20\win32com\client\combrowse.py causes a 
stack fault:

-----begin pain-------

PYTHON caused a stack fault in module MSVCRT.DLL at 
016f:78001169.
Registers:
EAX=5f401151 CS=016f EIP=78001169 EFLGS=00010246
EBX=00542048 SS=0177 ESP=00542000 EBP=0054200c
ECX=00542048 DS=0177 ESI=005420f2 FS=470f
EDX=005420c2 ES=0177 EDI=00540000 GS=0000
Bytes at CS:EIP:
50 c3 8b 44 24 04 66 8b 08 66 85 c9 74 0b 66 3b 
Stack dump:
0054202c 5f492d87 ffffffff 005420a0 5f4012da 00000000 
1e44a1f1 00000cac 005420f2 00000000 00542048 00542090 
1e45ac48 ffffffff 1e436ff7 00542048 

-------end pain-------

Any attempt to run combrowse.py again required hard 
reboot.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=419213&group_id=5470


From noreply@sourceforge.net  Thu Apr 26 20:05:59 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 26 Apr 2001 12:05:59 -0700
Subject: [Python-bugs-list] [ python-Bugs-416943 ] 2.1 segfaults on pydoc HTTP
Message-ID: <E14sr5T-0004KN-00@usw-sf-web1.sourceforge.net>

Bugs item #416943, was updated on 2001-04-17 20:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416943&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 7
Submitted By: Andy Dustman (adustman)
Assigned to: Ka-Ping Yee (ping)
Summary: 2.1 segfaults on pydoc HTTP 

Initial Comment:
Platform info: 2.1 final, Red Hat 7.1 beta for i386.

Run pydoc -p xxx. Pull up info on a C extension module.
Now
recompile that module so that it changes in a
significant way.
Try to pull it up again and segfault occurs.

#0  0x0808db62 in PyString_FromString (str=0x0) at
Objects/stringobject.c:89
84	}
85	
86	PyObject *
87	PyString_FromString(const char *str)
88	{
89		register size_t size = strlen(str);
90		register PyStringObject *op;
91		if (size > INT_MAX) {
92			PyErr_SetString(PyExc_OverflowError,
93				"string is too long for a Python string");
(gdb) frame 1
#1  0x0808d003 in PyObject_GetAttrString (v=0x8164ec0, 
    name=0x80c888c "__name__") at Objects/object.c:1002
1002			return (*v->ob_type->tp_getattr)(v, name);
(gdb) list
997				     v->ob_type->tp_name,
998				     name);
999			return NULL;
1000		}
1001		else {
1002			return (*v->ob_type->tp_getattr)(v, name);
1003		}
1004	}
1005	
1006	int
(gdb) print (*v->ob_type->tp_getattr)
$1 = {PyObject *()} 0x808b3c8 <meth_getattr>
$6 = {ob_refcnt = 3, ob_type = 0x80bb920, ob_size = 0, 
  tp_name = 0x80aa94e "builtin_function_or_method",
tp_basicsize = 16, 
  tp_itemsize = 0, tp_dealloc = 0x808b390
<meth_dealloc>, tp_print = 0, 
  tp_getattr = 0x808b3c8 <meth_getattr>, tp_setattr =
0, 
  tp_compare = 0x808b550 <meth_compare>, tp_repr =
0x808b4ec <meth_repr>, 
  tp_as_number = 0x0, tp_as_sequence = 0x0,
tp_as_mapping = 0x0, 
  tp_hash = 0x808b5a4 <meth_hash>, tp_call = 0, tp_str
= 0, tp_getattro = 0, 
  tp_setattro = 0, tp_as_buffer = 0x0, tp_flags = 0,
tp_doc = 0x0, 
  tp_traverse = 0, tp_clear = 0, tp_richcompare = 0,
tp_weaklistoffset = 0}
(gdb) print ((PyCFunctionObject *)v)->m_ml
$7 = (PyMethodDef *) 0x401c7ecc
(gdb) print
$8 = 0x0
(gdb) list meth_getattr
67		free_list = m;
68	}
69	
70	static PyObject *
71	meth_getattr(PyCFunctionObject *m, char *name)
72	{
73		if (strcmp(name, "__name__") == 0) {
74			return PyString_FromString(m->m_ml->ml_name);
75		}
76		if (strcmp(name, "__doc__") == 0) {

((PyCFunctionObject *)v)->m_ml->ml_name ==
m->m_ml->ml_name == NULL. From what I can tell, all
members of v->m_ml are NULL. Note that name is getting
smashed somewhere, probably after the call at
Objects/object.c:1002.

Feel free to contact me for further information if
necessary. Complete backtrace attached.

----------------------------------------------------------------------

>Comment By: Andy Dustman (adustman)
Date: 2001-04-26 12:05

Message:
Logged In: YES 
user_id=71372

...and just to clarify, I don't think this is a pydoc bug.
It seems to be related to Python internals. The module used
in this case is MySQLdb
(http://sourceforge.net/projects/mysql-python). It could be
related to that module, but I really don't think so.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416943&group_id=5470


From noreply@sourceforge.net  Thu Apr 26 20:18:54 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 26 Apr 2001 12:18:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-417176 ] MultiFile.read() includes CRLF boundary
Message-ID: <E14srHy-0001cJ-00@usw-sf-web3.sourceforge.net>

Bugs item #417176, was updated on 2001-04-18 15:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417176&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martijn Pieters (mjpieters)
>Assigned to: Barry Warsaw (bwarsaw)
Summary: MultiFile.read() includes CRLF boundary

Initial Comment:
multifile.MultiFile.readlines()and .read() will return 
a body of a multipart message including the line 
delimiter that is to be regarded part of the boundary.

In a partial multipart message like:

--BoundaryHere
Content-Type: text/plain

1
2
3
4
--BoundaryHere

the message within the delimiters does not include the 
final line delimiter (CRLF or LF or whatnot) after the 
line reading '4'; it is considered part of the 
boundary. MultiFile however, returns it as part of the 
body.

See RFC2046 section 5.1.1. In the usual text 
formatting of the RFC, you'll find the definition and 
explanation in the first two paragraphs of page 19.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417176&group_id=5470


From noreply@sourceforge.net  Thu Apr 26 20:19:04 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 26 Apr 2001 12:19:04 -0700
Subject: [Python-bugs-list] [ python-Bugs-419213 ] win32all: combrowse.py causes crash/`95
Message-ID: <E14srI8-0001cn-00@usw-sf-web3.sourceforge.net>

Bugs item #419213, was updated on 2001-04-26 11:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=419213&group_id=5470

Category: Extension Modules
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Douglas Shawhan (lysdexia)
>Assigned to: Tim Peters (tim_one)
Summary: win32all: combrowse.py causes crash/`95

Initial Comment:
Attempting to run 
C:\python20\win32com\client\combrowse.py causes a 
stack fault:

-----begin pain-------

PYTHON caused a stack fault in module MSVCRT.DLL at 
016f:78001169.
Registers:
EAX=5f401151 CS=016f EIP=78001169 EFLGS=00010246
EBX=00542048 SS=0177 ESP=00542000 EBP=0054200c
ECX=00542048 DS=0177 ESI=005420f2 FS=470f
EDX=005420c2 ES=0177 EDI=00540000 GS=0000
Bytes at CS:EIP:
50 c3 8b 44 24 04 66 8b 08 66 85 c9 74 0b 66 3b 
Stack dump:
0054202c 5f492d87 ffffffff 005420a0 5f4012da 00000000 
1e44a1f1 00000cac 005420f2 00000000 00542048 00542090 
1e45ac48 ffffffff 1e436ff7 00542048 

-------end pain-------

Any attempt to run combrowse.py again required hard 
reboot.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=419213&group_id=5470


From noreply@sourceforge.net  Thu Apr 26 20:19:37 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 26 Apr 2001 12:19:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-417949 ] Missing #defines for Borland compiler
Message-ID: <E14srIf-0001dF-00@usw-sf-web3.sourceforge.net>

Bugs item #417949, was updated on 2001-04-21 19:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417949&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Stephen Hansen (ixokai)
>Assigned to: Tim Peters (tim_one)
Summary: Missing #defines for Borland compiler

Initial Comment:
Under Python2.1:

PC/config.h globally defines HAVE_SYS_UTIME_H at ~line 
597, but the Borland C++Builder/compiler needs 
HAVE_UTIME_H instead; this is used in other files 
(posixmodule.c, specifically) to #include <utime.h> 
instead of <sys/utime.h>.



----------------------------------------------------------------------

Comment By: Stephen Hansen (ixokai)
Date: 2001-04-21 20:09

Message:
Logged In: YES 
user_id=200343

Additionally, Borland also requires a '#define 
HAVE_DIRENT_H' in the config.h file to get BCC to finally 
compile through Posixmodule before it crashes into 
timemodule. *grin* :)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417949&group_id=5470


From noreply@sourceforge.net  Thu Apr 26 20:19:37 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 26 Apr 2001 12:19:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-417802 ] mode_t not appropriate for chmod in BCC
Message-ID: <E14srIf-0001dV-00@usw-sf-web3.sourceforge.net>

Bugs item #417802, was updated on 2001-04-20 22:49
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417802&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Stephen Hansen (ixokai)
>Assigned to: Tim Peters (tim_one)
Summary: mode_t not appropriate for chmod in BCC

Initial Comment:
In reference to the 'chmod' definition in 
posixmodule.c (~line 155). Under Borland 
C++5.5, 'mode_t' is defined in sys/types.h as a short, 
and yet io.h defines 'chmod' as taking char* and an 
int, so the compiler gives an error of, "Type mismatch 
in redeclaration of 'chmod'" here.

Since sys/types.h is going to redefine mode_t after 
anything we put into pyport/config, the only way I can 
see to fix this would be to put an #ifdef __BORLANDC__ 
in there.

Now, to go fix all the other errors BC is spitting out 
in that file. <le sigh>

----------------------------------------------------------------------

Comment By: Stephen Hansen (ixokai)
Date: 2001-04-21 19:36

Message:
Logged In: YES 
user_id=200343

The below is Python 2.1final, btw. I keep forgetting to 
include that.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417802&group_id=5470


From noreply@sourceforge.net  Thu Apr 26 20:19:37 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 26 Apr 2001 12:19:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-417952 ] Borland spells timezone as _timezone
Message-ID: <E14srIf-0001dN-00@usw-sf-web3.sourceforge.net>

Bugs item #417952, was updated on 2001-04-21 20:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417952&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Stephen Hansen (ixokai)
>Assigned to: Tim Peters (tim_one)
Summary: Borland spells timezone as _timezone

Initial Comment:
Borland (to be difficult, I 'spose :)) 
spells 'timezone' 'daylight' and 'tzname' with an 
underscore at the begenning. These errors are in the 
inittime function.

The fix I used on my machine (just until I see how 
ya'll do it officially) was to add the following lines 
under '#include <time.h>' in pyport.h:

#ifdef __BORLANDC__
#  define timezone _timezone
#  define daylight _daylight
#  define tzname _tzname
#endif

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417952&group_id=5470


From noreply@sourceforge.net  Thu Apr 26 22:51:37 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 26 Apr 2001 14:51:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-416677 ] re.groups misbehaviour
Message-ID: <E14stfl-0005r6-00@usw-sf-web2.sourceforge.net>

Bugs item #416677, was updated on 2001-04-17 06:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416677&group_id=5470

Category: Regular Expressions
>Group: Not a Bug
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Andreas Jung (ajung)
Assigned to: Fredrik Lundh (effbot)
Summary: re.groups misbehaviour

Initial Comment:
import re
 
pat = "[0-9][0-9]"
s="22 the quick 100 brown fox jumps 44 over the xx lazy 33 dog"
 
r = re.compile(pat)
mo = r.match(s)
print mo.groups()
print mo.group(0)

I expected that mo.groups() returns for this testcase a tuple with  3 elements ('22','44','33)
but instead it returns (). mo.group(0) returns as expected '22'.
Is this a bug or an error in the documentation ?



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-04-18 16:32

Message:
Logged In: YES 
user_id=31435

Assigned to effbot for final disposition.

AFAICT, everything here is working as designed and as 
documented.  Since you have no parentheses in your regexp, 
the only group that exists is the implicit group 0, 
representing the whole match.  .groups() is documented as 
returning all the groups in the match "from 1 up to however 
many groups are in the pattern".  Since there are no groups 
with ordinal larger than 0, that's an empty set, so 
mo.groups() returns an empty tuple.

Sounds more like you want re.findall().  But in that case, 
it would return ['22', '10', '44', '33']:  there's nothing 
in your regexp to prevent it from matching the "10" at the 
start of "100".


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416677&group_id=5470


From noreply@sourceforge.net  Thu Apr 26 22:52:13 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 26 Apr 2001 14:52:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-419213 ] win32all: combrowse.py causes crash/`95
Message-ID: <E14stgL-0007AC-00@usw-sf-web1.sourceforge.net>

Bugs item #419213, was updated on 2001-04-26 11:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=419213&group_id=5470

Category: Extension Modules
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Douglas Shawhan (lysdexia)
>Assigned to: Mark Hammond (mhammond)
Summary: win32all: combrowse.py causes crash/`95

Initial Comment:
Attempting to run 
C:\python20\win32com\client\combrowse.py causes a 
stack fault:

-----begin pain-------

PYTHON caused a stack fault in module MSVCRT.DLL at 
016f:78001169.
Registers:
EAX=5f401151 CS=016f EIP=78001169 EFLGS=00010246
EBX=00542048 SS=0177 ESP=00542000 EBP=0054200c
ECX=00542048 DS=0177 ESI=005420f2 FS=470f
EDX=005420c2 ES=0177 EDI=00540000 GS=0000
Bytes at CS:EIP:
50 c3 8b 44 24 04 66 8b 08 66 85 c9 74 0b 66 3b 
Stack dump:
0054202c 5f492d87 ffffffff 005420a0 5f4012da 00000000 
1e44a1f1 00000cac 005420f2 00000000 00542048 00542090 
1e45ac48 ffffffff 1e436ff7 00542048 

-------end pain-------

Any attempt to run combrowse.py again required hard 
reboot.



----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-04-26 14:52

Message:
Logged In: YES 
user_id=31435

Assigned to MarkH.  Douglas, the Win32 extensions aren't 
part of the core Python project (i.e., it's not our code) --
 you'd probably have better luck reporting this to 
ActiveState.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=419213&group_id=5470


From noreply@sourceforge.net  Thu Apr 26 22:50:18 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 26 Apr 2001 14:50:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-416670 ] MatchObjects not deepcopy()able
Message-ID: <E14steU-0005qC-00@usw-sf-web2.sourceforge.net>

Bugs item #416670, was updated on 2001-04-17 05:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416670&group_id=5470

Category: Regular Expressions
>Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Henning Thielemann (amigalemming)
Assigned to: Fredrik Lundh (effbot)
Summary: MatchObjects not deepcopy()able

Initial Comment:

In the re-Module which come with Python version 2.0
(Nov 28 11:10 re.py) the created MatchObjects cannot be
copied with a deepcopy(). Switching back to the old
"pre.py" as proposed in "re.py" makes everything work
ok.



----------------------------------------------------------------------

>Comment By: Fredrik Lundh (effbot)
Date: 2001-04-26 14:50

Message:
Logged In: YES 
user_id=38376

I'm not sure this is a bug -- imo, you're relying on
an implementation artifact in the original PCRE port.
And making this work under SRE isn't as easy as it may
appear (the proposed patch may work in your specific
case, but it isn't a general solution).

But before I make up my mind here, maybe you could tell
me why you think it's a good idea to use deepcopy on
match objects.  Why not just store "m.groups()" or
"m.regs" instead?

Cheers /F

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-04-26 01:01

Message:
Logged In: YES 
user_id=21627

A patch for that problem is in
http://sourceforge.net/tracker/index.php?func=detail&aid=419070&group_id=5470&atid=305470

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416670&group_id=5470


From noreply@sourceforge.net  Thu Apr 26 22:55:40 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 26 Apr 2001 14:55:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-233790 ] [Irix] re package does not work.
Message-ID: <E14stjg-0005uB-00@usw-sf-web2.sourceforge.net>

Bugs item #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
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fredrik Lundh (effbot)
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 (effbot)
Date: 2001-04-26 14:55

Message:
Logged In: YES 
user_id=38376

time to stop accepting platform-specific bugs without
a known sender?  unless someone buys me an Irix box,
I cannot really do anything about this...

</F>

----------------------------------------------------------------------

Comment By: Fredrik Lundh (effbot)
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 noreply@sourceforge.net  Thu Apr 26 23:01:47 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 26 Apr 2001 15:01:47 -0700
Subject: [Python-bugs-list] [ python-Bugs-416526 ] Regular expression tests: SEGV on Mac OS
Message-ID: <E14stpb-0005xy-00@usw-sf-web2.sourceforge.net>

Bugs item #416526, was updated on 2001-04-16 14:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416526&group_id=5470

Category: Regular Expressions
Group: Platform-specific
Status: Open
Resolution: None
Priority: 7
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fredrik Lundh (effbot)
Summary: Regular expression tests: SEGV on Mac OS

Initial Comment:
The regular expression regression tests 'test_re' 
causes a SEGV failure on Mac OS X version 10.0.1 
when using Python 2.1c2 (and earlier). This is 
caused by the test trying to recurse 50,000 levels 
deep.

Workaround: A workaround is to limit how deep the 
regular expression library can recurse (this is 
already done for Win32). This can be achieved by 
changing file './Modules/_sre.c' using the following 
patch:

--- ./orig/_sre.c   Sun Apr 15 19:00:58 2001
+++ ./new/_sre.c    Mon Apr 16 21:39:29 2001
@@ -75,6 +75,9 @@
    Win64 (MS_WIN64), Linux64 (__LP64__), 
Monterey (64-bit AIX) (_LP64) */
 /* FIXME: maybe the limit should be 40000 / 
sizeof(void*) ? */
 #define USE_RECURSION_LIMIT 7500
+#elif defined(__APPLE_CC__)
+/* Apple 'cc' compiler eg. for Mac OS X */
+#define USE_RECURSION_LIMIT 4000
 #else
 #define USE_RECURSION_LIMIT 10000
 #endif


----------------------------------------------------------------------

>Comment By: Fredrik Lundh (effbot)
Date: 2001-04-26 15:01

Message:
Logged In: YES 
user_id=38376

An alternate (and perhaps better) workaround could be
to increase the stack size on Mac OS X.

But in either case, my plan is to get rid of the recursion
limit in 2.2 (stackless SRE may still run out of memory,
but it shouldn't have to run out of stack).

Cheers /F

----------------------------------------------------------------------

Comment By: Dan Wolfe (dkwolfe)
Date: 2001-04-17 16:52

Message:
Logged In: YES 
user_id=80173

Instead of relying on a compiler variable, we should probably 
set a environment variable as part of the ./configure and use 
that to determine when to reduce the USE_RECURSION_LIMIT.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416526&group_id=5470


From noreply@sourceforge.net  Thu Apr 26 23:06:36 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 26 Apr 2001 15:06:36 -0700
Subject: [Python-bugs-list] [ python-Bugs-419201 ] sys.setdefaultencoding() missing
Message-ID: <E14stuG-00061A-00@usw-sf-web2.sourceforge.net>

Bugs item #419201, was updated on 2001-04-26 10:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=419201&group_id=5470

Category: Unicode
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Andreas Jung (ajung)
Assigned to: Nobody/Anonymous (nobody)
Summary: sys.setdefaultencoding() missing 

Initial Comment:
yetix@/usr/home/ajung/new/Python-2.1/Python(253)% python2.1
Python 2.1 (#1, Apr 24 2001, 19:56:49)
[GCC 2.95.3 20010315 (release)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.setdefaultencoding('iso-8859-1')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
AttributeError: 'sys' module has no attribute 'setdefaultencoding'

Where has it gone ?

Andreas

----------------------------------------------------------------------

>Comment By: Fredrik Lundh (effbot)
Date: 2001-04-26 15:06

Message:
Logged In: YES 
user_id=38376

the default encoding is an experimental feature that can
only be changed during startup (from within the site.py
module)

see the site.py file for more info.

and remember that this function may go away completely
in a future version.  don't rely on it.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=419201&group_id=5470


From noreply@sourceforge.net  Thu Apr 26 23:08:15 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 26 Apr 2001 15:08:15 -0700
Subject: [Python-bugs-list] [ python-Bugs-418173 ] Unicode problem in Tkinter under Windows
Message-ID: <E14stvr-00062J-00@usw-sf-web2.sourceforge.net>

Bugs item #418173, was updated on 2001-04-23 02:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418173&group_id=5470

Category: Tkinter
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Fredrik Lundh (effbot)
Summary: Unicode problem in Tkinter under Windows

Initial Comment:
Unicode problem in Tkinter under Windows 2000
Keyboard-entered chars in ascii range > 128 mess up 
internal unicode encoding in text-widget leading to 
unicode errors

The following example should reproduce the bug:

>>> import Tkinter
>>> t=Tkinter.Text()
>>> t.pack()
>>> t.insert("1.0",u'\xe2\xee\xfb')

Now set the focus to the text-widget and via the 
keyboard enter an a umlaut into the text-widget 
(alternatively press ALT and enter 0228 on the Numpad 
of your Keyboard to simulate this)
Then test the result:
>>> t.get("1.0","end")
u'\xe2\xee\xfb\xe4\n'
This is what you get under Linux (I was told) and what 
it should be.
However, under Windows 2000 I get:
'\xc3\xa2\xc3\xae\xc3\xbb\xe4\n'
which is a mixture of UTF-8 and cp1252(?) leading to 
an Unicode-error, if I try e.g. to save it as a file.
(All characters of an 8-bit value > 128 (e.g. latin-1 
or cp1252) entered via keyboard into a text-widget 
cause such a weird behaviour, not just the a umlaut.)

A simple workaround (not thoroughly tested) could look 
like this:

def badkey(self, event):
    try:
        if ord(event.char) > 127:
            txt.insert("insert", unicode
(event.char,"cp1252"))
            return "break"
    except:
        pass

`txt` being the instance of a text-widget, that is 
bound to a callback for the key-press-event:

if sys.platform == "win32":
         txt.bind("<KeyPress>",badkey)


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-04-23 04:29

Message:
Logged In: YES 
user_id=38388

I believe that this is a TCL bug. Could someone with more
Tcl/tk knowledge please review this ? If it is Unicode
related, then you can assign it back to me.

Thanks.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418173&group_id=5470


From noreply@sourceforge.net  Thu Apr 26 23:07:13 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 26 Apr 2001 15:07:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-419201 ] sys.setdefaultencoding() missing
Message-ID: <E14stur-00061m-00@usw-sf-web2.sourceforge.net>

Bugs item #419201, was updated on 2001-04-26 10:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=419201&group_id=5470

Category: Unicode
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Andreas Jung (ajung)
Assigned to: Nobody/Anonymous (nobody)
Summary: sys.setdefaultencoding() missing 

Initial Comment:
yetix@/usr/home/ajung/new/Python-2.1/Python(253)% python2.1
Python 2.1 (#1, Apr 24 2001, 19:56:49)
[GCC 2.95.3 20010315 (release)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.setdefaultencoding('iso-8859-1')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
AttributeError: 'sys' module has no attribute 'setdefaultencoding'

Where has it gone ?

Andreas

----------------------------------------------------------------------

>Comment By: Fredrik Lundh (effbot)
Date: 2001-04-26 15:07

Message:
Logged In: YES 
user_id=38376

the default encoding is an experimental feature that can
only be changed during startup (from within the site.py
module)

see the site.py file for more info.

and remember that this function may go away completely
in a future version.  don't rely on it.

----------------------------------------------------------------------

Comment By: Fredrik Lundh (effbot)
Date: 2001-04-26 15:06

Message:
Logged In: YES 
user_id=38376

the default encoding is an experimental feature that can
only be changed during startup (from within the site.py
module)

see the site.py file for more info.

and remember that this function may go away completely
in a future version.  don't rely on it.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=419201&group_id=5470


From noreply@sourceforge.net  Thu Apr 26 23:27:40 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 26 Apr 2001 15:27:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-416824 ] Python 2.1 installer freezes on Win 2000
Message-ID: <E14suEe-0004AF-00@usw-sf-web3.sourceforge.net>

Bugs item #416824, was updated on 2001-04-17 13:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416824&group_id=5470

Category: Windows
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Xavier Lagraula (xlagraula)
Assigned to: Tim Peters (tim_one)
Summary: Python 2.1 installer freezes on Win 2000

Initial Comment:
My aim is to install Python 2.1 on a Windows 2000 
Professionnal (French) workstation.

The windows intaller works well until it show the 
screen where one can choose which parts of the product 
one wants to install (third window).

If one hit the "next" button without touching anything 
else, the installer will definitively freeze. Trying 
to stop it using the pop-up menu in the task bar will 
result in a few seconds pause, followed by an error 
window telling that the 16-bit subsystem has not 
answered in time to the stop request. The possibility 
is then given to kill it, eventually leaving the 16 
bit subsystem unstable.

I tried to download the installer from both the main 
site and sourceforge, to check if it came from a 
corrupted file. Same result.

The workaround is simple: just uncheck at least one of 
the check boxes, click "next", it won't freeze. Now 
click "back", re-check the check boxe, click "next" 
and... tada! It won't freeze neither. Now you can go 
on installing the whole package. Haven't thoroughly 
tested it yet, but seems to be working fine.

This problem is not really serious as one can easily 
bypass it, and as it doesn't involve the langage or 
the interpreter themselves. Nevertheless, it IS a 
bug...

Regards,
  Xavier


----------------------------------------------------------------------

Comment By: Eike Hanus (luckyarts)
Date: 2001-04-26 15:27

Message:
Logged In: YES 
user_id=205479

I was having the same problem on my W2K laptop (Dell 
Latitude LS 128 MB RAM) several times. The workaround 
didn't work for me either. Something else strangely 
happened. When I rebooted the machine and tried once more I 
slipped on the touchpad invoking a double click on the next 
button effectively skipping the critical page and directly 
going to the screen asking where to put the icons. I have 
no idea how that worked but maybe the error also only 
happenes after having the page open for a minimum time.

----------------------------------------------------------------------

Comment By: Xavier Lagraula (xlagraula)
Date: 2001-04-25 07:57

Message:
Logged In: YES 
user_id=198402

Well, it is not a bugfix, but a solution is to use the 
ActivePython distribution instead, as suggested by tim_one
(cf. #418156). Even after managing to work around the 
problem of the first distribution (as I've said), I tried 
to install it on my win2k workstation (sheer curiosity) and 
it worked without problem.

It comes as a .msi file, the new standard. You may need to 
download the installer on microsoft.com. Everything is 
explained on the ActiveState web site:
http://www.activestate.com/ASPN/Downloads/ActivePython/

I'll soon have a look at the availability of this msi 
format: if the old version of the Wise Solution installer 
starts to make problems, we might as well start to look for 
a replacement.

--
Xavier

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-04-18 15:30

Message:
Logged In: NO 

In case it helps, I've got a win2k pro workstation, 128MB 
ram, and it also hangs on the same page during the 
installation.  Oh, and the workaround you mentioned did not 
work for me.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-04-18 11:41

Message:
Logged In: YES 
user_id=31435

It's fine that you were logged in as an Administrator.  
Indeed, things probably have the *best* chance of working 
then.

Please note that we didn't write the installer code:  the 
Wise installer is a commercial product, which they kindly 
let Python use for free:

http://www.wisesolutions.com/

We have no access to the source code, either.  So if you 
*do*, for example, find evidence of an uninitialized 
variable, there's nothing we can do about it.  Alas, I 
doubt Wise will do anything about it either, as the version 
of the product we're using is over 5 years old (and looks 
like they stopped supporting it a few years ago).

OTOH, the Windows installer is used many thousands of 
times, and this is the only freeze report we've seen.  If 
we don't see another, the presumption still has to favor 
that there's something flaky about your particular machine.

BTW, I've never tried it on a machine w/ 512Mb of RAM, so 
perhaps that is relevant.  Have tried it on machines w/ 
256Mb.

----------------------------------------------------------------------

Comment By: Xavier Lagraula (xlagraula)
Date: 2001-04-18 05:31

Message:
Logged In: YES 
user_id=198402

To answer your question: I was logged using the 
Administrator account ("Administrateur", in fact, on a 
french box). Like most of the time, because many software 
which are not specifically written for NT won't run 
correctly without it. I know this is bad but what else can 
I do?

Anyway I don't have access to another french win2k box. All 
I can do is give you spécific information about my computer:
- PII 400 - 512Mo of PC133 SDRAM
- Asus MB - P3 BF
- Video: GeForce 256 DDR (Hercules) / Hauppauge WinTV
- Sound: SB Live Player!
- Network: 2 SN3200 (PCI, ethernet 10Mbps, ne2000 
compatible)
- SCSI: Diamond Fireport 40 / CDROM x32 (plextor) / CD 
burner (ricoh MP6200s)
- Win2k french SP1 + IE 5.5
- mysql: latest stable version + MyODBC drivers
- apache: latest stable version + PHP
- naviscope (web proxy/dns cache)
- net vampire: v4.0 beta
- ICQ 2000b
- all drivers were up to date 3 weeks ago.

Still, I believe that those symptoms look either like a 
uninitialized variable or a faulty pointer, such bugs that 
can remain hidden except under very specific "context-
specific" circumstances. (Un)checking one of the check 
boxes, by forcing a value in the variable or by allocating 
a memory block would correct the problem and allow the user 
to go on with the installation.

If I can reproduce the bug this evening, I'll try to see if 
the installer eats all CPU while freezed. Could give a clue 
about what's really happenning. I may also try removing 
256Mo of RAM to verify my "pointer hypothesis" (if it makes 
the bug impossible to reproduce, then it has something to 
do with memory allocation. Crude method but quite useful 
sometimes).

Regards,
  Xavier

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-04-18 02:47

Message:
Logged In: YES 
user_id=31435

This is the only freeze report we've seen for Win2K.

Did you do something bizarre <wink>?  For example, we've 
had one-of-a-kind reports from people in the past who tried 
to install on NT or Win2K while logged in to a Restricted 
User account.  Were you?  Or were you logged in to an 
Administrator account?  Or were you logged in as something 
in between?

Could you try it on another Win2K (French) box?  We have a 
poor track record when it comes to fixing Microsoft's bugs 
for them, and in the absence of more info I have to assume 
it's a bug unique to the specific box you used.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416824&group_id=5470


From noreply@sourceforge.net  Fri Apr 27 06:27:38 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 26 Apr 2001 22:27:38 -0700
Subject: [Python-bugs-list] [ python-Bugs-417802 ] mode_t not appropriate for chmod in BCC
Message-ID: <E14t0n4-0005m9-00@usw-sf-web1.sourceforge.net>

Bugs item #417802, was updated on 2001-04-20 22:49
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417802&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Stephen Hansen (ixokai)
Assigned to: Tim Peters (tim_one)
Summary: mode_t not appropriate for chmod in BCC

Initial Comment:
In reference to the 'chmod' definition in 
posixmodule.c (~line 155). Under Borland 
C++5.5, 'mode_t' is defined in sys/types.h as a short, 
and yet io.h defines 'chmod' as taking char* and an 
int, so the compiler gives an error of, "Type mismatch 
in redeclaration of 'chmod'" here.

Since sys/types.h is going to redefine mode_t after 
anything we put into pyport/config, the only way I can 
see to fix this would be to put an #ifdef __BORLANDC__ 
in there.

Now, to go fix all the other errors BC is spitting out 
in that file. <le sigh>

----------------------------------------------------------------------

>Comment By: Stephen Hansen (ixokai)
Date: 2001-04-26 22:27

Message:
Logged In: YES 
user_id=200343

I submitted a patch (#418147) that corrects this and the 
other problems w/ compiling Borland on Python.

----------------------------------------------------------------------

Comment By: Stephen Hansen (ixokai)
Date: 2001-04-21 19:36

Message:
Logged In: YES 
user_id=200343

The below is Python 2.1final, btw. I keep forgetting to 
include that.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417802&group_id=5470


From noreply@sourceforge.net  Fri Apr 27 06:27:50 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 26 Apr 2001 22:27:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-417952 ] Borland spells timezone as _timezone
Message-ID: <E14t0nG-0005mO-00@usw-sf-web1.sourceforge.net>

Bugs item #417952, was updated on 2001-04-21 20:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417952&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Stephen Hansen (ixokai)
Assigned to: Tim Peters (tim_one)
Summary: Borland spells timezone as _timezone

Initial Comment:
Borland (to be difficult, I 'spose :)) 
spells 'timezone' 'daylight' and 'tzname' with an 
underscore at the begenning. These errors are in the 
inittime function.

The fix I used on my machine (just until I see how 
ya'll do it officially) was to add the following lines 
under '#include <time.h>' in pyport.h:

#ifdef __BORLANDC__
#  define timezone _timezone
#  define daylight _daylight
#  define tzname _tzname
#endif

----------------------------------------------------------------------

>Comment By: Stephen Hansen (ixokai)
Date: 2001-04-26 22:27

Message:
Logged In: YES 
user_id=200343

I submitted a patch (#418147) that corrects this and the 
other problems w/ compiling Borland on Python.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417952&group_id=5470


From noreply@sourceforge.net  Fri Apr 27 06:28:02 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 26 Apr 2001 22:28:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-417949 ] Missing #defines for Borland compiler
Message-ID: <E14t0nS-0005mw-00@usw-sf-web1.sourceforge.net>

Bugs item #417949, was updated on 2001-04-21 19:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417949&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Stephen Hansen (ixokai)
Assigned to: Tim Peters (tim_one)
Summary: Missing #defines for Borland compiler

Initial Comment:
Under Python2.1:

PC/config.h globally defines HAVE_SYS_UTIME_H at ~line 
597, but the Borland C++Builder/compiler needs 
HAVE_UTIME_H instead; this is used in other files 
(posixmodule.c, specifically) to #include <utime.h> 
instead of <sys/utime.h>.



----------------------------------------------------------------------

>Comment By: Stephen Hansen (ixokai)
Date: 2001-04-26 22:28

Message:
Logged In: YES 
user_id=200343

I submitted a patch (#418147) that corrects this and the 
other problems w/ compiling Borland on Python.

----------------------------------------------------------------------

Comment By: Stephen Hansen (ixokai)
Date: 2001-04-21 20:09

Message:
Logged In: YES 
user_id=200343

Additionally, Borland also requires a '#define 
HAVE_DIRENT_H' in the config.h file to get BCC to finally 
compile through Posixmodule before it crashes into 
timemodule. *grin* :)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417949&group_id=5470


From noreply@sourceforge.net  Fri Apr 27 07:57:04 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 26 Apr 2001 23:57:04 -0700
Subject: [Python-bugs-list] [ python-Bugs-419390 ] base64.py could be smarter...
Message-ID: <E14t2Bc-0003w8-00@usw-sf-web2.sourceforge.net>

Bugs item #419390, was updated on 2001-04-26 23:57
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=419390&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Nobody/Anonymous (nobody)
Summary: base64.py could be smarter...

Initial Comment:
base64.encodestring and decodestring take the
provided string, wrap it in a StringIO, then 
pass it to encode/decode which uses read() to 
pull it back out again. 

Seems pretty inefficient.

Replacing decodestring with:
  return binascii.a2b_base64(s)

results in a speedup of a factor of 16 or so.
(my sample: a 2Mb encoded voice message - takes
an average of 10s in the current form, and 0.6s
using just binascii.)

A similar speedup for encodestring seems possible.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=419390&group_id=5470


From noreply@sourceforge.net  Fri Apr 27 08:16:27 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 27 Apr 2001 00:16:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-233790 ] [Irix] re package does not work.
Message-ID: <E14t2UN-00021v-00@usw-sf-web3.sourceforge.net>

Bugs item #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
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fredrik Lundh (effbot)
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: Nobody/Anonymous (nobody)
Date: 2001-04-27 00:16

Message:
Logged In: NO 

This is a guess - but it is most likely related to the
fact that gcc 2.8.x sets sys.maxint to -1 under
IRIX 6.x.  This bug has manifest itself in several places
before on this particular compiler and platform combination.
The solution is to use a newer version of gcc.

raj


----------------------------------------------------------------------

Comment By: Fredrik Lundh (effbot)
Date: 2001-04-26 14:55

Message:
Logged In: YES 
user_id=38376

time to stop accepting platform-specific bugs without
a known sender?  unless someone buys me an Irix box,
I cannot really do anything about this...

</F>

----------------------------------------------------------------------

Comment By: Fredrik Lundh (effbot)
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 noreply@sourceforge.net  Fri Apr 27 08:58:57 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 27 Apr 2001 00:58:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-419201 ] sys.setdefaultencoding() missing
Message-ID: <E14t39V-0004gD-00@usw-sf-web2.sourceforge.net>

Bugs item #419201, was updated on 2001-04-26 10:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=419201&group_id=5470

Category: Unicode
>Group: Not a Bug
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Andreas Jung (ajung)
>Assigned to: M.-A. Lemburg (lemburg)
Summary: sys.setdefaultencoding() missing 

Initial Comment:
yetix@/usr/home/ajung/new/Python-2.1/Python(253)% python2.1
Python 2.1 (#1, Apr 24 2001, 19:56:49)
[GCC 2.95.3 20010315 (release)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.setdefaultencoding('iso-8859-1')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
AttributeError: 'sys' module has no attribute 'setdefaultencoding'

Where has it gone ?

Andreas

----------------------------------------------------------------------

Comment By: Fredrik Lundh (effbot)
Date: 2001-04-26 15:07

Message:
Logged In: YES 
user_id=38376

the default encoding is an experimental feature that can
only be changed during startup (from within the site.py
module)

see the site.py file for more info.

and remember that this function may go away completely
in a future version.  don't rely on it.

----------------------------------------------------------------------

Comment By: Fredrik Lundh (effbot)
Date: 2001-04-26 15:06

Message:
Logged In: YES 
user_id=38376

the default encoding is an experimental feature that can
only be changed during startup (from within the site.py
module)

see the site.py file for more info.

and remember that this function may go away completely
in a future version.  don't rely on it.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=419201&group_id=5470


From noreply@sourceforge.net  Fri Apr 27 10:50:27 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 27 Apr 2001 02:50:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-419434 ] Tutorial contains wrong sample code.
Message-ID: <E14t4tP-0003sH-00@usw-sf-web3.sourceforge.net>

Bugs item #419434, was updated on 2001-04-27 02:50
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=419434&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dinu C. Gherman (dinu_gherman)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Tutorial contains wrong sample code.

Initial Comment:
The tutorial for version 2.1 of Python contains this piece of wrong code:

>>> x = 10 * 3.14
>>> y = 200*200
>>> s = 'The value of x is ' + `x` + ', and y is ' + `y` + '...'
>>> print s
The value of x is 31.4, and y is 40000...

where the real output should read:

>>> print s
The value of x is 31.400000000000002, and y is 40000...

Dinu Gherman


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=419434&group_id=5470


From noreply@sourceforge.net  Fri Apr 27 11:03:48 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 27 Apr 2001 03:03:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-416670 ] MatchObjects not deepcopy()able
Message-ID: <E14t56K-0006CN-00@usw-sf-web2.sourceforge.net>

Bugs item #416670, was updated on 2001-04-17 05:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416670&group_id=5470

Category: Regular Expressions
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Henning Thielemann (amigalemming)
Assigned to: Fredrik Lundh (effbot)
Summary: MatchObjects not deepcopy()able

Initial Comment:

In the re-Module which come with Python version 2.0
(Nov 28 11:10 re.py) the created MatchObjects cannot be
copied with a deepcopy(). Switching back to the old
"pre.py" as proposed in "re.py" makes everything work
ok.



----------------------------------------------------------------------

>Comment By: Henning Thielemann (amigalemming)
Date: 2001-04-27 03:03

Message:
Logged In: YES 
user_id=197994

You are right, m.groupdict() and m.groups() are surely the
better choice.


----------------------------------------------------------------------

Comment By: Fredrik Lundh (effbot)
Date: 2001-04-26 14:50

Message:
Logged In: YES 
user_id=38376

I'm not sure this is a bug -- imo, you're relying on
an implementation artifact in the original PCRE port.
And making this work under SRE isn't as easy as it may
appear (the proposed patch may work in your specific
case, but it isn't a general solution).

But before I make up my mind here, maybe you could tell
me why you think it's a good idea to use deepcopy on
match objects.  Why not just store "m.groups()" or
"m.regs" instead?

Cheers /F

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-04-26 01:01

Message:
Logged In: YES 
user_id=21627

A patch for that problem is in
http://sourceforge.net/tracker/index.php?func=detail&aid=419070&group_id=5470&atid=305470

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416670&group_id=5470


From noreply@sourceforge.net  Fri Apr 27 13:08:01 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 27 Apr 2001 05:08:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-419462 ] python 2.0 compile fails on mandrake 8
Message-ID: <E14t72X-0003Yy-00@usw-sf-web1.sourceforge.net>

Bugs item #419462, was updated on 2001-04-27 05:08
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=419462&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Luke Kenneth Casson Leighton (lkcl)
Assigned to: Nobody/Anonymous (nobody)
Summary: python 2.0 compile fails on mandrake 8

Initial Comment:
bddbmodule fails to compile on mandrake 8.

if bdb is not a mandatory module, autoconf should be
used to
detect that bdb is or is not installed.  [it's looking
for
R_NEXT etc. which don't exist]

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=419462&group_id=5470


From noreply@sourceforge.net  Sat Apr 28 07:04:26 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 27 Apr 2001 23:04:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-417178 ] uu.py doesn't close in_file on exception
Message-ID: <E14tNqE-000423-00@usw-sf-web1.sourceforge.net>

Bugs item #417178, was updated on 2001-04-18 15:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417178&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Tim Peters (tim_one)
Summary: uu.py doesn't close in_file on exception

Initial Comment:
When decoding a uu-encoded file with uu.decode(), the 
given in_file is not closed before a uu.Error is 
raised.

This leads to problems on Win32 when trying to 
os.remove() the file after the exception was raised, 
because the permission to remove the file is denied.

Maybe the same problem is present for out_file.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-04-27 23:04

Message:
Logged In: YES 
user_id=31435

It's unclear whether you're passing a file object or a 
pathname to decode().

If you're passing a file object, it's never decode()'s job 
to close it (decode didn't open it, so it's got no business 
closing it either).

If you're passing a pathname, you're using a deprecated 
feature (see the docs), and deprecated features don't get 
enhanced (they only exist for backward compatibility).

So, sorry, but in either case this won't be changed.  As 
the dcos say, you should pass a file object, and then it's 
your responsibility to close the files you open.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417178&group_id=5470


From noreply@sourceforge.net  Sat Apr 28 09:53:27 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 28 Apr 2001 01:53:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-416670 ] MatchObjects not deepcopy()able
Message-ID: <E14tQTn-0006Ds-00@usw-sf-web2.sourceforge.net>

Bugs item #416670, was updated on 2001-04-17 05:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416670&group_id=5470

Category: Regular Expressions
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Henning Thielemann (amigalemming)
Assigned to: Fredrik Lundh (effbot)
Summary: MatchObjects not deepcopy()able

Initial Comment:

In the re-Module which come with Python version 2.0
(Nov 28 11:10 re.py) the created MatchObjects cannot be
copied with a deepcopy(). Switching back to the old
"pre.py" as proposed in "re.py" makes everything work
ok.



----------------------------------------------------------------------

>Comment By: Fredrik Lundh (effbot)
Date: 2001-04-28 01:53

Message:
Logged In: YES 
user_id=38376

On the other hand, it looks like we've found a rather
elegant way to solve this.  I'll leave this one open
(as a feature request).

----------------------------------------------------------------------

Comment By: Henning Thielemann (amigalemming)
Date: 2001-04-27 03:03

Message:
Logged In: YES 
user_id=197994

You are right, m.groupdict() and m.groups() are surely the
better choice.


----------------------------------------------------------------------

Comment By: Fredrik Lundh (effbot)
Date: 2001-04-26 14:50

Message:
Logged In: YES 
user_id=38376

I'm not sure this is a bug -- imo, you're relying on
an implementation artifact in the original PCRE port.
And making this work under SRE isn't as easy as it may
appear (the proposed patch may work in your specific
case, but it isn't a general solution).

But before I make up my mind here, maybe you could tell
me why you think it's a good idea to use deepcopy on
match objects.  Why not just store "m.groups()" or
"m.regs" instead?

Cheers /F

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-04-26 01:01

Message:
Logged In: YES 
user_id=21627

A patch for that problem is in
http://sourceforge.net/tracker/index.php?func=detail&aid=419070&group_id=5470&atid=305470

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416670&group_id=5470


From noreply@sourceforge.net  Sun Apr 29 00:22:56 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 28 Apr 2001 16:22:56 -0700
Subject: [Python-bugs-list] [ python-Bugs-419873 ] ThreadingTCPServer invalidating sockets
Message-ID: <E14te3E-0005wy-00@usw-sf-web3.sourceforge.net>

Bugs item #419873, was updated on 2001-04-28 16:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=419873&group_id=5470

Category: Threads
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: ThreadingTCPServer invalidating sockets

Initial Comment:
running this:
import SocketServer

class TestServer(SocketServer.ThreadingTCPServer):
    def __init__(self, server_address,
RequestHandlerClass):
        SocketServer.ThreadingTCPServer.__init__(self,
server_address, RequestHandlerClass)
        self.quit = 0

    def process_request(self, request, client_address):
        print 'socket in process_request = %s' % request
        print 'id(socket) in process_request = %d' %
id(request)
       
SocketServer.ThreadingTCPServer.process_request(self,
request, client_address)

    def finish_request(self, request, client_address):
        print 'socket in finish_request = %s' % request
        print 'id(socket) in finish_request = %d' %
id(request)
        self.RequestHandlerClass(request,
client_address, self)
    
    def get_request(self):
        conn, addr = self.socket.accept()
        print 'socket in get_request = %s' % conn
        print 'id(socket) in get_request = %d' % id(conn)
        return conn,addr

if __name__ == '__main__':
    s = TestServer(('',9950),
SocketServer.BaseRequestHandler)
    s.handle_request()
    s.server_close()

results in the following output (when connected to
remotely):

socket in get_request = <socket object, fd=4, family=2,
type=1, protocol=0>
id(socket) in get_request = 135335216
socket in process_request = <socket object, fd=4,
family=2, type=1, protocol=0>
id(socket) in process_request = 135335216
socket in finish_request = <socket object, fd=-1,
family=2, type=1, protocol=0>
id(socket) in finish_request = 135335216

between in the thread-creation in process_request, the
socket's fd changes to -1.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=419873&group_id=5470


From noreply@sourceforge.net  Sun Apr 29 22:14:54 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 29 Apr 2001 14:14:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-420011 ] \u escapes don't work inside ranges
Message-ID: <E14tyWs-0006tz-00@usw-sf-web1.sourceforge.net>

Bugs item #420011, was updated on 2001-04-29 14:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420011&group_id=5470

Category: Regular Expressions
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Fredrik Lundh (effbot)
Assigned to: Fredrik Lundh (effbot)
Summary: \u escapes don't work inside ranges

Initial Comment:
the pattern "[\u0000-\uffff]" should match any
unicode character.  for some reason, it doesn't
seem to do that...

</F>

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420011&group_id=5470


From noreply@sourceforge.net  Sun Apr 29 22:18:24 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 29 Apr 2001 14:18:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-420011 ] \u escapes don't work inside ranges
Message-ID: <E14tyaG-0006y7-00@usw-sf-web1.sourceforge.net>

Bugs item #420011, was updated on 2001-04-29 14:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420011&group_id=5470

Category: Regular Expressions
>Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Fredrik Lundh (effbot)
Assigned to: Fredrik Lundh (effbot)
Summary: \u escapes don't work inside ranges

Initial Comment:
the pattern "[\u0000-\uffff]" should match any
unicode character.  for some reason, it doesn't
seem to do that...

</F>

----------------------------------------------------------------------

>Comment By: Fredrik Lundh (effbot)
Date: 2001-04-29 14:18

Message:
Logged In: YES 
user_id=38376

I meant r"[\u0000-\uffff]"

and on second thought, I'm not sure it's a bug: SRE doesn't
seem to support \u and \U escapes at all.  and the pattern
u"[\u0000-\uffff]" works as expected.

I'll change this to a feature request.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420011&group_id=5470


From noreply@sourceforge.net  Sun Apr 29 23:11:08 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 29 Apr 2001 15:11:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-417093 ] Case sensitive import: dir and .py file w/ same name
Message-ID: <E14tzPI-0007oG-00@usw-sf-web1.sourceforge.net>

Bugs item #417093, was updated on 2001-04-18 09:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417093&group_id=5470

>Category: Python Interpreter Core
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Tim Peters (tim_one)
>Summary: Case sensitive import: dir and .py file w/ same name

Initial Comment:
Consider the following files in the current directory:

Spam.py
spam/__init__.py

Using python 2.0:

Python 2.0 (#8, Oct 16 2000, 17:27:58) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> import Spam
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
NameError: Case mismatch for module name Spam
(filename spam)
>>> import spam; print spam
<module 'spam' from 'spam\__init__.py'>
>>>

Using python 2.1:

Python 2.1c2 (#14, Apr 15 2001, 21:29:05) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> import Spam
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
SystemError: NULL result without error in call_object
>>> import spam; print spam
<module 'spam' from 'spam\__init__.py'>
>>>


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-04-29 15:11

Message:
Logged In: YES 
user_id=31435

Looks like this bug should pop up on any platform w/ a case-
preserving case-insensitive filesystem, so fiddled 
descriptions and categories accordingly.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-04-18 15:56

Message:
Logged In: YES 
user_id=31435

Assigned to me.  Regardless of what should or shouldn't 
happen, a SystemError is *always* "a bug".


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417093&group_id=5470


From noreply@sourceforge.net  Sun Apr 29 23:22:24 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 29 Apr 2001 15:22:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-417093 ] Case sensitive import: dir and .py file w/ same name
Message-ID: <E14tzaC-0007k7-00@usw-sf-web2.sourceforge.net>

Bugs item #417093, was updated on 2001-04-18 09:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417093&group_id=5470

Category: Python Interpreter Core
Group: Platform-specific
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Tim Peters (tim_one)
Summary: Case sensitive import: dir and .py file w/ same name

Initial Comment:
Consider the following files in the current directory:

Spam.py
spam/__init__.py

Using python 2.0:

Python 2.0 (#8, Oct 16 2000, 17:27:58) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> import Spam
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
NameError: Case mismatch for module name Spam
(filename spam)
>>> import spam; print spam
<module 'spam' from 'spam\__init__.py'>
>>>

Using python 2.1:

Python 2.1c2 (#14, Apr 15 2001, 21:29:05) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> import Spam
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
SystemError: NULL result without error in call_object
>>> import spam; print spam
<module 'spam' from 'spam\__init__.py'>
>>>


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-04-29 15:22

Message:
Logged In: YES 
user_id=31435

Part of the code I didn't understand at the time assumed 
that something was an error on these platforms; in the new 
scheme, it was no longer an error so the routine it called 
didn't set an error string, but the code returned NULL 
anyway.  Fixed now (it's not an error anymore so should not 
return NULL).  New behavior:

Python 2.2a0 (#16, Apr 20 2001, 23:16:12) [MSC 32 bit 
(Intel)] on win32
>>> import Spam
>>> Spam
<module 'Spam' from 'Spam.py'>
>>> import spam
>>> spam
<module 'spam' from 'spam\__init__.py'>
>>>

Checked into Python/import.c rev 2.177.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-04-29 15:11

Message:
Logged In: YES 
user_id=31435

Looks like this bug should pop up on any platform w/ a case-
preserving case-insensitive filesystem, so fiddled 
descriptions and categories accordingly.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-04-18 15:56

Message:
Logged In: YES 
user_id=31435

Assigned to me.  Regardless of what should or shouldn't 
happen, a SystemError is *always* "a bug".


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417093&group_id=5470


From noreply@sourceforge.net  Mon Apr 30 12:14:26 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 30 Apr 2001 04:14:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-410620 ] pydoc installation w.r.t. RPM.
Message-ID: <E14uBdK-00068s-00@usw-sf-web3.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
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Ka-Ping Yee (ping)
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


----------------------------------------------------------------------

Comment By: Anthon van der Neut (anthon)
Date: 2001-04-30 04:14

Message:
Logged In: YES 
user_id=90778

I ran into the same problem with 2.1 final release. Tried to
use the --root option in that place only to find that 
the .so files installed by sharedinstall: where now in 
$(RPM_BUILD_ROOT)/$(RPM_BUILD_ROOT)/.... :(
I chose the more restricted patch:
--- Makefile.pre.in.org
+++ Makefile.pre.in     Mon Apr 30 11:33:53 
2001                                
@@ -704,7 +708,7 @@
 # This goes into $(exec_prefix)
 sharedinstall:
        PYTHONPATH= ./$(PYTHON) $(srcdir)/setup.py install \
-               --install-platlib=$(DESTSHARED)
+               --install-platlib=$(DESTSHARED) --install-
scripts=$(BINDIR)
 
 # 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  Mon Apr 30 19:03:23 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 30 Apr 2001 11:03:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-420216 ] bad links in v2.1 docs
Message-ID: <E14uI15-00035u-00@usw-sf-web3.sourceforge.net>

Bugs item #420216, was updated on 2001-04-30 11:03
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420216&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Grant Griffin (dspguru)
Assigned to: Nobody/Anonymous (nobody)
Summary: bad links in v2.1 docs

Initial Comment:
The file 'module-imap.html' is linked, but not 
supplied (see grep at bottom).

Also, there are several links to "about.html" in 
the "doc\dist" directory.  However, no "about.html" is 
supplied there.

Thanks!

=g2

----------------
F:\apps\Python21\Doc>grep -d+ module-imap.html *.html
File lib\module-poplib.html:
using the <tt class='module'><a href='module-
IMAP.html'>IMAP</a></tt> class, as
IMAP servers tend to be better
File lib\pop3-objects.html:
    <dt>Module <b><tt class='module'><a href='module-
imap.html'>imap</a></tt>:</
b>

F:\apps\Python21\Doc>dir module-imap.html /s
 Volume in drive F has no label.
 Volume Serial Number is 

File Not Found

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420216&group_id=5470


From noreply@sourceforge.net  Mon Apr 30 20:04:59 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 30 Apr 2001 12:04:59 -0700
Subject: [Python-bugs-list] [ python-Bugs-420230 ] fileinput deletes backups without warnin
Message-ID: <E14uIyh-0002Dc-00@usw-sf-web1.sourceforge.net>

Bugs item #420230, was updated on 2001-04-30 12:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420230&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bernhard Reiter (ber)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: fileinput deletes backups without warnin

Initial Comment:
When using the fileinput module with inplace=1 and a
specific
backup extension the file stays around as documented,
but if it existed before it gets overwritten without
warning.
This should be documented. 

"Backup files are overriden silently."

Other possible fixes could include adding an
overwrite=0 argument
so that an exceptions is thrown when overwrite=0.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420230&group_id=5470


From noreply@sourceforge.net  Mon Apr 30 23:18:47 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 30 Apr 2001 15:18:47 -0700
Subject: [Python-bugs-list] [ python-Bugs-417802 ] mode_t not appropriate for chmod in BCC
Message-ID: <E14uM0F-0008V0-00@usw-sf-web2.sourceforge.net>

Bugs item #417802, was updated on 2001-04-20 22:49
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417802&group_id=5470

Category: Build
Group: Platform-specific
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Stephen Hansen (ixokai)
Assigned to: Tim Peters (tim_one)
Summary: mode_t not appropriate for chmod in BCC

Initial Comment:
In reference to the 'chmod' definition in 
posixmodule.c (~line 155). Under Borland 
C++5.5, 'mode_t' is defined in sys/types.h as a short, 
and yet io.h defines 'chmod' as taking char* and an 
int, so the compiler gives an error of, "Type mismatch 
in redeclaration of 'chmod'" here.

Since sys/types.h is going to redefine mode_t after 
anything we put into pyport/config, the only way I can 
see to fix this would be to put an #ifdef __BORLANDC__ 
in there.

Now, to go fix all the other errors BC is spitting out 
in that file. <le sigh>

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-04-30 15:18

Message:
Logged In: YES 
user_id=31435

Superceded by patch 418147.

----------------------------------------------------------------------

Comment By: Stephen Hansen (ixokai)
Date: 2001-04-26 22:27

Message:
Logged In: YES 
user_id=200343

I submitted a patch (#418147) that corrects this and the 
other problems w/ compiling Borland on Python.

----------------------------------------------------------------------

Comment By: Stephen Hansen (ixokai)
Date: 2001-04-21 19:36

Message:
Logged In: YES 
user_id=200343

The below is Python 2.1final, btw. I keep forgetting to 
include that.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417802&group_id=5470


From noreply@sourceforge.net  Mon Apr 30 23:19:13 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 30 Apr 2001 15:19:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-417949 ] Missing #defines for Borland compiler
Message-ID: <E14uM0f-0008Vg-00@usw-sf-web2.sourceforge.net>

Bugs item #417949, was updated on 2001-04-21 19:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417949&group_id=5470

Category: Build
Group: Platform-specific
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Stephen Hansen (ixokai)
Assigned to: Tim Peters (tim_one)
Summary: Missing #defines for Borland compiler

Initial Comment:
Under Python2.1:

PC/config.h globally defines HAVE_SYS_UTIME_H at ~line 
597, but the Borland C++Builder/compiler needs 
HAVE_UTIME_H instead; this is used in other files 
(posixmodule.c, specifically) to #include <utime.h> 
instead of <sys/utime.h>.



----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-04-30 15:19

Message:
Logged In: YES 
user_id=31435

Superceded by patch 418147.

----------------------------------------------------------------------

Comment By: Stephen Hansen (ixokai)
Date: 2001-04-26 22:28

Message:
Logged In: YES 
user_id=200343

I submitted a patch (#418147) that corrects this and the 
other problems w/ compiling Borland on Python.

----------------------------------------------------------------------

Comment By: Stephen Hansen (ixokai)
Date: 2001-04-21 20:09

Message:
Logged In: YES 
user_id=200343

Additionally, Borland also requires a '#define 
HAVE_DIRENT_H' in the config.h file to get BCC to finally 
compile through Posixmodule before it crashes into 
timemodule. *grin* :)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417949&group_id=5470


From noreply@sourceforge.net  Mon Apr 30 23:19:38 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 30 Apr 2001 15:19:38 -0700
Subject: [Python-bugs-list] [ python-Bugs-417952 ] Borland spells timezone as _timezone
Message-ID: <E14uM14-0008WO-00@usw-sf-web2.sourceforge.net>

Bugs item #417952, was updated on 2001-04-21 20:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417952&group_id=5470

Category: Build
Group: Platform-specific
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Stephen Hansen (ixokai)
Assigned to: Tim Peters (tim_one)
Summary: Borland spells timezone as _timezone

Initial Comment:
Borland (to be difficult, I 'spose :)) 
spells 'timezone' 'daylight' and 'tzname' with an 
underscore at the begenning. These errors are in the 
inittime function.

The fix I used on my machine (just until I see how 
ya'll do it officially) was to add the following lines 
under '#include <time.h>' in pyport.h:

#ifdef __BORLANDC__
#  define timezone _timezone
#  define daylight _daylight
#  define tzname _tzname
#endif

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-04-30 15:19

Message:
Logged In: YES 
user_id=31435

Superceded by patch 418147.

----------------------------------------------------------------------

Comment By: Stephen Hansen (ixokai)
Date: 2001-04-26 22:27

Message:
Logged In: YES 
user_id=200343

I submitted a patch (#418147) that corrects this and the 
other problems w/ compiling Borland on Python.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417952&group_id=5470