From noreply@sourceforge.net  Thu Aug  1 01:00:05 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 31 Jul 2002 17:00:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-589422 ] shared libpython & dependant libraries
Message-ID: <E17a3Nt-0003Zi-00@usw-sf-web5.sourceforge.net>

Bugs item #589422, was opened at 2002-08-01 00:00
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=589422&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: shared libpython & dependant libraries

Initial Comment:
When building the shared libpython.so, the shared 
library is not linked against dependent shared libraries, 
which are needed for the modules linked in the library.

i.e. the thread module normally is linked in the library, 
but libpython.so is not linked against the thread library ( 
pthread on Linux).


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

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


From noreply@sourceforge.net  Thu Aug  1 01:13:24 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 31 Jul 2002 17:13:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-589427 ] standard include paths on command line
Message-ID: <E17a3am-0005Q2-00@usw-sf-web3.sourceforge.net>

Bugs item #589427, was opened at 2002-08-01 00:13
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=589427&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: standard include paths on command line

Initial Comment:
when compiling shared modules (using gcc-3.1.1), 
standard include paths are included (by setup.py?) in 
the include path, which can change the search order. 
gcc-3.1 warns about:

building 'xreadlines' extension
gcc-3.1 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -
fPIC -I. -I/home/packages/pyt
hon2.3/python2.3-2.2.90/./Include -I/usr/include -
I/usr/local/include -I/home/pa
ckages/python2.3/python2.3-2.2.90/Include -
I/home/packages/python2.3/python2.3-2
.2.90/build-static -
c /home/packages/python2.3/python2.3-
2.2.90/Modules/xreadlin
esmodule.c -o build/temp.linux-i686-
2.3/xreadlinesmodule.o
gcc -shared build/temp.linux-i686-
2.3/xreadlinesmodule.o -L/usr/lib -L/usr/local
/lib -o build/lib.linux-i686-2.3/xreadlines.so
building 'array' extension
gcc-3.1 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -
fPIC -I. -I/hocc1: warning: c
hanging search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory

In this case, /usr/include and /usr/local/include should 
not be included on the command line.


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

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


From noreply@sourceforge.net  Thu Aug  1 01:17:07 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 31 Jul 2002 17:17:07 -0700
Subject: [Python-bugs-list] [ python-Bugs-589429 ] libpython.a with PIC objects
Message-ID: <E17a3eN-0005UC-00@usw-sf-web3.sourceforge.net>

Bugs item #589429, was opened at 2002-08-01 00:17
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=589429&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: libpython.a with PIC objects

Initial Comment:
when configuring with --enable-shared, the "static" 
library libpython.a is build with PIC-compiled objects.
Using the option --enable-shared builds a shared library 
in addition to the static library (with objects compiled 
without PIC).


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

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


From noreply@sourceforge.net  Thu Aug  1 09:57:54 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 01 Aug 2002 01:57:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-534864 ] profiling with xml parsing asserts
Message-ID: <E17aBmM-0005MR-00@usw-sf-web3.sourceforge.net>

Bugs item #534864, was opened at 2002-03-25 21:15
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=534864&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Aron K. Insinga (ainsinga)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: profiling with xml parsing asserts

Initial Comment:
I'm getting a 'bad call' assertion error when using the
profiler when parsing XML.  (It works ok without the
profiler, and if I don't call SAXparser.parse it
doesn't happen.)


Python 2.2 (#1, Dec 23 2001, 09:30:32)
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on
linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import t4crash
start document
end document
>>> import profile
>>> t4crash.test()
start document
end document
>>> profile.run('t4crash.test()')
start document
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.2/profile.py", line 71, in run
    prof = prof.run(statement)
  File "/usr/lib/python2.2/profile.py", line 404, in
run
    return self.runctx(cmd, dict, dict)
  File "/usr/lib/python2.2/profile.py", line 410, in
runctx
    exec cmd in globals, locals
  File "<string>", line 1, in ?
  File "t4crash.py", line 46, in test
    main(files)
  File "t4crash.py", line 39, in main
    SAXparser.parse(fileName)
  File
"/var/tmp/python2-2.2-root/usr/lib/python2.2/xml/sax/expatreader.py",
line 53, in parse
  File
"/var/tmp/python2-2.2-root/usr/lib/python2.2/xml/sax/xmlreader.py",
line
123, in parse  File
"/var/tmp/python2-2.2-root/usr/lib/python2.2/xml/sax/expatreader.py",
line 106,
in feed
  File
"/var/tmp/python2-2.2-root/usr/lib/python2.2/xml/sax/expatreader.py",
line 179, in start_element
  File "/usr/lib/python2.2/profile.py", line 214, in
trace_dispatch_i
    if self.dispatch[event](self, frame,t):
  File "/usr/lib/python2.2/profile.py", line 260, in
trace_dispatch_call
    assert rframe.f_back is frame.f_back, ("Bad call",
rfn,
AssertionError: ('Bad call',
('/var/tmp/python2-2.2-root/usr/lib/python2.2/xml/sax/expatreader.py',
95,
'feed'), <frame object at 0x81d5454>, <frame object at
0x81c82e4>, <frame object
at 0x81d50b4>, <frame object at 0x81d5284>)
>>>
[ainsinga@ainsinga index_xml]$ cat t4crash.py
#!/usr/bin/env python2

# t4crash.py by Aron K. Insinga (aron.insinga@av.com)
25-Mar-2002

import xml.sax
import sys
import string
import re


class ContentHandler(xml.sax.ContentHandler):
    """ Handle callbacks from the SAX XML parser. """

    def __init__(selfy):
        pass

    def setDocumentLocator(self, locator):
        pass

    def startDocument(self):
        print 'start document'

    def endDocument(self):
        print 'end document'

    def startElement(self, name, attrs):
        pass

    def endElement(self, name):
        pass


def main(files):
    SAXparser = xml.sax.make_parser()
    chand = ContentHandler()
    SAXparser.setContentHandler(chand)
    try:
        for fileName in files:
            SAXparser.parse(fileName)
    except xml.sax.SAXParseException:
        sys.stderr.write("%s; processing aborted\n" %
(xml.sax.SAXParseException))
        sys.exit(1)

def test():
    files = ['doc0.xml']
    main(files)

test()
[ainsinga@ainsinga index_xml]$ cat doc0.xml
<?xml version="1.0" encoding="ISO-8859-1"?>
<html>
  <head>
    <title>Gettysburg Address</title>
  </head>
  <body>
    <p>
      Four score and seven years ago...<br/>
    </p>
  </body>
  <info>
    <author>
     
<lastname>Lincoln</lastname><firstname>Abraham</firstname>
    </author>
    <date>
      <month>11</month><day>19</day><year>1863</year>
    </date>
    <editor /><!-- editor name="aki"/ -->
    <editor/>
  </info>
</html>
[ainsinga@ainsinga index_xml]$ which python
/usr/bin/python
[ainsinga@ainsinga index_xml]$ set | grep PATH
LD_LIBRARY_PATH=/home/ainsinga/adabas/lib:/home/ainsinga/adabas/lib:/home/ainsinga/adabas/lib:/home/ainsinga/adabas/lib:/home/ainsinga/adabas/lib:
PATH=$'/home/ainsinga/adabas/bin:/home/ainsinga/adabas/pgm:.:/home/ainsinga/adabas/bin:/home/ainsinga/adabas/pgm:.:/home/ainsinga/adabas/bin:/home/ainsinga/adabas/pgm:.:/home/ainsinga/adabas/bin:/home/ainsinga/adabas/pgm:.:.:/home/ainsinga/bin:/home/ainsinga/adabas/bin:/home/ainsinga/adabas/pgm:.:/bin:/usr/bin:/usr/X11R6/bin:/usr/local/bin:~/staroffice6.0:/home/ainsinga/mozilla:~/staroffice6.0:/home/ainsinga/mozilla:~/staroffice6.0:/home/ainsinga/mozilla:~/staroffice6.0:/home/ainsinga/mozilla:~/
staroffice6.0:/home/ainsinga/mozilla'
[ainsinga@ainsinga index_xml]$ set | grep -i py
[ainsinga@ainsinga index_xml]$uname -a
Linux ainsinga 2.4.7-10 #1 Thu Sep 6 17:27:27 EDT 2001
i686 unknown
[ainsinga@ainsinga index_xml]$


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

Comment By: Andrew P. Lentvorski, Jr. (andrewl)
Date: 2002-08-01 08:57

Message:
Logged In: YES 
user_id=28733

I took a quick look in the browsable CVS repository, and the
diff to expat.c doesn't seem to be committed.  Is there
something further that I need to do so that this bug can get
closed?

-a

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-07-02 07:05

Message:
Logged In: YES 
user_id=21627

Attached is a patch that fixes the problem.

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

Comment By: Andrew P. Lentvorski, Jr. (andrewl)
Date: 2002-07-02 00:13

Message:
Logged In: YES 
user_id=28733

The xmltest.py program follows since I appear to be too
stupid to figure out how to attach a file to a bug report on
SourceForge.

-a

#!/usr/bin/env python

import xml.sax

testxml = \
"""
<html />
"""

class ContentHandler(xml.sax.ContentHandler):
    """ Handle callbacks from the SAX XML parser. """

    def __init__(self):
        pass

    def startElement(self, name, attrs):
        print "start element"

    def endElement(self, name):
        print "end element"

def main():
    chand = ContentHandler()
    xml.sax.parseString(testxml, chand)

if __name__ == "__main__":
    main()


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

Comment By: Andrew P. Lentvorski, Jr. (andrewl)
Date: 2002-07-02 00:01

Message:
Logged In: YES 
user_id=28733

Here is a session log for a much more self-contained
regression file (xmltest.py):

andrewl@taz:andrewl$ python
Python 2.2.1 (#1, May 27 2002, 16:42:22) 
[GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4
Type "help", "copyright", "credits" or "license" for more
information.
>>> import profile
>>> import xmltest
>>> profile.run('xmltest.main()')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.2/profile.py", line 71, in
run
    prof = prof.run(statement)
  File "/usr/local/lib/python2.2/profile.py", line 404, in
run
    return self.runctx(cmd, dict, dict)
  File "/usr/local/lib/python2.2/profile.py", line 410, in
runctx
    exec cmd in globals, locals
  File "<string>", line 1, in ?
  File "xmltest.py", line 24, in main
    xml.sax.parseString(testxml, chand)
  File "/usr/local/lib/python2.2/xml/sax/__init__.py", line
49, in parseString
    parser.parse(inpsrc)
  File "/usr/local/lib/python2.2/xml/sax/expatreader.py",
line 90, in parse
    xmlreader.IncrementalParser.parse(self, source)
  File "/usr/local/lib/python2.2/xml/sax/xmlreader.py", line
123, in parse
    self.feed(buffer)
  File "/usr/local/lib/python2.2/xml/sax/expatreader.py",
line 143, in feed
    self._parser.Parse(data, isFinal)
  File "/usr/local/lib/python2.2/xml/sax/expatreader.py",
line 216, in start_element
    def start_element(self, name, attrs):
  File "/usr/local/lib/python2.2/profile.py", line 214, in
trace_dispatch_i
    if self.dispatch[event](self, frame,t):
  File "/usr/local/lib/python2.2/profile.py", line 260, in
trace_dispatch_call
    assert rframe.f_back is frame.f_back, ("Bad call", rfn,
AssertionError: ('Bad call',
('/usr/local/lib/python2.2/xml/sax/expatreader.py', 132,
'feed'), <frame object at 0x81a880c>, <frame object at
0x81a840c>, <frame object at 0x81bb60c>, <frame object at
0x81a8a0c>)


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

Comment By: Andrew P. Lentvorski, Jr. (andrewl)
Date: 2002-07-01 22:57

Message:
Logged In: YES 
user_id=28733

There is another filing on this problem at:

http://mail.python.org/pipermail/xml-sig/2002-April/007632.html

Also, I reproduced this on another FreeBSD box today as
well.

andrewl@taz:andrewl$ python
Python 2.2.1 (#1, May 27 2002, 16:42:22) 
[GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4

-a


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

Comment By: Tim Peters (tim_one)
Date: 2002-07-01 15:55

Message:
Logged In: YES 
user_id=31435

I reproduced this with current CVS Python on Windows; 
see attached traceback.txt, which shows a screen dump of 
the offending <wink> interactive session.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-07-01 05:55

Message:
Logged In: YES 
user_id=21627

I can't reproduce it with the Python 2.2 that ships with
SuSE 8.0, either.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 12:30

Message:
Logged In: YES 
user_id=21627

I can't reproduce the crash, with 2.3a0.

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

Comment By: Tim Peters (tim_one)
Date: 2002-03-25 22:27

Message:
Logged In: YES 
user_id=31435

Assigned to Fred.

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

Comment By: Aron K. Insinga (ainsinga)
Date: 2002-03-25 21:19

Message:
Logged In: YES 
user_id=496408

attached is the sample program (which ought to have
indenting preserved!)


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

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


From noreply@sourceforge.net  Thu Aug  1 10:08:54 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 01 Aug 2002 02:08:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-589427 ] standard include paths on command line
Message-ID: <E17aBx0-0002Uj-00@usw-sf-web1.sourceforge.net>

Bugs item #589427, was opened at 2002-08-01 00:13
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=589427&group_id=5470

Category: Build
Group: Python 2.3
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Matthias Klose (doko)
>Assigned to: Michael Hudson (mwh)
Summary: standard include paths on command line

Initial Comment:
when compiling shared modules (using gcc-3.1.1), 
standard include paths are included (by setup.py?) in 
the include path, which can change the search order. 
gcc-3.1 warns about:

building 'xreadlines' extension
gcc-3.1 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -
fPIC -I. -I/home/packages/pyt
hon2.3/python2.3-2.2.90/./Include -I/usr/include -
I/usr/local/include -I/home/pa
ckages/python2.3/python2.3-2.2.90/Include -
I/home/packages/python2.3/python2.3-2
.2.90/build-static -
c /home/packages/python2.3/python2.3-
2.2.90/Modules/xreadlin
esmodule.c -o build/temp.linux-i686-
2.3/xreadlinesmodule.o
gcc -shared build/temp.linux-i686-
2.3/xreadlinesmodule.o -L/usr/lib -L/usr/local
/lib -o build/lib.linux-i686-2.3/xreadlines.so
building 'array' extension
gcc-3.1 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -
fPIC -I. -I/hocc1: warning: c
hanging search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory

In this case, /usr/include and /usr/local/include should 
not be included on the command line.


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

>Comment By: Michael Hudson (mwh)
Date: 2002-08-01 09:08

Message:
Logged In: YES 
user_id=6656

This has been deemed a bug in gcc, see this thread:

http://mail.python.org/pipermail/python-dev/2002-June/025990.html

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

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


From noreply@sourceforge.net  Thu Aug  1 11:56:42 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 01 Aug 2002 03:56:42 -0700
Subject: [Python-bugs-list] [ python-Bugs-534864 ] profiling with xml parsing asserts
Message-ID: <E17aDdK-0004h4-00@usw-sf-web1.sourceforge.net>

Bugs item #534864, was opened at 2002-03-25 22:15
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=534864&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Aron K. Insinga (ainsinga)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: profiling with xml parsing asserts

Initial Comment:
I'm getting a 'bad call' assertion error when using the
profiler when parsing XML.  (It works ok without the
profiler, and if I don't call SAXparser.parse it
doesn't happen.)


Python 2.2 (#1, Dec 23 2001, 09:30:32)
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on
linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import t4crash
start document
end document
>>> import profile
>>> t4crash.test()
start document
end document
>>> profile.run('t4crash.test()')
start document
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.2/profile.py", line 71, in run
    prof = prof.run(statement)
  File "/usr/lib/python2.2/profile.py", line 404, in
run
    return self.runctx(cmd, dict, dict)
  File "/usr/lib/python2.2/profile.py", line 410, in
runctx
    exec cmd in globals, locals
  File "<string>", line 1, in ?
  File "t4crash.py", line 46, in test
    main(files)
  File "t4crash.py", line 39, in main
    SAXparser.parse(fileName)
  File
"/var/tmp/python2-2.2-root/usr/lib/python2.2/xml/sax/expatreader.py",
line 53, in parse
  File
"/var/tmp/python2-2.2-root/usr/lib/python2.2/xml/sax/xmlreader.py",
line
123, in parse  File
"/var/tmp/python2-2.2-root/usr/lib/python2.2/xml/sax/expatreader.py",
line 106,
in feed
  File
"/var/tmp/python2-2.2-root/usr/lib/python2.2/xml/sax/expatreader.py",
line 179, in start_element
  File "/usr/lib/python2.2/profile.py", line 214, in
trace_dispatch_i
    if self.dispatch[event](self, frame,t):
  File "/usr/lib/python2.2/profile.py", line 260, in
trace_dispatch_call
    assert rframe.f_back is frame.f_back, ("Bad call",
rfn,
AssertionError: ('Bad call',
('/var/tmp/python2-2.2-root/usr/lib/python2.2/xml/sax/expatreader.py',
95,
'feed'), <frame object at 0x81d5454>, <frame object at
0x81c82e4>, <frame object
at 0x81d50b4>, <frame object at 0x81d5284>)
>>>
[ainsinga@ainsinga index_xml]$ cat t4crash.py
#!/usr/bin/env python2

# t4crash.py by Aron K. Insinga (aron.insinga@av.com)
25-Mar-2002

import xml.sax
import sys
import string
import re


class ContentHandler(xml.sax.ContentHandler):
    """ Handle callbacks from the SAX XML parser. """

    def __init__(selfy):
        pass

    def setDocumentLocator(self, locator):
        pass

    def startDocument(self):
        print 'start document'

    def endDocument(self):
        print 'end document'

    def startElement(self, name, attrs):
        pass

    def endElement(self, name):
        pass


def main(files):
    SAXparser = xml.sax.make_parser()
    chand = ContentHandler()
    SAXparser.setContentHandler(chand)
    try:
        for fileName in files:
            SAXparser.parse(fileName)
    except xml.sax.SAXParseException:
        sys.stderr.write("%s; processing aborted\n" %
(xml.sax.SAXParseException))
        sys.exit(1)

def test():
    files = ['doc0.xml']
    main(files)

test()
[ainsinga@ainsinga index_xml]$ cat doc0.xml
<?xml version="1.0" encoding="ISO-8859-1"?>
<html>
  <head>
    <title>Gettysburg Address</title>
  </head>
  <body>
    <p>
      Four score and seven years ago...<br/>
    </p>
  </body>
  <info>
    <author>
     
<lastname>Lincoln</lastname><firstname>Abraham</firstname>
    </author>
    <date>
      <month>11</month><day>19</day><year>1863</year>
    </date>
    <editor /><!-- editor name="aki"/ -->
    <editor/>
  </info>
</html>
[ainsinga@ainsinga index_xml]$ which python
/usr/bin/python
[ainsinga@ainsinga index_xml]$ set | grep PATH
LD_LIBRARY_PATH=/home/ainsinga/adabas/lib:/home/ainsinga/adabas/lib:/home/ainsinga/adabas/lib:/home/ainsinga/adabas/lib:/home/ainsinga/adabas/lib:
PATH=$'/home/ainsinga/adabas/bin:/home/ainsinga/adabas/pgm:.:/home/ainsinga/adabas/bin:/home/ainsinga/adabas/pgm:.:/home/ainsinga/adabas/bin:/home/ainsinga/adabas/pgm:.:/home/ainsinga/adabas/bin:/home/ainsinga/adabas/pgm:.:.:/home/ainsinga/bin:/home/ainsinga/adabas/bin:/home/ainsinga/adabas/pgm:.:/bin:/usr/bin:/usr/X11R6/bin:/usr/local/bin:~/staroffice6.0:/home/ainsinga/mozilla:~/staroffice6.0:/home/ainsinga/mozilla:~/staroffice6.0:/home/ainsinga/mozilla:~/staroffice6.0:/home/ainsinga/mozilla:~/
staroffice6.0:/home/ainsinga/mozilla'
[ainsinga@ainsinga index_xml]$ set | grep -i py
[ainsinga@ainsinga index_xml]$uname -a
Linux ainsinga 2.4.7-10 #1 Thu Sep 6 17:27:27 EDT 2001
i686 unknown
[ainsinga@ainsinga index_xml]$


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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-08-01 12:56

Message:
Logged In: YES 
user_id=21627

Confirming that the patch solves the problem for you would help.

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

Comment By: Andrew P. Lentvorski, Jr. (andrewl)
Date: 2002-08-01 10:57

Message:
Logged In: YES 
user_id=28733

I took a quick look in the browsable CVS repository, and the
diff to expat.c doesn't seem to be committed.  Is there
something further that I need to do so that this bug can get
closed?

-a

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-07-02 09:05

Message:
Logged In: YES 
user_id=21627

Attached is a patch that fixes the problem.

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

Comment By: Andrew P. Lentvorski, Jr. (andrewl)
Date: 2002-07-02 02:13

Message:
Logged In: YES 
user_id=28733

The xmltest.py program follows since I appear to be too
stupid to figure out how to attach a file to a bug report on
SourceForge.

-a

#!/usr/bin/env python

import xml.sax

testxml = \
"""
<html />
"""

class ContentHandler(xml.sax.ContentHandler):
    """ Handle callbacks from the SAX XML parser. """

    def __init__(self):
        pass

    def startElement(self, name, attrs):
        print "start element"

    def endElement(self, name):
        print "end element"

def main():
    chand = ContentHandler()
    xml.sax.parseString(testxml, chand)

if __name__ == "__main__":
    main()


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

Comment By: Andrew P. Lentvorski, Jr. (andrewl)
Date: 2002-07-02 02:01

Message:
Logged In: YES 
user_id=28733

Here is a session log for a much more self-contained
regression file (xmltest.py):

andrewl@taz:andrewl$ python
Python 2.2.1 (#1, May 27 2002, 16:42:22) 
[GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4
Type "help", "copyright", "credits" or "license" for more
information.
>>> import profile
>>> import xmltest
>>> profile.run('xmltest.main()')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.2/profile.py", line 71, in
run
    prof = prof.run(statement)
  File "/usr/local/lib/python2.2/profile.py", line 404, in
run
    return self.runctx(cmd, dict, dict)
  File "/usr/local/lib/python2.2/profile.py", line 410, in
runctx
    exec cmd in globals, locals
  File "<string>", line 1, in ?
  File "xmltest.py", line 24, in main
    xml.sax.parseString(testxml, chand)
  File "/usr/local/lib/python2.2/xml/sax/__init__.py", line
49, in parseString
    parser.parse(inpsrc)
  File "/usr/local/lib/python2.2/xml/sax/expatreader.py",
line 90, in parse
    xmlreader.IncrementalParser.parse(self, source)
  File "/usr/local/lib/python2.2/xml/sax/xmlreader.py", line
123, in parse
    self.feed(buffer)
  File "/usr/local/lib/python2.2/xml/sax/expatreader.py",
line 143, in feed
    self._parser.Parse(data, isFinal)
  File "/usr/local/lib/python2.2/xml/sax/expatreader.py",
line 216, in start_element
    def start_element(self, name, attrs):
  File "/usr/local/lib/python2.2/profile.py", line 214, in
trace_dispatch_i
    if self.dispatch[event](self, frame,t):
  File "/usr/local/lib/python2.2/profile.py", line 260, in
trace_dispatch_call
    assert rframe.f_back is frame.f_back, ("Bad call", rfn,
AssertionError: ('Bad call',
('/usr/local/lib/python2.2/xml/sax/expatreader.py', 132,
'feed'), <frame object at 0x81a880c>, <frame object at
0x81a840c>, <frame object at 0x81bb60c>, <frame object at
0x81a8a0c>)


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

Comment By: Andrew P. Lentvorski, Jr. (andrewl)
Date: 2002-07-02 00:57

Message:
Logged In: YES 
user_id=28733

There is another filing on this problem at:

http://mail.python.org/pipermail/xml-sig/2002-April/007632.html

Also, I reproduced this on another FreeBSD box today as
well.

andrewl@taz:andrewl$ python
Python 2.2.1 (#1, May 27 2002, 16:42:22) 
[GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4

-a


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

Comment By: Tim Peters (tim_one)
Date: 2002-07-01 17:55

Message:
Logged In: YES 
user_id=31435

I reproduced this with current CVS Python on Windows; 
see attached traceback.txt, which shows a screen dump of 
the offending <wink> interactive session.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-07-01 07:55

Message:
Logged In: YES 
user_id=21627

I can't reproduce it with the Python 2.2 that ships with
SuSE 8.0, either.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 13:30

Message:
Logged In: YES 
user_id=21627

I can't reproduce the crash, with 2.3a0.

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

Comment By: Tim Peters (tim_one)
Date: 2002-03-25 23:27

Message:
Logged In: YES 
user_id=31435

Assigned to Fred.

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

Comment By: Aron K. Insinga (ainsinga)
Date: 2002-03-25 22:19

Message:
Logged In: YES 
user_id=496408

attached is the sample program (which ought to have
indenting preserved!)


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

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


From noreply@sourceforge.net  Thu Aug  1 21:23:19 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 01 Aug 2002 13:23:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-589427 ] standard include paths on command line
Message-ID: <E17aMTf-0002VE-00@usw-sf-web3.sourceforge.net>

Bugs item #589427, was opened at 2002-08-01 00:13
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=589427&group_id=5470

Category: Build
Group: Python 2.3
>Status: Open
Resolution: Invalid
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Michael Hudson (mwh)
Summary: standard include paths on command line

Initial Comment:
when compiling shared modules (using gcc-3.1.1), 
standard include paths are included (by setup.py?) in 
the include path, which can change the search order. 
gcc-3.1 warns about:

building 'xreadlines' extension
gcc-3.1 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -
fPIC -I. -I/home/packages/pyt
hon2.3/python2.3-2.2.90/./Include -I/usr/include -
I/usr/local/include -I/home/pa
ckages/python2.3/python2.3-2.2.90/Include -
I/home/packages/python2.3/python2.3-2
.2.90/build-static -
c /home/packages/python2.3/python2.3-
2.2.90/Modules/xreadlin
esmodule.c -o build/temp.linux-i686-
2.3/xreadlinesmodule.o
gcc -shared build/temp.linux-i686-
2.3/xreadlinesmodule.o -L/usr/lib -L/usr/local
/lib -o build/lib.linux-i686-2.3/xreadlines.so
building 'array' extension
gcc-3.1 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -
fPIC -I. -I/hocc1: warning: c
hanging search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory

In this case, /usr/include and /usr/local/include should 
not be included on the command line.


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

>Comment By: Matthias Klose (doko)
Date: 2002-08-01 20:23

Message:
Logged In: YES 
user_id=60903

I disagree. The discussion is on /usr/local/include. We are 
talking about /usr/include, which is a system include dir on 
almost all systems.

See the thread "gcc 3.2's cpp breaks configure scripts" at 
http://gcc.gnu.org/ml/gcc/2002-07/, i.e.:

http://gcc.gnu.org/ml/gcc/2002-07/msg01527.html

Inclusion of /usr/include can lead to errors, as explained in:
http://gcc.gnu.org/ml/gcc/2002-07/msg01541.html

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

Comment By: Michael Hudson (mwh)
Date: 2002-08-01 09:08

Message:
Logged In: YES 
user_id=6656

This has been deemed a bug in gcc, see this thread:

http://mail.python.org/pipermail/python-dev/2002-June/025990.html

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

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


From noreply@sourceforge.net  Thu Aug  1 21:33:48 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 01 Aug 2002 13:33:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-570678 ] CGIHTTPServer flushes read-only file.
Message-ID: <E17aMdo-0001JR-00@usw-sf-web5.sourceforge.net>

Bugs item #570678, was opened at 2002-06-18 09:59
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=570678&group_id=5470

Category: Python Library
Group: Platform-specific
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Tony Lownds (tonylownds)
Assigned to: Jack Jansen (jackjansen)
Summary: CGIHTTPServer flushes read-only file.

Initial Comment:
On Mac OS X, flushing a file open only for reading
causing an IOError. That behavior matches what the
system's fflush man page describes:

ERRORS
     [EBADF]            Stream is not an open stream,
or, in the case of
                        fflush(), not a stream open for
writing.

CGIHTTPServer.py calls .flush on the read-only part of
it's socket before it forks and then quickly breaks.

The attached patch simply removes that line.
The bug is listed as Platform-specific because this
behavior does not appear under Linux (even though the
fflush man page on Linux lists the same EBADF error).



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

Comment By: Kevin Altis (kasplat)
Date: 2002-08-01 13:33

Message:
Logged In: YES 
user_id=228025

If this patch has been accepted and integrated into the 
sources in cvs, then this should issue should be closed out. If 
there is some reason it hasn't been rolled into the sources, 
what is the reason?

I'm just trying to chase down the issues with the CGI handling 
in the standard lib for Windows and OS X. Commenting out 
the flush line appears to allow CGIs to work. It appears that 
environment variables are not showing up in CGIs on the Mac 
OS X, but that should be a separate issue.

Thanks,

ka

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-19 08:26

Message:
Logged In: YES 
user_id=6380

I thought the C standard supports fflush() on a stream open
for reading as a way to clear the buffer and reposition the
file descriptor to its logical position. Maybe I'm mistaken;
maybe the MacOS X stdio library is not standard-conforming.
But I think it's fine to take that flush() out here, because
(1) it's a socket, and (2) it's unbuffered.

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

Comment By: Jack Jansen (jackjansen)
Date: 2002-06-19 02:26

Message:
Logged In: YES 
user_id=45365

Apparently Guido is the one who put the self.rfile.flush() call in there, so he's probably also the person who knows whether it's a good idea to take it out again.

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

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


From noreply@sourceforge.net  Thu Aug  1 22:13:31 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 01 Aug 2002 14:13:31 -0700
Subject: [Python-bugs-list] [ python-Bugs-570678 ] CGIHTTPServer flushes read-only file.
Message-ID: <E17aNGF-0004Wh-00@usw-sf-web2.sourceforge.net>

Bugs item #570678, was opened at 2002-06-18 12:59
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=570678&group_id=5470

Category: Python Library
Group: Platform-specific
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Tony Lownds (tonylownds)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: CGIHTTPServer flushes read-only file.

Initial Comment:
On Mac OS X, flushing a file open only for reading
causing an IOError. That behavior matches what the
system's fflush man page describes:

ERRORS
     [EBADF]            Stream is not an open stream,
or, in the case of
                        fflush(), not a stream open for
writing.

CGIHTTPServer.py calls .flush on the read-only part of
it's socket before it forks and then quickly breaks.

The attached patch simply removes that line.
The bug is listed as Platform-specific because this
behavior does not appear under Linux (even though the
fflush man page on Linux lists the same EBADF error).



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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-01 17:13

Message:
Logged In: YES 
user_id=6380

OK, checked in. Thanks for reminding me (it had fallen off
my plate :-).

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

Comment By: Kevin Altis (kasplat)
Date: 2002-08-01 16:33

Message:
Logged In: YES 
user_id=228025

If this patch has been accepted and integrated into the 
sources in cvs, then this should issue should be closed out. If 
there is some reason it hasn't been rolled into the sources, 
what is the reason?

I'm just trying to chase down the issues with the CGI handling 
in the standard lib for Windows and OS X. Commenting out 
the flush line appears to allow CGIs to work. It appears that 
environment variables are not showing up in CGIs on the Mac 
OS X, but that should be a separate issue.

Thanks,

ka

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-19 11:26

Message:
Logged In: YES 
user_id=6380

I thought the C standard supports fflush() on a stream open
for reading as a way to clear the buffer and reposition the
file descriptor to its logical position. Maybe I'm mistaken;
maybe the MacOS X stdio library is not standard-conforming.
But I think it's fine to take that flush() out here, because
(1) it's a socket, and (2) it's unbuffered.

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

Comment By: Jack Jansen (jackjansen)
Date: 2002-06-19 05:26

Message:
Logged In: YES 
user_id=45365

Apparently Guido is the one who put the self.rfile.flush() call in there, so he's probably also the person who knows whether it's a good idea to take it out again.

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

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


From noreply@sourceforge.net  Fri Aug  2 06:27:28 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 01 Aug 2002 22:27:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-589965 ] "".split() ignores maxsplit arg
Message-ID: <E17aUyG-0003kr-00@usw-sf-web2.sourceforge.net>

Bugs item #589965, was opened at 2002-08-02 15:27
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=589965&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregory Bond (gnbond)
Assigned to: Nobody/Anonymous (nobody)
Summary: "".split() ignores maxsplit arg

Initial Comment:
lightning$ python
Python 2.1.1 (#4, Oct 10 2001, 11:07:04) 
[GCC 2.95.3 20010315 (release)] on sunos5
Type "copyright", "credits" or "license" for more
information.
>>> s = 'a b c d e f g'
>>> s.split()
['a', 'b', 'c', 'd', 'e', 'f', 'g']
>>> s.split(maxsplit=3)
['a', 'b', 'c', 'd', 'e', 'f', 'g']
>>> import string
>>> string.split(s, maxsplit=3)
['a', 'b', 'c', 'd e f g']
>>> 
lightning$ 

i.e. s.split(maxsplit=3) is NOT the same as
string.split(s, maxsplit=3)


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

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


From noreply@sourceforge.net  Fri Aug  2 09:53:12 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 02 Aug 2002 01:53:12 -0700
Subject: [Python-bugs-list] [ python-Bugs-589427 ] standard include paths on command line
Message-ID: <E17aYBM-0007Em-00@usw-sf-web1.sourceforge.net>

Bugs item #589427, was opened at 2002-08-01 00:13
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=589427&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: Invalid
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Michael Hudson (mwh)
Summary: standard include paths on command line

Initial Comment:
when compiling shared modules (using gcc-3.1.1), 
standard include paths are included (by setup.py?) in 
the include path, which can change the search order. 
gcc-3.1 warns about:

building 'xreadlines' extension
gcc-3.1 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -
fPIC -I. -I/home/packages/pyt
hon2.3/python2.3-2.2.90/./Include -I/usr/include -
I/usr/local/include -I/home/pa
ckages/python2.3/python2.3-2.2.90/Include -
I/home/packages/python2.3/python2.3-2
.2.90/build-static -
c /home/packages/python2.3/python2.3-
2.2.90/Modules/xreadlin
esmodule.c -o build/temp.linux-i686-
2.3/xreadlinesmodule.o
gcc -shared build/temp.linux-i686-
2.3/xreadlinesmodule.o -L/usr/lib -L/usr/local
/lib -o build/lib.linux-i686-2.3/xreadlines.so
building 'array' extension
gcc-3.1 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -
fPIC -I. -I/hocc1: warning: c
hanging search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory

In this case, /usr/include and /usr/local/include should 
not be included on the command line.


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

>Comment By: Michael Hudson (mwh)
Date: 2002-08-02 08:53

Message:
Logged In: YES 
user_id=6656

Ah, sorry!

Hmm.  Now I don't see the problem, i.e. for me
-I/usr/include is not part of the command line passed to the
compiler.

Are you building from up-to-date CVS?  Though I don't recall
any recent changes in this area.  Ahh, you're running
".../configure --prefix=/usr", right?

I'll dig.

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

Comment By: Matthias Klose (doko)
Date: 2002-08-01 20:23

Message:
Logged In: YES 
user_id=60903

I disagree. The discussion is on /usr/local/include. We are 
talking about /usr/include, which is a system include dir on 
almost all systems.

See the thread "gcc 3.2's cpp breaks configure scripts" at 
http://gcc.gnu.org/ml/gcc/2002-07/, i.e.:

http://gcc.gnu.org/ml/gcc/2002-07/msg01527.html

Inclusion of /usr/include can lead to errors, as explained in:
http://gcc.gnu.org/ml/gcc/2002-07/msg01541.html

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

Comment By: Michael Hudson (mwh)
Date: 2002-08-01 09:08

Message:
Logged In: YES 
user_id=6656

This has been deemed a bug in gcc, see this thread:

http://mail.python.org/pipermail/python-dev/2002-June/025990.html

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

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


From noreply@sourceforge.net  Fri Aug  2 13:54:12 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 02 Aug 2002 05:54:12 -0700
Subject: [Python-bugs-list] [ python-Bugs-589427 ] standard include paths on command line
Message-ID: <E17abwa-0003vZ-00@usw-sf-web1.sourceforge.net>

Bugs item #589427, was opened at 2002-08-01 00:13
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=589427&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: Invalid
Priority: 5
Submitted By: Matthias Klose (doko)
>Assigned to: Martin v. Löwis (loewis)
Summary: standard include paths on command line

Initial Comment:
when compiling shared modules (using gcc-3.1.1), 
standard include paths are included (by setup.py?) in 
the include path, which can change the search order. 
gcc-3.1 warns about:

building 'xreadlines' extension
gcc-3.1 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -
fPIC -I. -I/home/packages/pyt
hon2.3/python2.3-2.2.90/./Include -I/usr/include -
I/usr/local/include -I/home/pa
ckages/python2.3/python2.3-2.2.90/Include -
I/home/packages/python2.3/python2.3-2
.2.90/build-static -
c /home/packages/python2.3/python2.3-
2.2.90/Modules/xreadlin
esmodule.c -o build/temp.linux-i686-
2.3/xreadlinesmodule.o
gcc -shared build/temp.linux-i686-
2.3/xreadlinesmodule.o -L/usr/lib -L/usr/local
/lib -o build/lib.linux-i686-2.3/xreadlines.so
building 'array' extension
gcc-3.1 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -
fPIC -I. -I/hocc1: warning: c
hanging search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory

In this case, /usr/include and /usr/local/include should 
not be included on the command line.


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

>Comment By: Michael Hudson (mwh)
Date: 2002-08-02 12:54

Message:
Logged In: YES 
user_id=6656

OK, can you try the attached patch?

Martin, does this look OK to you?

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

Comment By: Michael Hudson (mwh)
Date: 2002-08-02 08:53

Message:
Logged In: YES 
user_id=6656

Ah, sorry!

Hmm.  Now I don't see the problem, i.e. for me
-I/usr/include is not part of the command line passed to the
compiler.

Are you building from up-to-date CVS?  Though I don't recall
any recent changes in this area.  Ahh, you're running
".../configure --prefix=/usr", right?

I'll dig.

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

Comment By: Matthias Klose (doko)
Date: 2002-08-01 20:23

Message:
Logged In: YES 
user_id=60903

I disagree. The discussion is on /usr/local/include. We are 
talking about /usr/include, which is a system include dir on 
almost all systems.

See the thread "gcc 3.2's cpp breaks configure scripts" at 
http://gcc.gnu.org/ml/gcc/2002-07/, i.e.:

http://gcc.gnu.org/ml/gcc/2002-07/msg01527.html

Inclusion of /usr/include can lead to errors, as explained in:
http://gcc.gnu.org/ml/gcc/2002-07/msg01541.html

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

Comment By: Michael Hudson (mwh)
Date: 2002-08-01 09:08

Message:
Logged In: YES 
user_id=6656

This has been deemed a bug in gcc, see this thread:

http://mail.python.org/pipermail/python-dev/2002-June/025990.html

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

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


From noreply@sourceforge.net  Fri Aug  2 14:18:54 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 02 Aug 2002 06:18:54 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-590115 ] please add list.stable_sort()
Message-ID: <E17acKU-0003hL-00@usw-sf-web4.sourceforge.net>

Feature Requests item #590115, was opened at 2002-08-02 15:18
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=590115&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Markus F.X.J. Oberhumer (mfx)
Assigned to: Nobody/Anonymous (nobody)
Summary: please add list.stable_sort()

Initial Comment:
Now that we have a default stable list.sort() algorithm
in the CVS it would be very nice to guarantee some
stable-sorting for future (i.e. post 2.3) Python versions.

I therefore propose the addtion of a list method
stable_sort().

The motivation behind this is that I fear that sooner
or later Tim will find yet another major improvement in
the sort implementation that might no longer provide
stability <wink>

Currently, doing stable sorting "by hand" typically
involves using tuples with added index fields as keys,
which is more than suboptimal w.r.t perfomance, memory
and code cleanless.

Markus

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

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


From noreply@sourceforge.net  Fri Aug  2 14:49:06 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 02 Aug 2002 06:49:06 -0700
Subject: [Python-bugs-list] [ python-Bugs-589427 ] standard include paths on command line
Message-ID: <E17acni-0003C4-00@usw-sf-web5.sourceforge.net>

Bugs item #589427, was opened at 2002-08-01 02:13
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=589427&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Matthias Klose (doko)
>Assigned to: Michael Hudson (mwh)
Summary: standard include paths on command line

Initial Comment:
when compiling shared modules (using gcc-3.1.1), 
standard include paths are included (by setup.py?) in 
the include path, which can change the search order. 
gcc-3.1 warns about:

building 'xreadlines' extension
gcc-3.1 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -
fPIC -I. -I/home/packages/pyt
hon2.3/python2.3-2.2.90/./Include -I/usr/include -
I/usr/local/include -I/home/pa
ckages/python2.3/python2.3-2.2.90/Include -
I/home/packages/python2.3/python2.3-2
.2.90/build-static -
c /home/packages/python2.3/python2.3-
2.2.90/Modules/xreadlin
esmodule.c -o build/temp.linux-i686-
2.3/xreadlinesmodule.o
gcc -shared build/temp.linux-i686-
2.3/xreadlinesmodule.o -L/usr/lib -L/usr/local
/lib -o build/lib.linux-i686-2.3/xreadlines.so
building 'array' extension
gcc-3.1 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -
fPIC -I. -I/hocc1: warning: c
hanging search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory

In this case, /usr/include and /usr/local/include should 
not be included on the command line.


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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-08-02 15:49

Message:
Logged In: YES 
user_id=21627

The patch looks fine to me, please apply it.

I still think that the bogus warning should be removed from
gcc entirely.

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

Comment By: Michael Hudson (mwh)
Date: 2002-08-02 14:54

Message:
Logged In: YES 
user_id=6656

OK, can you try the attached patch?

Martin, does this look OK to you?

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

Comment By: Michael Hudson (mwh)
Date: 2002-08-02 10:53

Message:
Logged In: YES 
user_id=6656

Ah, sorry!

Hmm.  Now I don't see the problem, i.e. for me
-I/usr/include is not part of the command line passed to the
compiler.

Are you building from up-to-date CVS?  Though I don't recall
any recent changes in this area.  Ahh, you're running
".../configure --prefix=/usr", right?

I'll dig.

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

Comment By: Matthias Klose (doko)
Date: 2002-08-01 22:23

Message:
Logged In: YES 
user_id=60903

I disagree. The discussion is on /usr/local/include. We are 
talking about /usr/include, which is a system include dir on 
almost all systems.

See the thread "gcc 3.2's cpp breaks configure scripts" at 
http://gcc.gnu.org/ml/gcc/2002-07/, i.e.:

http://gcc.gnu.org/ml/gcc/2002-07/msg01527.html

Inclusion of /usr/include can lead to errors, as explained in:
http://gcc.gnu.org/ml/gcc/2002-07/msg01541.html

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

Comment By: Michael Hudson (mwh)
Date: 2002-08-01 11:08

Message:
Logged In: YES 
user_id=6656

This has been deemed a bug in gcc, see this thread:

http://mail.python.org/pipermail/python-dev/2002-June/025990.html

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

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


From noreply@sourceforge.net  Fri Aug  2 14:49:50 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 02 Aug 2002 06:49:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-589429 ] libpython.a with PIC objects
Message-ID: <E17acoQ-0003Cx-00@usw-sf-web5.sourceforge.net>

Bugs item #589429, was opened at 2002-08-01 02:17
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=589429&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: libpython.a with PIC objects

Initial Comment:
when configuring with --enable-shared, the "static" 
library libpython.a is build with PIC-compiled objects.
Using the option --enable-shared builds a shared library 
in addition to the static library (with objects compiled 
without PIC).


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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-08-02 15:49

Message:
Logged In: YES 
user_id=21627

What is the bug here?

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

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


From noreply@sourceforge.net  Fri Aug  2 14:56:56 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 02 Aug 2002 06:56:56 -0700
Subject: [Python-bugs-list] [ python-Bugs-589427 ] standard include paths on command line
Message-ID: <E17acvI-0004sY-00@usw-sf-web2.sourceforge.net>

Bugs item #589427, was opened at 2002-08-01 00:13
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=589427&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Michael Hudson (mwh)
Summary: standard include paths on command line

Initial Comment:
when compiling shared modules (using gcc-3.1.1), 
standard include paths are included (by setup.py?) in 
the include path, which can change the search order. 
gcc-3.1 warns about:

building 'xreadlines' extension
gcc-3.1 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -
fPIC -I. -I/home/packages/pyt
hon2.3/python2.3-2.2.90/./Include -I/usr/include -
I/usr/local/include -I/home/pa
ckages/python2.3/python2.3-2.2.90/Include -
I/home/packages/python2.3/python2.3-2
.2.90/build-static -
c /home/packages/python2.3/python2.3-
2.2.90/Modules/xreadlin
esmodule.c -o build/temp.linux-i686-
2.3/xreadlinesmodule.o
gcc -shared build/temp.linux-i686-
2.3/xreadlinesmodule.o -L/usr/lib -L/usr/local
/lib -o build/lib.linux-i686-2.3/xreadlines.so
building 'array' extension
gcc-3.1 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -
fPIC -I. -I/hocc1: warning: c
hanging search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory

In this case, /usr/include and /usr/local/include should 
not be included on the command line.


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

>Comment By: Michael Hudson (mwh)
Date: 2002-08-02 13:56

Message:
Logged In: YES 
user_id=6656

OK, done, in

setup.py revision 1.100

I don't see us removing /usr/local/include from the command
line.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-02 13:49

Message:
Logged In: YES 
user_id=21627

The patch looks fine to me, please apply it.

I still think that the bogus warning should be removed from
gcc entirely.

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

Comment By: Michael Hudson (mwh)
Date: 2002-08-02 12:54

Message:
Logged In: YES 
user_id=6656

OK, can you try the attached patch?

Martin, does this look OK to you?

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

Comment By: Michael Hudson (mwh)
Date: 2002-08-02 08:53

Message:
Logged In: YES 
user_id=6656

Ah, sorry!

Hmm.  Now I don't see the problem, i.e. for me
-I/usr/include is not part of the command line passed to the
compiler.

Are you building from up-to-date CVS?  Though I don't recall
any recent changes in this area.  Ahh, you're running
".../configure --prefix=/usr", right?

I'll dig.

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

Comment By: Matthias Klose (doko)
Date: 2002-08-01 20:23

Message:
Logged In: YES 
user_id=60903

I disagree. The discussion is on /usr/local/include. We are 
talking about /usr/include, which is a system include dir on 
almost all systems.

See the thread "gcc 3.2's cpp breaks configure scripts" at 
http://gcc.gnu.org/ml/gcc/2002-07/, i.e.:

http://gcc.gnu.org/ml/gcc/2002-07/msg01527.html

Inclusion of /usr/include can lead to errors, as explained in:
http://gcc.gnu.org/ml/gcc/2002-07/msg01541.html

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

Comment By: Michael Hudson (mwh)
Date: 2002-08-01 09:08

Message:
Logged In: YES 
user_id=6656

This has been deemed a bug in gcc, see this thread:

http://mail.python.org/pipermail/python-dev/2002-June/025990.html

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

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


From noreply@sourceforge.net  Fri Aug  2 14:57:09 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 02 Aug 2002 06:57:09 -0700
Subject: [Python-bugs-list] [ python-Bugs-589427 ] standard include paths on command line
Message-ID: <E17acvV-0001YW-00@usw-sf-web3.sourceforge.net>

Bugs item #589427, was opened at 2002-08-01 00:13
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=589427&group_id=5470

Category: Build
Group: Python 2.3
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Michael Hudson (mwh)
Summary: standard include paths on command line

Initial Comment:
when compiling shared modules (using gcc-3.1.1), 
standard include paths are included (by setup.py?) in 
the include path, which can change the search order. 
gcc-3.1 warns about:

building 'xreadlines' extension
gcc-3.1 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -
fPIC -I. -I/home/packages/pyt
hon2.3/python2.3-2.2.90/./Include -I/usr/include -
I/usr/local/include -I/home/pa
ckages/python2.3/python2.3-2.2.90/Include -
I/home/packages/python2.3/python2.3-2
.2.90/build-static -
c /home/packages/python2.3/python2.3-
2.2.90/Modules/xreadlin
esmodule.c -o build/temp.linux-i686-
2.3/xreadlinesmodule.o
gcc -shared build/temp.linux-i686-
2.3/xreadlinesmodule.o -L/usr/lib -L/usr/local
/lib -o build/lib.linux-i686-2.3/xreadlines.so
building 'array' extension
gcc-3.1 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -
fPIC -I. -I/hocc1: warning: c
hanging search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory

In this case, /usr/include and /usr/local/include should 
not be included on the command line.


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

Comment By: Michael Hudson (mwh)
Date: 2002-08-02 13:56

Message:
Logged In: YES 
user_id=6656

OK, done, in

setup.py revision 1.100

I don't see us removing /usr/local/include from the command
line.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-02 13:49

Message:
Logged In: YES 
user_id=21627

The patch looks fine to me, please apply it.

I still think that the bogus warning should be removed from
gcc entirely.

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

Comment By: Michael Hudson (mwh)
Date: 2002-08-02 12:54

Message:
Logged In: YES 
user_id=6656

OK, can you try the attached patch?

Martin, does this look OK to you?

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

Comment By: Michael Hudson (mwh)
Date: 2002-08-02 08:53

Message:
Logged In: YES 
user_id=6656

Ah, sorry!

Hmm.  Now I don't see the problem, i.e. for me
-I/usr/include is not part of the command line passed to the
compiler.

Are you building from up-to-date CVS?  Though I don't recall
any recent changes in this area.  Ahh, you're running
".../configure --prefix=/usr", right?

I'll dig.

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

Comment By: Matthias Klose (doko)
Date: 2002-08-01 20:23

Message:
Logged In: YES 
user_id=60903

I disagree. The discussion is on /usr/local/include. We are 
talking about /usr/include, which is a system include dir on 
almost all systems.

See the thread "gcc 3.2's cpp breaks configure scripts" at 
http://gcc.gnu.org/ml/gcc/2002-07/, i.e.:

http://gcc.gnu.org/ml/gcc/2002-07/msg01527.html

Inclusion of /usr/include can lead to errors, as explained in:
http://gcc.gnu.org/ml/gcc/2002-07/msg01541.html

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

Comment By: Michael Hudson (mwh)
Date: 2002-08-01 09:08

Message:
Logged In: YES 
user_id=6656

This has been deemed a bug in gcc, see this thread:

http://mail.python.org/pipermail/python-dev/2002-June/025990.html

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

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


From noreply@sourceforge.net  Fri Aug  2 15:05:56 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 02 Aug 2002 07:05:56 -0700
Subject: [Python-bugs-list] [ python-Bugs-589427 ] standard include paths on command line
Message-ID: <E17ad40-0003Xy-00@usw-sf-web5.sourceforge.net>

Bugs item #589427, was opened at 2002-08-01 02:13
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=589427&group_id=5470

Category: Build
Group: Python 2.3
Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Michael Hudson (mwh)
Summary: standard include paths on command line

Initial Comment:
when compiling shared modules (using gcc-3.1.1), 
standard include paths are included (by setup.py?) in 
the include path, which can change the search order. 
gcc-3.1 warns about:

building 'xreadlines' extension
gcc-3.1 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -
fPIC -I. -I/home/packages/pyt
hon2.3/python2.3-2.2.90/./Include -I/usr/include -
I/usr/local/include -I/home/pa
ckages/python2.3/python2.3-2.2.90/Include -
I/home/packages/python2.3/python2.3-2
.2.90/build-static -
c /home/packages/python2.3/python2.3-
2.2.90/Modules/xreadlin
esmodule.c -o build/temp.linux-i686-
2.3/xreadlinesmodule.o
gcc -shared build/temp.linux-i686-
2.3/xreadlinesmodule.o -L/usr/lib -L/usr/local
/lib -o build/lib.linux-i686-2.3/xreadlines.so
building 'array' extension
gcc-3.1 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -
fPIC -I. -I/hocc1: warning: c
hanging search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory

In this case, /usr/include and /usr/local/include should 
not be included on the command line.


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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-08-02 16:05

Message:
Logged In: YES 
user_id=21627

And indeed, we should not remove /usr/local/include, since
the system compiler may not be gcc.

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

Comment By: Michael Hudson (mwh)
Date: 2002-08-02 15:56

Message:
Logged In: YES 
user_id=6656

OK, done, in

setup.py revision 1.100

I don't see us removing /usr/local/include from the command
line.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-02 15:49

Message:
Logged In: YES 
user_id=21627

The patch looks fine to me, please apply it.

I still think that the bogus warning should be removed from
gcc entirely.

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

Comment By: Michael Hudson (mwh)
Date: 2002-08-02 14:54

Message:
Logged In: YES 
user_id=6656

OK, can you try the attached patch?

Martin, does this look OK to you?

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

Comment By: Michael Hudson (mwh)
Date: 2002-08-02 10:53

Message:
Logged In: YES 
user_id=6656

Ah, sorry!

Hmm.  Now I don't see the problem, i.e. for me
-I/usr/include is not part of the command line passed to the
compiler.

Are you building from up-to-date CVS?  Though I don't recall
any recent changes in this area.  Ahh, you're running
".../configure --prefix=/usr", right?

I'll dig.

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

Comment By: Matthias Klose (doko)
Date: 2002-08-01 22:23

Message:
Logged In: YES 
user_id=60903

I disagree. The discussion is on /usr/local/include. We are 
talking about /usr/include, which is a system include dir on 
almost all systems.

See the thread "gcc 3.2's cpp breaks configure scripts" at 
http://gcc.gnu.org/ml/gcc/2002-07/, i.e.:

http://gcc.gnu.org/ml/gcc/2002-07/msg01527.html

Inclusion of /usr/include can lead to errors, as explained in:
http://gcc.gnu.org/ml/gcc/2002-07/msg01541.html

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

Comment By: Michael Hudson (mwh)
Date: 2002-08-01 11:08

Message:
Logged In: YES 
user_id=6656

This has been deemed a bug in gcc, see this thread:

http://mail.python.org/pipermail/python-dev/2002-June/025990.html

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

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


From noreply@sourceforge.net  Fri Aug  2 15:36:12 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 02 Aug 2002 07:36:12 -0700
Subject: [Python-bugs-list] [ python-Bugs-588714 ] urllib.urlopen.geturl() and redirects
Message-ID: <E17adXI-0004FF-00@usw-sf-web5.sourceforge.net>

Bugs item #588714, was opened at 2002-07-30 19:11
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=588714&group_id=5470

Category: Python Library
Group: Python 2.2.1
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Jeremy Hylton (jhylton)
Summary: urllib.urlopen.geturl() and redirects

Initial Comment:
[From http://bugs.debian.org/146408]

From: Matthew Vernon <matthew@pick.ucam.org>
Subject: python2.2: urllib.urlopen.geturl() fails to
deal with redirects properly

urllib.urlopen.geturl() claims: "

The geturl() method returns the real URL of the page.
In some cases,
the HTTP server redirects a client to another URL. The
urlopen()
function handles this transparently, but in some cases
the caller
needs to know which URL the client was redirected to.
The geturl()
method can be used to get at this redirected URL.

But it appears not to:

>>>
urllib.urlopen("http://www.google.com/search?q=test&btnI=I'm+Feeling+Lucky").geturl()
"http://www.google.com/search?q=test&btnI=I'm+Feeling+Lucky"

Doing the same by steam:

HEAD
http://www.google.com/search?q=test&btnI=I'm+Feeling+Lucky
HTTP/1.1
Host: www.google.com

HTTP/1.0 302 Moved Temporarily
Content-Length: 151
Server: GWS/2.0
Date: Thu, 09 May 2002 16:51:37 GMT
Location: http://www.toefl.org/
Content-Type: text/html



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

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-08-02 14:36

Message:
Logged In: YES 
user_id=31392

The original bug report was that geturl() returns the
incorrect result.  In this case, it has returned the correct
URL because google did not redirect it.  There is no Python
bug here, so I trust the debian folks will close their bug
report, too.  The original poster should probably take up
the issue with Google, or set a custom user-agent header.


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

Comment By: Jeremy Hylton (jhylton)
Date: 2002-07-31 16:52

Message:
Logged In: YES 
user_id=31392

The body of the error message is interesting.  Google is
explicitly refusing to serve requests issues by urllib and
urllib2.  It appears to be keying on the User-Agent field.

<HTML><HEAD><TITLE>403 Forbidden</TITLE></HEAD>
<BODY><H1>403 Forbidden</H1>
Your client does not have permission to get URL
<code>/search?q=test&amp;btnI=I'm+Feeling+Lucky</code> from
this server.
(Client IP address: 208.251.201.35)<BR><BR>
Please see Google's Terms of Service posted at
http://www.google.com/terms_of_service.html
<BR><BR><P>If you believe that you have received this
response in error, please send email to <A
href="mailto:forbidden@google.com">forbidden@google.com</A>.
 Before sending this email, however, please make sure to
take a look at our Terms of Service
(http://www.google.com/terms_of_service.html).In your email,
please send us the <b>entire</b> code displayed below. 
Please also send us any information you may know about how
you are performing your Google searches-- for example, "I'm
using the Opera browser on Linux to do searches from home. 
My Internet access is through a dial-up account I have with
the FooCorp ISP." or "I'm using the Konqueror browser on
Linux to search from my job at myFoo.com.  My machine's IP
address is 10.20.30.40, but all of myFoo's web traffic goes
through some kind of proxy server whose IP address is
10.11.12.13."  (If you don't know any information like this,
that's OK.  But this kind of information can help us track
down problems, so please tell us what you can.)</P><P>We
will use all this information to diagnose the problem, and
we'll hopefully have you back up and Googlin' again quickly!</P>
<P>Please note that although we read all the email we
receive, we are not always able to send a personal response
to each and every email.  So don't despair if you don't hear
back from us!</P>
<P>Also note that if you do not send us the <b>entire</b>
code below, <i>we will not be able to help
you</i>.</P><P>Best wishes,<BR>The Google
Team</BR></P><BLOCKQUOTE>/+/+/+/+/+/+/+/+/+/+/+/+/+/+/+/+/+/+/+/+/+/+/+/+/<BR>
AD1IFXbQ-8kjZGNiMTEAAGtHRVQgL3NlYXJjaD9xPXRlc3QmY<BR>
nRuST1JJ20rRmVlbGluZytMdWNreSBIVFRQLzEuMA0KSG9zdD<BR>
ogd3d3Lmdvb2dsZS5jb20NClVzZXItYWdlbnQ6IFB5dGhvbi1<BR>
1cmxsaWIvMi4wYTENCrSY3UI=<BR>
+/+/+/+/+/+/+/+/+/+/+/+/+/+/+/+/+/+/+/+/+/+/+/+/+<BR></BLOCKQUOTE>

                                                           
                                                           
                                                           
                                                           
                                                           
                                                           
                                                           
                                                           
                                        
</BODY></HTML>


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

Comment By: Michael Hudson (mwh)
Date: 2002-07-31 08:34

Message:
Logged In: YES 
user_id=6656

Something even wierder happens when I try urllib2:

>>>
urllib2.urlopen("http://www.google.com/search?q=test&btnI=I'm+Feeling+Lucky").geturl()

Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/home/mwh/src/python/dist/src/Lib/urllib2.py", line
136, in urlopen
    return _opener.open(url, data)
  File "/home/mwh/src/python/dist/src/Lib/urllib2.py", line
324, in open
    '_open', req)
  File "/home/mwh/src/python/dist/src/Lib/urllib2.py", line
303, in _call_chain
    result = func(*args)
  File "/home/mwh/src/python/dist/src/Lib/urllib2.py", line
792, in http_open
    return self.do_open(httplib.HTTP, req)
  File "/home/mwh/src/python/dist/src/Lib/urllib2.py", line
786, in do_open
    return self.parent.error('http', req, fp, code, msg, hdrs)
  File "/home/mwh/src/python/dist/src/Lib/urllib2.py", line
350, in error
    return self._call_chain(*args)
  File "/home/mwh/src/python/dist/src/Lib/urllib2.py", line
303, in _call_chain
    result = func(*args)
  File "/home/mwh/src/python/dist/src/Lib/urllib2.py", line
402, in http_error_default
    raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
urllib2.HTTPError: HTTP Error 403: Forbidden

(sf is going to mangle that traceback, I can tell).

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

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


From noreply@sourceforge.net  Fri Aug  2 16:38:01 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 02 Aug 2002 08:38:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-590207 ] PyMapping_Keys unexported in dll
Message-ID: <E17aeV7-00069Y-00@usw-sf-web4.sourceforge.net>

Bugs item #590207, was opened at 2002-08-02 15:38
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=590207&group_id=5470

Category: Windows
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Marco Beri (marcoberi)
Assigned to: Tim Peters (tim_one)
Summary: PyMapping_Keys unexported in dll

Initial Comment:
PyMapping_Keys (as lots of other C API) is not 
exported in python22.dll.

Moreover, with a binary search I find an undocumented 
PyMapping_Size function.


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

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


From noreply@sourceforge.net  Fri Aug  2 19:24:44 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 02 Aug 2002 11:24:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-589429 ] libpython.a with PIC objects
Message-ID: <E17ah6S-00072P-00@usw-sf-web3.sourceforge.net>

Bugs item #589429, was opened at 2002-08-01 00:17
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=589429&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: libpython.a with PIC objects

Initial Comment:
when configuring with --enable-shared, the "static" 
library libpython.a is build with PIC-compiled objects.
Using the option --enable-shared builds a shared library 
in addition to the static library (with objects compiled 
without PIC).


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

>Comment By: Matthias Klose (doko)
Date: 2002-08-02 18:24

Message:
Logged In: YES 
user_id=60903

I expect (as mostly known from other GNU libraries on Linux
systems), that I get an additional library with
--enable-shared, not a changed static library.
Currently the option really is
--enable-shared-and-build-static-with-pic.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-02 13:49

Message:
Logged In: YES 
user_id=21627

What is the bug here?

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

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


From noreply@sourceforge.net  Fri Aug  2 21:06:15 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 02 Aug 2002 13:06:15 -0700
Subject: [Python-bugs-list] [ python-Bugs-534864 ] profiling with xml parsing asserts
Message-ID: <E17aigh-0005i5-00@usw-sf-web1.sourceforge.net>

Bugs item #534864, was opened at 2002-03-25 16:15
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=534864&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Aron K. Insinga (ainsinga)
>Assigned to: Martin v. Löwis (loewis)
Summary: profiling with xml parsing asserts

Initial Comment:
I'm getting a 'bad call' assertion error when using the
profiler when parsing XML.  (It works ok without the
profiler, and if I don't call SAXparser.parse it
doesn't happen.)


Python 2.2 (#1, Dec 23 2001, 09:30:32)
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on
linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import t4crash
start document
end document
>>> import profile
>>> t4crash.test()
start document
end document
>>> profile.run('t4crash.test()')
start document
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.2/profile.py", line 71, in run
    prof = prof.run(statement)
  File "/usr/lib/python2.2/profile.py", line 404, in
run
    return self.runctx(cmd, dict, dict)
  File "/usr/lib/python2.2/profile.py", line 410, in
runctx
    exec cmd in globals, locals
  File "<string>", line 1, in ?
  File "t4crash.py", line 46, in test
    main(files)
  File "t4crash.py", line 39, in main
    SAXparser.parse(fileName)
  File
"/var/tmp/python2-2.2-root/usr/lib/python2.2/xml/sax/expatreader.py",
line 53, in parse
  File
"/var/tmp/python2-2.2-root/usr/lib/python2.2/xml/sax/xmlreader.py",
line
123, in parse  File
"/var/tmp/python2-2.2-root/usr/lib/python2.2/xml/sax/expatreader.py",
line 106,
in feed
  File
"/var/tmp/python2-2.2-root/usr/lib/python2.2/xml/sax/expatreader.py",
line 179, in start_element
  File "/usr/lib/python2.2/profile.py", line 214, in
trace_dispatch_i
    if self.dispatch[event](self, frame,t):
  File "/usr/lib/python2.2/profile.py", line 260, in
trace_dispatch_call
    assert rframe.f_back is frame.f_back, ("Bad call",
rfn,
AssertionError: ('Bad call',
('/var/tmp/python2-2.2-root/usr/lib/python2.2/xml/sax/expatreader.py',
95,
'feed'), <frame object at 0x81d5454>, <frame object at
0x81c82e4>, <frame object
at 0x81d50b4>, <frame object at 0x81d5284>)
>>>
[ainsinga@ainsinga index_xml]$ cat t4crash.py
#!/usr/bin/env python2

# t4crash.py by Aron K. Insinga (aron.insinga@av.com)
25-Mar-2002

import xml.sax
import sys
import string
import re


class ContentHandler(xml.sax.ContentHandler):
    """ Handle callbacks from the SAX XML parser. """

    def __init__(selfy):
        pass

    def setDocumentLocator(self, locator):
        pass

    def startDocument(self):
        print 'start document'

    def endDocument(self):
        print 'end document'

    def startElement(self, name, attrs):
        pass

    def endElement(self, name):
        pass


def main(files):
    SAXparser = xml.sax.make_parser()
    chand = ContentHandler()
    SAXparser.setContentHandler(chand)
    try:
        for fileName in files:
            SAXparser.parse(fileName)
    except xml.sax.SAXParseException:
        sys.stderr.write("%s; processing aborted\n" %
(xml.sax.SAXParseException))
        sys.exit(1)

def test():
    files = ['doc0.xml']
    main(files)

test()
[ainsinga@ainsinga index_xml]$ cat doc0.xml
<?xml version="1.0" encoding="ISO-8859-1"?>
<html>
  <head>
    <title>Gettysburg Address</title>
  </head>
  <body>
    <p>
      Four score and seven years ago...<br/>
    </p>
  </body>
  <info>
    <author>
     
<lastname>Lincoln</lastname><firstname>Abraham</firstname>
    </author>
    <date>
      <month>11</month><day>19</day><year>1863</year>
    </date>
    <editor /><!-- editor name="aki"/ -->
    <editor/>
  </info>
</html>
[ainsinga@ainsinga index_xml]$ which python
/usr/bin/python
[ainsinga@ainsinga index_xml]$ set | grep PATH
LD_LIBRARY_PATH=/home/ainsinga/adabas/lib:/home/ainsinga/adabas/lib:/home/ainsinga/adabas/lib:/home/ainsinga/adabas/lib:/home/ainsinga/adabas/lib:
PATH=$'/home/ainsinga/adabas/bin:/home/ainsinga/adabas/pgm:.:/home/ainsinga/adabas/bin:/home/ainsinga/adabas/pgm:.:/home/ainsinga/adabas/bin:/home/ainsinga/adabas/pgm:.:/home/ainsinga/adabas/bin:/home/ainsinga/adabas/pgm:.:.:/home/ainsinga/bin:/home/ainsinga/adabas/bin:/home/ainsinga/adabas/pgm:.:/bin:/usr/bin:/usr/X11R6/bin:/usr/local/bin:~/staroffice6.0:/home/ainsinga/mozilla:~/staroffice6.0:/home/ainsinga/mozilla:~/staroffice6.0:/home/ainsinga/mozilla:~/staroffice6.0:/home/ainsinga/mozilla:~/
staroffice6.0:/home/ainsinga/mozilla'
[ainsinga@ainsinga index_xml]$ set | grep -i py
[ainsinga@ainsinga index_xml]$uname -a
Linux ainsinga 2.4.7-10 #1 Thu Sep 6 17:27:27 EDT 2001
i686 unknown
[ainsinga@ainsinga index_xml]$


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-02 16:06

Message:
Logged In: YES 
user_id=6380

It solves the isolated test case submitted by Andrew P.
Lentvorski to python-dev on July 1, so I propose to check
this in.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-01 06:56

Message:
Logged In: YES 
user_id=21627

Confirming that the patch solves the problem for you would help.

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

Comment By: Andrew P. Lentvorski, Jr. (andrewl)
Date: 2002-08-01 04:57

Message:
Logged In: YES 
user_id=28733

I took a quick look in the browsable CVS repository, and the
diff to expat.c doesn't seem to be committed.  Is there
something further that I need to do so that this bug can get
closed?

-a

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-07-02 03:05

Message:
Logged In: YES 
user_id=21627

Attached is a patch that fixes the problem.

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

Comment By: Andrew P. Lentvorski, Jr. (andrewl)
Date: 2002-07-01 20:13

Message:
Logged In: YES 
user_id=28733

The xmltest.py program follows since I appear to be too
stupid to figure out how to attach a file to a bug report on
SourceForge.

-a

#!/usr/bin/env python

import xml.sax

testxml = \
"""
<html />
"""

class ContentHandler(xml.sax.ContentHandler):
    """ Handle callbacks from the SAX XML parser. """

    def __init__(self):
        pass

    def startElement(self, name, attrs):
        print "start element"

    def endElement(self, name):
        print "end element"

def main():
    chand = ContentHandler()
    xml.sax.parseString(testxml, chand)

if __name__ == "__main__":
    main()


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

Comment By: Andrew P. Lentvorski, Jr. (andrewl)
Date: 2002-07-01 20:01

Message:
Logged In: YES 
user_id=28733

Here is a session log for a much more self-contained
regression file (xmltest.py):

andrewl@taz:andrewl$ python
Python 2.2.1 (#1, May 27 2002, 16:42:22) 
[GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4
Type "help", "copyright", "credits" or "license" for more
information.
>>> import profile
>>> import xmltest
>>> profile.run('xmltest.main()')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.2/profile.py", line 71, in
run
    prof = prof.run(statement)
  File "/usr/local/lib/python2.2/profile.py", line 404, in
run
    return self.runctx(cmd, dict, dict)
  File "/usr/local/lib/python2.2/profile.py", line 410, in
runctx
    exec cmd in globals, locals
  File "<string>", line 1, in ?
  File "xmltest.py", line 24, in main
    xml.sax.parseString(testxml, chand)
  File "/usr/local/lib/python2.2/xml/sax/__init__.py", line
49, in parseString
    parser.parse(inpsrc)
  File "/usr/local/lib/python2.2/xml/sax/expatreader.py",
line 90, in parse
    xmlreader.IncrementalParser.parse(self, source)
  File "/usr/local/lib/python2.2/xml/sax/xmlreader.py", line
123, in parse
    self.feed(buffer)
  File "/usr/local/lib/python2.2/xml/sax/expatreader.py",
line 143, in feed
    self._parser.Parse(data, isFinal)
  File "/usr/local/lib/python2.2/xml/sax/expatreader.py",
line 216, in start_element
    def start_element(self, name, attrs):
  File "/usr/local/lib/python2.2/profile.py", line 214, in
trace_dispatch_i
    if self.dispatch[event](self, frame,t):
  File "/usr/local/lib/python2.2/profile.py", line 260, in
trace_dispatch_call
    assert rframe.f_back is frame.f_back, ("Bad call", rfn,
AssertionError: ('Bad call',
('/usr/local/lib/python2.2/xml/sax/expatreader.py', 132,
'feed'), <frame object at 0x81a880c>, <frame object at
0x81a840c>, <frame object at 0x81bb60c>, <frame object at
0x81a8a0c>)


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

Comment By: Andrew P. Lentvorski, Jr. (andrewl)
Date: 2002-07-01 18:57

Message:
Logged In: YES 
user_id=28733

There is another filing on this problem at:

http://mail.python.org/pipermail/xml-sig/2002-April/007632.html

Also, I reproduced this on another FreeBSD box today as
well.

andrewl@taz:andrewl$ python
Python 2.2.1 (#1, May 27 2002, 16:42:22) 
[GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4

-a


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

Comment By: Tim Peters (tim_one)
Date: 2002-07-01 11:55

Message:
Logged In: YES 
user_id=31435

I reproduced this with current CVS Python on Windows; 
see attached traceback.txt, which shows a screen dump of 
the offending <wink> interactive session.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-07-01 01:55

Message:
Logged In: YES 
user_id=21627

I can't reproduce it with the Python 2.2 that ships with
SuSE 8.0, either.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 07:30

Message:
Logged In: YES 
user_id=21627

I can't reproduce the crash, with 2.3a0.

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

Comment By: Tim Peters (tim_one)
Date: 2002-03-25 17:27

Message:
Logged In: YES 
user_id=31435

Assigned to Fred.

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

Comment By: Aron K. Insinga (ainsinga)
Date: 2002-03-25 16:19

Message:
Logged In: YES 
user_id=496408

attached is the sample program (which ought to have
indenting preserved!)


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

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


From noreply@sourceforge.net  Fri Aug  2 21:26:13 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 02 Aug 2002 13:26:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-576419 ] Infinite recursion in Pickle
Message-ID: <E17aj01-0003IN-00@usw-sf-web2.sourceforge.net>

Bugs item #576419, was opened at 2002-07-02 11:02
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=576419&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Oleg Broytmann (phd)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: Infinite recursion in Pickle

Initial Comment:
Pickle falls into infininite recursion, cPickle crashed
(segfault on Linux, bus error on FreeBSD). See the
attached file. There is initial pickle (just a very
simple though somewhat large tree of bookmarks;
unfortunately lesser tree does not trigger the bug);
bkmk_objects.py module that includes class definitions
for the pickled object, and simple test program that
demonstrates the bug.

The program loads initial pickle, runs a function upon
it and saves the pickle back. The function runs through
the entire tree and creates backlinks - every object
got a link to its parent folder.

So it seems the bug is related to pickling objects with
loops.

When I changed builtin list as a parent class of Folder
to UserList (and recreated initial pickle) the bug
disappeared, so I think the bug is related to pickling
new classes.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-02 16:26

Message:
Logged In: YES 
user_id=6380

Mmm, interesting.

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

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


From noreply@sourceforge.net  Fri Aug  2 21:30:57 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 02 Aug 2002 13:30:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-576084 ] Sig11 in cPickle (stack overflow)
Message-ID: <E17aj4b-0002AH-00@usw-sf-web5.sourceforge.net>

Bugs item #576084, was opened at 2002-07-01 14:34
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=576084&group_id=5470

Category: Python Library
Group: None
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Jeff Epler (jepler)
>Assigned to: Martin v. Löwis (loewis)
Summary: Sig11 in cPickle (stack overflow)

Initial Comment:
The following program dies for me with a sig11.  It
appears that cPickle overflows the stack of the thread
where it executes.  (In my platform, the main thread's
stack is very large, but other threads' stacks are
fairly small)

Should some kind of guard be added in cPickle to stop
the overflow?
This does safely die with a "RuntimeError: maximum
recursion depth exceeded" when using regular pickle.

(I wrote this simple program after a python-dev poster
wrote that a "deeply recursive data structure" was
sometimes causing a sig11 inside cPickle.  I do not
know if this is the same problem as his or not)

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-02 16:30

Message:
Logged In: YES 
user_id=6380

Looks good. It fixes the test case. Only comment: would the
call to Py_GetRecursionLimit() cause a measurable slowdown?
(Hard to believe given the amount of work that's done
already.) Suggestion: check it in.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-07-30 11:21

Message:
Logged In: YES 
user_id=21627

Can you please try the attached patch?


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

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


From noreply@sourceforge.net  Fri Aug  2 21:42:39 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 02 Aug 2002 13:42:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-576419 ] Infinite recursion in Pickle
Message-ID: <E17ajFv-0001IF-00@usw-sf-web3.sourceforge.net>

Bugs item #576419, was opened at 2002-07-02 11:02
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=576419&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
>Priority: 3
Submitted By: Oleg Broytmann (phd)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Infinite recursion in Pickle

Initial Comment:
Pickle falls into infininite recursion, cPickle crashed
(segfault on Linux, bus error on FreeBSD). See the
attached file. There is initial pickle (just a very
simple though somewhat large tree of bookmarks;
unfortunately lesser tree does not trigger the bug);
bkmk_objects.py module that includes class definitions
for the pickled object, and simple test program that
demonstrates the bug.

The program loads initial pickle, runs a function upon
it and saves the pickle back. The function runs through
the entire tree and creates backlinks - every object
got a link to its parent folder.

So it seems the bug is related to pickling objects with
loops.

When I changed builtin list as a parent class of Folder
to UserList (and recreated initial pickle) the bug
disappeared, so I think the bug is related to pickling
new classes.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-02 16:42

Message:
Logged In: YES 
user_id=6380

Oleg, could it be that your data structure is just very
deeply nested? On my machine (RedHat Linux 7.2), your test
program completes without problem, so there doesn't seem to
be something in the data that inherently triggers a bug.
However, when I apply Martin von Loewis's patch from SF bug
576084, cPickle raises RuntimeError: maximum recursion depth
exceeded. I'm guessing that you are building what is in
essence a very long doubly-linked list; the pickle algorithm
necessarily has to enter a recursion level for each list
node in this case.

Switching to UserList probably reduces the number of stack
frames per recursion level and that would explain that it
doesn't fail.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-02 16:26

Message:
Logged In: YES 
user_id=6380

Mmm, interesting.

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

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


From noreply@sourceforge.net  Fri Aug  2 21:57:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 02 Aug 2002 13:57:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-590366 ] Small typo in listsort:ParseTuple
Message-ID: <E17ajUY-0003qT-00@usw-sf-web2.sourceforge.net>

Bugs item #590366, was opened at 2002-08-02 22:57
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=590366&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 2
Submitted By: Finn Bock (bckfnn)
Assigned to: Tim Peters (tim_one)
Summary: Small typo in listsort:ParseTuple

Initial Comment:
Internally the sort method is called 'msort':


Python 2.3a0 (#6, Aug  2 2002, 19:38:01)
[GCC 2.95.3-5 (cygwin special)] on cygwin
Type "help", "copyright", "credits" or "license" for
more information.
>>> [].sort(1,2)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: msort() takes at most 1 argument (2 given)
>>>

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

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


From noreply@sourceforge.net  Fri Aug  2 22:21:09 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 02 Aug 2002 14:21:09 -0700
Subject: [Python-bugs-list] [ python-Bugs-534864 ] profiling with xml parsing asserts
Message-ID: <E17ajrB-0004JZ-00@usw-sf-web4.sourceforge.net>

Bugs item #534864, was opened at 2002-03-25 21:15
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=534864&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Aron K. Insinga (ainsinga)
Assigned to: Martin v. Löwis (loewis)
Summary: profiling with xml parsing asserts

Initial Comment:
I'm getting a 'bad call' assertion error when using the
profiler when parsing XML.  (It works ok without the
profiler, and if I don't call SAXparser.parse it
doesn't happen.)


Python 2.2 (#1, Dec 23 2001, 09:30:32)
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on
linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import t4crash
start document
end document
>>> import profile
>>> t4crash.test()
start document
end document
>>> profile.run('t4crash.test()')
start document
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.2/profile.py", line 71, in run
    prof = prof.run(statement)
  File "/usr/lib/python2.2/profile.py", line 404, in
run
    return self.runctx(cmd, dict, dict)
  File "/usr/lib/python2.2/profile.py", line 410, in
runctx
    exec cmd in globals, locals
  File "<string>", line 1, in ?
  File "t4crash.py", line 46, in test
    main(files)
  File "t4crash.py", line 39, in main
    SAXparser.parse(fileName)
  File
"/var/tmp/python2-2.2-root/usr/lib/python2.2/xml/sax/expatreader.py",
line 53, in parse
  File
"/var/tmp/python2-2.2-root/usr/lib/python2.2/xml/sax/xmlreader.py",
line
123, in parse  File
"/var/tmp/python2-2.2-root/usr/lib/python2.2/xml/sax/expatreader.py",
line 106,
in feed
  File
"/var/tmp/python2-2.2-root/usr/lib/python2.2/xml/sax/expatreader.py",
line 179, in start_element
  File "/usr/lib/python2.2/profile.py", line 214, in
trace_dispatch_i
    if self.dispatch[event](self, frame,t):
  File "/usr/lib/python2.2/profile.py", line 260, in
trace_dispatch_call
    assert rframe.f_back is frame.f_back, ("Bad call",
rfn,
AssertionError: ('Bad call',
('/var/tmp/python2-2.2-root/usr/lib/python2.2/xml/sax/expatreader.py',
95,
'feed'), <frame object at 0x81d5454>, <frame object at
0x81c82e4>, <frame object
at 0x81d50b4>, <frame object at 0x81d5284>)
>>>
[ainsinga@ainsinga index_xml]$ cat t4crash.py
#!/usr/bin/env python2

# t4crash.py by Aron K. Insinga (aron.insinga@av.com)
25-Mar-2002

import xml.sax
import sys
import string
import re


class ContentHandler(xml.sax.ContentHandler):
    """ Handle callbacks from the SAX XML parser. """

    def __init__(selfy):
        pass

    def setDocumentLocator(self, locator):
        pass

    def startDocument(self):
        print 'start document'

    def endDocument(self):
        print 'end document'

    def startElement(self, name, attrs):
        pass

    def endElement(self, name):
        pass


def main(files):
    SAXparser = xml.sax.make_parser()
    chand = ContentHandler()
    SAXparser.setContentHandler(chand)
    try:
        for fileName in files:
            SAXparser.parse(fileName)
    except xml.sax.SAXParseException:
        sys.stderr.write("%s; processing aborted\n" %
(xml.sax.SAXParseException))
        sys.exit(1)

def test():
    files = ['doc0.xml']
    main(files)

test()
[ainsinga@ainsinga index_xml]$ cat doc0.xml
<?xml version="1.0" encoding="ISO-8859-1"?>
<html>
  <head>
    <title>Gettysburg Address</title>
  </head>
  <body>
    <p>
      Four score and seven years ago...<br/>
    </p>
  </body>
  <info>
    <author>
     
<lastname>Lincoln</lastname><firstname>Abraham</firstname>
    </author>
    <date>
      <month>11</month><day>19</day><year>1863</year>
    </date>
    <editor /><!-- editor name="aki"/ -->
    <editor/>
  </info>
</html>
[ainsinga@ainsinga index_xml]$ which python
/usr/bin/python
[ainsinga@ainsinga index_xml]$ set | grep PATH
LD_LIBRARY_PATH=/home/ainsinga/adabas/lib:/home/ainsinga/adabas/lib:/home/ainsinga/adabas/lib:/home/ainsinga/adabas/lib:/home/ainsinga/adabas/lib:
PATH=$'/home/ainsinga/adabas/bin:/home/ainsinga/adabas/pgm:.:/home/ainsinga/adabas/bin:/home/ainsinga/adabas/pgm:.:/home/ainsinga/adabas/bin:/home/ainsinga/adabas/pgm:.:/home/ainsinga/adabas/bin:/home/ainsinga/adabas/pgm:.:.:/home/ainsinga/bin:/home/ainsinga/adabas/bin:/home/ainsinga/adabas/pgm:.:/bin:/usr/bin:/usr/X11R6/bin:/usr/local/bin:~/staroffice6.0:/home/ainsinga/mozilla:~/staroffice6.0:/home/ainsinga/mozilla:~/staroffice6.0:/home/ainsinga/mozilla:~/staroffice6.0:/home/ainsinga/mozilla:~/
staroffice6.0:/home/ainsinga/mozilla'
[ainsinga@ainsinga index_xml]$ set | grep -i py
[ainsinga@ainsinga index_xml]$uname -a
Linux ainsinga 2.4.7-10 #1 Thu Sep 6 17:27:27 EDT 2001
i686 unknown
[ainsinga@ainsinga index_xml]$


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

Comment By: Andrew P. Lentvorski, Jr. (andrewl)
Date: 2002-08-02 21:21

Message:
Logged In: YES 
user_id=28733

I didn't realize you were waiting for confirmation from me
directly.  Preliminary runs look like the problem is fixed.

Please commit the patch and mark this bug as closed.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-02 20:06

Message:
Logged In: YES 
user_id=6380

It solves the isolated test case submitted by Andrew P.
Lentvorski to python-dev on July 1, so I propose to check
this in.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-01 10:56

Message:
Logged In: YES 
user_id=21627

Confirming that the patch solves the problem for you would help.

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

Comment By: Andrew P. Lentvorski, Jr. (andrewl)
Date: 2002-08-01 08:57

Message:
Logged In: YES 
user_id=28733

I took a quick look in the browsable CVS repository, and the
diff to expat.c doesn't seem to be committed.  Is there
something further that I need to do so that this bug can get
closed?

-a

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-07-02 07:05

Message:
Logged In: YES 
user_id=21627

Attached is a patch that fixes the problem.

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

Comment By: Andrew P. Lentvorski, Jr. (andrewl)
Date: 2002-07-02 00:13

Message:
Logged In: YES 
user_id=28733

The xmltest.py program follows since I appear to be too
stupid to figure out how to attach a file to a bug report on
SourceForge.

-a

#!/usr/bin/env python

import xml.sax

testxml = \
"""
<html />
"""

class ContentHandler(xml.sax.ContentHandler):
    """ Handle callbacks from the SAX XML parser. """

    def __init__(self):
        pass

    def startElement(self, name, attrs):
        print "start element"

    def endElement(self, name):
        print "end element"

def main():
    chand = ContentHandler()
    xml.sax.parseString(testxml, chand)

if __name__ == "__main__":
    main()


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

Comment By: Andrew P. Lentvorski, Jr. (andrewl)
Date: 2002-07-02 00:01

Message:
Logged In: YES 
user_id=28733

Here is a session log for a much more self-contained
regression file (xmltest.py):

andrewl@taz:andrewl$ python
Python 2.2.1 (#1, May 27 2002, 16:42:22) 
[GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4
Type "help", "copyright", "credits" or "license" for more
information.
>>> import profile
>>> import xmltest
>>> profile.run('xmltest.main()')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.2/profile.py", line 71, in
run
    prof = prof.run(statement)
  File "/usr/local/lib/python2.2/profile.py", line 404, in
run
    return self.runctx(cmd, dict, dict)
  File "/usr/local/lib/python2.2/profile.py", line 410, in
runctx
    exec cmd in globals, locals
  File "<string>", line 1, in ?
  File "xmltest.py", line 24, in main
    xml.sax.parseString(testxml, chand)
  File "/usr/local/lib/python2.2/xml/sax/__init__.py", line
49, in parseString
    parser.parse(inpsrc)
  File "/usr/local/lib/python2.2/xml/sax/expatreader.py",
line 90, in parse
    xmlreader.IncrementalParser.parse(self, source)
  File "/usr/local/lib/python2.2/xml/sax/xmlreader.py", line
123, in parse
    self.feed(buffer)
  File "/usr/local/lib/python2.2/xml/sax/expatreader.py",
line 143, in feed
    self._parser.Parse(data, isFinal)
  File "/usr/local/lib/python2.2/xml/sax/expatreader.py",
line 216, in start_element
    def start_element(self, name, attrs):
  File "/usr/local/lib/python2.2/profile.py", line 214, in
trace_dispatch_i
    if self.dispatch[event](self, frame,t):
  File "/usr/local/lib/python2.2/profile.py", line 260, in
trace_dispatch_call
    assert rframe.f_back is frame.f_back, ("Bad call", rfn,
AssertionError: ('Bad call',
('/usr/local/lib/python2.2/xml/sax/expatreader.py', 132,
'feed'), <frame object at 0x81a880c>, <frame object at
0x81a840c>, <frame object at 0x81bb60c>, <frame object at
0x81a8a0c>)


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

Comment By: Andrew P. Lentvorski, Jr. (andrewl)
Date: 2002-07-01 22:57

Message:
Logged In: YES 
user_id=28733

There is another filing on this problem at:

http://mail.python.org/pipermail/xml-sig/2002-April/007632.html

Also, I reproduced this on another FreeBSD box today as
well.

andrewl@taz:andrewl$ python
Python 2.2.1 (#1, May 27 2002, 16:42:22) 
[GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4

-a


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

Comment By: Tim Peters (tim_one)
Date: 2002-07-01 15:55

Message:
Logged In: YES 
user_id=31435

I reproduced this with current CVS Python on Windows; 
see attached traceback.txt, which shows a screen dump of 
the offending <wink> interactive session.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-07-01 05:55

Message:
Logged In: YES 
user_id=21627

I can't reproduce it with the Python 2.2 that ships with
SuSE 8.0, either.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 12:30

Message:
Logged In: YES 
user_id=21627

I can't reproduce the crash, with 2.3a0.

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

Comment By: Tim Peters (tim_one)
Date: 2002-03-25 22:27

Message:
Logged In: YES 
user_id=31435

Assigned to Fred.

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

Comment By: Aron K. Insinga (ainsinga)
Date: 2002-03-25 21:19

Message:
Logged In: YES 
user_id=496408

attached is the sample program (which ought to have
indenting preserved!)


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

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


From noreply@sourceforge.net  Fri Aug  2 22:48:29 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 02 Aug 2002 14:48:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-589427 ] standard include paths on command line
Message-ID: <E17akHd-0004p9-00@usw-sf-web2.sourceforge.net>

Bugs item #589427, was opened at 2002-08-01 00:13
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=589427&group_id=5470

Category: Build
Group: Python 2.3
>Status: Open
>Resolution: Remind
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Michael Hudson (mwh)
Summary: standard include paths on command line

Initial Comment:
when compiling shared modules (using gcc-3.1.1), 
standard include paths are included (by setup.py?) in 
the include path, which can change the search order. 
gcc-3.1 warns about:

building 'xreadlines' extension
gcc-3.1 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -
fPIC -I. -I/home/packages/pyt
hon2.3/python2.3-2.2.90/./Include -I/usr/include -
I/usr/local/include -I/home/pa
ckages/python2.3/python2.3-2.2.90/Include -
I/home/packages/python2.3/python2.3-2
.2.90/build-static -
c /home/packages/python2.3/python2.3-
2.2.90/Modules/xreadlin
esmodule.c -o build/temp.linux-i686-
2.3/xreadlinesmodule.o
gcc -shared build/temp.linux-i686-
2.3/xreadlinesmodule.o -L/usr/lib -L/usr/local
/lib -o build/lib.linux-i686-2.3/xreadlines.so
building 'array' extension
gcc-3.1 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -
fPIC -I. -I/hocc1: warning: c
hanging search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory

In this case, /usr/include and /usr/local/include should 
not be included on the command line.


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

>Comment By: Matthias Klose (doko)
Date: 2002-08-02 21:48

Message:
Logged In: YES 
user_id=60903

Thanks for the fix, however when building shared modules,
-I/usr/include and -L/usr/lib are still passed to the compiler.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-02 14:05

Message:
Logged In: YES 
user_id=21627

And indeed, we should not remove /usr/local/include, since
the system compiler may not be gcc.

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

Comment By: Michael Hudson (mwh)
Date: 2002-08-02 13:56

Message:
Logged In: YES 
user_id=6656

OK, done, in

setup.py revision 1.100

I don't see us removing /usr/local/include from the command
line.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-02 13:49

Message:
Logged In: YES 
user_id=21627

The patch looks fine to me, please apply it.

I still think that the bogus warning should be removed from
gcc entirely.

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

Comment By: Michael Hudson (mwh)
Date: 2002-08-02 12:54

Message:
Logged In: YES 
user_id=6656

OK, can you try the attached patch?

Martin, does this look OK to you?

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

Comment By: Michael Hudson (mwh)
Date: 2002-08-02 08:53

Message:
Logged In: YES 
user_id=6656

Ah, sorry!

Hmm.  Now I don't see the problem, i.e. for me
-I/usr/include is not part of the command line passed to the
compiler.

Are you building from up-to-date CVS?  Though I don't recall
any recent changes in this area.  Ahh, you're running
".../configure --prefix=/usr", right?

I'll dig.

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

Comment By: Matthias Klose (doko)
Date: 2002-08-01 20:23

Message:
Logged In: YES 
user_id=60903

I disagree. The discussion is on /usr/local/include. We are 
talking about /usr/include, which is a system include dir on 
almost all systems.

See the thread "gcc 3.2's cpp breaks configure scripts" at 
http://gcc.gnu.org/ml/gcc/2002-07/, i.e.:

http://gcc.gnu.org/ml/gcc/2002-07/msg01527.html

Inclusion of /usr/include can lead to errors, as explained in:
http://gcc.gnu.org/ml/gcc/2002-07/msg01541.html

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

Comment By: Michael Hudson (mwh)
Date: 2002-08-01 09:08

Message:
Logged In: YES 
user_id=6656

This has been deemed a bug in gcc, see this thread:

http://mail.python.org/pipermail/python-dev/2002-June/025990.html

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

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


From noreply@sourceforge.net  Sat Aug  3 02:19:38 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 02 Aug 2002 18:19:38 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-590115 ] please add list.stable_sort()
Message-ID: <E17anZy-000877-00@usw-sf-web4.sourceforge.net>

Feature Requests item #590115, was opened at 2002-08-02 09:18
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=590115&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Markus F.X.J. Oberhumer (mfx)
Assigned to: Nobody/Anonymous (nobody)
Summary: please add list.stable_sort()

Initial Comment:
Now that we have a default stable list.sort() algorithm
in the CVS it would be very nice to guarantee some
stable-sorting for future (i.e. post 2.3) Python versions.

I therefore propose the addtion of a list method
stable_sort().

The motivation behind this is that I fear that sooner
or later Tim will find yet another major improvement in
the sort implementation that might no longer provide
stability <wink>

Currently, doing stable sorting "by hand" typically
involves using tuples with added index fields as keys,
which is more than suboptimal w.r.t perfomance, memory
and code cleanless.

Markus

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

>Comment By: Tim Peters (tim_one)
Date: 2002-08-02 21:19

Message:
Logged In: YES 
user_id=31435

Noting that Guido already rejected this idea.  Note that the 
word "stable" appears in the docstring for list.sort() in 2.3, 
but not before, so it's easy to check <wink>.

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

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


From noreply@sourceforge.net  Sat Aug  3 03:29:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 02 Aug 2002 19:29:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-590366 ] Small typo in listsort:ParseTuple
Message-ID: <E17aof9-00009H-00@usw-sf-web5.sourceforge.net>

Bugs item #590366, was opened at 2002-08-02 16:57
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=590366&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 2
Submitted By: Finn Bock (bckfnn)
Assigned to: Tim Peters (tim_one)
Summary: Small typo in listsort:ParseTuple

Initial Comment:
Internally the sort method is called 'msort':


Python 2.3a0 (#6, Aug  2 2002, 19:38:01)
[GCC 2.95.3-5 (cygwin special)] on cygwin
Type "help", "copyright", "credits" or "license" for
more information.
>>> [].sort(1,2)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: msort() takes at most 1 argument (2 given)
>>>

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

>Comment By: Tim Peters (tim_one)
Date: 2002-08-02 22:29

Message:
Logged In: YES 
user_id=31435

Good eye!  Fixed in listobject.c rev 2.131.

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

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


From noreply@sourceforge.net  Sat Aug  3 05:34:47 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 02 Aug 2002 21:34:47 -0700
Subject: [Python-bugs-list] [ python-Bugs-576419 ] Infinite recursion in Pickle
Message-ID: <E17aqcp-0006SL-00@usw-sf-web1.sourceforge.net>

Bugs item #576419, was opened at 2002-07-02 19:02
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=576419&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 3
Submitted By: Oleg Broytmann (phd)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Infinite recursion in Pickle

Initial Comment:
Pickle falls into infininite recursion, cPickle crashed
(segfault on Linux, bus error on FreeBSD). See the
attached file. There is initial pickle (just a very
simple though somewhat large tree of bookmarks;
unfortunately lesser tree does not trigger the bug);
bkmk_objects.py module that includes class definitions
for the pickled object, and simple test program that
demonstrates the bug.

The program loads initial pickle, runs a function upon
it and saves the pickle back. The function runs through
the entire tree and creates backlinks - every object
got a link to its parent folder.

So it seems the bug is related to pickling objects with
loops.

When I changed builtin list as a parent class of Folder
to UserList (and recreated initial pickle) the bug
disappeared, so I think the bug is related to pickling
new classes.

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

>Comment By: Oleg Broytmann (phd)
Date: 2002-08-03 08:34

Message:
Logged In: YES 
user_id=4799

> could it be that your data structure is just very deeply nested?
[skip]
> I'm guessing that you are building what is in essence a very long doubly-linked list

I thought about it. It is not vrey deeply nested, just very long. So what should I do? Devise a formula that calculates recusion limit depending on the number of objects and call sys.setrecursionlimit()? Or just call sys.setrecursionlimit() in a loop, catching RuntimeError and increasing recusrion limit?

In any case I hope to see cPickle patched so it will not crash with a reasonable recursion limit.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-03 00:42

Message:
Logged In: YES 
user_id=6380

Oleg, could it be that your data structure is just very
deeply nested? On my machine (RedHat Linux 7.2), your test
program completes without problem, so there doesn't seem to
be something in the data that inherently triggers a bug.
However, when I apply Martin von Loewis's patch from SF bug
576084, cPickle raises RuntimeError: maximum recursion depth
exceeded. I'm guessing that you are building what is in
essence a very long doubly-linked list; the pickle algorithm
necessarily has to enter a recursion level for each list
node in this case.

Switching to UserList probably reduces the number of stack
frames per recursion level and that would explain that it
doesn't fail.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-03 00:26

Message:
Logged In: YES 
user_id=6380

Mmm, interesting.

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

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


From noreply@sourceforge.net  Sat Aug  3 07:47:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 02 Aug 2002 23:47:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-590456 ] preconvert AppleSingle resource files
Message-ID: <E17ashD-0003pe-00@usw-sf-web5.sourceforge.net>

Bugs item #590456, was opened at 2002-08-03 08:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=590456&group_id=5470

Category: Macintosh
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Jack Jansen (jackjansen)
Summary: preconvert AppleSingle resource files

Initial Comment:
IDLE fails to start when using a recent Python 2.3 snapshot 
because it tries to write files in the Python.framework, which is not 
writeable by normal users. 

A traceback:

IOError: [Errno 13] Permission denied: '/Library/Frameworks/
Python.framework/Versions/2.3/Mac/Tools/IDE/Widgets.rsrc.
df.rsrc'
Traceback (most recent call last):
  File "./Mac/Tools/IDE/PythonIDE.py", line 35, in ?
  File "./Mac/Tools/IDE/PythonIDE.py", line 23, in init
  File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/
Lib/macresource.py"
, line 64, in need
    refno = open_pathname(pathname)
  File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/
Lib/macresource.py"
, line 92, in open_pathname
    pathname = _decode(pathname)
  File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/
Lib/macresource.py"
, line 104, in _decode
    applesingle.decode(pathname, newpathname, resonly=1)
  File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/
Lib/applesingle.py"
, line 74, in decode
    fp = open(output, 'wb')
IOError: [Errno 13] Permission denied: '/Library/Frameworks/
Python.framework/Versions/2.3/Mac/Tools/IDE/Widgets.rsrc.
df.rsrc'
Traceback (most recent call last):
  File "./Mac/Tools/IDE/PythonIDE.py", line 35, in ?
  File "./Mac/Tools/IDE/PythonIDE.py", line 23, in init
  File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/
Lib/macresource.py"
, line 64, in need
    refno = open_pathname(pathname)
  File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/
Lib/macresource.py"
, line 92, in open_pathname
    pathname = _decode(pathname)
  File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/
Lib/macresource.py"
, line 104, in _decode
    applesingle.decode(pathname, newpathname, resonly=1)
  File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/
Lib/applesingle.py"
, line 74, in decode
    fp = open(output, 'wb')


Initial reaction from Jack:

Ah! That's an interesting problem...

Here's what's going on, maybe someone here has good ideas on 
how to solve it.

The ".rsrc" files in the CVS tree aren't actually resource files: 
they're resource files encoded as AppleSingle. This is the way 
MacCVS manages to store two-fork files on a CVS server that is 
blissfully unaware of this Apple-ism. The macresourced module is 
aware that a .rsrc file can be either a bona-fide resource file or an 
AppleSingle file. In the latter case it decodes the file and caches 
the result as a ".rsrc.df.rsrc" file, with the resources in the data 
fork. But: if you can't write the directory where the .rsrc resides 
this fails.

Storing the files as datafork-based .rsrc files in CVS will make life 
miserable for me when building on OS9.

Checking the files out with MacCVS will make the standard unix 
tarball distribution non-functional on OSX.

Hmm, I could probably pre-convert the files while installing, similar 
to the precompilation step for .pyc and .pyo files....

Could you file a sourceforge bug report for this, please, so I won't 
forget?



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

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


From noreply@sourceforge.net  Sat Aug  3 11:53:51 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 03 Aug 2002 03:53:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-588711 ] imaplib: prefix-quoted strings
Message-ID: <E17awXf-0003aP-00@usw-sf-web1.sourceforge.net>

Bugs item #588711, was opened at 2002-07-31 05:07
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=588711&group_id=5470

Category: Python Library
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 7
Submitted By: Matthias Klose (doko)
Assigned to: Piers Lauder (pierslauder)
Summary: imaplib: prefix-quoted strings

Initial Comment:
[From Debian BTS http://bugs.debian.org/150485]

From: John Goerzen <jgoerzen@quovix.com>
Subject: python2.2: imaplib: doesn't properly support
prefix-quoted strings

imaplib's fetch command is totally useless with many
servers.

They'll send the message body in this form:
{100}
Headers here, body here, (100 characters worth)

This is specified in RFC2060 secion 4.3.  imaplib's
fetch chokes on
"unexpected data" in the response.

imaplib should receive this prefix-quoted string
properly and return it in a
non-quoted fashion.

As it is, it is totally impossible to read messages
from most imap servers.

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

>Comment By: Piers Lauder (pierslauder)
Date: 2002-08-03 20:53

Message:
Logged In: YES 
user_id=196212

(Apologies for delay in responding, i've been away.)

This command has been working fine for ages, so I'm
surprised it has suddenly stopped working. It still works
on my imap server which sends prefix-quoted
strings for fetch responses.

Can you run the test at the bottom of imaplib.py with
debugging turned on and e-mail me the output?

  python imaplib.py -d5 <imap_server_host>

Repeat if for each of the different imap servers you are
having the problem with (it would help if you could identify
the imap server version as well.)

That will help me track down the problem. Thanks!

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

Comment By: Michael Hudson (mwh)
Date: 2002-07-31 18:29

Message:
Logged In: YES 
user_id=6656

Maybe you can stop test_imaplib failing while you're at it.

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

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


From noreply@sourceforge.net  Sat Aug  3 12:05:10 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 03 Aug 2002 04:05:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-589429 ] libpython.a with PIC objects
Message-ID: <E17awic-0003qx-00@usw-sf-web1.sourceforge.net>

Bugs item #589429, was opened at 2002-08-01 02:17
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=589429&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: libpython.a with PIC objects

Initial Comment:
when configuring with --enable-shared, the "static" 
library libpython.a is build with PIC-compiled objects.
Using the option --enable-shared builds a shared library 
in addition to the static library (with objects compiled 
without PIC).


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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-08-03 13:05

Message:
Logged In: YES 
user_id=21627

I personally think that all the other packages are "wrong",
or perhaps address different usage scenarios:

If you have a PIC-compiled static library, you can link this
static library into other DSOs. Not having a PIC-compiled
library causes problems. 

E.g. on Solaris, people building Python extension modules
frequently find that they only have a static version of
libreadline or OpenSSL, which they then cannot integrate
into the readline or socket Python modules (because you need
PIC code for a DSO).

So, a PIC static library can support use cases that a
non-PIC static library cannot. The downside is that the PIC
library might be less efficient. User using --enable-shared
have already accepted less efficient code (since the shared
library is also PIC), so they should accept PIC code in the
static library as well.

In addition, not building non-PIC objects simplifies the
build process: you don't have to compile everything twice,
just because somebody may want non-PIC objects. If somebody
really requires non-PIC objects for reasons I cannot see,
they need to recompile Python separately.

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

Comment By: Matthias Klose (doko)
Date: 2002-08-02 20:24

Message:
Logged In: YES 
user_id=60903

I expect (as mostly known from other GNU libraries on Linux
systems), that I get an additional library with
--enable-shared, not a changed static library.
Currently the option really is
--enable-shared-and-build-static-with-pic.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-02 15:49

Message:
Logged In: YES 
user_id=21627

What is the bug here?

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

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


From noreply@sourceforge.net  Sat Aug  3 12:13:45 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 03 Aug 2002 04:13:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-588756 ] python should obey the FHS
Message-ID: <E17awqv-0007lU-00@usw-sf-web5.sourceforge.net>

Bugs item #588756, was opened at 2002-07-30 22:12
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=588756&group_id=5470

Category: Installation
Group: Feature Request
Status: Open
Resolution: None
Priority: 3
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: python should obey the FHS

Initial Comment:
[From: http://bugs.debian.org/134762]

FHS Compliance - .py{,c} are architecture independant
thus belong in /usr/share

The Python manual makes it clear that byte compiled
python files are
 platform independant, and thus belong in
arch-independant packages and stored in /usr/share, as
per the FHS recommendations for such things.

So the request is to store them in
<prefix>/share/pythonX.Y.


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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-08-03 13:13

Message:
Logged In: YES 
user_id=21627

I think this requires a PEP. A Python package can consist of
byte code modules and extension modules; arranging the
package loader to find those in different directories is a
challenge.

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

Comment By: Matthias Klose (doko)
Date: 2002-07-30 22:15

Message:
Logged In: YES 
user_id=60903

FHS: Filesystem Hierarchy Standard

    http://www.pathname.com/fhs/


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

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


From noreply@sourceforge.net  Sat Aug  3 12:15:06 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 03 Aug 2002 04:15:06 -0700
Subject: [Python-bugs-list] [ python-Bugs-586972 ] won't build with gcc 3.1
Message-ID: <E17awsE-0004zM-00@usw-sf-web3.sourceforge.net>

Bugs item #586972, was opened at 2002-07-26 14:26
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=586972&group_id=5470

Category: Build
Group: Python 2.2.1
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Alexander Pletzer (pletzer)
Assigned to: Nobody/Anonymous (nobody)
Summary: won't build with gcc 3.1

Initial Comment:
Hi,

I'm running Linux Red-Hat 7.2 with gcc 3.1 but have
been unable to compile python 2.2.1.


[root@apletzer-pc Python-2.2.1]# uname -a
Linux apletzer-pc 2.4.7-10 #1 Thu Sep 6 17:27:27 EDT
2001 i686 unknown
[root@apletzer-pc Python-2.2.1]# gcc --version
gcc (GCC) 3.1
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying
conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

make 
..
gcc  -Xlinker -export-dynamic -o python \
                Modules/python.o \
                libpython2.2.a -ldl  -lpthread -lutil
-lreadline -ltermcap  -L/usr/lib -ltk8.3 -ltcl8.3
-L/usr/X11R6/lib -lX11   -lm  
/usr/bin/ld: Dwarf Error: Invalid or unhandled FORM
value: 14.
libpython2.2.a(posixmodule.o): In function `posix_tmpnam':
/usr/local-apletzer/Python-2.2.1/Modules/posixmodule.c:4501:
the use of `tmpnam_r' is dangerous, better use `mkstemp'
libpython2.2.a(posixmodule.o): In function `posix_tempnam':
/usr/local-apletzer/Python-2.2.1/Modules/posixmodule.c:4451:
the use of `tempnam' is dangerous, better use `mkstemp'
collect2: ld returned 1 exit status

make CC=/usr/bin/gcc on the other hand works
/usr/bin/gcc --version

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-07-26 20:48

Message:
Logged In: YES 
user_id=21627

This is not a bug in Python. To use gcc 3.1, you must use a
corresponding binutils release. Please see gcc 3.1 build
instructions for details.

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

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


From noreply@sourceforge.net  Sat Aug  3 12:16:52 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 03 Aug 2002 04:16:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-586905 ] test_imaplib broken on Mac
Message-ID: <E17awtw-00041s-00@usw-sf-web1.sourceforge.net>

Bugs item #586905, was opened at 2002-07-26 19:37
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=586905&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Piers Lauder (pierslauder)
Summary: test_imaplib broken on Mac

Initial Comment:
Test_imaplib recently broke on the Macintosh (or, to be more specific, for MacPython).

The reason seems to be that the test has been modified to check that all 5 test dates (3 in 1967, 2 in 2033) return the same value after a round trip. For MacPython this is true for the 3 1967 values but not for the 2033 values: these are both the same value, but in 2033, which is also what i would expect, really.

Is the 1967/2033 match testing for something that is really part of the imap spec? Or could it be that it is testing a artefact of the Unix implementation of time values (which apparently doesn't occur when using the Metrowerks runtime on MacOS, which has a wholly different representation of time), and that we really shouldn't be testing this? Or testing it and only matching it against itself (i.e. the 2033 time value)?

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

>Comment By: Piers Lauder (pierslauder)
Date: 2002-08-03 21:16

Message:
Logged In: YES 
user_id=196212

I've reverted test_imaplib.py to version 1.2 which as far as
I know is known to work everywhere.


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

Comment By: Piers Lauder (pierslauder)
Date: 2002-07-27 10:41

Message:
Logged In: YES 
user_id=196212

All 5 dates are supposed to be the same time (Wed May 18 03:33:20 2033 GMT)
The first three are numbers, the second two are IMAP4 INTERNALDATE representations of that time in different 
timezones.

But of course time.time() values are O/S dpendant, so those numbers will only work on O/Ss with 1/1/1970 as the 
epoch..

I've removed the numbers from the test. Please try the new test, it should now be O/S agnostic.



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

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


From noreply@sourceforge.net  Sat Aug  3 12:22:26 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 03 Aug 2002 04:22:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-586905 ] test_imaplib broken on Mac
Message-ID: <E17awzK-00047D-00@usw-sf-web1.sourceforge.net>

Bugs item #586905, was opened at 2002-07-26 19:37
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=586905&group_id=5470

Category: Macintosh
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Piers Lauder (pierslauder)
Summary: test_imaplib broken on Mac

Initial Comment:
Test_imaplib recently broke on the Macintosh (or, to be more specific, for MacPython).

The reason seems to be that the test has been modified to check that all 5 test dates (3 in 1967, 2 in 2033) return the same value after a round trip. For MacPython this is true for the 3 1967 values but not for the 2033 values: these are both the same value, but in 2033, which is also what i would expect, really.

Is the 1967/2033 match testing for something that is really part of the imap spec? Or could it be that it is testing a artefact of the Unix implementation of time values (which apparently doesn't occur when using the Metrowerks runtime on MacOS, which has a wholly different representation of time), and that we really shouldn't be testing this? Or testing it and only matching it against itself (i.e. the 2033 time value)?

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

>Comment By: Piers Lauder (pierslauder)
Date: 2002-08-03 21:22

Message:
Logged In: YES 
user_id=196212

version 1.2 of test_imaplib.py worked, so should fix this
problem.

(The later versions were an attempt to increase the number
of functions tested, but clearly didn't solve the time-zone
problem. Version 1.2 just tests that there is no exception
for one function, and doesn't attempt to check the output.)

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

Comment By: Piers Lauder (pierslauder)
Date: 2002-08-03 21:16

Message:
Logged In: YES 
user_id=196212

I've reverted test_imaplib.py to version 1.2 which as far as
I know is known to work everywhere.


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

Comment By: Piers Lauder (pierslauder)
Date: 2002-07-27 10:41

Message:
Logged In: YES 
user_id=196212

All 5 dates are supposed to be the same time (Wed May 18 03:33:20 2033 GMT)
The first three are numbers, the second two are IMAP4 INTERNALDATE representations of that time in different 
timezones.

But of course time.time() values are O/S dpendant, so those numbers will only work on O/Ss with 1/1/1970 as the 
epoch..

I've removed the numbers from the test. Please try the new test, it should now be O/S agnostic.



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

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


From noreply@sourceforge.net  Sat Aug  3 15:38:30 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 03 Aug 2002 07:38:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-576419 ] Infinite recursion in Pickle
Message-ID: <E17b034-0008TV-00@usw-sf-web2.sourceforge.net>

Bugs item #576419, was opened at 2002-07-02 11:02
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=576419&group_id=5470

Category: Python Library
Group: Python 2.2
>Status: Closed
>Resolution: Duplicate
Priority: 3
Submitted By: Oleg Broytmann (phd)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Infinite recursion in Pickle

Initial Comment:
Pickle falls into infininite recursion, cPickle crashed
(segfault on Linux, bus error on FreeBSD). See the
attached file. There is initial pickle (just a very
simple though somewhat large tree of bookmarks;
unfortunately lesser tree does not trigger the bug);
bkmk_objects.py module that includes class definitions
for the pickled object, and simple test program that
demonstrates the bug.

The program loads initial pickle, runs a function upon
it and saves the pickle back. The function runs through
the entire tree and creates backlinks - every object
got a link to its parent folder.

So it seems the bug is related to pickling objects with
loops.

When I changed builtin list as a parent class of Folder
to UserList (and recreated initial pickle) the bug
disappeared, so I think the bug is related to pickling
new classes.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-03 10:38

Message:
Logged In: YES 
user_id=6380

Well, from the POV of pickle, a long chain is
indistinguishable from a deeply nested structure. cPickle
*will* be fixed (by the patch of bug 576084). So I'm going
to close this as a duplicate.

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

Comment By: Oleg Broytmann (phd)
Date: 2002-08-03 00:34

Message:
Logged In: YES 
user_id=4799

> could it be that your data structure is just very deeply nested?
[skip]
> I'm guessing that you are building what is in essence a very long doubly-linked list

I thought about it. It is not vrey deeply nested, just very long. So what should I do? Devise a formula that calculates recusion limit depending on the number of objects and call sys.setrecursionlimit()? Or just call sys.setrecursionlimit() in a loop, catching RuntimeError and increasing recusrion limit?

In any case I hope to see cPickle patched so it will not crash with a reasonable recursion limit.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-02 16:42

Message:
Logged In: YES 
user_id=6380

Oleg, could it be that your data structure is just very
deeply nested? On my machine (RedHat Linux 7.2), your test
program completes without problem, so there doesn't seem to
be something in the data that inherently triggers a bug.
However, when I apply Martin von Loewis's patch from SF bug
576084, cPickle raises RuntimeError: maximum recursion depth
exceeded. I'm guessing that you are building what is in
essence a very long doubly-linked list; the pickle algorithm
necessarily has to enter a recursion level for each list
node in this case.

Switching to UserList probably reduces the number of stack
frames per recursion level and that would explain that it
doesn't fail.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-02 16:26

Message:
Logged In: YES 
user_id=6380

Mmm, interesting.

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

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


From noreply@sourceforge.net  Sat Aug  3 16:12:56 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 03 Aug 2002 08:12:56 -0700
Subject: [Python-bugs-list] [ python-Bugs-589427 ] standard include paths on command line
Message-ID: <E17b0aO-0000YV-00@usw-sf-web2.sourceforge.net>

Bugs item #589427, was opened at 2002-08-01 00:13
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=589427&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: Remind
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Michael Hudson (mwh)
Summary: standard include paths on command line

Initial Comment:
when compiling shared modules (using gcc-3.1.1), 
standard include paths are included (by setup.py?) in 
the include path, which can change the search order. 
gcc-3.1 warns about:

building 'xreadlines' extension
gcc-3.1 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -
fPIC -I. -I/home/packages/pyt
hon2.3/python2.3-2.2.90/./Include -I/usr/include -
I/usr/local/include -I/home/pa
ckages/python2.3/python2.3-2.2.90/Include -
I/home/packages/python2.3/python2.3-2
.2.90/build-static -
c /home/packages/python2.3/python2.3-
2.2.90/Modules/xreadlin
esmodule.c -o build/temp.linux-i686-
2.3/xreadlinesmodule.o
gcc -shared build/temp.linux-i686-
2.3/xreadlinesmodule.o -L/usr/lib -L/usr/local
/lib -o build/lib.linux-i686-2.3/xreadlines.so
building 'array' extension
gcc-3.1 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -
fPIC -I. -I/hocc1: warning: c
hanging search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory

In this case, /usr/include and /usr/local/include should 
not be included on the command line.


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

>Comment By: Michael Hudson (mwh)
Date: 2002-08-03 15:12

Message:
Logged In: YES 
user_id=6656

Really?  Nuts.  They're not on my machine.

What arguments are you passing to configure?

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

Comment By: Matthias Klose (doko)
Date: 2002-08-02 21:48

Message:
Logged In: YES 
user_id=60903

Thanks for the fix, however when building shared modules,
-I/usr/include and -L/usr/lib are still passed to the compiler.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-02 14:05

Message:
Logged In: YES 
user_id=21627

And indeed, we should not remove /usr/local/include, since
the system compiler may not be gcc.

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

Comment By: Michael Hudson (mwh)
Date: 2002-08-02 13:56

Message:
Logged In: YES 
user_id=6656

OK, done, in

setup.py revision 1.100

I don't see us removing /usr/local/include from the command
line.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-02 13:49

Message:
Logged In: YES 
user_id=21627

The patch looks fine to me, please apply it.

I still think that the bogus warning should be removed from
gcc entirely.

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

Comment By: Michael Hudson (mwh)
Date: 2002-08-02 12:54

Message:
Logged In: YES 
user_id=6656

OK, can you try the attached patch?

Martin, does this look OK to you?

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

Comment By: Michael Hudson (mwh)
Date: 2002-08-02 08:53

Message:
Logged In: YES 
user_id=6656

Ah, sorry!

Hmm.  Now I don't see the problem, i.e. for me
-I/usr/include is not part of the command line passed to the
compiler.

Are you building from up-to-date CVS?  Though I don't recall
any recent changes in this area.  Ahh, you're running
".../configure --prefix=/usr", right?

I'll dig.

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

Comment By: Matthias Klose (doko)
Date: 2002-08-01 20:23

Message:
Logged In: YES 
user_id=60903

I disagree. The discussion is on /usr/local/include. We are 
talking about /usr/include, which is a system include dir on 
almost all systems.

See the thread "gcc 3.2's cpp breaks configure scripts" at 
http://gcc.gnu.org/ml/gcc/2002-07/, i.e.:

http://gcc.gnu.org/ml/gcc/2002-07/msg01527.html

Inclusion of /usr/include can lead to errors, as explained in:
http://gcc.gnu.org/ml/gcc/2002-07/msg01541.html

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

Comment By: Michael Hudson (mwh)
Date: 2002-08-01 09:08

Message:
Logged In: YES 
user_id=6656

This has been deemed a bug in gcc, see this thread:

http://mail.python.org/pipermail/python-dev/2002-June/025990.html

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

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


From noreply@sourceforge.net  Sat Aug  3 16:56:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 03 Aug 2002 08:56:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-589427 ] standard include paths on command line
Message-ID: <E17b1GV-0000Fv-00@usw-sf-web1.sourceforge.net>

Bugs item #589427, was opened at 2002-08-01 00:13
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=589427&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: Remind
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Michael Hudson (mwh)
Summary: standard include paths on command line

Initial Comment:
when compiling shared modules (using gcc-3.1.1), 
standard include paths are included (by setup.py?) in 
the include path, which can change the search order. 
gcc-3.1 warns about:

building 'xreadlines' extension
gcc-3.1 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -
fPIC -I. -I/home/packages/pyt
hon2.3/python2.3-2.2.90/./Include -I/usr/include -
I/usr/local/include -I/home/pa
ckages/python2.3/python2.3-2.2.90/Include -
I/home/packages/python2.3/python2.3-2
.2.90/build-static -
c /home/packages/python2.3/python2.3-
2.2.90/Modules/xreadlin
esmodule.c -o build/temp.linux-i686-
2.3/xreadlinesmodule.o
gcc -shared build/temp.linux-i686-
2.3/xreadlinesmodule.o -L/usr/lib -L/usr/local
/lib -o build/lib.linux-i686-2.3/xreadlines.so
building 'array' extension
gcc-3.1 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -
fPIC -I. -I/hocc1: warning: c
hanging search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory

In this case, /usr/include and /usr/local/include should 
not be included on the command line.


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

>Comment By: Matthias Klose (doko)
Date: 2002-08-03 15:56

Message:
Logged In: YES 
user_id=60903

build log attached. please tell me if you need an account on
a Debian machine (doko   debian org).
configure \
        --with-gcc=gcc-3.1 \
        --with-cxx=g++-3.1 \
        --prefix=/usr \
        --with-fpectl \
        --enable-ipv6


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

Comment By: Michael Hudson (mwh)
Date: 2002-08-03 15:12

Message:
Logged In: YES 
user_id=6656

Really?  Nuts.  They're not on my machine.

What arguments are you passing to configure?

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

Comment By: Matthias Klose (doko)
Date: 2002-08-02 21:48

Message:
Logged In: YES 
user_id=60903

Thanks for the fix, however when building shared modules,
-I/usr/include and -L/usr/lib are still passed to the compiler.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-02 14:05

Message:
Logged In: YES 
user_id=21627

And indeed, we should not remove /usr/local/include, since
the system compiler may not be gcc.

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

Comment By: Michael Hudson (mwh)
Date: 2002-08-02 13:56

Message:
Logged In: YES 
user_id=6656

OK, done, in

setup.py revision 1.100

I don't see us removing /usr/local/include from the command
line.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-02 13:49

Message:
Logged In: YES 
user_id=21627

The patch looks fine to me, please apply it.

I still think that the bogus warning should be removed from
gcc entirely.

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

Comment By: Michael Hudson (mwh)
Date: 2002-08-02 12:54

Message:
Logged In: YES 
user_id=6656

OK, can you try the attached patch?

Martin, does this look OK to you?

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

Comment By: Michael Hudson (mwh)
Date: 2002-08-02 08:53

Message:
Logged In: YES 
user_id=6656

Ah, sorry!

Hmm.  Now I don't see the problem, i.e. for me
-I/usr/include is not part of the command line passed to the
compiler.

Are you building from up-to-date CVS?  Though I don't recall
any recent changes in this area.  Ahh, you're running
".../configure --prefix=/usr", right?

I'll dig.

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

Comment By: Matthias Klose (doko)
Date: 2002-08-01 20:23

Message:
Logged In: YES 
user_id=60903

I disagree. The discussion is on /usr/local/include. We are 
talking about /usr/include, which is a system include dir on 
almost all systems.

See the thread "gcc 3.2's cpp breaks configure scripts" at 
http://gcc.gnu.org/ml/gcc/2002-07/, i.e.:

http://gcc.gnu.org/ml/gcc/2002-07/msg01527.html

Inclusion of /usr/include can lead to errors, as explained in:
http://gcc.gnu.org/ml/gcc/2002-07/msg01541.html

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

Comment By: Michael Hudson (mwh)
Date: 2002-08-01 09:08

Message:
Logged In: YES 
user_id=6656

This has been deemed a bug in gcc, see this thread:

http://mail.python.org/pipermail/python-dev/2002-June/025990.html

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

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


From noreply@sourceforge.net  Sat Aug  3 17:19:18 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 03 Aug 2002 09:19:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-589427 ] standard include paths on command line
Message-ID: <E17b1cc-0001dz-00@usw-sf-web2.sourceforge.net>

Bugs item #589427, was opened at 2002-08-01 00:13
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=589427&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: Remind
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Michael Hudson (mwh)
Summary: standard include paths on command line

Initial Comment:
when compiling shared modules (using gcc-3.1.1), 
standard include paths are included (by setup.py?) in 
the include path, which can change the search order. 
gcc-3.1 warns about:

building 'xreadlines' extension
gcc-3.1 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -
fPIC -I. -I/home/packages/pyt
hon2.3/python2.3-2.2.90/./Include -I/usr/include -
I/usr/local/include -I/home/pa
ckages/python2.3/python2.3-2.2.90/Include -
I/home/packages/python2.3/python2.3-2
.2.90/build-static -
c /home/packages/python2.3/python2.3-
2.2.90/Modules/xreadlin
esmodule.c -o build/temp.linux-i686-
2.3/xreadlinesmodule.o
gcc -shared build/temp.linux-i686-
2.3/xreadlinesmodule.o -L/usr/lib -L/usr/local
/lib -o build/lib.linux-i686-2.3/xreadlines.so
building 'array' extension
gcc-3.1 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -
fPIC -I. -I/hocc1: warning: c
hanging search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory

In this case, /usr/include and /usr/local/include should 
not be included on the command line.


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

>Comment By: Michael Hudson (mwh)
Date: 2002-08-03 16:19

Message:
Logged In: YES 
user_id=6656

It's only the _ssl module, right?  I've fixed that.

The -R/usr/lib and -L/usr/lib's come from various database
modules, the configuration of which is under review anyway.
 I hope those doing the reviewing have seen this bug traffic...

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

Comment By: Matthias Klose (doko)
Date: 2002-08-03 15:56

Message:
Logged In: YES 
user_id=60903

build log attached. please tell me if you need an account on
a Debian machine (doko   debian org).
configure \
        --with-gcc=gcc-3.1 \
        --with-cxx=g++-3.1 \
        --prefix=/usr \
        --with-fpectl \
        --enable-ipv6


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

Comment By: Michael Hudson (mwh)
Date: 2002-08-03 15:12

Message:
Logged In: YES 
user_id=6656

Really?  Nuts.  They're not on my machine.

What arguments are you passing to configure?

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

Comment By: Matthias Klose (doko)
Date: 2002-08-02 21:48

Message:
Logged In: YES 
user_id=60903

Thanks for the fix, however when building shared modules,
-I/usr/include and -L/usr/lib are still passed to the compiler.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-02 14:05

Message:
Logged In: YES 
user_id=21627

And indeed, we should not remove /usr/local/include, since
the system compiler may not be gcc.

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

Comment By: Michael Hudson (mwh)
Date: 2002-08-02 13:56

Message:
Logged In: YES 
user_id=6656

OK, done, in

setup.py revision 1.100

I don't see us removing /usr/local/include from the command
line.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-02 13:49

Message:
Logged In: YES 
user_id=21627

The patch looks fine to me, please apply it.

I still think that the bogus warning should be removed from
gcc entirely.

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

Comment By: Michael Hudson (mwh)
Date: 2002-08-02 12:54

Message:
Logged In: YES 
user_id=6656

OK, can you try the attached patch?

Martin, does this look OK to you?

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

Comment By: Michael Hudson (mwh)
Date: 2002-08-02 08:53

Message:
Logged In: YES 
user_id=6656

Ah, sorry!

Hmm.  Now I don't see the problem, i.e. for me
-I/usr/include is not part of the command line passed to the
compiler.

Are you building from up-to-date CVS?  Though I don't recall
any recent changes in this area.  Ahh, you're running
".../configure --prefix=/usr", right?

I'll dig.

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

Comment By: Matthias Klose (doko)
Date: 2002-08-01 20:23

Message:
Logged In: YES 
user_id=60903

I disagree. The discussion is on /usr/local/include. We are 
talking about /usr/include, which is a system include dir on 
almost all systems.

See the thread "gcc 3.2's cpp breaks configure scripts" at 
http://gcc.gnu.org/ml/gcc/2002-07/, i.e.:

http://gcc.gnu.org/ml/gcc/2002-07/msg01527.html

Inclusion of /usr/include can lead to errors, as explained in:
http://gcc.gnu.org/ml/gcc/2002-07/msg01541.html

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

Comment By: Michael Hudson (mwh)
Date: 2002-08-01 09:08

Message:
Logged In: YES 
user_id=6656

This has been deemed a bug in gcc, see this thread:

http://mail.python.org/pipermail/python-dev/2002-June/025990.html

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

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


From noreply@sourceforge.net  Sat Aug  3 17:23:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 03 Aug 2002 09:23:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-589429 ] libpython.a with PIC objects
Message-ID: <E17b1gd-0000po-00@usw-sf-web3.sourceforge.net>

Bugs item #589429, was opened at 2002-08-01 00:17
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=589429&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: libpython.a with PIC objects

Initial Comment:
when configuring with --enable-shared, the "static" 
library libpython.a is build with PIC-compiled objects.
Using the option --enable-shared builds a shared library 
in addition to the static library (with objects compiled 
without PIC).


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

>Comment By: Matthias Klose (doko)
Date: 2002-08-03 16:23

Message:
Logged In: YES 
user_id=60903

well, why not call this library libpython_pic.a then? Or at
least it should be *documented*, that libpython.a contains
pic objects when configured with --enabled-shared, and
non-pic objects, when configured without --enabled-shared

I currently work around by building python twice: a complete
build without --enable-shared and a second build building
only libpython2.3.so.1.0. The configury is done twice, but I
get what I want.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-03 11:05

Message:
Logged In: YES 
user_id=21627

I personally think that all the other packages are "wrong",
or perhaps address different usage scenarios:

If you have a PIC-compiled static library, you can link this
static library into other DSOs. Not having a PIC-compiled
library causes problems. 

E.g. on Solaris, people building Python extension modules
frequently find that they only have a static version of
libreadline or OpenSSL, which they then cannot integrate
into the readline or socket Python modules (because you need
PIC code for a DSO).

So, a PIC static library can support use cases that a
non-PIC static library cannot. The downside is that the PIC
library might be less efficient. User using --enable-shared
have already accepted less efficient code (since the shared
library is also PIC), so they should accept PIC code in the
static library as well.

In addition, not building non-PIC objects simplifies the
build process: you don't have to compile everything twice,
just because somebody may want non-PIC objects. If somebody
really requires non-PIC objects for reasons I cannot see,
they need to recompile Python separately.

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

Comment By: Matthias Klose (doko)
Date: 2002-08-02 18:24

Message:
Logged In: YES 
user_id=60903

I expect (as mostly known from other GNU libraries on Linux
systems), that I get an additional library with
--enable-shared, not a changed static library.
Currently the option really is
--enable-shared-and-build-static-with-pic.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-02 13:49

Message:
Logged In: YES 
user_id=21627

What is the bug here?

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

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


From noreply@sourceforge.net  Sat Aug  3 17:30:23 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 03 Aug 2002 09:30:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-589427 ] standard include paths on command line
Message-ID: <E17b1nL-0000uS-00@usw-sf-web3.sourceforge.net>

Bugs item #589427, was opened at 2002-08-01 00:13
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=589427&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: Remind
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Michael Hudson (mwh)
Summary: standard include paths on command line

Initial Comment:
when compiling shared modules (using gcc-3.1.1), 
standard include paths are included (by setup.py?) in 
the include path, which can change the search order. 
gcc-3.1 warns about:

building 'xreadlines' extension
gcc-3.1 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -
fPIC -I. -I/home/packages/pyt
hon2.3/python2.3-2.2.90/./Include -I/usr/include -
I/usr/local/include -I/home/pa
ckages/python2.3/python2.3-2.2.90/Include -
I/home/packages/python2.3/python2.3-2
.2.90/build-static -
c /home/packages/python2.3/python2.3-
2.2.90/Modules/xreadlin
esmodule.c -o build/temp.linux-i686-
2.3/xreadlinesmodule.o
gcc -shared build/temp.linux-i686-
2.3/xreadlinesmodule.o -L/usr/lib -L/usr/local
/lib -o build/lib.linux-i686-2.3/xreadlines.so
building 'array' extension
gcc-3.1 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -
fPIC -I. -I/hocc1: warning: c
hanging search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory

In this case, /usr/include and /usr/local/include should 
not be included on the command line.


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

>Comment By: Matthias Klose (doko)
Date: 2002-08-03 16:30

Message:
Logged In: YES 
user_id=60903

No. It's:

 - bsddb
 - dbm
 - _tkinter

all modules, which are installed in /usr at least on Debian
GNU/Linux (but maybe on other distros as well).

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

Comment By: Michael Hudson (mwh)
Date: 2002-08-03 16:19

Message:
Logged In: YES 
user_id=6656

It's only the _ssl module, right?  I've fixed that.

The -R/usr/lib and -L/usr/lib's come from various database
modules, the configuration of which is under review anyway.
 I hope those doing the reviewing have seen this bug traffic...

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

Comment By: Matthias Klose (doko)
Date: 2002-08-03 15:56

Message:
Logged In: YES 
user_id=60903

build log attached. please tell me if you need an account on
a Debian machine (doko   debian org).
configure \
        --with-gcc=gcc-3.1 \
        --with-cxx=g++-3.1 \
        --prefix=/usr \
        --with-fpectl \
        --enable-ipv6


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

Comment By: Michael Hudson (mwh)
Date: 2002-08-03 15:12

Message:
Logged In: YES 
user_id=6656

Really?  Nuts.  They're not on my machine.

What arguments are you passing to configure?

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

Comment By: Matthias Klose (doko)
Date: 2002-08-02 21:48

Message:
Logged In: YES 
user_id=60903

Thanks for the fix, however when building shared modules,
-I/usr/include and -L/usr/lib are still passed to the compiler.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-02 14:05

Message:
Logged In: YES 
user_id=21627

And indeed, we should not remove /usr/local/include, since
the system compiler may not be gcc.

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

Comment By: Michael Hudson (mwh)
Date: 2002-08-02 13:56

Message:
Logged In: YES 
user_id=6656

OK, done, in

setup.py revision 1.100

I don't see us removing /usr/local/include from the command
line.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-02 13:49

Message:
Logged In: YES 
user_id=21627

The patch looks fine to me, please apply it.

I still think that the bogus warning should be removed from
gcc entirely.

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

Comment By: Michael Hudson (mwh)
Date: 2002-08-02 12:54

Message:
Logged In: YES 
user_id=6656

OK, can you try the attached patch?

Martin, does this look OK to you?

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

Comment By: Michael Hudson (mwh)
Date: 2002-08-02 08:53

Message:
Logged In: YES 
user_id=6656

Ah, sorry!

Hmm.  Now I don't see the problem, i.e. for me
-I/usr/include is not part of the command line passed to the
compiler.

Are you building from up-to-date CVS?  Though I don't recall
any recent changes in this area.  Ahh, you're running
".../configure --prefix=/usr", right?

I'll dig.

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

Comment By: Matthias Klose (doko)
Date: 2002-08-01 20:23

Message:
Logged In: YES 
user_id=60903

I disagree. The discussion is on /usr/local/include. We are 
talking about /usr/include, which is a system include dir on 
almost all systems.

See the thread "gcc 3.2's cpp breaks configure scripts" at 
http://gcc.gnu.org/ml/gcc/2002-07/, i.e.:

http://gcc.gnu.org/ml/gcc/2002-07/msg01527.html

Inclusion of /usr/include can lead to errors, as explained in:
http://gcc.gnu.org/ml/gcc/2002-07/msg01541.html

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

Comment By: Michael Hudson (mwh)
Date: 2002-08-01 09:08

Message:
Logged In: YES 
user_id=6656

This has been deemed a bug in gcc, see this thread:

http://mail.python.org/pipermail/python-dev/2002-June/025990.html

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

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


From noreply@sourceforge.net  Sat Aug  3 18:37:16 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 03 Aug 2002 10:37:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-427345 ] CGIHTTPServer fix for Windows
Message-ID: <E17b2q4-00039m-00@usw-sf-web2.sourceforge.net>

Bugs item #427345, was opened at 2001-05-25 10:37
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=427345&group_id=5470

Category: Python Library
Group: Platform-specific
Status: Open
Resolution: None
Priority: 3
Submitted By: Kevin Altis (kasplat)
Assigned to: Nobody/Anonymous (nobody)
Summary: CGIHTTPServer fix for Windows

Initial Comment:
CGIHTTPServer.py in the Python 2.1 library needs two 
changes to the popen2 section in order to support 
binary data and to avoid buffering problems under 
Windows. The complete code block is shown at the end 
of this message. The two changed lines are:
cmdline = "%s -u %s" % (interp, cmdline)
fi, fo = os.popen2(cmdline, 'b')

I've tested this under Windows 2000 Pro and binary 
file uploads now work, however more extensive tests 
should probably be done.

It appears there is another socket-related problem 
and/or end-of-line conversion error that occurs when 
using Internet Explorer 5.x and BASEHTTPServer with 
CGIHTTPServer on the same machine. I'm still 
investigating that issue.

Finally, I have done a small rewrite of 
CGIHTTPServer.py to simplify subclassing it to support 
running CGIs in any or all directories and using other 
file extensions such as .cgi. The maintainer for the 
current file should email me about the changes to see 
whether they want to update the official library file. 
I didn't post it here since it needs more tweaking

ka
---
CGIHTTPServer.p fixes...
elif self.have_popen2:
    # Windows -- use popen2 to create a subprocess
    import shutil
    os.environ.update(env)
    cmdline = scriptfile
    if self.is_python(scriptfile):
        interp = sys.executable
        if interp.lower().endswith("w.exe"):
            # On Windows, use python.exe, not 
python.exe
            interp = interp[:-5] = interp[-4:]
        cmdline = "%s -u %s" % (interp, cmdline)
    if '=' not in query and '"' not in query:
        cmdline = '%s "%s"' % (cmdline, query)
    self.log_error("command: %s", cmdline)
    try:
        nbytes = int(length)
    except:
        nbytes = 0
    fi, fo = os.popen2(cmdline, 'b')
    if self.command.lower() == "post" and nbytes > 0:
        data = self.rfile.read(nbytes)
        fi.write(data)
    fi.close()
    shutil.copyfileobj(fo, self.wfile)
    sts = fo.close()
    if sts:
        self.log_error("CGI script exit status %#x", 
sts)
    else:
        self.log_error("CGI script exited OK")


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

>Comment By: Kevin Altis (kasplat)
Date: 2002-08-03 10:37

Message:
Logged In: YES 
user_id=228025

This bug is related to another bug

https://sourceforge.net/tracker/?
func=detail&aid=430160&group_id=5470&atid=105470

Bob Denny (author of the WebSite server, formerly sold by 
O'Reilly) had this to say about the POST problem:

"This is an old problem, traced back to Netscape and Unix-
based shell CGI scripts. Netscape browsers did this to force 
completion of the POST into shell scripts. The cr/lf is not part 
of the POST payload, and the CGI script that is dealing with 
the POST needs to toss it away. The general solution is, read 
Content-Length bytes, then reas anything else that may be in 
the buffer and junk it. IE is emulating the behavior of 
Netscape."

So, that explains why IE (and possibly other browsers) sticks 
a CR/LF on the end of a POST causing a mismatch with the 
Content-length header. Now the question is where a fix can 
be inserted in the libs?

Looking again at CGIHTTPServer.py, perhaps this problem is 
isolated to Windows, in which case the fix might be in the 
block of code starting on line 218, and more specifically, line 
246

data = self.rfile.read(nbytes)

so at that point, the remaining 2 bytes should be read, but 
tossed. I'll investigate. Steve Holden and I have been emailing 
back and forth on this issue, so if anyone else has other 
suggestions, post here or email one of us.

Thanks,

ka

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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-07-08 18:27

Message:
Logged In: NO 

hello

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

Comment By: Thomas Justin Shaw (justinshaw)
Date: 2002-03-31 00:48

Message:
Logged In: YES 
user_id=135558

To: Matthew King
Thanks for reposting that solution.  That did seem to fix 
the problem.

To: Mark Lutz
Using: Win2000 Pro IE5 python2.2.1c locally
The bug shows up as a popup message but the page loads.
When I tried it accross a lan the page wouldn't even
load (blowing a little demo).  So I guess it is not ONLY a 
local problem.

Thanks for posting.
Justin Shaw

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

Comment By: Thomas Justin Shaw (justinshaw)
Date: 2002-03-28 23:36

Message:
Logged In: YES 
user_id=135558

I'm experiencing a problem on windows.
When I execute the scripts as 
'http://localhost:8080/cgi-bin\junk.py' 
the page seems to load ok but I get the popup message:
Internet Explorer cannot open the Internet site 
http://localhost:8080/cgi-bin\junk.py
The connection with the server ws reset

On Netscape no errors but the download also takes forever. 
The slow download seems to be caused by the 
FieldStorage() call.


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

Comment By: Matthew King (kyrrigle)
Date: 2002-03-28 13:21

Message:
Logged In: YES 
user_id=247536

this looks like the same issue as #430160.  and here's what 
I just wrote there...

it appears that IE is sending 2 extra bytes ('\r\n') after 
the request data.  and if you don't read those two extra 
bytes off, the window's socket handling gets messed up.

the result is that a partial response is returned and the 
socket closed.  IE tries to recover by re-POST'ing (which 
is behavior specified in the HTTP/1.1 RFC)... only they 
seem to add an embedded NULL the second time through, and 
the original socket problem happens again anyway.

Try reading an extra 2 bytes from the rfile before sending 
your response and the problem should go away.  (you can do 
that by 'self.rfile._rbufsize = content_length + 2' inside 
your do_POST method before reading the content)

not sure what the real fix for this should be?


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-09-05 08:40

Message:
Logged In: YES 
user_id=6380

Load shedding.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-09 06:14

Message:
Logged In: YES 
user_id=6380

Reopening -- not that I have time for this. :-(

Note that that patch is in socket.py.

If this really is a work-around, I'd like to understand why.

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

Comment By: Steve Pike (oztourer)
Date: 2001-08-09 05:27

Message:
Logged In: YES 
user_id=120658

To further elaborate on the problems with POST on Windows 
95: without having reached any real understanding of the 
problem I have found a tolerable workaround. By modifying 
the default _rbufsize for class _fileobject in socket.py I 
can get any POSTs with text length less than _rbufsize to 
work. Here is the mod:

<pre>
class _fileobject:
    def __init__(self, sock, mode, bufsize):
        self._sock = sock
        self._mode = mode
        if bufsize < 0:
            bufsize = 512
        # SP 9 Aug 2001: default _rbufsize is too small, 
crashing CGIHTTPServer on POST's
        # This fix still only allows pages of less than 
given buffer size to be updated,
        # so the real fix has still to be discovered.
        #self._rbufsize = max(1, bufsize)
        self._rbufsize = max(16*1024, bufsize)
        self._wbufsize = bufsize
        self._wbuf = self._rbuf = ""
</pre>

-- StevePike

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-07 12:59

Message:
Logged In: YES 
user_id=6380

I agree that this is a laudable goal, but I don't have the
time to spend to work on this.  Please upload a patch to the
SF patch manager and assign it to me and I'll look at it.

In the mean time, I've applied the two small suggestions and
will close this bug report.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-05-29 09:29

Message:
Logged In: NO 

I want to elaborate on the second-to-last 
paragraph in this report.  CGIHTTPServer 
in 2.1 and 2.0 is apparently broken for 
POST requests (only) to CGI scripts, when
running locally on Windows with an IE client.

The details: there is a problem with 
the combination of a CGIHTTPServer and 
Intenernet Explorer both running locally 
on Windows (with server name "localhost").
In this setup, POST requests to CGI scripts
fail, but GET requests to the exact same 
script work fine.  That is, a form with 
method=GET, or a URL with an appended 
query string, both work ok.

In POST mode, the CGI script gets proper
data in the input stream, and generates 
a correct reply stream (which is in fact 
identical to the output generated for 
quivalent GET requests).  So, somewhere 
between CGIHTTPServer and IE, the data 
seems to be dropped or munged.  The same
thing happens of you force CGIHTTPServer 
to use execfile() to launch the script, 
instead of os.popen2.

I've also observed that endline conventions 
seem to be irrelevant to the problem; using 
\n or \r\n makes no difference in both the 
input and reply streams.  I've also been 
told that the problem may not exist in 
Netscape clients.

Since CGIHTTPServer is a very nice way to test
CGI scripts (all you need is a standard Python
install), this seems important.  It would also 
be nice if the directory assumptions in that 
module were more customizable, but that's just
a wish.

--Mark Lutz


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

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


From noreply@sourceforge.net  Sat Aug  3 22:01:17 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 03 Aug 2002 14:01:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-585923 ] macfs.FSSpec fails for "new" files
Message-ID: <E17b61V-0004kt-00@usw-sf-web3.sourceforge.net>

Bugs item #585923, was opened at 2002-07-24 15:35
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=585923&group_id=5470

Category: Macintosh
Group: Python 2.3
Status: Open
Resolution: None
Priority: 7
Submitted By: Just van Rossum (jvr)
Assigned to: Jack Jansen (jackjansen)
>Summary: macfs.FSSpec fails for "new" files

Initial Comment:
In the mach-o version of Python on MacOSX, the macfs.FSSpec() 
library function fails for files that don't yet exist.

The problem is caused by (internally) using an FSRef to construct 
the FSSpec: FSRefs can't hold references to non-existent files, 
whereas FSSpecs can.

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

>Comment By: Jack Jansen (jackjansen)
Date: 2002-08-03 23:01

Message:
Logged In: YES 
user_id=45365

As the workaround is going to be both difficult to implement and incomplete I'm tempted to punt on this one. Difficult because we have to split the path in C, and we have to do /: substitutions on the last component; incomplete because we cannot cater for utf8/macroman differences and filenames > 32 characters.

If we punt on this we should make sure we phase out using fsspec's in the standard library in favor of the fsref calls.

Do you think this is an acceptable solution? How much work would it be?

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

Comment By: Just van Rossum (jvr)
Date: 2002-07-29 23:56

Message:
Logged In: YES 
user_id=92689

This bug also cause macostools.copy() to fail, making the breakage 
larger than I thought :-(

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

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


From noreply@sourceforge.net  Sat Aug  3 22:40:56 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 03 Aug 2002 14:40:56 -0700
Subject: [Python-bugs-list] [ python-Bugs-589429 ] libpython.a with PIC objects
Message-ID: <E17b6ds-0000eR-00@usw-sf-web5.sourceforge.net>

Bugs item #589429, was opened at 2002-08-01 02:17
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=589429&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: libpython.a with PIC objects

Initial Comment:
when configuring with --enable-shared, the "static" 
library libpython.a is build with PIC-compiled objects.
Using the option --enable-shared builds a shared library 
in addition to the static library (with objects compiled 
without PIC).


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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-08-03 23:40

Message:
Logged In: YES 
user_id=21627

Ok, this behaviour is now documented in README 1.151.

I still don't understand why you need a non-PIC libpython.a,
and I don't think that the standard build process should
produce a file named libpython_pic.a. My suggestion would be
to just run configure once - I still cannot see what
problems this would cause.

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

Comment By: Matthias Klose (doko)
Date: 2002-08-03 18:23

Message:
Logged In: YES 
user_id=60903

well, why not call this library libpython_pic.a then? Or at
least it should be *documented*, that libpython.a contains
pic objects when configured with --enabled-shared, and
non-pic objects, when configured without --enabled-shared

I currently work around by building python twice: a complete
build without --enable-shared and a second build building
only libpython2.3.so.1.0. The configury is done twice, but I
get what I want.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-03 13:05

Message:
Logged In: YES 
user_id=21627

I personally think that all the other packages are "wrong",
or perhaps address different usage scenarios:

If you have a PIC-compiled static library, you can link this
static library into other DSOs. Not having a PIC-compiled
library causes problems. 

E.g. on Solaris, people building Python extension modules
frequently find that they only have a static version of
libreadline or OpenSSL, which they then cannot integrate
into the readline or socket Python modules (because you need
PIC code for a DSO).

So, a PIC static library can support use cases that a
non-PIC static library cannot. The downside is that the PIC
library might be less efficient. User using --enable-shared
have already accepted less efficient code (since the shared
library is also PIC), so they should accept PIC code in the
static library as well.

In addition, not building non-PIC objects simplifies the
build process: you don't have to compile everything twice,
just because somebody may want non-PIC objects. If somebody
really requires non-PIC objects for reasons I cannot see,
they need to recompile Python separately.

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

Comment By: Matthias Klose (doko)
Date: 2002-08-02 20:24

Message:
Logged In: YES 
user_id=60903

I expect (as mostly known from other GNU libraries on Linux
systems), that I get an additional library with
--enable-shared, not a changed static library.
Currently the option really is
--enable-shared-and-build-static-with-pic.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-02 15:49

Message:
Logged In: YES 
user_id=21627

What is the bug here?

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

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


From noreply@sourceforge.net  Sun Aug  4 09:22:37 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 04 Aug 2002 01:22:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-576084 ] Sig11 in cPickle (stack overflow)
Message-ID: <E17bGer-0007SI-00@usw-sf-web1.sourceforge.net>

Bugs item #576084, was opened at 2002-07-01 20:34
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=576084&group_id=5470

Category: Python Library
Group: None
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Jeff Epler (jepler)
Assigned to: Martin v. Löwis (loewis)
Summary: Sig11 in cPickle (stack overflow)

Initial Comment:
The following program dies for me with a sig11.  It
appears that cPickle overflows the stack of the thread
where it executes.  (In my platform, the main thread's
stack is very large, but other threads' stacks are
fairly small)

Should some kind of guard be added in cPickle to stop
the overflow?
This does safely die with a "RuntimeError: maximum
recursion depth exceeded" when using regular pickle.

(I wrote this simple program after a python-dev poster
wrote that a "deeply recursive data structure" was
sometimes causing a sig11 inside cPickle.  I do not
know if this is the same problem as his or not)

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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-08-04 10:22

Message:
Logged In: YES 
user_id=21627

Applied as cPickle.c 2.93.

I have not backported it to 2.2, since it carries the risk
that you get a RuntimeError in pickling, even though
pickling would currently comlete just fine.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-02 22:30

Message:
Logged In: YES 
user_id=6380

Looks good. It fixes the test case. Only comment: would the
call to Py_GetRecursionLimit() cause a measurable slowdown?
(Hard to believe given the amount of work that's done
already.) Suggestion: check it in.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-07-30 17:21

Message:
Logged In: YES 
user_id=21627

Can you please try the attached patch?


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

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


From noreply@sourceforge.net  Sun Aug  4 09:27:28 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 04 Aug 2002 01:27:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-534864 ] profiling with xml parsing asserts
Message-ID: <E17bGjY-00051h-00@usw-sf-web3.sourceforge.net>

Bugs item #534864, was opened at 2002-03-25 22:15
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=534864&group_id=5470

Category: Python Library
Group: Python 2.2
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Aron K. Insinga (ainsinga)
Assigned to: Martin v. Löwis (loewis)
Summary: profiling with xml parsing asserts

Initial Comment:
I'm getting a 'bad call' assertion error when using the
profiler when parsing XML.  (It works ok without the
profiler, and if I don't call SAXparser.parse it
doesn't happen.)


Python 2.2 (#1, Dec 23 2001, 09:30:32)
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on
linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import t4crash
start document
end document
>>> import profile
>>> t4crash.test()
start document
end document
>>> profile.run('t4crash.test()')
start document
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.2/profile.py", line 71, in run
    prof = prof.run(statement)
  File "/usr/lib/python2.2/profile.py", line 404, in
run
    return self.runctx(cmd, dict, dict)
  File "/usr/lib/python2.2/profile.py", line 410, in
runctx
    exec cmd in globals, locals
  File "<string>", line 1, in ?
  File "t4crash.py", line 46, in test
    main(files)
  File "t4crash.py", line 39, in main
    SAXparser.parse(fileName)
  File
"/var/tmp/python2-2.2-root/usr/lib/python2.2/xml/sax/expatreader.py",
line 53, in parse
  File
"/var/tmp/python2-2.2-root/usr/lib/python2.2/xml/sax/xmlreader.py",
line
123, in parse  File
"/var/tmp/python2-2.2-root/usr/lib/python2.2/xml/sax/expatreader.py",
line 106,
in feed
  File
"/var/tmp/python2-2.2-root/usr/lib/python2.2/xml/sax/expatreader.py",
line 179, in start_element
  File "/usr/lib/python2.2/profile.py", line 214, in
trace_dispatch_i
    if self.dispatch[event](self, frame,t):
  File "/usr/lib/python2.2/profile.py", line 260, in
trace_dispatch_call
    assert rframe.f_back is frame.f_back, ("Bad call",
rfn,
AssertionError: ('Bad call',
('/var/tmp/python2-2.2-root/usr/lib/python2.2/xml/sax/expatreader.py',
95,
'feed'), <frame object at 0x81d5454>, <frame object at
0x81c82e4>, <frame object
at 0x81d50b4>, <frame object at 0x81d5284>)
>>>
[ainsinga@ainsinga index_xml]$ cat t4crash.py
#!/usr/bin/env python2

# t4crash.py by Aron K. Insinga (aron.insinga@av.com)
25-Mar-2002

import xml.sax
import sys
import string
import re


class ContentHandler(xml.sax.ContentHandler):
    """ Handle callbacks from the SAX XML parser. """

    def __init__(selfy):
        pass

    def setDocumentLocator(self, locator):
        pass

    def startDocument(self):
        print 'start document'

    def endDocument(self):
        print 'end document'

    def startElement(self, name, attrs):
        pass

    def endElement(self, name):
        pass


def main(files):
    SAXparser = xml.sax.make_parser()
    chand = ContentHandler()
    SAXparser.setContentHandler(chand)
    try:
        for fileName in files:
            SAXparser.parse(fileName)
    except xml.sax.SAXParseException:
        sys.stderr.write("%s; processing aborted\n" %
(xml.sax.SAXParseException))
        sys.exit(1)

def test():
    files = ['doc0.xml']
    main(files)

test()
[ainsinga@ainsinga index_xml]$ cat doc0.xml
<?xml version="1.0" encoding="ISO-8859-1"?>
<html>
  <head>
    <title>Gettysburg Address</title>
  </head>
  <body>
    <p>
      Four score and seven years ago...<br/>
    </p>
  </body>
  <info>
    <author>
     
<lastname>Lincoln</lastname><firstname>Abraham</firstname>
    </author>
    <date>
      <month>11</month><day>19</day><year>1863</year>
    </date>
    <editor /><!-- editor name="aki"/ -->
    <editor/>
  </info>
</html>
[ainsinga@ainsinga index_xml]$ which python
/usr/bin/python
[ainsinga@ainsinga index_xml]$ set | grep PATH
LD_LIBRARY_PATH=/home/ainsinga/adabas/lib:/home/ainsinga/adabas/lib:/home/ainsinga/adabas/lib:/home/ainsinga/adabas/lib:/home/ainsinga/adabas/lib:
PATH=$'/home/ainsinga/adabas/bin:/home/ainsinga/adabas/pgm:.:/home/ainsinga/adabas/bin:/home/ainsinga/adabas/pgm:.:/home/ainsinga/adabas/bin:/home/ainsinga/adabas/pgm:.:/home/ainsinga/adabas/bin:/home/ainsinga/adabas/pgm:.:.:/home/ainsinga/bin:/home/ainsinga/adabas/bin:/home/ainsinga/adabas/pgm:.:/bin:/usr/bin:/usr/X11R6/bin:/usr/local/bin:~/staroffice6.0:/home/ainsinga/mozilla:~/staroffice6.0:/home/ainsinga/mozilla:~/staroffice6.0:/home/ainsinga/mozilla:~/staroffice6.0:/home/ainsinga/mozilla:~/
staroffice6.0:/home/ainsinga/mozilla'
[ainsinga@ainsinga index_xml]$ set | grep -i py
[ainsinga@ainsinga index_xml]$uname -a
Linux ainsinga 2.4.7-10 #1 Thu Sep 6 17:27:27 EDT 2001
i686 unknown
[ainsinga@ainsinga index_xml]$


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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-08-04 10:27

Message:
Logged In: YES 
user_id=21627

Committed as pyexpat.c 2.72 and 2.57.6.1.

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

Comment By: Andrew P. Lentvorski, Jr. (andrewl)
Date: 2002-08-02 23:21

Message:
Logged In: YES 
user_id=28733

I didn't realize you were waiting for confirmation from me
directly.  Preliminary runs look like the problem is fixed.

Please commit the patch and mark this bug as closed.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-02 22:06

Message:
Logged In: YES 
user_id=6380

It solves the isolated test case submitted by Andrew P.
Lentvorski to python-dev on July 1, so I propose to check
this in.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-01 12:56

Message:
Logged In: YES 
user_id=21627

Confirming that the patch solves the problem for you would help.

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

Comment By: Andrew P. Lentvorski, Jr. (andrewl)
Date: 2002-08-01 10:57

Message:
Logged In: YES 
user_id=28733

I took a quick look in the browsable CVS repository, and the
diff to expat.c doesn't seem to be committed.  Is there
something further that I need to do so that this bug can get
closed?

-a

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-07-02 09:05

Message:
Logged In: YES 
user_id=21627

Attached is a patch that fixes the problem.

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

Comment By: Andrew P. Lentvorski, Jr. (andrewl)
Date: 2002-07-02 02:13

Message:
Logged In: YES 
user_id=28733

The xmltest.py program follows since I appear to be too
stupid to figure out how to attach a file to a bug report on
SourceForge.

-a

#!/usr/bin/env python

import xml.sax

testxml = \
"""
<html />
"""

class ContentHandler(xml.sax.ContentHandler):
    """ Handle callbacks from the SAX XML parser. """

    def __init__(self):
        pass

    def startElement(self, name, attrs):
        print "start element"

    def endElement(self, name):
        print "end element"

def main():
    chand = ContentHandler()
    xml.sax.parseString(testxml, chand)

if __name__ == "__main__":
    main()


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

Comment By: Andrew P. Lentvorski, Jr. (andrewl)
Date: 2002-07-02 02:01

Message:
Logged In: YES 
user_id=28733

Here is a session log for a much more self-contained
regression file (xmltest.py):

andrewl@taz:andrewl$ python
Python 2.2.1 (#1, May 27 2002, 16:42:22) 
[GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4
Type "help", "copyright", "credits" or "license" for more
information.
>>> import profile
>>> import xmltest
>>> profile.run('xmltest.main()')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.2/profile.py", line 71, in
run
    prof = prof.run(statement)
  File "/usr/local/lib/python2.2/profile.py", line 404, in
run
    return self.runctx(cmd, dict, dict)
  File "/usr/local/lib/python2.2/profile.py", line 410, in
runctx
    exec cmd in globals, locals
  File "<string>", line 1, in ?
  File "xmltest.py", line 24, in main
    xml.sax.parseString(testxml, chand)
  File "/usr/local/lib/python2.2/xml/sax/__init__.py", line
49, in parseString
    parser.parse(inpsrc)
  File "/usr/local/lib/python2.2/xml/sax/expatreader.py",
line 90, in parse
    xmlreader.IncrementalParser.parse(self, source)
  File "/usr/local/lib/python2.2/xml/sax/xmlreader.py", line
123, in parse
    self.feed(buffer)
  File "/usr/local/lib/python2.2/xml/sax/expatreader.py",
line 143, in feed
    self._parser.Parse(data, isFinal)
  File "/usr/local/lib/python2.2/xml/sax/expatreader.py",
line 216, in start_element
    def start_element(self, name, attrs):
  File "/usr/local/lib/python2.2/profile.py", line 214, in
trace_dispatch_i
    if self.dispatch[event](self, frame,t):
  File "/usr/local/lib/python2.2/profile.py", line 260, in
trace_dispatch_call
    assert rframe.f_back is frame.f_back, ("Bad call", rfn,
AssertionError: ('Bad call',
('/usr/local/lib/python2.2/xml/sax/expatreader.py', 132,
'feed'), <frame object at 0x81a880c>, <frame object at
0x81a840c>, <frame object at 0x81bb60c>, <frame object at
0x81a8a0c>)


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

Comment By: Andrew P. Lentvorski, Jr. (andrewl)
Date: 2002-07-02 00:57

Message:
Logged In: YES 
user_id=28733

There is another filing on this problem at:

http://mail.python.org/pipermail/xml-sig/2002-April/007632.html

Also, I reproduced this on another FreeBSD box today as
well.

andrewl@taz:andrewl$ python
Python 2.2.1 (#1, May 27 2002, 16:42:22) 
[GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4

-a


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

Comment By: Tim Peters (tim_one)
Date: 2002-07-01 17:55

Message:
Logged In: YES 
user_id=31435

I reproduced this with current CVS Python on Windows; 
see attached traceback.txt, which shows a screen dump of 
the offending <wink> interactive session.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-07-01 07:55

Message:
Logged In: YES 
user_id=21627

I can't reproduce it with the Python 2.2 that ships with
SuSE 8.0, either.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 13:30

Message:
Logged In: YES 
user_id=21627

I can't reproduce the crash, with 2.3a0.

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

Comment By: Tim Peters (tim_one)
Date: 2002-03-25 23:27

Message:
Logged In: YES 
user_id=31435

Assigned to Fred.

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

Comment By: Aron K. Insinga (ainsinga)
Date: 2002-03-25 22:19

Message:
Logged In: YES 
user_id=496408

attached is the sample program (which ought to have
indenting preserved!)


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

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


From noreply@sourceforge.net  Sun Aug  4 10:31:12 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 04 Aug 2002 02:31:12 -0700
Subject: [Python-bugs-list] [ python-Bugs-589429 ] libpython.a with PIC objects
Message-ID: <E17bHjE-0005qQ-00@usw-sf-web3.sourceforge.net>

Bugs item #589429, was opened at 2002-08-01 02:17
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=589429&group_id=5470

Category: Build
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: libpython.a with PIC objects

Initial Comment:
when configuring with --enable-shared, the "static" 
library libpython.a is build with PIC-compiled objects.
Using the option --enable-shared builds a shared library 
in addition to the static library (with objects compiled 
without PIC).


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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-08-04 11:31

Message:
Logged In: YES 
user_id=21627

After email discussion, we can close this report. 

Debian will build Python twice: once to obtain a
statically-linked /usr/bin/python and a non-PIC libpython.a,
and once to obtain a  libpython.so.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-03 23:40

Message:
Logged In: YES 
user_id=21627

Ok, this behaviour is now documented in README 1.151.

I still don't understand why you need a non-PIC libpython.a,
and I don't think that the standard build process should
produce a file named libpython_pic.a. My suggestion would be
to just run configure once - I still cannot see what
problems this would cause.

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

Comment By: Matthias Klose (doko)
Date: 2002-08-03 18:23

Message:
Logged In: YES 
user_id=60903

well, why not call this library libpython_pic.a then? Or at
least it should be *documented*, that libpython.a contains
pic objects when configured with --enabled-shared, and
non-pic objects, when configured without --enabled-shared

I currently work around by building python twice: a complete
build without --enable-shared and a second build building
only libpython2.3.so.1.0. The configury is done twice, but I
get what I want.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-03 13:05

Message:
Logged In: YES 
user_id=21627

I personally think that all the other packages are "wrong",
or perhaps address different usage scenarios:

If you have a PIC-compiled static library, you can link this
static library into other DSOs. Not having a PIC-compiled
library causes problems. 

E.g. on Solaris, people building Python extension modules
frequently find that they only have a static version of
libreadline or OpenSSL, which they then cannot integrate
into the readline or socket Python modules (because you need
PIC code for a DSO).

So, a PIC static library can support use cases that a
non-PIC static library cannot. The downside is that the PIC
library might be less efficient. User using --enable-shared
have already accepted less efficient code (since the shared
library is also PIC), so they should accept PIC code in the
static library as well.

In addition, not building non-PIC objects simplifies the
build process: you don't have to compile everything twice,
just because somebody may want non-PIC objects. If somebody
really requires non-PIC objects for reasons I cannot see,
they need to recompile Python separately.

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

Comment By: Matthias Klose (doko)
Date: 2002-08-02 20:24

Message:
Logged In: YES 
user_id=60903

I expect (as mostly known from other GNU libraries on Linux
systems), that I get an additional library with
--enable-shared, not a changed static library.
Currently the option really is
--enable-shared-and-build-static-with-pic.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-02 15:49

Message:
Logged In: YES 
user_id=21627

What is the bug here?

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

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


From noreply@sourceforge.net  Sun Aug  4 10:47:34 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 04 Aug 2002 02:47:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-221327 ] threads within an embedded python interpreter
Message-ID: <E17bHz4-00066O-00@usw-sf-web3.sourceforge.net>

Bugs item #221327, was opened at 2000-11-03 21:31
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=221327&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: threads within an embedded python interpreter

Initial Comment:
I have an application which I am required to embedd a python interpreter inside of a C++ application. The python script creates a separate thread of control to handle a TCP/IP socket connection. The thread can send data just find but hangs on the socket 'recv' fnction.

After a dya of debugging my code I went into the python socketmodule.c and at line 1082 I commented out the thread protection code:

/*Py_BEGIN_ALLOW_THREADS*/
n = recv(s->sock_fd, PyString_AsString(buf), len, flags);
/*Py_END_ALLOW_THREADS*/

I then recompiled the python library and then recompiled my C++ app and everything worked just fine.

The problem does not exist when I run the script alone using the python interpreter. Only when I embedd the interpreter, so this is some sort of configuration issue.

David Schere
Email: david_schere@yahoo.com





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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-08-04 11:47

Message:
Logged In: YES 
user_id=21627

Doc/api/init.tex already has a paragraph about calling
Python from a C thread; this patch adds a cookbook example.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-01 23:58

Message:
Logged In: YES 
user_id=6380

but is it a doco bug or not?

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

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-01 23:34

Message:
Logged In: YES 
user_id=31392

Probably ought to fix this for 2.3


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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-31 21:57

Message:
Logged In: NO 

Now u pay,.

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

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

Message:
Most likely, the problem is not the socket module but how you call Python code from a thread that was started from C/C++. Look at t_bootstrap() in threadmodule.c for an example on what to do. (And yes, it's tricky.) There should also be something in the Python/C API documentation about this.

I'm not closing the bug report since this is really a documentation issue; it needs to be documented better. I'll assign it to Fred.

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

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


From noreply@sourceforge.net  Sun Aug  4 10:48:51 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 04 Aug 2002 02:48:51 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-223599 ] Need user-centered info for Windows users.
Message-ID: <E17bI0J-0002OK-00@usw-sf-web5.sourceforge.net>

Feature Requests item #223599, was opened at 2000-11-27 17:31
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=223599&group_id=5470

>Category: None
>Group: None
Status: Open
Resolution: None
Priority: 6
Submitted By: Fred L. Drake, Jr. (fdrake)
>Assigned to: Nobody/Anonymous (nobody)
Summary: Need user-centered info for Windows users.

Initial Comment:
Users ask questions like "How do I write batch files using Python?"; there should be a document that acts as a user's guide specifically for Windows users.  This could be similar to what the Macintosh Modules Reference is becoming.  This should be part of the standard documentation and could acquire the Windows module documentation.

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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-08-04 11:48

Message:
Logged In: YES 
user_id=21627

Moved into feature requests tracker.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-06-18 05:28

Message:
Logged In: NO 

is it a really bad effect after i batch the file

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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-03-07 17:46

Message:
Logged In: NO 

hello! i am wantin! plz

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

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-01 23:37

Message:
Logged In: YES 
user_id=31392

Can we move this out of bugs and into feature requests?


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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-01-22 17:04

Message:
Another question that should be answered in this document:  "How do I create/recall modules?"  This one comes up most with first time programmers and users from environments that don't expose source code as editable text files (VB?).

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

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


From noreply@sourceforge.net  Sun Aug  4 10:58:01 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 04 Aug 2002 02:58:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-448679 ] Left to right
Message-ID: <E17bI9B-0002W4-00@usw-sf-web5.sourceforge.net>

Bugs item #448679, was opened at 2001-08-07 08:55
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=448679&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Left to right

Initial Comment:
The Ref Man doesn't explicitly say anything about 
Python's left-to-right evaluation order.  Strict left-
to-right was Guido's intent, though, and it comes up a 
few times per year on c.l.py (indeed, I was just 
replying to a msg asking about it).

The docs should get fleshed out.

There's also a bug:

>>> counter = 0
>>> def i():
...     global counter
...     counter += 1
...     return counter
...
>>> {i(): i()}
{2: 1}
>>> {i(): i(), i(): i()}
{4: 3, 6: 5}
>>>

That is, key:value *pairs* are evaluated left to 
right, but within a single key:value pair, the value 
gets evaluated first.  When I asked Guido about that 
some years ago, he agreed it was a bug.


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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-08-04 11:58

Message:
Logged In: YES 
user_id=21627

With the patch attached, this behaviour is cast into stone
(or, atleast into a SF tracker :)

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

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


From noreply@sourceforge.net  Sun Aug  4 13:39:16 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 04 Aug 2002 05:39:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-589422 ] shared libpython & dependant libraries
Message-ID: <E17bKfE-0005LT-00@usw-sf-web1.sourceforge.net>

Bugs item #589422, was opened at 2002-08-01 02:00
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=589422&group_id=5470

Category: Build
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: shared libpython & dependant libraries

Initial Comment:
When building the shared libpython.so, the shared 
library is not linked against dependent shared libraries, 
which are needed for the modules linked in the library.

i.e. the thread module normally is linked in the library, 
but libpython.so is not linked against the thread library ( 
pthread on Linux).


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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-08-04 14:39

Message:
Logged In: YES 
user_id=21627

Fixed in configure.in 1.340, configure 1.329.

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

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


From noreply@sourceforge.net  Sun Aug  4 13:47:58 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 04 Aug 2002 05:47:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-589427 ] standard include paths on command line
Message-ID: <E17bKne-0005Va-00@usw-sf-web1.sourceforge.net>

Bugs item #589427, was opened at 2002-08-01 02:13
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=589427&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: Remind
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Michael Hudson (mwh)
Summary: standard include paths on command line

Initial Comment:
when compiling shared modules (using gcc-3.1.1), 
standard include paths are included (by setup.py?) in 
the include path, which can change the search order. 
gcc-3.1 warns about:

building 'xreadlines' extension
gcc-3.1 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -
fPIC -I. -I/home/packages/pyt
hon2.3/python2.3-2.2.90/./Include -I/usr/include -
I/usr/local/include -I/home/pa
ckages/python2.3/python2.3-2.2.90/Include -
I/home/packages/python2.3/python2.3-2
.2.90/build-static -
c /home/packages/python2.3/python2.3-
2.2.90/Modules/xreadlin
esmodule.c -o build/temp.linux-i686-
2.3/xreadlinesmodule.o
gcc -shared build/temp.linux-i686-
2.3/xreadlinesmodule.o -L/usr/lib -L/usr/local
/lib -o build/lib.linux-i686-2.3/xreadlines.so
building 'array' extension
gcc-3.1 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -
fPIC -I. -I/hocc1: warning: c
hanging search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory

In this case, /usr/include and /usr/local/include should 
not be included on the command line.


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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-08-04 14:47

Message:
Logged In: YES 
user_id=21627

I can't reproduce this. With the current CVS, on Debian,
with --prefix=/usr, I get

gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC
-DWITH_APPINIT=1 -I/usr/include/tcl8.3 -I/usr/X11R6/include
-I. -I/vol/marvin-vol8/loewis/python/dist/src/./Include
-I/usr/local/include
-I/vol/marvin-vol8/loewis/python/dist/src/Include
-I/vol/marvin-vol8/loewis/python/dist/src -c
/vol/marvin-vol8/loewis/python/dist/src/Modules/_tkinter.c
-o build/temp.linux-i686-2.3/_tkinter.o

So it won't add -I/usr/include to the command line options.

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

Comment By: Matthias Klose (doko)
Date: 2002-08-03 18:30

Message:
Logged In: YES 
user_id=60903

No. It's:

 - bsddb
 - dbm
 - _tkinter

all modules, which are installed in /usr at least on Debian
GNU/Linux (but maybe on other distros as well).

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

Comment By: Michael Hudson (mwh)
Date: 2002-08-03 18:19

Message:
Logged In: YES 
user_id=6656

It's only the _ssl module, right?  I've fixed that.

The -R/usr/lib and -L/usr/lib's come from various database
modules, the configuration of which is under review anyway.
 I hope those doing the reviewing have seen this bug traffic...

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

Comment By: Matthias Klose (doko)
Date: 2002-08-03 17:56

Message:
Logged In: YES 
user_id=60903

build log attached. please tell me if you need an account on
a Debian machine (doko   debian org).
configure \
        --with-gcc=gcc-3.1 \
        --with-cxx=g++-3.1 \
        --prefix=/usr \
        --with-fpectl \
        --enable-ipv6


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

Comment By: Michael Hudson (mwh)
Date: 2002-08-03 17:12

Message:
Logged In: YES 
user_id=6656

Really?  Nuts.  They're not on my machine.

What arguments are you passing to configure?

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

Comment By: Matthias Klose (doko)
Date: 2002-08-02 23:48

Message:
Logged In: YES 
user_id=60903

Thanks for the fix, however when building shared modules,
-I/usr/include and -L/usr/lib are still passed to the compiler.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-02 16:05

Message:
Logged In: YES 
user_id=21627

And indeed, we should not remove /usr/local/include, since
the system compiler may not be gcc.

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

Comment By: Michael Hudson (mwh)
Date: 2002-08-02 15:56

Message:
Logged In: YES 
user_id=6656

OK, done, in

setup.py revision 1.100

I don't see us removing /usr/local/include from the command
line.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-02 15:49

Message:
Logged In: YES 
user_id=21627

The patch looks fine to me, please apply it.

I still think that the bogus warning should be removed from
gcc entirely.

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

Comment By: Michael Hudson (mwh)
Date: 2002-08-02 14:54

Message:
Logged In: YES 
user_id=6656

OK, can you try the attached patch?

Martin, does this look OK to you?

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

Comment By: Michael Hudson (mwh)
Date: 2002-08-02 10:53

Message:
Logged In: YES 
user_id=6656

Ah, sorry!

Hmm.  Now I don't see the problem, i.e. for me
-I/usr/include is not part of the command line passed to the
compiler.

Are you building from up-to-date CVS?  Though I don't recall
any recent changes in this area.  Ahh, you're running
".../configure --prefix=/usr", right?

I'll dig.

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

Comment By: Matthias Klose (doko)
Date: 2002-08-01 22:23

Message:
Logged In: YES 
user_id=60903

I disagree. The discussion is on /usr/local/include. We are 
talking about /usr/include, which is a system include dir on 
almost all systems.

See the thread "gcc 3.2's cpp breaks configure scripts" at 
http://gcc.gnu.org/ml/gcc/2002-07/, i.e.:

http://gcc.gnu.org/ml/gcc/2002-07/msg01527.html

Inclusion of /usr/include can lead to errors, as explained in:
http://gcc.gnu.org/ml/gcc/2002-07/msg01541.html

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

Comment By: Michael Hudson (mwh)
Date: 2002-08-01 11:08

Message:
Logged In: YES 
user_id=6656

This has been deemed a bug in gcc, see this thread:

http://mail.python.org/pipermail/python-dev/2002-June/025990.html

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

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


From noreply@sourceforge.net  Sun Aug  4 23:16:12 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 04 Aug 2002 15:16:12 -0700
Subject: [Python-bugs-list] [ python-Bugs-590888 ] off-by-one error in encoding warning
Message-ID: <E17bTfY-0008HX-00@usw-sf-web5.sourceforge.net>

Bugs item #590888, was opened at 2002-08-04 17:16
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=590888&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Martin v. Löwis (loewis)
Summary: off-by-one error in encoding warning

Initial Comment:
There seems to be an off-by-one error in the line number reported by 
the new encoding warnings.  Consider this simple file (three lines):

if __name__ == "__main__":
    x = "Bennett,Scott (guitar)" == "Scott Bennett"
    x = u"Andrè Previn" == "Andrè Previn"

If I import this into the current CVS Python, I get this warning:

>>> import dummy
dummy.py:2: DeprecationWarning: Non-ASCII character '\xe8', but 
no declared encoding
  x = "Bennett,Scott (guitar)" == "Scott Bennett"

It should be reporting and displaying line 3, not line 2.


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

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


From noreply@sourceforge.net  Mon Aug  5 02:49:48 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 04 Aug 2002 18:49:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-590888 ] off-by-one error in encoding warning
Message-ID: <E17bX0G-0006Vs-00@usw-sf-web3.sourceforge.net>

Bugs item #590888, was opened at 2002-08-05 00:16
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=590888&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Martin v. Löwis (loewis)
Summary: off-by-one error in encoding warning

Initial Comment:
There seems to be an off-by-one error in the line number reported by 
the new encoding warnings.  Consider this simple file (three lines):

if __name__ == "__main__":
    x = "Bennett,Scott (guitar)" == "Scott Bennett"
    x = u"Andrè Previn" == "Andrè Previn"

If I import this into the current CVS Python, I get this warning:

>>> import dummy
dummy.py:2: DeprecationWarning: Non-ASCII character '\xe8', but 
no declared encoding
  x = "Bennett,Scott (guitar)" == "Scott Bennett"

It should be reporting and displaying line 3, not line 2.


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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-08-05 03:49

Message:
Logged In: YES 
user_id=21627

Thanks for your report. Fixed in tokenizer.c 2.60.

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

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


From noreply@sourceforge.net  Mon Aug  5 03:06:16 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 04 Aug 2002 19:06:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-589149 ] Memory leakage in SAX with exception
Message-ID: <E17bXGC-0006ij-00@usw-sf-web3.sourceforge.net>

Bugs item #589149, was opened at 2002-07-31 17:02
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=589149&group_id=5470

Category: XML
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Paolo Andreetto (pandreetto)
Assigned to: Nobody/Anonymous (nobody)
Summary: Memory leakage in SAX with exception

Initial Comment:
Trying the following test:

#!/usr/bin/python

import sys,string,StringIO,traceback,time,gc
import xml.sax,xml.sax.handler
gc.set_debug(gc.DEBUG_SAVEALL)

class SimpleHandler(xml.sax.handler.ContentHandler):
    def __init__(self):
        pass

    def startElement(self,name,attrs):
        print 'start ',name

    def endElement(self,name):
        print 'end ',name

    def characters(self,content):
        print content

class SimpleErrorHandler(xml.sax.handler.ErrorHandler):
    def __init__(self):
        pass
        
    def fatalError(self,e):
        print e

myHandler=SimpleHandler()
myErrHandler=SimpleErrorHandler()
data='<test>something</>'
while 1:
    gc.collect()
    print len(gc.garbage)
    
    try:
        #xml.sax.parseString(data,myHandler,myErrHandler)
        xml.sax.parseString(data,myHandler)
    except Exception, e:
        sinfo=sys.exc_info()
	traceback.print_tb(sinfo[2],None)
    time.sleep(1)

it seems that lots of object remain uncollectable.
Using the SimpleErrorHandler the behaviour of gc is
good but a memory leakage still remain (4Kb every 30
seconds).
Tests run on i386 with debian/Linux (sid), python 2.1.3
(Build of July 29th).

Thanks

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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-08-05 04:06

Message:
Logged In: YES 
user_id=21627

Your analysis of this result is wrong. Instead, the result
shows that all objects *are* collectible, and that there is
merely cyclic garbage in case of a parser error - this
garbage *will* be collected, unless you explicitly ask the
GC to save it (which you do in your example).

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

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


From noreply@sourceforge.net  Mon Aug  5 03:14:55 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 04 Aug 2002 19:14:55 -0700
Subject: [Python-bugs-list] [ python-Bugs-589965 ] "".split() ignores maxsplit arg
Message-ID: <E17bXOZ-0002VW-00@usw-sf-web1.sourceforge.net>

Bugs item #589965, was opened at 2002-08-02 07:27
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=589965&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Gregory Bond (gnbond)
Assigned to: Nobody/Anonymous (nobody)
>Summary: "".split() ignores maxsplit arg

Initial Comment:
lightning$ python
Python 2.1.1 (#4, Oct 10 2001, 11:07:04) 
[GCC 2.95.3 20010315 (release)] on sunos5
Type "copyright", "credits" or "license" for more
information.
>>> s = 'a b c d e f g'
>>> s.split()
['a', 'b', 'c', 'd', 'e', 'f', 'g']
>>> s.split(maxsplit=3)
['a', 'b', 'c', 'd', 'e', 'f', 'g']
>>> import string
>>> string.split(s, maxsplit=3)
['a', 'b', 'c', 'd e f g']
>>> 
lightning$ 

i.e. s.split(maxsplit=3) is NOT the same as
string.split(s, maxsplit=3)


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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-08-05 04:14

Message:
Logged In: YES 
user_id=21627

This has been fixed in Python 2.2, which reports

>>> s.split(maxsplit=3)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: split() takes no keyword arguments

That means that the keyword argument is not supported; you
must write this as

s.split(' ', 3)

If you do not want to give a string separator, you need to
pass None.

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

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


From noreply@sourceforge.net  Mon Aug  5 05:07:10 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 04 Aug 2002 21:07:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-427345 ] CGIHTTPServer fix for Windows
Message-ID: <E17bZ9C-0004bO-00@usw-sf-web5.sourceforge.net>

Bugs item #427345, was opened at 2001-05-25 10:37
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=427345&group_id=5470

Category: Python Library
Group: Platform-specific
Status: Open
Resolution: None
Priority: 3
Submitted By: Kevin Altis (kasplat)
Assigned to: Nobody/Anonymous (nobody)
Summary: CGIHTTPServer fix for Windows

Initial Comment:
CGIHTTPServer.py in the Python 2.1 library needs two 
changes to the popen2 section in order to support 
binary data and to avoid buffering problems under 
Windows. The complete code block is shown at the end 
of this message. The two changed lines are:
cmdline = "%s -u %s" % (interp, cmdline)
fi, fo = os.popen2(cmdline, 'b')

I've tested this under Windows 2000 Pro and binary 
file uploads now work, however more extensive tests 
should probably be done.

It appears there is another socket-related problem 
and/or end-of-line conversion error that occurs when 
using Internet Explorer 5.x and BASEHTTPServer with 
CGIHTTPServer on the same machine. I'm still 
investigating that issue.

Finally, I have done a small rewrite of 
CGIHTTPServer.py to simplify subclassing it to support 
running CGIs in any or all directories and using other 
file extensions such as .cgi. The maintainer for the 
current file should email me about the changes to see 
whether they want to update the official library file. 
I didn't post it here since it needs more tweaking

ka
---
CGIHTTPServer.p fixes...
elif self.have_popen2:
    # Windows -- use popen2 to create a subprocess
    import shutil
    os.environ.update(env)
    cmdline = scriptfile
    if self.is_python(scriptfile):
        interp = sys.executable
        if interp.lower().endswith("w.exe"):
            # On Windows, use python.exe, not 
python.exe
            interp = interp[:-5] = interp[-4:]
        cmdline = "%s -u %s" % (interp, cmdline)
    if '=' not in query and '"' not in query:
        cmdline = '%s "%s"' % (cmdline, query)
    self.log_error("command: %s", cmdline)
    try:
        nbytes = int(length)
    except:
        nbytes = 0
    fi, fo = os.popen2(cmdline, 'b')
    if self.command.lower() == "post" and nbytes > 0:
        data = self.rfile.read(nbytes)
        fi.write(data)
    fi.close()
    shutil.copyfileobj(fo, self.wfile)
    sts = fo.close()
    if sts:
        self.log_error("CGI script exit status %#x", 
sts)
    else:
        self.log_error("CGI script exited OK")


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

>Comment By: Kevin Altis (kasplat)
Date: 2002-08-04 21:07

Message:
Logged In: YES 
user_id=228025

I have a possible fix, at least when the server is running on 
Windows. As suggested previously, the key is to read the 
bytes beyond the content-length, but without blocking. Steve 
Holden suggested I use select, which seems simpler than 
another solution which is to make the socket non-blocking, 
then attempting to read 2 bytes of data within a try/except 
block.

The solution below just loops with select.select

            if self.command.lower() == "post" and nbytes > 0:
                data = self.rfile.read(nbytes)
                fi.write(data)
                # now throw away data past Content-length
                while select.select([self.rfile._sock], [], [], 0)[0] != 
[]:
                    waste = self.rfile._sock.recv(1)
            fi.close()

This is slightly verbose. The two additional lines go below the 
fi.write statement on line 247 of CGIHTTPServer.py, line 248 if 
you count the import select statement that needs to be 
added at the top of the file.

I have only tested this on Windows since the server code is 
Windows-specific. I do not know if a server running on Unix 
suffers this same problem. I verified that POST works 
correctly from the following browsers on Windows 2000: IE 
5.5, Opera 6.0.4, and Netscape 4.7. Only IE sends the extra 
CR/LF, Opera and Netscape do not.

ka

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

Comment By: Kevin Altis (kasplat)
Date: 2002-08-03 10:37

Message:
Logged In: YES 
user_id=228025

This bug is related to another bug

https://sourceforge.net/tracker/?
func=detail&aid=430160&group_id=5470&atid=105470

Bob Denny (author of the WebSite server, formerly sold by 
O'Reilly) had this to say about the POST problem:

"This is an old problem, traced back to Netscape and Unix-
based shell CGI scripts. Netscape browsers did this to force 
completion of the POST into shell scripts. The cr/lf is not part 
of the POST payload, and the CGI script that is dealing with 
the POST needs to toss it away. The general solution is, read 
Content-Length bytes, then reas anything else that may be in 
the buffer and junk it. IE is emulating the behavior of 
Netscape."

So, that explains why IE (and possibly other browsers) sticks 
a CR/LF on the end of a POST causing a mismatch with the 
Content-length header. Now the question is where a fix can 
be inserted in the libs?

Looking again at CGIHTTPServer.py, perhaps this problem is 
isolated to Windows, in which case the fix might be in the 
block of code starting on line 218, and more specifically, line 
246

data = self.rfile.read(nbytes)

so at that point, the remaining 2 bytes should be read, but 
tossed. I'll investigate. Steve Holden and I have been emailing 
back and forth on this issue, so if anyone else has other 
suggestions, post here or email one of us.

Thanks,

ka

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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-07-08 18:27

Message:
Logged In: NO 

hello

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

Comment By: Thomas Justin Shaw (justinshaw)
Date: 2002-03-31 00:48

Message:
Logged In: YES 
user_id=135558

To: Matthew King
Thanks for reposting that solution.  That did seem to fix 
the problem.

To: Mark Lutz
Using: Win2000 Pro IE5 python2.2.1c locally
The bug shows up as a popup message but the page loads.
When I tried it accross a lan the page wouldn't even
load (blowing a little demo).  So I guess it is not ONLY a 
local problem.

Thanks for posting.
Justin Shaw

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

Comment By: Thomas Justin Shaw (justinshaw)
Date: 2002-03-28 23:36

Message:
Logged In: YES 
user_id=135558

I'm experiencing a problem on windows.
When I execute the scripts as 
'http://localhost:8080/cgi-bin\junk.py' 
the page seems to load ok but I get the popup message:
Internet Explorer cannot open the Internet site 
http://localhost:8080/cgi-bin\junk.py
The connection with the server ws reset

On Netscape no errors but the download also takes forever. 
The slow download seems to be caused by the 
FieldStorage() call.


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

Comment By: Matthew King (kyrrigle)
Date: 2002-03-28 13:21

Message:
Logged In: YES 
user_id=247536

this looks like the same issue as #430160.  and here's what 
I just wrote there...

it appears that IE is sending 2 extra bytes ('\r\n') after 
the request data.  and if you don't read those two extra 
bytes off, the window's socket handling gets messed up.

the result is that a partial response is returned and the 
socket closed.  IE tries to recover by re-POST'ing (which 
is behavior specified in the HTTP/1.1 RFC)... only they 
seem to add an embedded NULL the second time through, and 
the original socket problem happens again anyway.

Try reading an extra 2 bytes from the rfile before sending 
your response and the problem should go away.  (you can do 
that by 'self.rfile._rbufsize = content_length + 2' inside 
your do_POST method before reading the content)

not sure what the real fix for this should be?


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-09-05 08:40

Message:
Logged In: YES 
user_id=6380

Load shedding.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-09 06:14

Message:
Logged In: YES 
user_id=6380

Reopening -- not that I have time for this. :-(

Note that that patch is in socket.py.

If this really is a work-around, I'd like to understand why.

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

Comment By: Steve Pike (oztourer)
Date: 2001-08-09 05:27

Message:
Logged In: YES 
user_id=120658

To further elaborate on the problems with POST on Windows 
95: without having reached any real understanding of the 
problem I have found a tolerable workaround. By modifying 
the default _rbufsize for class _fileobject in socket.py I 
can get any POSTs with text length less than _rbufsize to 
work. Here is the mod:

<pre>
class _fileobject:
    def __init__(self, sock, mode, bufsize):
        self._sock = sock
        self._mode = mode
        if bufsize < 0:
            bufsize = 512
        # SP 9 Aug 2001: default _rbufsize is too small, 
crashing CGIHTTPServer on POST's
        # This fix still only allows pages of less than 
given buffer size to be updated,
        # so the real fix has still to be discovered.
        #self._rbufsize = max(1, bufsize)
        self._rbufsize = max(16*1024, bufsize)
        self._wbufsize = bufsize
        self._wbuf = self._rbuf = ""
</pre>

-- StevePike

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-07 12:59

Message:
Logged In: YES 
user_id=6380

I agree that this is a laudable goal, but I don't have the
time to spend to work on this.  Please upload a patch to the
SF patch manager and assign it to me and I'll look at it.

In the mean time, I've applied the two small suggestions and
will close this bug report.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-05-29 09:29

Message:
Logged In: NO 

I want to elaborate on the second-to-last 
paragraph in this report.  CGIHTTPServer 
in 2.1 and 2.0 is apparently broken for 
POST requests (only) to CGI scripts, when
running locally on Windows with an IE client.

The details: there is a problem with 
the combination of a CGIHTTPServer and 
Intenernet Explorer both running locally 
on Windows (with server name "localhost").
In this setup, POST requests to CGI scripts
fail, but GET requests to the exact same 
script work fine.  That is, a form with 
method=GET, or a URL with an appended 
query string, both work ok.

In POST mode, the CGI script gets proper
data in the input stream, and generates 
a correct reply stream (which is in fact 
identical to the output generated for 
quivalent GET requests).  So, somewhere 
between CGIHTTPServer and IE, the data 
seems to be dropped or munged.  The same
thing happens of you force CGIHTTPServer 
to use execfile() to launch the script, 
instead of os.popen2.

I've also observed that endline conventions 
seem to be irrelevant to the problem; using 
\n or \r\n makes no difference in both the 
input and reply streams.  I've also been 
told that the problem may not exist in 
Netscape clients.

Since CGIHTTPServer is a very nice way to test
CGI scripts (all you need is a standard Python
install), this seems important.  It would also 
be nice if the directory assumptions in that 
module were more customizable, but that's just
a wish.

--Mark Lutz


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

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


From noreply@sourceforge.net  Mon Aug  5 06:53:23 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 04 Aug 2002 22:53:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-587087 ] ur'\u' not handled properly
Message-ID: <E17banz-0008Ai-00@usw-sf-web2.sourceforge.net>

Bugs item #587087, was opened at 2002-07-26 11:05
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=587087&group_id=5470

Category: Parser/Compiler
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeff Epler (jepler)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: ur'\u' not handled properly

Initial Comment:
according to
http://www.python.org/doc/current/ref/strings.html, no
\-escapes have a meaning inside raw strings.

However, \u seems to be interpreted:
>>> ur'\u'
UnicodeError: Unicode-Escape decoding error: truncated
\uXXXX
>>> ur'\u0100'
u'\u0100'

I would expect the values to be
u'\u'
u'\u0100'

Tested in 2.3a0 from <2 weeks ago and python 2.2.

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-08-05 00:53

Message:
Logged In: YES 
user_id=80475

Documentation patch attached for Fred's approval.

If okay, re-assign back to Raymond for a commit and 
backport to 2.2.

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-07-26 11:31

Message:
Logged In: YES 
user_id=38388

I suppose this is a documentation bug. According to PEP 100:

    u = ur'<raw-unicode-escape encoded Python string>'

    The 'raw-unicode-escape' encoding is defined as follows:

    - \uXXXX sequence represent the U+XXXX Unicode character
if and
      only if the number of leading backslashes is odd

    - all other characters represent themselves as Unicode
ordinal
      (e.g. 'b' -> U+0062)

Assigned to Fred.

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

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


From noreply@sourceforge.net  Mon Aug  5 07:31:08 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 04 Aug 2002 23:31:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-582071 ] ''.split() docstring clarification
Message-ID: <E17bbOW-0006ir-00@usw-sf-web1.sourceforge.net>

Bugs item #582071, was opened at 2002-07-15 22:20
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=582071&group_id=5470

Category: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: David Niergarth (jdnier)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: ''.split() docstring clarification

Initial Comment:
I'm suggesting a small clarification in the docstring for the 
split method of strings.

>>> print ''.split.__doc__
S.split([sep [,maxsplit]]) -> list of strings

Return a list of the words in the string S, using sep as the
delimiter string.  If maxsplit is given, at most maxsplit
splits are done. If sep is not specified, any whitespace 
string is a separator.
>>>

I think that last sentence would better read:

    If sep is not specified or is None, any whitespace 
    string is a separator. 

adding "or is None".

For the longest time I thought is wasn't possible to specify 
maxsplit and still split on "any whitespace." It turns out 
None is the magic value you can use to indicate "any 
whitespace." For example,

    >>> 'a\tb c d'.split(None, 2)
    ['a', 'b', 'c d']

This is suggested by the signature of the old string.split 
function

    def split(s, sep=None, maxsplit=-1):

although the new-ish ''.split() method does not accept 
keyword args.

This little clarification would have helped in my case 
anyway (re.split() notwithstanding).

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-08-05 01:31

Message:
Logged In: YES 
user_id=80475

Thank you for the contribution.

Added "or is None" to the docstring.
Committed as stringobject.c. 2.174 and backported to 
2.147.6.7

Closing bug.



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

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


From noreply@sourceforge.net  Mon Aug  5 09:25:12 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 05 Aug 2002 01:25:12 -0700
Subject: [Python-bugs-list] [ python-Bugs-589149 ] Memory leakage in SAX with exception
Message-ID: <E17bdAu-0000et-00@usw-sf-web1.sourceforge.net>

Bugs item #589149, was opened at 2002-07-31 17:02
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=589149&group_id=5470

Category: XML
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Paolo Andreetto (pandreetto)
Assigned to: Nobody/Anonymous (nobody)
Summary: Memory leakage in SAX with exception

Initial Comment:
Trying the following test:

#!/usr/bin/python

import sys,string,StringIO,traceback,time,gc
import xml.sax,xml.sax.handler
gc.set_debug(gc.DEBUG_SAVEALL)

class SimpleHandler(xml.sax.handler.ContentHandler):
    def __init__(self):
        pass

    def startElement(self,name,attrs):
        print 'start ',name

    def endElement(self,name):
        print 'end ',name

    def characters(self,content):
        print content

class SimpleErrorHandler(xml.sax.handler.ErrorHandler):
    def __init__(self):
        pass
        
    def fatalError(self,e):
        print e

myHandler=SimpleHandler()
myErrHandler=SimpleErrorHandler()
data='<test>something</>'
while 1:
    gc.collect()
    print len(gc.garbage)
    
    try:
        #xml.sax.parseString(data,myHandler,myErrHandler)
        xml.sax.parseString(data,myHandler)
    except Exception, e:
        sinfo=sys.exc_info()
	traceback.print_tb(sinfo[2],None)
    time.sleep(1)

it seems that lots of object remain uncollectable.
Using the SimpleErrorHandler the behaviour of gc is
good but a memory leakage still remain (4Kb every 30
seconds).
Tests run on i386 with debian/Linux (sid), python 2.1.3
(Build of July 29th).

Thanks

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

>Comment By: Paolo Andreetto (pandreetto)
Date: 2002-08-05 10:25

Message:
Logged In: YES 
user_id=551296

This is correct, it's my fault, but removing the
gc.set_dubug instruction the situation doesn't change. The
script is just a simple test, my trouble comes from a memory
leakage into SOAPpy module which uses another SAX-based
XML-parser.
If you think the problem doesn't depends on the python core,
please close this bug.
Thanks

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-05 04:06

Message:
Logged In: YES 
user_id=21627

Your analysis of this result is wrong. Instead, the result
shows that all objects *are* collectible, and that there is
merely cyclic garbage in case of a parser error - this
garbage *will* be collected, unless you explicitly ask the
GC to save it (which you do in your example).

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

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


From noreply@sourceforge.net  Mon Aug  5 15:23:25 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 05 Aug 2002 07:23:25 -0700
Subject: [Python-bugs-list] [ python-Bugs-591104 ] os.tmpfile() can fail on win32
Message-ID: <E17bilZ-0000ly-00@usw-sf-web2.sourceforge.net>

Bugs item #591104, was opened at 2002-08-05 14:23
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=591104&group_id=5470

Category: Windows
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Joseph barillari (jdbarillari)
Assigned to: Tim Peters (tim_one)
Summary: os.tmpfile() can fail on win32

Initial Comment:
I've discovered what appears to be a bug in Python 2.2.1 
on Win32. I'm
using the 2.2.1 build that I downloaded from python.org. 
I'm running
Windows 2000.

If os.tmpfile() is exceuted when the CWD is a UNC path, 
the base of
which is not writeable by the current user, tmpfile will
fail. tempfile.TemporaryFile will work, so I suspect this is 
a bug in os.tmpfile().

For example:

C:\>pwd  
/cygdrive/c   #I use cygwin

C:\>bash    # I have to use bash; the DOS shell doesn't 
support UNC paths
bash: .bashrc: No such file or directory
bash-2.05a$ cd //bopp/jbarilla
bash-2.05a$ pwd
//bopp/jbarilla
bash-2.05a$ python
Python 2.2.1 (#34, Apr  9 2002, 19:34:33) [MSC 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import os; os.tmpfile()
<open file '<tmpfile>', mode 'w+' at 0x007762C0> # It 
works.
>>> ^Z

If I chmod 555 //bopp/jbarilla (from unix via NFS; 
incidentally,
"chmod 555 ." from cygwin is ineffectual), then tmpfile 
fails:

bash-2.05a$ pwd
//bopp/jbarilla
bash-2.05a$ python
Python 2.2.1 (#34, Apr  9 2002, 19:34:33) [MSC 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import os; os.tmpfile()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OSError: [Errno 13] Permission denied # Oops.

# However, tempfile.TemporaryFile works:

>>> import tempfile; tempfile.TemporaryFile()
<open file 'c:\DOCUME~1\jbarilla\LOCALS~1
\Temp\~1880-0', mode 'w+b' at 0x00779B00>

--Joe

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

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


From noreply@sourceforge.net  Mon Aug  5 15:51:45 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 05 Aug 2002 07:51:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-589427 ] standard include paths on command line
Message-ID: <E17bjCz-0005Fo-00@usw-sf-web3.sourceforge.net>

Bugs item #589427, was opened at 2002-08-01 00:13
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=589427&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: Remind
Priority: 5
Submitted By: Matthias Klose (doko)
>Assigned to: Skip Montanaro (montanaro)
Summary: standard include paths on command line

Initial Comment:
when compiling shared modules (using gcc-3.1.1), 
standard include paths are included (by setup.py?) in 
the include path, which can change the search order. 
gcc-3.1 warns about:

building 'xreadlines' extension
gcc-3.1 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -
fPIC -I. -I/home/packages/pyt
hon2.3/python2.3-2.2.90/./Include -I/usr/include -
I/usr/local/include -I/home/pa
ckages/python2.3/python2.3-2.2.90/Include -
I/home/packages/python2.3/python2.3-2
.2.90/build-static -
c /home/packages/python2.3/python2.3-
2.2.90/Modules/xreadlin
esmodule.c -o build/temp.linux-i686-
2.3/xreadlinesmodule.o
gcc -shared build/temp.linux-i686-
2.3/xreadlinesmodule.o -L/usr/lib -L/usr/local
/lib -o build/lib.linux-i686-2.3/xreadlines.so
building 'array' extension
gcc-3.1 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -
fPIC -I. -I/hocc1: warning: c
hanging search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory

In this case, /usr/include and /usr/local/include should 
not be included on the command line.


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

>Comment By: Michael Hudson (mwh)
Date: 2002-08-05 14:51

Message:
Logged In: YES 
user_id=6656

Skip, are you still working on the bsddb related bits of
setup.py?  Can you look into how /usr/include is getting
onto the commandline?


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-04 12:47

Message:
Logged In: YES 
user_id=21627

I can't reproduce this. With the current CVS, on Debian,
with --prefix=/usr, I get

gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC
-DWITH_APPINIT=1 -I/usr/include/tcl8.3 -I/usr/X11R6/include
-I. -I/vol/marvin-vol8/loewis/python/dist/src/./Include
-I/usr/local/include
-I/vol/marvin-vol8/loewis/python/dist/src/Include
-I/vol/marvin-vol8/loewis/python/dist/src -c
/vol/marvin-vol8/loewis/python/dist/src/Modules/_tkinter.c
-o build/temp.linux-i686-2.3/_tkinter.o

So it won't add -I/usr/include to the command line options.

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

Comment By: Matthias Klose (doko)
Date: 2002-08-03 16:30

Message:
Logged In: YES 
user_id=60903

No. It's:

 - bsddb
 - dbm
 - _tkinter

all modules, which are installed in /usr at least on Debian
GNU/Linux (but maybe on other distros as well).

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

Comment By: Michael Hudson (mwh)
Date: 2002-08-03 16:19

Message:
Logged In: YES 
user_id=6656

It's only the _ssl module, right?  I've fixed that.

The -R/usr/lib and -L/usr/lib's come from various database
modules, the configuration of which is under review anyway.
 I hope those doing the reviewing have seen this bug traffic...

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

Comment By: Matthias Klose (doko)
Date: 2002-08-03 15:56

Message:
Logged In: YES 
user_id=60903

build log attached. please tell me if you need an account on
a Debian machine (doko   debian org).
configure \
        --with-gcc=gcc-3.1 \
        --with-cxx=g++-3.1 \
        --prefix=/usr \
        --with-fpectl \
        --enable-ipv6


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

Comment By: Michael Hudson (mwh)
Date: 2002-08-03 15:12

Message:
Logged In: YES 
user_id=6656

Really?  Nuts.  They're not on my machine.

What arguments are you passing to configure?

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

Comment By: Matthias Klose (doko)
Date: 2002-08-02 21:48

Message:
Logged In: YES 
user_id=60903

Thanks for the fix, however when building shared modules,
-I/usr/include and -L/usr/lib are still passed to the compiler.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-02 14:05

Message:
Logged In: YES 
user_id=21627

And indeed, we should not remove /usr/local/include, since
the system compiler may not be gcc.

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

Comment By: Michael Hudson (mwh)
Date: 2002-08-02 13:56

Message:
Logged In: YES 
user_id=6656

OK, done, in

setup.py revision 1.100

I don't see us removing /usr/local/include from the command
line.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-02 13:49

Message:
Logged In: YES 
user_id=21627

The patch looks fine to me, please apply it.

I still think that the bogus warning should be removed from
gcc entirely.

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

Comment By: Michael Hudson (mwh)
Date: 2002-08-02 12:54

Message:
Logged In: YES 
user_id=6656

OK, can you try the attached patch?

Martin, does this look OK to you?

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

Comment By: Michael Hudson (mwh)
Date: 2002-08-02 08:53

Message:
Logged In: YES 
user_id=6656

Ah, sorry!

Hmm.  Now I don't see the problem, i.e. for me
-I/usr/include is not part of the command line passed to the
compiler.

Are you building from up-to-date CVS?  Though I don't recall
any recent changes in this area.  Ahh, you're running
".../configure --prefix=/usr", right?

I'll dig.

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

Comment By: Matthias Klose (doko)
Date: 2002-08-01 20:23

Message:
Logged In: YES 
user_id=60903

I disagree. The discussion is on /usr/local/include. We are 
talking about /usr/include, which is a system include dir on 
almost all systems.

See the thread "gcc 3.2's cpp breaks configure scripts" at 
http://gcc.gnu.org/ml/gcc/2002-07/, i.e.:

http://gcc.gnu.org/ml/gcc/2002-07/msg01527.html

Inclusion of /usr/include can lead to errors, as explained in:
http://gcc.gnu.org/ml/gcc/2002-07/msg01541.html

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

Comment By: Michael Hudson (mwh)
Date: 2002-08-01 09:08

Message:
Logged In: YES 
user_id=6656

This has been deemed a bug in gcc, see this thread:

http://mail.python.org/pipermail/python-dev/2002-June/025990.html

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

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


From noreply@sourceforge.net  Mon Aug  5 16:00:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 05 Aug 2002 08:00:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-427345 ] CGIHTTPServer fix for Windows
Message-ID: <E17bjL0-0000zt-00@usw-sf-web5.sourceforge.net>

Bugs item #427345, was opened at 2001-05-25 13:37
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=427345&group_id=5470

Category: Python Library
Group: Platform-specific
Status: Open
Resolution: None
>Priority: 5
Submitted By: Kevin Altis (kasplat)
>Assigned to: Steve Holden (holdenweb)
Summary: CGIHTTPServer fix for Windows

Initial Comment:
CGIHTTPServer.py in the Python 2.1 library needs two 
changes to the popen2 section in order to support 
binary data and to avoid buffering problems under 
Windows. The complete code block is shown at the end 
of this message. The two changed lines are:
cmdline = "%s -u %s" % (interp, cmdline)
fi, fo = os.popen2(cmdline, 'b')

I've tested this under Windows 2000 Pro and binary 
file uploads now work, however more extensive tests 
should probably be done.

It appears there is another socket-related problem 
and/or end-of-line conversion error that occurs when 
using Internet Explorer 5.x and BASEHTTPServer with 
CGIHTTPServer on the same machine. I'm still 
investigating that issue.

Finally, I have done a small rewrite of 
CGIHTTPServer.py to simplify subclassing it to support 
running CGIs in any or all directories and using other 
file extensions such as .cgi. The maintainer for the 
current file should email me about the changes to see 
whether they want to update the official library file. 
I didn't post it here since it needs more tweaking

ka
---
CGIHTTPServer.p fixes...
elif self.have_popen2:
    # Windows -- use popen2 to create a subprocess
    import shutil
    os.environ.update(env)
    cmdline = scriptfile
    if self.is_python(scriptfile):
        interp = sys.executable
        if interp.lower().endswith("w.exe"):
            # On Windows, use python.exe, not 
python.exe
            interp = interp[:-5] = interp[-4:]
        cmdline = "%s -u %s" % (interp, cmdline)
    if '=' not in query and '"' not in query:
        cmdline = '%s "%s"' % (cmdline, query)
    self.log_error("command: %s", cmdline)
    try:
        nbytes = int(length)
    except:
        nbytes = 0
    fi, fo = os.popen2(cmdline, 'b')
    if self.command.lower() == "post" and nbytes > 0:
        data = self.rfile.read(nbytes)
        fi.write(data)
    fi.close()
    shutil.copyfileobj(fo, self.wfile)
    sts = fo.close()
    if sts:
        self.log_error("CGI script exit status %#x", 
sts)
    else:
        self.log_error("CGI script exited OK")


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-05 11:00

Message:
Logged In: YES 
user_id=6380

Like 430160, I'm assigning this to Steve Holden who may
check in a fix. Good luck!

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

Comment By: Kevin Altis (kasplat)
Date: 2002-08-05 00:07

Message:
Logged In: YES 
user_id=228025

I have a possible fix, at least when the server is running on 
Windows. As suggested previously, the key is to read the 
bytes beyond the content-length, but without blocking. Steve 
Holden suggested I use select, which seems simpler than 
another solution which is to make the socket non-blocking, 
then attempting to read 2 bytes of data within a try/except 
block.

The solution below just loops with select.select

            if self.command.lower() == "post" and nbytes > 0:
                data = self.rfile.read(nbytes)
                fi.write(data)
                # now throw away data past Content-length
                while select.select([self.rfile._sock], [], [], 0)[0] != 
[]:
                    waste = self.rfile._sock.recv(1)
            fi.close()

This is slightly verbose. The two additional lines go below the 
fi.write statement on line 247 of CGIHTTPServer.py, line 248 if 
you count the import select statement that needs to be 
added at the top of the file.

I have only tested this on Windows since the server code is 
Windows-specific. I do not know if a server running on Unix 
suffers this same problem. I verified that POST works 
correctly from the following browsers on Windows 2000: IE 
5.5, Opera 6.0.4, and Netscape 4.7. Only IE sends the extra 
CR/LF, Opera and Netscape do not.

ka

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

Comment By: Kevin Altis (kasplat)
Date: 2002-08-03 13:37

Message:
Logged In: YES 
user_id=228025

This bug is related to another bug

https://sourceforge.net/tracker/?
func=detail&aid=430160&group_id=5470&atid=105470

Bob Denny (author of the WebSite server, formerly sold by 
O'Reilly) had this to say about the POST problem:

"This is an old problem, traced back to Netscape and Unix-
based shell CGI scripts. Netscape browsers did this to force 
completion of the POST into shell scripts. The cr/lf is not part 
of the POST payload, and the CGI script that is dealing with 
the POST needs to toss it away. The general solution is, read 
Content-Length bytes, then reas anything else that may be in 
the buffer and junk it. IE is emulating the behavior of 
Netscape."

So, that explains why IE (and possibly other browsers) sticks 
a CR/LF on the end of a POST causing a mismatch with the 
Content-length header. Now the question is where a fix can 
be inserted in the libs?

Looking again at CGIHTTPServer.py, perhaps this problem is 
isolated to Windows, in which case the fix might be in the 
block of code starting on line 218, and more specifically, line 
246

data = self.rfile.read(nbytes)

so at that point, the remaining 2 bytes should be read, but 
tossed. I'll investigate. Steve Holden and I have been emailing 
back and forth on this issue, so if anyone else has other 
suggestions, post here or email one of us.

Thanks,

ka

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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-07-08 21:27

Message:
Logged In: NO 

hello

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

Comment By: Thomas Justin Shaw (justinshaw)
Date: 2002-03-31 03:48

Message:
Logged In: YES 
user_id=135558

To: Matthew King
Thanks for reposting that solution.  That did seem to fix 
the problem.

To: Mark Lutz
Using: Win2000 Pro IE5 python2.2.1c locally
The bug shows up as a popup message but the page loads.
When I tried it accross a lan the page wouldn't even
load (blowing a little demo).  So I guess it is not ONLY a 
local problem.

Thanks for posting.
Justin Shaw

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

Comment By: Thomas Justin Shaw (justinshaw)
Date: 2002-03-29 02:36

Message:
Logged In: YES 
user_id=135558

I'm experiencing a problem on windows.
When I execute the scripts as 
'http://localhost:8080/cgi-bin\junk.py' 
the page seems to load ok but I get the popup message:
Internet Explorer cannot open the Internet site 
http://localhost:8080/cgi-bin\junk.py
The connection with the server ws reset

On Netscape no errors but the download also takes forever. 
The slow download seems to be caused by the 
FieldStorage() call.


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

Comment By: Matthew King (kyrrigle)
Date: 2002-03-28 16:21

Message:
Logged In: YES 
user_id=247536

this looks like the same issue as #430160.  and here's what 
I just wrote there...

it appears that IE is sending 2 extra bytes ('\r\n') after 
the request data.  and if you don't read those two extra 
bytes off, the window's socket handling gets messed up.

the result is that a partial response is returned and the 
socket closed.  IE tries to recover by re-POST'ing (which 
is behavior specified in the HTTP/1.1 RFC)... only they 
seem to add an embedded NULL the second time through, and 
the original socket problem happens again anyway.

Try reading an extra 2 bytes from the rfile before sending 
your response and the problem should go away.  (you can do 
that by 'self.rfile._rbufsize = content_length + 2' inside 
your do_POST method before reading the content)

not sure what the real fix for this should be?


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-09-05 11:40

Message:
Logged In: YES 
user_id=6380

Load shedding.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-09 09:14

Message:
Logged In: YES 
user_id=6380

Reopening -- not that I have time for this. :-(

Note that that patch is in socket.py.

If this really is a work-around, I'd like to understand why.

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

Comment By: Steve Pike (oztourer)
Date: 2001-08-09 08:27

Message:
Logged In: YES 
user_id=120658

To further elaborate on the problems with POST on Windows 
95: without having reached any real understanding of the 
problem I have found a tolerable workaround. By modifying 
the default _rbufsize for class _fileobject in socket.py I 
can get any POSTs with text length less than _rbufsize to 
work. Here is the mod:

<pre>
class _fileobject:
    def __init__(self, sock, mode, bufsize):
        self._sock = sock
        self._mode = mode
        if bufsize < 0:
            bufsize = 512
        # SP 9 Aug 2001: default _rbufsize is too small, 
crashing CGIHTTPServer on POST's
        # This fix still only allows pages of less than 
given buffer size to be updated,
        # so the real fix has still to be discovered.
        #self._rbufsize = max(1, bufsize)
        self._rbufsize = max(16*1024, bufsize)
        self._wbufsize = bufsize
        self._wbuf = self._rbuf = ""
</pre>

-- StevePike

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-07 15:59

Message:
Logged In: YES 
user_id=6380

I agree that this is a laudable goal, but I don't have the
time to spend to work on this.  Please upload a patch to the
SF patch manager and assign it to me and I'll look at it.

In the mean time, I've applied the two small suggestions and
will close this bug report.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-05-29 12:29

Message:
Logged In: NO 

I want to elaborate on the second-to-last 
paragraph in this report.  CGIHTTPServer 
in 2.1 and 2.0 is apparently broken for 
POST requests (only) to CGI scripts, when
running locally on Windows with an IE client.

The details: there is a problem with 
the combination of a CGIHTTPServer and 
Intenernet Explorer both running locally 
on Windows (with server name "localhost").
In this setup, POST requests to CGI scripts
fail, but GET requests to the exact same 
script work fine.  That is, a form with 
method=GET, or a URL with an appended 
query string, both work ok.

In POST mode, the CGI script gets proper
data in the input stream, and generates 
a correct reply stream (which is in fact 
identical to the output generated for 
quivalent GET requests).  So, somewhere 
between CGIHTTPServer and IE, the data 
seems to be dropped or munged.  The same
thing happens of you force CGIHTTPServer 
to use execfile() to launch the script, 
instead of os.popen2.

I've also observed that endline conventions 
seem to be irrelevant to the problem; using 
\n or \r\n makes no difference in both the 
input and reply streams.  I've also been 
told that the problem may not exist in 
Netscape clients.

Since CGIHTTPServer is a very nice way to test
CGI scripts (all you need is a standard Python
install), this seems important.  It would also 
be nice if the directory assumptions in that 
module were more customizable, but that's just
a wish.

--Mark Lutz


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

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


From noreply@sourceforge.net  Mon Aug  5 16:01:51 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 05 Aug 2002 08:01:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-576084 ] Sig11 in cPickle (stack overflow)
Message-ID: <E17bjMl-00011M-00@usw-sf-web5.sourceforge.net>

Bugs item #576084, was opened at 2002-07-01 14:34
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=576084&group_id=5470

Category: Python Library
Group: None
Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Jeff Epler (jepler)
Assigned to: Martin v. Löwis (loewis)
Summary: Sig11 in cPickle (stack overflow)

Initial Comment:
The following program dies for me with a sig11.  It
appears that cPickle overflows the stack of the thread
where it executes.  (In my platform, the main thread's
stack is very large, but other threads' stacks are
fairly small)

Should some kind of guard be added in cPickle to stop
the overflow?
This does safely die with a "RuntimeError: maximum
recursion depth exceeded" when using regular pickle.

(I wrote this simple program after a python-dev poster
wrote that a "deeply recursive data structure" was
sometimes causing a sig11 inside cPickle.  I do not
know if this is the same problem as his or not)

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-05 11:01

Message:
Logged In: YES 
user_id=6380

Hm, since it *does* fix a real bug, I think that that's an
acceptable risk. We just need to mention the risk in the
NEWS file. Mind backporting this after all?

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-04 04:22

Message:
Logged In: YES 
user_id=21627

Applied as cPickle.c 2.93.

I have not backported it to 2.2, since it carries the risk
that you get a RuntimeError in pickling, even though
pickling would currently comlete just fine.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-02 16:30

Message:
Logged In: YES 
user_id=6380

Looks good. It fixes the test case. Only comment: would the
call to Py_GetRecursionLimit() cause a measurable slowdown?
(Hard to believe given the amount of work that's done
already.) Suggestion: check it in.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-07-30 11:21

Message:
Logged In: YES 
user_id=21627

Can you please try the attached patch?


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

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


From noreply@sourceforge.net  Mon Aug  5 15:57:29 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 05 Aug 2002 07:57:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-430160 ] CGIHTTPServer.py POST bug using IE
Message-ID: <E17bjIX-0000wH-00@usw-sf-web5.sourceforge.net>

Bugs item #430160, was opened at 2001-06-04 20:09
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=430160&group_id=5470

Category: Windows
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Kevin Altis (kasplat)
>Assigned to: Steve Holden (holdenweb)
Summary: CGIHTTPServer.py POST bug using IE

Initial Comment:
>From the readme included in the zip:
This set of files shows a bug that occurs when doing 
POST requests via the CGIHTTPServer.py module in 
Python 2.1 The testpost.html file when accessed via 
Internet Explorer 5.5 from webserver.py should show 
this bug. On short POST requests IE will end up doing 
a second POST and then displaying an error message 
while longer POSTs will be followed by a second POST 
and then a GET.

The problem appears to be specific to the interaction 
of IE and the handling of windows sockets in Python in 
the CGIHTTPServer.py module which relies on 
BaseHTTPServer.py, SocketServer.py...

posttestwebserver.py is currently setup to use 
C:\tmp\testpost as the document root, so either move 
the "testpost" folder to C:\tmp or change the 
directory to wherever the testpost folder is located. 
Start the server using the .bat file and bring 
up .html page with something like:
  http://localhost/testpost.html

The bug should occur when you try:
  Test short CGI response with POST
or
  Test long CGI response with POST

The other requests should work fine. The bug will 
occur regardless of whether IE is set to use HTTP/1.0 
or HTTP/1.1. The bug doesn't appear to occur when 
going through a simple proxy. You can also get the bug 
to occur using a remote IE client (either on a LAN or 
over the Net). In addition, it doesn't appear to 
matter whether running with unbuffered binary pipes 
(python -u) or not. I also tested against my modified 
CGIHTTPServer.py See the bug I posted at:
http://sourceforge.net/tracker/?
func=detail&atid=105470&aid=427345&group_id=5470

My configuration:
Windows 2000 Pro, SP2
AMD 1.2GHz
256MB RAM
ActiveStatet Python 2.1 (build 210)
Internet Explorer 5.5 (5.50.4522.1800)

ka
---
Mark Lutz said:
"FWIW, I noticed today (in between lecturing a class) 
that on Windows, Python actually uses a special Python-
coded socket.py library module, not the standard C-
coded socket extension module.  socket.py lives in the 
library directory; it does unique things for closes 
and deletes that may not make sense in all cases 
(e.g., the makefile call generates a class instance, 
not a true file object).  It may also be trying to 
close the underlying socket twice.  I don't have"


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-05 10:57

Message:
Logged In: YES 
user_id=6380

Steve, I'm assigning this bug to you. Feel free to check in
a fix if you think one exists (as long as it doesn't break
on Unix).

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

Comment By: Matthew King (kyrrigle)
Date: 2002-03-28 15:49

Message:
Logged In: YES 
user_id=247536

it appears that IE is sending 2 extra bytes ('\r\n') after 
the request data.  and if you don't read those two extra 
bytes off, the window's socket handling gets messed up.

the result is that a partial response is returned and the 
socket closed.  IE tries to recover by re-POST'ing (which 
is behavior specified in the HTTP/1.1 RFC)... only they 
seem to add an embedded NULL the second time through, and 
the original socket problem happens again anyway.

Try reading an extra 2 bytes from the rfile before sending 
your response and the problem should go away.

not sure what the real fix for this should be?


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

Comment By: Steve Holden (holdenweb)
Date: 2001-07-17 07:28

Message:
Logged In: YES 
user_id=88157

Please note that I have observed this behavior on Windows
98 using Python 2.0 (#8, Mar  7 2001, 16:04:37) [MSC 32 bit 
(Intel)] using the same build of IE, so it is not a Win2k-
specific problem.

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

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


From noreply@sourceforge.net  Mon Aug  5 15:57:58 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 05 Aug 2002 07:57:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-575715 ] Parts of 2.2.1 core use old gc API
Message-ID: <E17bjJ0-0003GL-00@usw-sf-web4.sourceforge.net>

Bugs item #575715, was opened at 2002-06-30 18:18
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575715&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: Parts of 2.2.1 core use old gc API

Initial Comment:
At least generators, iterators, and bound method 
objects in 2.2.1 are using the 2.1 gc API internally 
(PyObject_GC_Init & friends), which collapses to a 
bunch of nops.  That's not intentional, right?  I'm 
tempted to call it a critical bug, except nobody has 
noticed <wink>.

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

>Comment By: Neil Schemenauer (nascheme)
Date: 2002-08-05 14:57

Message:
Logged In: YES 
user_id=35752

I've removed the noops.  Should I re-enable GC for these
types? Assigning
to Guido for pronouncement or delegation.

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

Comment By: Neil Schemenauer (nascheme)
Date: 2002-07-01 16:21

Message:
Logged In: YES 
user_id=35752

It wasn't intentional but it's been known for a while.  No
one complained
and so we didn't fix it in a bugfix release.  I think it
would be considered a
new feature.  Maybe we should leave it up to the 2.2 release
manager to
decide.

This is a good example of why it would be useful to have an
option to
disable compatibilty code.

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

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


From noreply@sourceforge.net  Mon Aug  5 16:19:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 05 Aug 2002 08:19:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-576084 ] Sig11 in cPickle (stack overflow)
Message-ID: <E17bjdn-0005dP-00@usw-sf-web3.sourceforge.net>

Bugs item #576084, was opened at 2002-07-01 20:34
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=576084&group_id=5470

Category: Python Library
Group: None
>Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Jeff Epler (jepler)
Assigned to: Martin v. Löwis (loewis)
Summary: Sig11 in cPickle (stack overflow)

Initial Comment:
The following program dies for me with a sig11.  It
appears that cPickle overflows the stack of the thread
where it executes.  (In my platform, the main thread's
stack is very large, but other threads' stacks are
fairly small)

Should some kind of guard be added in cPickle to stop
the overflow?
This does safely die with a "RuntimeError: maximum
recursion depth exceeded" when using regular pickle.

(I wrote this simple program after a python-dev poster
wrote that a "deeply recursive data structure" was
sometimes causing a sig11 inside cPickle.  I do not
know if this is the same problem as his or not)

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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-08-05 17:19

Message:
Logged In: YES 
user_id=21627

Not right now. I'd wait a while to see whether anybody
notices this change in CVS Python; if nobody does,
backporting it should be fine.

The backport is probably not straight-forward, because of
white-space changes.

Reopening.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-05 17:01

Message:
Logged In: YES 
user_id=6380

Hm, since it *does* fix a real bug, I think that that's an
acceptable risk. We just need to mention the risk in the
NEWS file. Mind backporting this after all?

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-04 10:22

Message:
Logged In: YES 
user_id=21627

Applied as cPickle.c 2.93.

I have not backported it to 2.2, since it carries the risk
that you get a RuntimeError in pickling, even though
pickling would currently comlete just fine.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-02 22:30

Message:
Logged In: YES 
user_id=6380

Looks good. It fixes the test case. Only comment: would the
call to Py_GetRecursionLimit() cause a measurable slowdown?
(Hard to believe given the amount of work that's done
already.) Suggestion: check it in.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-07-30 17:21

Message:
Logged In: YES 
user_id=21627

Can you please try the attached patch?


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

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


From noreply@sourceforge.net  Mon Aug  5 16:25:25 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 05 Aug 2002 08:25:25 -0700
Subject: [Python-bugs-list] [ python-Bugs-219960 ] Problems with Tcl/Tk and non-ASCII text entry
Message-ID: <E17bjjZ-0005ii-00@usw-sf-web3.sourceforge.net>

Bugs item #219960, was opened at 2000-10-31 22:38
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=219960&group_id=5470

Category: Unicode
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 3
Submitted By: Kirill Simonov (kirill_simonov)
Assigned to: Martin v. Löwis (loewis)
Summary: Problems with Tcl/Tk and non-ASCII text entry

Initial Comment:
Win98, Python2.0final.

1. I can't write cyrillic letters in IDLE editor.

I tried to figure, what's happened and found that
Tcl has command 'encoding'. I typed in IDLE shell:

>>> from Tkinter import *
>>> root = Tk()
>>> root.tk.call("encoding", "names")
'utf-8 identity unicode'
>>> root.tk.call("encoding", "system")
'identity'

But Tcl had numerous encodings in 'tcl\tcl8.3\encodings'
including 'cp1251'!

Then I installed Tk separately and removed tcl83.dll
and tk83.dll from DLLs:

>>> from Tkinter import *
>>> root = Tk()
>>> root.tk.call("encoding", "names")
'cp860 cp861 [.........] cp857 unicode'
>>> root.tk.call("encoding", "system")
'cp1251'

So, when tcl/tk dlls in Python\DLLs directory,
TCL can't load all it's encodings.

But this is not the end.

I typed in IDLE shell:

>>> print "hello <in russian>" # all chars looks correctly.
and got:
Exception in Tkinter callback
Traceback (most recent call last):
  File "c:\python20\lib\lib-tk\Tkinter.py", line 1287, in __call__
    return apply(self.func, args)
  File "C:\PYTHON20\Tools\idle\PyShell.py", line 579, in enter_callback
    self.runit()
  File "C:\PYTHON20\Tools\idle\PyShell.py", line 598, in runit
    more = self.interp.runsource(line)
  File "C:\PYTHON20\Tools\idle\PyShell.py", line 183, in runsource
    return InteractiveInterpreter.runsource(self, source, filename)
  File "c:\python20\lib\code.py", line 61, in runsource
    code = compile_command(source, filename, symbol)
  File "c:\python20\lib\codeop.py", line 61, in compile_command
    code = compile(source, filename, symbol)
UnicodeError: ASCII encoding error: ordinal not in range(128)
print "[the same characters]"
Then, when I pressed Enter again, i got the same
error message. I stopped this by pressing C-Break.

[1/2 hour later]
I fix this by editing site.py:
if 1: # was: if 0
  # Enable to support locale aware default string encodings.

I typed again:
>>> print "hello <in russian>"
and got:
<some strange letters>
>>> print unicode("hello <in russian>")
<some strange letters>

[2 hours later]
Looking sources of _tkinter.c:

static Tcl_Obj* AsObj(PyObject *value)
{
    if type(value) is StringType:
        return Tcl_NewStringObj(value)
    elif type(value) is UnicodeType:
        ...
...
}

But I read in
<http://dev.scriptics.com/doc/howto/i18n.html>
that all Tcl functions require all strings to
be passed in UTF-8. So, this code must look like:

    if type(value) is StringType:
        if TCL_Version >= 8.1:
             return Tcl_NewStringObj(<value converted
           to UTF-8 string using sys.getdefaultencoding()>)
        else:
             return Tcl_NewStringObj(value)

And when I typed:
>>> print unicode("hello <in russian>").encode('utf-8')
i got:
hello <in russian>

This is the end.

P.S. Sorry for my bad english, but I really want to
use IDLE and Tkinter in our school, so I can't wait
for somebody other writing bug report.

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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-08-05 17:25

Message:
Logged In: YES 
user_id=21627

The IDLE problems have been fixed in CVS: IDLE now
implements PEP 263, and uses the locale's encoding for
interactive input.

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-02-24 18:31

Message:
Logged In: YES 
user_id=38388

Assigned to Martin for further processing -- I know
to little about Tkinter to be of any help here.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-02-24 18:07

Message:
Logged In: YES 
user_id=21627

Item 1. of MAL's list becomes 'Tcl does not find its
encoding directory' in Python 2.2; this is fixed with
FixTk.py 1.6.

Item 2. has been fixed for Python 2.2; the remaining problem
was that the OutputWindow converted all unicode objects to
strings first, this has been fixed with OutputWindow.py 1.6.

I'm not sure which problem is supposed to be solved with
item 3. in MAL's list, I believe that this change is not
necessary, and may be incorrect in some cases.

Item 1. of the original submitter's problems is solved with
the changes to FixTk.py.

As for entering non-ASCII characters in the IDLE shell, I'm
not sure what to do with this. For entering non-ASCII
characters in a IDLE source window, see patch

http://sourceforge.net/tracker/index.php?func=detail&aid=508973&group_id=9579&atid=309579
and PEP 263.

I'm inclined to recommend that IDLE should encode Unicode
strings entered by the user as UTF-8 before passing them to
the interpreter; most likely, any byte strings will be
printed to a Tk window, in which case UTF-8 should work right.




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

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-01-03 22:37

Message:
I've changed the subject line to better reflect the cause of the error:

1. The Tcl version shipped with Python 2.0 apparently 
doesn't include the Tcl codec libs, but these seem to be needed by
Tcl to allow entry of characters in non-ASCII environments.

2. Python's print statement should allow Unicode to be passed through
to sys.stdout.

3. _tkinter should recode all 8-bit strings into Unicode under the assumption
that the 8-bit strings use sys.getdefaultencoding() as encoding.

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

Comment By: Kirill Simonov (kirill_simonov)
Date: 2000-11-12 13:17

Message:
No, you are wrong! Entry and Text widget depends on TCL system encoding. If TCL can't find cyrillic encoding (cp1251) then I can't enter cyrillic characters.


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

Comment By: Martin v. Löwis (loewis)
Date: 2000-11-12 12:30

Message:
It should be no problem that Tcl can't find its encodings. When used with Tkinter, Tcl can only expect Unicode strings, or strings in sys.getdefaultencoding() (i.e. 'ascii'). Therefore, Tk never needs any other encoding.

If you want to make use of the Tcl system encoding (which is apparently not supported in Tkinter), you probably need to set the TCL_LIBRARY environment variable.

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

Comment By: Kirill Simonov (kirill_simonov)
Date: 2000-11-10 19:53

Message:
Yes, this is a solution. But don't forget that
TCL can't load it's encodings at startup.

Look at FixTk.py:

import sys, os, _tkinter
[...]
os.environ["TCL_LIBRARY"] = v

But 'import _tkinter' loads _tkinter.pyd; _tkinter.pyd
loads tcl83.dll; tcl83.dll tryes to load it's encodings
at startup and fails, becourse TCL_LIBRARY is not defined!

I can fix this:
#import sys, os, _tkinter
import sys, os
#ver = str(_tkinter.TCL_VERSION)
ver = "8.3"
[...]


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

Comment By: M.-A. Lemburg (lemburg)
Date: 2000-11-09 11:00

Message:
Ok, as we've found out in discussions on python-dev, the cause for the
problem is (partially) the fact that "print obj" does an implicit str(obj), so any
Unicode object printed will turn out as default encoded string no matter
how hard we try.

To fix this, we'll need to tweak the current "print" mechanism a bit to allow
Unicode to pass through to the receveiving end (sys.stdout in this case).

About the problem that Tcl/tk needs UTF-8 strings: we could have _tkinter.c
recode the strings for you in case sys.getdefaultencoding() returns anything
other than 'ascii' or 'utf-8'. That way you can use a different default encoding
in Python while Tcl/tk will always get a true UTF-8 string.

Would this be a solution ?


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

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

Message:
Assigned to Marc-Andre, since I have no idea what to do about this... :-(

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

Comment By: Kirill Simonov (kirill_simonov)
Date: 2000-11-01 22:16

Message:
1. print unicode("<cyrillic>") in IDLE don't work!
The mechanics (I think) is
a) print unicode_string encodes unicode string to
normal string using default encoding and pass it
to sys.stdout.
b) sys.stdout intercepted by IDLE. IDLE sent this string
to Tkinter.
c) Tkinter pass this string (not unicode but cp1251!)
to TCL but TCL waits for UTF-8 string!!!
d) I see messy characters on screen.
2. You breaks compability! In 1.5 I can write
Button(root, text="<cyrillic>") and this works.
Writing unicode("<>", 'cp1251') is UGLY and ANNOYING!
TCL requires string in utf-8. All pythonian strings
is sys.getdefaultencoding() encoding. So, we have to
recode all strings to utf-8.
3. TCL in DLLs can't found it's encodings in
tcl\tk8.3\encodings! I don't no why. So, I can't write
in Tkinter.Text in russian.

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2000-11-01 21:47

Message:
AFAIK, the _tkinter.c code automatically converts Unicode
to UTF-8 and then passes this to Tcl/Tk.

So basically the folloing should get you correct results...

print unicode("hello <in russian>", "cp1251")

Alternatively, you can set your default encoding to "cp1251"
in the way your describe and then write:

print unicode("hello <in russian>")

I am not too familiar with Tcl/Tk, so I can't judge whether trying
to recode normal 8-bit into UTF-8 is a good idea in general
for the _tkinter.c interface. It would easily be possible using:

utf8 = string.encode('utf-8')

since 8-bit support the .encode() method too.

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

Comment By: Jeremy Hylton (jhylton)
Date: 2000-11-01 17:00

Message:
I am not entirely sure what the bug is, though I agree that it can be confusing to deal with Unicode strings.


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

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


From noreply@sourceforge.net  Mon Aug  5 16:25:55 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 05 Aug 2002 08:25:55 -0700
Subject: [Python-bugs-list] [ python-Bugs-589427 ] standard include paths on command line
Message-ID: <E17bjk3-0001dK-00@usw-sf-web5.sourceforge.net>

Bugs item #589427, was opened at 2002-07-31 19:13
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=589427&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: Remind
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Skip Montanaro (montanaro)
Summary: standard include paths on command line

Initial Comment:
when compiling shared modules (using gcc-3.1.1), 
standard include paths are included (by setup.py?) in 
the include path, which can change the search order. 
gcc-3.1 warns about:

building 'xreadlines' extension
gcc-3.1 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -
fPIC -I. -I/home/packages/pyt
hon2.3/python2.3-2.2.90/./Include -I/usr/include -
I/usr/local/include -I/home/pa
ckages/python2.3/python2.3-2.2.90/Include -
I/home/packages/python2.3/python2.3-2
.2.90/build-static -
c /home/packages/python2.3/python2.3-
2.2.90/Modules/xreadlin
esmodule.c -o build/temp.linux-i686-
2.3/xreadlinesmodule.o
gcc -shared build/temp.linux-i686-
2.3/xreadlinesmodule.o -L/usr/lib -L/usr/local
/lib -o build/lib.linux-i686-2.3/xreadlines.so
building 'array' extension
gcc-3.1 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -
fPIC -I. -I/hocc1: warning: c
hanging search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory

In this case, /usr/include and /usr/local/include should 
not be included on the command line.


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

>Comment By: Skip Montanaro (montanaro)
Date: 2002-08-05 10:25

Message:
Logged In: YES 
user_id=44345

Sorry guys, I'm coming in on this late.  

I'm done with the bsddb trickery.  In any case /usr/include is not added 
as a -I argument under any circumstances in the bsddb build section of 
setup.py.  Various Linux vendors allow you to install multiple versions of 
Berkeley DB simultaneously.  The only way you can guarantee that a 
particular version is compiled against and linked with is to add the 
appropriate -I and -L flags to the command line.  On RedHat-derived 
systems the include files are in /usr/include/db{1,2,3,4} if installed as part 
of a system install, while if you install from Sleepycat source I believe it's 
/usr/local/BerkeleyDB<version>/include.   I can't really get rid of the 
RH-related include directories. 

Wait a minute.  I take some of that back.  *If* you are foolish enough to 
uncomment the section of code which enables compilation and linkage 
with Berkeley DB 1.85, you might wind up with -I/usr/include on the 
command line to build the bsddb module.  I will correct that (make it so 
/usr/include isn't added to the -I flag) and also reorder the directory 
search so system include directories are scanned after non-system 
directories.

How's this going to help the OP?  I thought the problem he saw was 
more pervasive (xreadlines, _ssl, etc).



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

Comment By: Michael Hudson (mwh)
Date: 2002-08-05 09:51

Message:
Logged In: YES 
user_id=6656

Skip, are you still working on the bsddb related bits of
setup.py?  Can you look into how /usr/include is getting
onto the commandline?


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-04 07:47

Message:
Logged In: YES 
user_id=21627

I can't reproduce this. With the current CVS, on Debian,
with --prefix=/usr, I get

gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC
-DWITH_APPINIT=1 -I/usr/include/tcl8.3 -I/usr/X11R6/include
-I. -I/vol/marvin-vol8/loewis/python/dist/src/./Include
-I/usr/local/include
-I/vol/marvin-vol8/loewis/python/dist/src/Include
-I/vol/marvin-vol8/loewis/python/dist/src -c
/vol/marvin-vol8/loewis/python/dist/src/Modules/_tkinter.c
-o build/temp.linux-i686-2.3/_tkinter.o

So it won't add -I/usr/include to the command line options.

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

Comment By: Matthias Klose (doko)
Date: 2002-08-03 11:30

Message:
Logged In: YES 
user_id=60903

No. It's:

 - bsddb
 - dbm
 - _tkinter

all modules, which are installed in /usr at least on Debian
GNU/Linux (but maybe on other distros as well).

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

Comment By: Michael Hudson (mwh)
Date: 2002-08-03 11:19

Message:
Logged In: YES 
user_id=6656

It's only the _ssl module, right?  I've fixed that.

The -R/usr/lib and -L/usr/lib's come from various database
modules, the configuration of which is under review anyway.
 I hope those doing the reviewing have seen this bug traffic...

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

Comment By: Matthias Klose (doko)
Date: 2002-08-03 10:56

Message:
Logged In: YES 
user_id=60903

build log attached. please tell me if you need an account on
a Debian machine (doko   debian org).
configure \
        --with-gcc=gcc-3.1 \
        --with-cxx=g++-3.1 \
        --prefix=/usr \
        --with-fpectl \
        --enable-ipv6


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

Comment By: Michael Hudson (mwh)
Date: 2002-08-03 10:12

Message:
Logged In: YES 
user_id=6656

Really?  Nuts.  They're not on my machine.

What arguments are you passing to configure?

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

Comment By: Matthias Klose (doko)
Date: 2002-08-02 16:48

Message:
Logged In: YES 
user_id=60903

Thanks for the fix, however when building shared modules,
-I/usr/include and -L/usr/lib are still passed to the compiler.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-02 09:05

Message:
Logged In: YES 
user_id=21627

And indeed, we should not remove /usr/local/include, since
the system compiler may not be gcc.

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

Comment By: Michael Hudson (mwh)
Date: 2002-08-02 08:56

Message:
Logged In: YES 
user_id=6656

OK, done, in

setup.py revision 1.100

I don't see us removing /usr/local/include from the command
line.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-02 08:49

Message:
Logged In: YES 
user_id=21627

The patch looks fine to me, please apply it.

I still think that the bogus warning should be removed from
gcc entirely.

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

Comment By: Michael Hudson (mwh)
Date: 2002-08-02 07:54

Message:
Logged In: YES 
user_id=6656

OK, can you try the attached patch?

Martin, does this look OK to you?

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

Comment By: Michael Hudson (mwh)
Date: 2002-08-02 03:53

Message:
Logged In: YES 
user_id=6656

Ah, sorry!

Hmm.  Now I don't see the problem, i.e. for me
-I/usr/include is not part of the command line passed to the
compiler.

Are you building from up-to-date CVS?  Though I don't recall
any recent changes in this area.  Ahh, you're running
".../configure --prefix=/usr", right?

I'll dig.

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

Comment By: Matthias Klose (doko)
Date: 2002-08-01 15:23

Message:
Logged In: YES 
user_id=60903

I disagree. The discussion is on /usr/local/include. We are 
talking about /usr/include, which is a system include dir on 
almost all systems.

See the thread "gcc 3.2's cpp breaks configure scripts" at 
http://gcc.gnu.org/ml/gcc/2002-07/, i.e.:

http://gcc.gnu.org/ml/gcc/2002-07/msg01527.html

Inclusion of /usr/include can lead to errors, as explained in:
http://gcc.gnu.org/ml/gcc/2002-07/msg01541.html

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

Comment By: Michael Hudson (mwh)
Date: 2002-08-01 04:08

Message:
Logged In: YES 
user_id=6656

This has been deemed a bug in gcc, see this thread:

http://mail.python.org/pipermail/python-dev/2002-June/025990.html

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

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


From noreply@sourceforge.net  Mon Aug  5 16:31:58 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 05 Aug 2002 08:31:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-591135 ] Mixin broken for new-style classes
Message-ID: <E17bjpu-0002nk-00@usw-sf-web2.sourceforge.net>

Bugs item #591135, was opened at 2002-08-05 15:31
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=591135&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Joost Jacob (jjacob)
Assigned to: Nobody/Anonymous (nobody)
Summary: Mixin broken for new-style classes

Initial Comment:

In article:
http://www.linuxjournal.com/article.php?sid=4540
Chuck Esterbrook mentions an elegant technique
called 'Mixin'.

Assigning to __bases__ is useful if you want to add
ancestors without changing the object's source code.

It does not work with new-style classes because the
 .__bases__ attribute is now read-only.
This is also mentioned on
http://www.python.org/2.2.1/bugs.html
at the bottom but I could not find a bug-report here at
SF.


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

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


From noreply@sourceforge.net  Mon Aug  5 16:33:45 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 05 Aug 2002 08:33:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-500704 ] Tutorial does not describe nested scope
Message-ID: <E17bjrd-0002qD-00@usw-sf-web2.sourceforge.net>

Bugs item #500704, was opened at 2002-01-07 22:27
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=500704&group_id=5470

Category: Documentation
Group: Python 2.2
Status: Open
Resolution: None
Priority: 7
Submitted By: Pierre Rouleau (pierre_rouleau)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Tutorial does not describe nested scope

Initial Comment:
The current copy of the tuturial for Python 2.2 states, in chapter 9.2
(Python Scopes and Name Spaces):

"""Although scopes are determined statically, they are used dynamically.
At any time during execution, exactly three nested scopes are in use
(exactly three namespaces are directly accessible): the innermost scope,
which is searched first, contains the local names, the middle scope,
searched next, contains the current module's global names, and the
outermost scope (searched last) is the namespace containing built-in
names."""

I believe the above text should be updated to reflect the fact that Python 2.2 supports nested 
scopes.

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-08-05 10:33

Message:
Logged In: YES 
user_id=80475

Patch attached for Fred's approval. If okay, re-assign to 
me and I'll make the same change to the trunk.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-03-13 01:03

Message:
Logged In: YES 
user_id=3066

Bumped priority since this can cause real confusion for
someone learning Python.  The corrections need to be part of
Python 2.2.1 and the trunk.

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

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


From noreply@sourceforge.net  Mon Aug  5 16:47:44 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 05 Aug 2002 08:47:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-575715 ] Parts of 2.2.1 core use old gc API
Message-ID: <E17bk5A-0004Y6-00@usw-sf-web4.sourceforge.net>

Bugs item #575715, was opened at 2002-06-30 14:18
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575715&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Tim Peters (tim_one)
>Assigned to: Neil Schemenauer (nascheme)
Summary: Parts of 2.2.1 core use old gc API

Initial Comment:
At least generators, iterators, and bound method 
objects in 2.2.1 are using the 2.1 gc API internally 
(PyObject_GC_Init & friends), which collapses to a 
bunch of nops.  That's not intentional, right?  I'm 
tempted to call it a critical bug, except nobody has 
noticed <wink>.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-05 11:47

Message:
Logged In: YES 
user_id=6380

I don't think we need to enable GC for those types in 2.2
unless we find specific cases where it's needed in an app.

(Tim said bound method objects, sending me off on a wild
goose chase for a bit, until I realized he meant "whatever's
in methodobject.c". This is a misnomer -- it contains the
code for C functions. Bound methods are in classobject.c,
under the name "instance method" (in 2.3, "instancemethod").
Also a misnomer. :-( )

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

Comment By: Neil Schemenauer (nascheme)
Date: 2002-08-05 10:57

Message:
Logged In: YES 
user_id=35752

I've removed the noops.  Should I re-enable GC for these
types? Assigning
to Guido for pronouncement or delegation.

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

Comment By: Neil Schemenauer (nascheme)
Date: 2002-07-01 12:21

Message:
Logged In: YES 
user_id=35752

It wasn't intentional but it's been known for a while.  No
one complained
and so we didn't fix it in a bugfix release.  I think it
would be considered a
new feature.  Maybe we should leave it up to the 2.2 release
manager to
decide.

This is a good example of why it would be useful to have an
option to
disable compatibilty code.

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

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


From noreply@sourceforge.net  Mon Aug  5 17:35:41 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 05 Aug 2002 09:35:41 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-223599 ] Need user-centered info for Windows users.
Message-ID: <E17bkpZ-00037c-00@usw-sf-web1.sourceforge.net>

Feature Requests item #223599, was opened at 2000-11-27 11:31
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=223599&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 6
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Nobody/Anonymous (nobody)
Summary: Need user-centered info for Windows users.

Initial Comment:
Users ask questions like "How do I write batch files using Python?"; there should be a document that acts as a user's guide specifically for Windows users.  This could be similar to what the Macintosh Modules Reference is becoming.  This should be part of the standard documentation and could acquire the Windows module documentation.

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

Comment By: Kevin Cathcart (dev314159)
Date: 2002-08-05 12:35

Message:
Logged In: YES 
user_id=589477

> This one comes up most with first time programmers and
>users from environments that don't expose source code as
>editable text files (VB?).
actually VB can make most files into editable source files. 
(this option is found in the save dailog in most versions) 
but that is besides the point)

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-04 05:48

Message:
Logged In: YES 
user_id=21627

Moved into feature requests tracker.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-06-17 23:28

Message:
Logged In: NO 

is it a really bad effect after i batch the file

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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-03-07 11:46

Message:
Logged In: NO 

hello! i am wantin! plz

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

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-01 17:37

Message:
Logged In: YES 
user_id=31392

Can we move this out of bugs and into feature requests?


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

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

Message:
Another question that should be answered in this document:  "How do I create/recall modules?"  This one comes up most with first time programmers and users from environments that don't expose source code as editable text files (VB?).

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

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


From noreply@sourceforge.net  Mon Aug  5 18:31:52 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 05 Aug 2002 10:31:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-591205 ] errno not available at setup.py time
Message-ID: <E17blhw-0006k9-00@usw-sf-web4.sourceforge.net>

Bugs item #591205, was opened at 2002-08-05 13:31
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=591205&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 8
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Guido van Rossum (gvanrossum)
Summary: errno not available at setup.py time

Initial Comment:
This bug was introduced in Lib/os.py 1.59.

Distutils uses os._execvpe (indirectly) while building
extension modules, but the errno import can fail while
building the standard dynamically loadable modules that
come with Python.  This means that a clean build from
sources is not possible; the errno module must already
be available.

I can fix this by making the errno module built-in
statically, but would like approval before doing so,
since there may be other ways of dealing with this.  I
suspect errno is almost always used, however, so there
shouldn't be any problems with building it statically.

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

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


From noreply@sourceforge.net  Mon Aug  5 18:35:07 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 05 Aug 2002 10:35:07 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-591207 ] list objects should accept slice indices
Message-ID: <E17bll5-0004k8-00@usw-sf-web5.sourceforge.net>

Feature Requests item #591207, was opened at 2002-08-05 19:35
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=591207&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jürgen A. Erhard (jae)
Assigned to: Nobody/Anonymous (nobody)
Summary: list objects should accept slice indices

Initial Comment:
List objects should accept slice objects has index values.  Just what user-written classes do.  Both built-in classes and user-written classes should behave the same way.  (And when my __getitem__ method receives a slice as argument, I'd like to pass it directly to some embedded list object if possible, without further massaging)

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

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


From noreply@sourceforge.net  Mon Aug  5 18:47:41 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 05 Aug 2002 10:47:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-591205 ] errno not available at setup.py time
Message-ID: <E17blxF-0005Er-00@usw-sf-web1.sourceforge.net>

Bugs item #591205, was opened at 2002-08-05 13:31
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=591205&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 8
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Guido van Rossum (gvanrossum)
Summary: errno not available at setup.py time

Initial Comment:
This bug was introduced in Lib/os.py 1.59.

Distutils uses os._execvpe (indirectly) while building
extension modules, but the errno import can fail while
building the standard dynamically loadable modules that
come with Python.  This means that a clean build from
sources is not possible; the errno module must already
be available.

I can fix this by making the errno module built-in
statically, but would like approval before doing so,
since there may be other ways of dealing with this.  I
suspect errno is almost always used, however, so there
shouldn't be any problems with building it statically.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-05 13:47

Message:
Logged In: YES 
user_id=6380

Argh! OK, make errno static. The alternative (hardcoding the
error values if errno can't be imported) seems unattractive.

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

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


From noreply@sourceforge.net  Mon Aug  5 18:47:57 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 05 Aug 2002 10:47:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-591205 ] errno not available at setup.py time
Message-ID: <E17blxV-0005F7-00@usw-sf-web1.sourceforge.net>

Bugs item #591205, was opened at 2002-08-05 13:31
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=591205&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
>Resolution: Accepted
Priority: 8
Submitted By: Fred L. Drake, Jr. (fdrake)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: errno not available at setup.py time

Initial Comment:
This bug was introduced in Lib/os.py 1.59.

Distutils uses os._execvpe (indirectly) while building
extension modules, but the errno import can fail while
building the standard dynamically loadable modules that
come with Python.  This means that a clean build from
sources is not possible; the errno module must already
be available.

I can fix this by making the errno module built-in
statically, but would like approval before doing so,
since there may be other ways of dealing with this.  I
suspect errno is almost always used, however, so there
shouldn't be any problems with building it statically.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-05 13:47

Message:
Logged In: YES 
user_id=6380

Argh! OK, make errno static. The alternative (hardcoding the
error values if errno can't be imported) seems unattractive.

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

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


From noreply@sourceforge.net  Mon Aug  5 19:07:08 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 05 Aug 2002 11:07:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-591205 ] errno not available at setup.py time
Message-ID: <E17bmG4-0007c1-00@usw-sf-web4.sourceforge.net>

Bugs item #591205, was opened at 2002-08-05 13:31
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=591205&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 8
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: errno not available at setup.py time

Initial Comment:
This bug was introduced in Lib/os.py 1.59.

Distutils uses os._execvpe (indirectly) while building
extension modules, but the errno import can fail while
building the standard dynamically loadable modules that
come with Python.  This means that a clean build from
sources is not possible; the errno module must already
be available.

I can fix this by making the errno module built-in
statically, but would like approval before doing so,
since there may be other ways of dealing with this.  I
suspect errno is almost always used, however, so there
shouldn't be any problems with building it statically.

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-08-05 14:07

Message:
Logged In: YES 
user_id=3066

Fixed in setup.py 1.104 and Modules/Setup.dist 1.29.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-05 13:47

Message:
Logged In: YES 
user_id=6380

Argh! OK, make errno static. The alternative (hardcoding the
error values if errno can't be imported) seems unattractive.

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

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


From noreply@sourceforge.net  Mon Aug  5 19:39:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 05 Aug 2002 11:39:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-591205 ] errno not available at setup.py time
Message-ID: <E17bmkx-0008GM-00@usw-sf-web4.sourceforge.net>

Bugs item #591205, was opened at 2002-08-05 13:31
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=591205&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Open
>Resolution: Accepted
Priority: 8
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: errno not available at setup.py time

Initial Comment:
This bug was introduced in Lib/os.py 1.59.

Distutils uses os._execvpe (indirectly) while building
extension modules, but the errno import can fail while
building the standard dynamically loadable modules that
come with Python.  This means that a clean build from
sources is not possible; the errno module must already
be available.

I can fix this by making the errno module built-in
statically, but would like approval before doing so,
since there may be other ways of dealing with this.  I
suspect errno is almost always used, however, so there
shouldn't be any problems with building it statically.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-08-05 14:07

Message:
Logged In: YES 
user_id=3066

Fixed in setup.py 1.104 and Modules/Setup.dist 1.29.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-05 13:47

Message:
Logged In: YES 
user_id=6380

Argh! OK, make errno static. The alternative (hardcoding the
error values if errno can't be imported) seems unattractive.

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

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


From noreply@sourceforge.net  Mon Aug  5 19:39:36 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 05 Aug 2002 11:39:36 -0700
Subject: [Python-bugs-list] [ python-Bugs-591205 ] errno not available at setup.py time
Message-ID: <E17bmlU-0008Gs-00@usw-sf-web4.sourceforge.net>

Bugs item #591205, was opened at 2002-08-05 13:31
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=591205&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
Resolution: Accepted
Priority: 8
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: errno not available at setup.py time

Initial Comment:
This bug was introduced in Lib/os.py 1.59.

Distutils uses os._execvpe (indirectly) while building
extension modules, but the errno import can fail while
building the standard dynamically loadable modules that
come with Python.  This means that a clean build from
sources is not possible; the errno module must already
be available.

I can fix this by making the errno module built-in
statically, but would like approval before doing so,
since there may be other ways of dealing with this.  I
suspect errno is almost always used, however, so there
shouldn't be any problems with building it statically.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-08-05 14:07

Message:
Logged In: YES 
user_id=3066

Fixed in setup.py 1.104 and Modules/Setup.dist 1.29.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-05 13:47

Message:
Logged In: YES 
user_id=6380

Argh! OK, make errno static. The alternative (hardcoding the
error values if errno can't be imported) seems unattractive.

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

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


From noreply@sourceforge.net  Mon Aug  5 21:25:00 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 05 Aug 2002 13:25:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-591287 ] makesetup fails: long Setup.local lines
Message-ID: <E17boPU-0000a4-00@usw-sf-web2.sourceforge.net>

Bugs item #591287, was opened at 2002-08-05 16:25
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=591287&group_id=5470

Category: Build
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Sam Tannous (stannous)
Assigned to: Nobody/Anonymous (nobody)
Summary: makesetup fails: long Setup.local lines

Initial Comment:
makesetup fails: long Setup.local lines.  I've
included an attachment that describes the problem.

Thanks,
Sam Tannous (employees.org)

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

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


From noreply@sourceforge.net  Mon Aug  5 22:54:43 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 05 Aug 2002 14:54:43 -0700
Subject: [Python-bugs-list] [ python-Bugs-585923 ] macfs.FSSpec fails for "new" files
Message-ID: <E17bpoJ-0001uu-00@usw-sf-web5.sourceforge.net>

Bugs item #585923, was opened at 2002-07-24 15:35
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=585923&group_id=5470

Category: Macintosh
Group: Python 2.3
Status: Open
Resolution: None
Priority: 7
Submitted By: Just van Rossum (jvr)
Assigned to: Jack Jansen (jackjansen)
>Summary: macfs.FSSpec fails for "new" files

Initial Comment:
In the mach-o version of Python on MacOSX, the macfs.FSSpec() 
library function fails for files that don't yet exist.

The problem is caused by (internally) using an FSRef to construct 
the FSSpec: FSRefs can't hold references to non-existent files, 
whereas FSSpecs can.

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

>Comment By: Jack Jansen (jackjansen)
Date: 2002-08-05 23:54

Message:
Logged In: YES 
user_id=45365

macostools.copy() has been fixed in rev. 1.16. mkalias()
still has the problem, though.

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

Comment By: Jack Jansen (jackjansen)
Date: 2002-08-03 23:01

Message:
Logged In: YES 
user_id=45365

As the workaround is going to be both difficult to implement and incomplete I'm tempted to punt on this one. Difficult because we have to split the path in C, and we have to do /: substitutions on the last component; incomplete because we cannot cater for utf8/macroman differences and filenames > 32 characters.

If we punt on this we should make sure we phase out using fsspec's in the standard library in favor of the fsref calls.

Do you think this is an acceptable solution? How much work would it be?

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

Comment By: Just van Rossum (jvr)
Date: 2002-07-29 23:56

Message:
Logged In: YES 
user_id=92689

This bug also cause macostools.copy() to fail, making the breakage 
larger than I thought :-(

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

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


From noreply@sourceforge.net  Mon Aug  5 23:08:33 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 05 Aug 2002 15:08:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-580550 ] MacOSX python.app build problems
Message-ID: <E17bq1h-0002XM-00@usw-sf-web2.sourceforge.net>

Bugs item #580550, was opened at 2002-07-12 14:13
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=580550&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: MacOSX python.app build problems

Initial Comment:
If you build python in a different directory than the source directory then building Python.app doesn't work.

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

>Comment By: Jack Jansen (jackjansen)
Date: 2002-08-06 00:08

Message:
Logged In: YES 
user_id=45365

This has been fixed by letting the main Makefile do the building.

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

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


From noreply@sourceforge.net  Mon Aug  5 23:09:08 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 05 Aug 2002 15:09:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-580550 ] MacOSX python.app build problems
Message-ID: <E17bq2G-0002Y5-00@usw-sf-web2.sourceforge.net>

Bugs item #580550, was opened at 2002-07-12 14:13
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=580550&group_id=5470

Category: Macintosh
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: MacOSX python.app build problems

Initial Comment:
If you build python in a different directory than the source directory then building Python.app doesn't work.

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

Comment By: Jack Jansen (jackjansen)
Date: 2002-08-06 00:08

Message:
Logged In: YES 
user_id=45365

This has been fixed by letting the main Makefile do the building.

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

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


From noreply@sourceforge.net  Mon Aug  5 23:10:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 05 Aug 2002 15:10:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-587011 ] IBCarbon module
Message-ID: <E17bq3q-0002Zj-00@usw-sf-web2.sourceforge.net>

Bugs item #587011, was opened at 2002-07-26 15:41
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=587011&group_id=5470

Category: Macintosh
Group: Feature Request
Status: Open
Resolution: None
>Priority: 3
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: IBCarbon module

Initial Comment:
Donovan Preston donated an IBCarbon module, that allows Interface Builder (in Carbon mode) to be used for creating GUIs for Python scripts. This module should be incorporated in the Carbon package.

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

>Comment By: Jack Jansen (jackjansen)
Date: 2002-08-06 00:10

Message:
Logged In: YES 
user_id=45365

It is included now. I'm keeping this open because I want to coerce someone to provide an example of its use.

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

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


From noreply@sourceforge.net  Tue Aug  6 01:42:30 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 05 Aug 2002 17:42:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-591349 ] httplib sporadically throws a TypeError
Message-ID: <E17bsQg-0005sj-00@usw-sf-web1.sourceforge.net>

Bugs item #591349, was opened at 2002-08-05 19:42
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=591349&group_id=5470

Category: Python Library
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Rob Green (rbgrn)
Assigned to: Nobody/Anonymous (nobody)
Summary: httplib sporadically throws a TypeError

Initial Comment:
This is the output that occurs about 1 in 500 hits to any 
particular URL. I've only seen it so far hitting servers 
running Apache 1.3.20, but I don't have enough data to 
limit it to that.

Python 2.1.2 (#1, Mar 16 2002, 18:24:08)
[GCC 2.95.3 [FreeBSD] 20010315 (release)] on freebsd4

h = httplib.HTTPConnection(host)
response = h.getresponse()
data = response.read()
File "/usr/local/lib/python2.1/httplib.py", line 246, in read
value = value + self._safe_read(chunk_left)
File "/usr/local/lib/python2.1/httplib.py", line 314, in 
_safe_read
chunk = self.fp.read(amt)
TypeError: an integer is required



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

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


From noreply@sourceforge.net  Tue Aug  6 01:45:25 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 05 Aug 2002 17:45:25 -0700
Subject: [Python-bugs-list] [ python-Bugs-591349 ] httplib sporadically throws a TypeError
Message-ID: <E17bsTV-00052Q-00@usw-sf-web2.sourceforge.net>

Bugs item #591349, was opened at 2002-08-05 19:42
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=591349&group_id=5470

Category: Python Library
Group: Python 2.1.2
Status: Open
Resolution: None
>Priority: 7
Submitted By: Rob Green (rbgrn)
Assigned to: Nobody/Anonymous (nobody)
Summary: httplib sporadically throws a TypeError

Initial Comment:
This is the output that occurs about 1 in 500 hits to any 
particular URL. I've only seen it so far hitting servers 
running Apache 1.3.20, but I don't have enough data to 
limit it to that.

Python 2.1.2 (#1, Mar 16 2002, 18:24:08)
[GCC 2.95.3 [FreeBSD] 20010315 (release)] on freebsd4

h = httplib.HTTPConnection(host)
response = h.getresponse()
data = response.read()
File "/usr/local/lib/python2.1/httplib.py", line 246, in read
value = value + self._safe_read(chunk_left)
File "/usr/local/lib/python2.1/httplib.py", line 314, in 
_safe_read
chunk = self.fp.read(amt)
TypeError: an integer is required



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

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


From noreply@sourceforge.net  Tue Aug  6 04:19:59 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 05 Aug 2002 20:19:59 -0700
Subject: [Python-bugs-list] [ python-Bugs-591104 ] os.tmpfile() can fail on win32
Message-ID: <E17but5-0008WB-00@usw-sf-web1.sourceforge.net>

Bugs item #591104, was opened at 2002-08-05 10:23
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=591104&group_id=5470

Category: Windows
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Joseph Barillari (jdbarillari)
>Assigned to: Mark Hammond (mhammond)
Summary: os.tmpfile() can fail on win32

Initial Comment:
I've discovered what appears to be a bug in Python 2.2.1 
on Win32. I'm
using the 2.2.1 build that I downloaded from python.org. 
I'm running
Windows 2000.

If os.tmpfile() is exceuted when the CWD is a UNC path, 
the base of
which is not writeable by the current user, tmpfile will
fail. tempfile.TemporaryFile will work, so I suspect this is 
a bug in os.tmpfile().

For example:

C:\>pwd  
/cygdrive/c   #I use cygwin

C:\>bash    # I have to use bash; the DOS shell doesn't 
support UNC paths
bash: .bashrc: No such file or directory
bash-2.05a$ cd //bopp/jbarilla
bash-2.05a$ pwd
//bopp/jbarilla
bash-2.05a$ python
Python 2.2.1 (#34, Apr  9 2002, 19:34:33) [MSC 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import os; os.tmpfile()
<open file '<tmpfile>', mode 'w+' at 0x007762C0> # It 
works.
>>> ^Z

If I chmod 555 //bopp/jbarilla (from unix via NFS; 
incidentally,
"chmod 555 ." from cygwin is ineffectual), then tmpfile 
fails:

bash-2.05a$ pwd
//bopp/jbarilla
bash-2.05a$ python
Python 2.2.1 (#34, Apr  9 2002, 19:34:33) [MSC 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import os; os.tmpfile()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OSError: [Errno 13] Permission denied # Oops.

# However, tempfile.TemporaryFile works:

>>> import tempfile; tempfile.TemporaryFile()
<open file 'c:\DOCUME~1\jbarilla\LOCALS~1
\Temp\~1880-0', mode 'w+b' at 0x00779B00>

--Joe

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

>Comment By: Tim Peters (tim_one)
Date: 2002-08-05 23:19

Message:
Logged In: YES 
user_id=31435

Assigned to Mark in case he has another idea, but I think 
you're out of luck.  os.tmpfile() does nothing except call 
Microsoft's tmpfile() function, and that doesn't allow 
specifying a directory.  If you don't have permission to 
create a file in the current directory, you lose, and Python's 
behavior here will change when Microsoft's does.

tempfile.TemporaryFile() "simulates" a temp file via other 
means, and can control which directory it uses.

BTW, do you really think this has something to do with UNC 
paths?  From what you said it seems to be a matter of 
having sufficient permission to scribble in the current 
directory.

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

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


From noreply@sourceforge.net  Tue Aug  6 07:56:52 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 05 Aug 2002 23:56:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-581165 ] smtplib.SMTP.ehlo method esmtp_features
Message-ID: <E17byGy-00027B-00@usw-sf-web2.sourceforge.net>

Bugs item #581165, was opened at 2002-07-14 01:46
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=581165&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Piers Lauder (pierslauder)
Assigned to: Nobody/Anonymous (nobody)
Summary: smtplib.SMTP.ehlo method esmtp_features 

Initial Comment:
The ehlo() method in the smtplib class SMTP appears to
incorrectly
handle the response from Eudora Internet Mail Server
3.1.3 .

The rsponse to the "EHLO" command is:

send: 'ehlo gemini.cs.usyd.edu.au\r\n'
reply: '250-webfactory.com.au hello
gemini.cs.usyd.edu.au (129.78.111.139)\r\n'
reply: '250-EXPN\r\n'
reply: '250-PIPELINING\r\n'
reply: '250-8BITMIME\r\n'
reply: '250-BINARYMIME\r\n'
reply: '250-CHUNKING\r\n'
reply: '250-ENHANCEDSTATUSCODES\r\n'
reply: '250-ETRN\r\n'
reply: '250-AUTH CRAM-MD5 NTLM PLAIN LOGIN\r\n'
reply: '250-AUTH=LOGIN\r\n'
reply: '250 SIZE 2147483647\r\n'

which is then gathered into:

 ['webfactory.com.au hello gemini.cs.usyd.edu.au
(129.78.111.139)', 'EXPN', 'PIPELINING', '8BITMIME',
'BINARYMIME', 'CHUNKING', 'ENHANCEDSTATUSCODES',
'ETRN', 'AUTH CRAM-MD5 NTLM PLAIN LOGIN', 'AUTH=LOGIN',
'SIZE 2147483647']

which is then parsed into "self.esmtp_features as:

 {'enhancedstatuscodes': '', '8bitmime': '', 'expn':
'', 'chunking': '', 'etrn': '', 'pipelining': '',
'size': '2147483647', 'auth': '=LOGIN', 'binarymime': ''}

Note that the two lines starting "AUTH" have been
elided into the
one dictionary element 'auth':'=LOGIN'.

This prevents a subsequent call to the login() method
from correctly
identifying a suitable authentication method resulting in:

    raise SMTPException("No suitable authentication
method found.")



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

Comment By: Gerhard Häring (ghaering)
Date: 2002-08-06 08:56

Message:
Logged In: YES 
user_id=163326

Piers, could you please try my patch again? It contained a
very stupid bug (sent the username twice, but no password).
This seems unrelated to the error message your SMTP server
sent, but maybe it's worth a try.

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

Comment By: Piers Lauder (pierslauder)
Date: 2002-07-24 13:26

Message:
Logged In: YES 
user_id=196212

I tried the patch.

It gets me further - I now get "Syntax Error, not using
<cr><lf> as end of line."

Here's the trace:

resp: ['webfactory.com.au hello gemini.cs.usyd.edu.au
(129.78.111.139)', 'EXPN', 'PIPELINING', '8BITMIME',
'BINARYMIME', 'CHUNKING', 'ENHANCEDSTATUSCODES', 'ETRN',
'AUTH CRAM-MD5 NTLM PLAIN LOGIN', 'AUTH=LOGIN', 'SIZE
2147483647']
features: {'auth=login': '', 'enhancedstatuscodes': '',
'8bitmime': '', 'expn': '', 'chunking': '', 'etrn': '',
'pipelining': '', 'size': '2147483647', 'auth': 'CRAM-MD5
NTLM PLAIN LOGIN', 'binarymime': ''}
send: 'AUTH CRAM-MD5\r\n'
reply: '334
PDExODQ1NzY3NTctNjk3MjgzMDhAd2ViZmFjdG9yeS5jb20uYXU+\r\n'
reply: retcode (334); Msg:
PDExODQ1NzY3NTctNjk3MjgzMDhAd2ViZmFjdG9yeS5jb20uYXU+
send:
'cGllcnMlY29tbXVuaXR5c29sdXRpb25zLmNvbS5hdSAzOTU2NzVmYWUwZGUxZmQyN2I3MTRjNGQ5\nYzgzOWIwNQ==\r\n'
reply: '500 Syntax error, not using <cr><lf> as end of line\r\n'
reply: retcode (500); Msg: Syntax error, not using <cr><lf>
as end of line


Which doesn't make any sense, and is probably a server
problem, since I can see that each line sent _is_ terminated
with <cr><lf>.

So I consider the patch a (qualified) success.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-07-24 00:00

Message:
Logged In: YES 
user_id=21627

Can you please try the patch in

http://sourceforge.net/tracker/index.php?
func=detail&aid=572031&group_id=5470&atid=305470

and report whether it solves this problem?

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

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


From noreply@sourceforge.net  Tue Aug  6 09:35:28 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 06 Aug 2002 01:35:28 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-591207 ] list objects should accept slice indices
Message-ID: <E17bzoO-0005AC-00@usw-sf-web4.sourceforge.net>

Feature Requests item #591207, was opened at 2002-08-05 17:35
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=591207&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Jürgen A. Erhard (jae)
>Assigned to: Michael Hudson (mwh)
Summary: list objects should accept slice indices

Initial Comment:
List objects should accept slice objects has index values.  Just what user-written classes do.  Both built-in classes and user-written classes should behave the same way.  (And when my __getitem__ method receives a slice as argument, I'd like to pass it directly to some embedded list object if possible, without further massaging)

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

>Comment By: Michael Hudson (mwh)
Date: 2002-08-06 08:35

Message:
Logged In: YES 
user_id=6656

This is already implemented in current CVS.

I want a time machine too!


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

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


From noreply@sourceforge.net  Tue Aug  6 13:39:19 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 06 Aug 2002 05:39:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-566302 ] Bgen should generate 7-bit-clean code
Message-ID: <E17c3cN-0001xr-00@usw-sf-web5.sourceforge.net>

Bugs item #566302, was opened at 2002-06-08 23:50
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=566302&group_id=5470

Category: Macintosh
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: Bgen should generate 7-bit-clean code

Initial Comment:
Bgen should generate 7-bit clean code by using hex escapes for non-ascii characters. This should circumvene the problem with MacRoman vs. Latin-1 conversion for files under CVS. The bad news is that this means bgen may need to parse the constant declarations, but maybe we can get away by just escaping all non-ascii chars (as they should only occur within either strings or comments in C header files anyway).

The same probably holds for gensuitemodule.

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

>Comment By: Jack Jansen (jackjansen)
Date: 2002-08-06 14:39

Message:
Logged In: YES 
user_id=45365

This was fixed by Just in June (scantools.py rev 1.28).

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-10 13:59

Message:
Logged In: YES 
user_id=21627

I see, thanks for the explanation. I would still maintain
that it is a bug in the header files, then, since this is
implementation-defined behaviour as well, in C.

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

Comment By: Jack Jansen (jackjansen)
Date: 2002-06-09 21:40

Message:
Logged In: YES 
user_id=45365

The problem is mainly with MacOS "OSType" style values. OSType values are 32 bit longs, but they are customarily encoded as 4-char character constants (a rather obscure feature of C). These OSType values are ubiquitous in MacOS: creator and file type for files ('APPL' is the filetype for an executable, 'Pyth' is the creator code for MacPython), resource types ('DLOG' for dialog resources), AppleEvent/Open Scripting event type and subtype (send 'core'/'odoc' to open a document), etc etc etc.

Example of an OSType value that occur within the Python core is 'GU
I' (that's a Sigma there) for a resource that influences the I/O behaviour of the GUSI library. And all code that is generated by gensuitemodule or bgen will also contain lots of them.

Especially the Python code generated is error-prone as it may be used both by MacPython and MachoPython. This isn't true for core usage (which is MacPython-only, as far as I am aware).

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-09 12:51

Message:
Logged In: YES 
user_id=21627

That is precisely my question. Could you pass a copy of a
file that was used as input to bgen and shows this problem
(if for no other reason than to satisfy my curiosity)?

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

Comment By: Just van Rossum (jvr)
Date: 2002-06-09 11:15

Message:
Logged In: YES 
user_id=92689

*sigh* Do you know what bgen does? It parses C header files. For 
certain constant definitions it translates C to Python in a fairly simplistic 
way. Any 8-bit char in the C source was passed directly to the .py files. 
And yes, some Mac headers contain 8 bit chars in string constants. 
Revision 1.28 of Tools/bgen/bgen/scantools.py,v fixes this. I'll leave the 
bug open until it's more thoroughly tested.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-09 11:09

Message:
Logged In: YES 
user_id=21627

I think I understand the issue of using 7-bit clean source
code. I'm still trying to understand the bgen issue: why
would it ever produce output that is not 7-bit-clean?
(again, with examples please).

I would assume that the input is already in error, in such a
case.

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

Comment By: Just van Rossum (jvr)
Date: 2002-06-09 10:32

Message:
Logged In: YES 
user_id=92689

It's not a question of "doesn't work" but more a question of brittleness: 
Mac CVS clients optionally do text file encoding conversion, but this 
means that everyone involved _have_ to use the same settings or things 
go wrong. It helps to keep source files 7-bit clean. Some .py files in the 
Mac subdirectory are currently not 7-bit clean, and some of these are 
generated by bgen. Hence this "bug".

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-09 10:23

Message:
Logged In: YES 
user_id=21627

Can you give an example of code where it doesn't work
properly in this respect?

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

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


From noreply@sourceforge.net  Tue Aug  6 13:42:33 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 06 Aug 2002 05:42:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-591349 ] httplib sporadically throws a TypeError
Message-ID: <E17c3fV-00022s-00@usw-sf-web5.sourceforge.net>

Bugs item #591349, was opened at 2002-08-06 00:42
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=591349&group_id=5470

Category: Python Library
Group: Python 2.1.2
Status: Open
Resolution: None
>Priority: 5
Submitted By: Rob Green (rbgrn)
>Assigned to: Jeremy Hylton (jhylton)
Summary: httplib sporadically throws a TypeError

Initial Comment:
This is the output that occurs about 1 in 500 hits to any 
particular URL. I've only seen it so far hitting servers 
running Apache 1.3.20, but I don't have enough data to 
limit it to that.

Python 2.1.2 (#1, Mar 16 2002, 18:24:08)
[GCC 2.95.3 [FreeBSD] 20010315 (release)] on freebsd4

h = httplib.HTTPConnection(host)
response = h.getresponse()
data = response.read()
File "/usr/local/lib/python2.1/httplib.py", line 246, in read
value = value + self._safe_read(chunk_left)
File "/usr/local/lib/python2.1/httplib.py", line 314, in 
_safe_read
chunk = self.fp.read(amt)
TypeError: an integer is required



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

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-08-06 12:42

Message:
Logged In: YES 
user_id=31392

Can you provide any more information about what URLs cause
problems?  You could call set_debuglevel(1) to enable output
of all  HTTP trafffic.  Or just a list of some of the URLs
that failed.


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

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


From noreply@sourceforge.net  Tue Aug  6 14:06:29 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 06 Aug 2002 06:06:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-505423 ] Get rid of make frameworkinstall
Message-ID: <E17c42f-0001pi-00@usw-sf-web4.sourceforge.net>

Bugs item #505423, was opened at 2002-01-18 17:01
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=505423&group_id=5470

Category: Macintosh
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: Get rid of make frameworkinstall

Initial Comment:
We should get rid of "make frameworkinstall" if you build a framework Python, and in stead have installing the framework be handled with a normal "make install".

Various people have been confused by this. Including me. More than once. :-)

"make install" for a framework build should also install a symlink in the normal (/usr/local) location, but this may be a bit difficult as the PREFIX variable (and it's dependents such as BINDIR) are forced to point into the framework when we're doing a framework build.

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

>Comment By: Jack Jansen (jackjansen)
Date: 2002-08-06 15:06

Message:
Logged In: YES 
user_id=45365

I'm not going to do this after all. 'make frameworkinstall' is going to stay, and there's going to be companions 'make frameworkinstallapps' and 'make frameworkinstalltools' that install the apps and tools.

I will look into giving an error if "make install" in a framework build notices it is called outside of "make frameworkinstall".

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

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


From noreply@sourceforge.net  Tue Aug  6 15:40:38 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 06 Aug 2002 07:40:38 -0700
Subject: [Python-bugs-list] [ python-Bugs-591104 ] os.tmpfile() can fail on win32
Message-ID: <E17c5Vm-0004Lu-00@usw-sf-web4.sourceforge.net>

Bugs item #591104, was opened at 2002-08-05 14:23
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=591104&group_id=5470

Category: Windows
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Joseph Barillari (jdbarillari)
Assigned to: Mark Hammond (mhammond)
Summary: os.tmpfile() can fail on win32

Initial Comment:
I've discovered what appears to be a bug in Python 2.2.1 
on Win32. I'm
using the 2.2.1 build that I downloaded from python.org. 
I'm running
Windows 2000.

If os.tmpfile() is exceuted when the CWD is a UNC path, 
the base of
which is not writeable by the current user, tmpfile will
fail. tempfile.TemporaryFile will work, so I suspect this is 
a bug in os.tmpfile().

For example:

C:\>pwd  
/cygdrive/c   #I use cygwin

C:\>bash    # I have to use bash; the DOS shell doesn't 
support UNC paths
bash: .bashrc: No such file or directory
bash-2.05a$ cd //bopp/jbarilla
bash-2.05a$ pwd
//bopp/jbarilla
bash-2.05a$ python
Python 2.2.1 (#34, Apr  9 2002, 19:34:33) [MSC 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import os; os.tmpfile()
<open file '<tmpfile>', mode 'w+' at 0x007762C0> # It 
works.
>>> ^Z

If I chmod 555 //bopp/jbarilla (from unix via NFS; 
incidentally,
"chmod 555 ." from cygwin is ineffectual), then tmpfile 
fails:

bash-2.05a$ pwd
//bopp/jbarilla
bash-2.05a$ python
Python 2.2.1 (#34, Apr  9 2002, 19:34:33) [MSC 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import os; os.tmpfile()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OSError: [Errno 13] Permission denied # Oops.

# However, tempfile.TemporaryFile works:

>>> import tempfile; tempfile.TemporaryFile()
<open file 'c:\DOCUME~1\jbarilla\LOCALS~1
\Temp\~1880-0', mode 'w+b' at 0x00779B00>

--Joe

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

>Comment By: Joseph Barillari (jdbarillari)
Date: 2002-08-06 14:40

Message:
Logged In: YES 
user_id=589825

\quote{BTW, do you really think this has something to do 
with UNC 
paths?  From what you said it seems to be a matter of 
having sufficient permission to scribble in the current 
directory.}

Oops. You're right:

Z:\>touch a
touch: creating `a': Permission denied

Z:\>python
Python 2.2.1 (#34, Apr  9 2002, 19:34:33) [MSC 32 bit (Intel)] 
on win32
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import os; os.tmpfile()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OSError: [Errno 13] Permission denied
>>>

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

Comment By: Tim Peters (tim_one)
Date: 2002-08-06 03:19

Message:
Logged In: YES 
user_id=31435

Assigned to Mark in case he has another idea, but I think 
you're out of luck.  os.tmpfile() does nothing except call 
Microsoft's tmpfile() function, and that doesn't allow 
specifying a directory.  If you don't have permission to 
create a file in the current directory, you lose, and Python's 
behavior here will change when Microsoft's does.

tempfile.TemporaryFile() "simulates" a temp file via other 
means, and can control which directory it uses.

BTW, do you really think this has something to do with UNC 
paths?  From what you said it seems to be a matter of 
having sufficient permission to scribble in the current 
directory.

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

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


From noreply@sourceforge.net  Tue Aug  6 16:16:31 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 06 Aug 2002 08:16:31 -0700
Subject: [Python-bugs-list] [ python-Bugs-591586 ] Get rid of etype struct
Message-ID: <E17c64V-00060f-00@usw-sf-web5.sourceforge.net>

Bugs item #591586, was opened at 2002-08-06 11:16
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=591586&group_id=5470

Category: Type/class unification
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Get rid of etype struct

Initial Comment:
The 'etype' struct in typeobject.c prevents people like
David Abrahams and Christian Tismer from defining
C-level metatypes that add slots to the end of the type
structure. It should be possible for type_new() to
place the additional structures after an offset
determined by tp_basicsize of the metatype, rather than
at a fixed offset.

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

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


From noreply@sourceforge.net  Tue Aug  6 16:59:29 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 06 Aug 2002 08:59:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-576975 ] os.path.walk behavior on symlinks
Message-ID: <E17c6k5-0000O1-00@usw-sf-web1.sourceforge.net>

Bugs item #576975, was opened at 2002-07-03 10:26
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=576975&group_id=5470

Category: Documentation
Group: Feature Request
>Status: Pending
>Resolution: Fixed
Priority: 5
Submitted By: Damien Elmes (resolve)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: os.path.walk behavior on symlinks

Initial Comment:
os.path.walk won't recurse on symlinks pointing to
directories. That's okay - it's probably a reasonable
default behavior to have. It would be nice to point
this out in the docstring, however - something like:


"Note: os.path.walk will not recurse into symlinks
pointing to directories. You can accomplish this
yourself by checking os.path.isdir(file) and
os.path.islink(file) in func, and reinvocing walk from
there"

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

>Comment By: Steve Holden (holdenweb)
Date: 2002-08-06 11:59

Message:
Logged In: YES 
user_id=88157

I have added a suitable note to this effect.

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

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


From noreply@sourceforge.net  Tue Aug  6 17:12:44 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 06 Aug 2002 09:12:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-576975 ] os.path.walk behavior on symlinks
Message-ID: <E17c6wu-0004u4-00@usw-sf-web2.sourceforge.net>

Bugs item #576975, was opened at 2002-07-03 10:26
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=576975&group_id=5470

Category: Documentation
Group: Feature Request
>Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Damien Elmes (resolve)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: os.path.walk behavior on symlinks

Initial Comment:
os.path.walk won't recurse on symlinks pointing to
directories. That's okay - it's probably a reasonable
default behavior to have. It would be nice to point
this out in the docstring, however - something like:


"Note: os.path.walk will not recurse into symlinks
pointing to directories. You can accomplish this
yourself by checking os.path.isdir(file) and
os.path.islink(file) in func, and reinvocing walk from
there"

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

>Comment By: Steve Holden (holdenweb)
Date: 2002-08-06 12:12

Message:
Logged In: YES 
user_id=88157

I have added a suitable note to this effect.

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

Comment By: Steve Holden (holdenweb)
Date: 2002-08-06 11:59

Message:
Logged In: YES 
user_id=88157

I have added a suitable note to this effect.

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

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


From noreply@sourceforge.net  Tue Aug  6 17:22:28 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 06 Aug 2002 09:22:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-580495 ] mimetools module privacy leak
Message-ID: <E17c76K-0005Bb-00@usw-sf-web2.sourceforge.net>

Bugs item #580495, was opened at 2002-07-12 05:35
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=580495&group_id=5470

>Category: Python Library
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: mimetools module privacy leak

Initial Comment:
The mimetools "choose_boundary" function according to
its doc
returns a string of the form
'hostipaddr.uid.pid.timestamp.random'.
If this separator is actually used in a message, it
reveals the host ID
and UID of the sender.  This is a privacy breach
similar to the discovery
that Microsoft Word files contained user GUID's
revealing the user's
PC's ethernet card's MAC address (since fixed, after
the story was
published on the front page of the New York Times about
2 years ago).
Some info is at

  http://www.junkbusters.com/microsoft.html#advisory


The fix for choose_boundary is to make the boundary
string completely
random and not have it reveal personal information
about the user.


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

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2002-08-06 12:22

Message:
Logged In: YES 
user_id=12800

Is this a serious concern for most applications?  In most
email messages, some identifying information will always
leak so since it takes work to anonymize messages anyway, an
application with these concerns can simply implement its own
choose_boundary() algorithm, or lop off the hostid part of
the generated one.

Besides, mimetools.py should be considered obsolete, in
favor of the email package.  When it generates a boundary it
doesn't include any identifying information (but has a
moderately higher possibility of collision in the source text).

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

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


From noreply@sourceforge.net  Tue Aug  6 20:10:22 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 06 Aug 2002 12:10:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-591704 ] generators can't be weakly referenced
Message-ID: <E17c9io-0002JB-00@usw-sf-web5.sourceforge.net>

Bugs item #591704, was opened at 2002-08-06 15:10
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=591704&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: H. Richard Harkins (hrharkins)
Assigned to: Nobody/Anonymous (nobody)
Summary: generators can't be weakly referenced

Initial Comment:
I can't seem to weakly reference generators.  I can't
think of a good reason that this shouldn't work.  Here
is a code snippet to demonstrate the issue:

>>> from __future__ import generators
>>> import weakref
>>> def f():
...   yield "HELLO"
...
>>> weakref.proxy(f())
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: cannot create weak reference to 'generator'
object
>>>



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

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


From noreply@sourceforge.net  Tue Aug  6 20:48:29 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 06 Aug 2002 12:48:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-574207 ] Chained __slots__ dealloc segfault
Message-ID: <E17cAJh-000318-00@usw-sf-web5.sourceforge.net>

Bugs item #574207, was opened at 2002-06-26 14:35
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574207&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Jonathan Hogg (jhogg)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: Chained __slots__ dealloc segfault

Initial Comment:
With the following script ('foo.py'):

-----
class foo1(object):
    def __init__(self, n):
        self.n = n

class foo2(object):
    def __init__(self, n):
        self.n = n
    __slots__ = ['n']

o = None
for i in xrange(50000):
    o = foo1(o)
print 'alloc OK'
del o 
print 'dealloc OK'

o = None 
for i in xrange(50000):
    o = foo2(o)
print 'alloc OK'
del o 
print 'OK'
-----

Running this results in a segmentation fault in the
second 'del':

-----
onegood1-2% python foo.py
alloc OK
dealloc OK
alloc OK
zsh: 18593 segmentation fault  python foo.py
-----

A gdb stack trace shows:

-----
Program received signal EXC_BAD_ACCESS, Could not
access memory.
0x00037bbc in lookdict_string (mp=0xa7fb8, key=0x191d0,
hash=3882000) at Objects/dictobject.c:306
306     {
(gdb) where
#0  0x00037bbc in lookdict_string (mp=0xa7fb8,
key=0x191d0, hash=3882000) at Objects/dictobject.c:306
#1  0x00018994 in _PyType_Lookup (type=0x3d14f0,
name=0x3b3c10) at Objects/typeobject.c:1227
#2  0x00017348 in lookup_maybe (self=0xbb88f0,
attrstr=0x3d14f0 "", attrobj=0xa0228) at
Objects/typeobject.c:460
#3  0x00016f38 in call_finalizer (self=0xbb88f0) at
Objects/typeobject.c:280
#4  0x00017054 in subtype_dealloc (self=0xbb88f0) at
Objects/typeobject.c:328
#5  0x00017118 in subtype_dealloc (self=0xbb88d0) at
Objects/typeobject.c:353
#6  0x00017118 in subtype_dealloc (self=0xbb88b0) at
Objects/typeobject.c:353
[...]
#5431 0x00017118 in subtype_dealloc (self=0xbe3410) at
Objects/typeobject.c:353
#5432 0x00017118 in subtype_dealloc (self=0xbe33f0) at
Objects/typeobject.c:353
#5433 0x00017118 in subtype_dealloc (self=0xbe33d0) at
Objects/typeobject.c:353
#5434 0x000382f4 in PyDict_DelItem (op=0x3b3300,
key=0x405520) at Objects/dictobject.c:588
#5435 0x0005b348 in eval_frame (f=0x0) at
Python/ceval.c:1550
#5436 0x0005d6fc in PyEval_EvalCodeEx (co=0x3fd760,
globals=0x402d60, locals=0x3804c, args=0x0, argcount=0,
kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0)
at Python/ceval.c:2585
#5437 0x000588e0 in PyEval_EvalCode (co=0x3d14f0,
globals=0x402d60, locals=0x46257b48) at Python/ceval.c:483
#5438 0x00027850 in run_node (n=0x3bfba0,
filename=0x402d60 "", globals=0x3b3300,
locals=0x3b3300, flags=0x3d16e8) at Python/pythonrun.c:1079
#5439 0x000277f4 in run_err_node (n=0x3804c,
filename=0x402d60 "", globals=0x46257b48, locals=0x0,
flags=0x3d16e8) at Python/pythonrun.c:1066
#5440 0x000277c0 in PyRun_FileExFlags (fp=0x80008a98,
filename=0xbffffb46 "foo.py", start=1176861512,
globals=0x3b3300, locals=0x3b3300, closeit=1,
flags=0xbffff9c8) at Python/pythonrun.c:1057
#5441 0x0002683c in PyRun_SimpleFileExFlags
(fp=0x80008a98, filename=0xbffffb46 "foo.py",
closeit=1, flags=0xbffff9c8) at Python/pythonrun.c:685
#5442 0x00026254 in PyRun_AnyFileExFlags
(fp=0x80008a98, filename=0xbffffb46 "foo.py",
closeit=1, flags=0xbffff9c8) at Python/pythonrun.c:495
#5443 0x00005e10 in Py_Main (argc=2, argv=0xbffffab0)
at Modules/main.c:364
#5444 0x00001e2c in _start ()
#5445 0x00001c5c in start ()
-----

The number of objects that can be deallocated depends
on the stacksize, so it appears to be a stack overrun
problem.

This is on a Mac OS X 10.1.5 system, but was originally
reported by Glyph Lefkowitz using Python 2.2.1 on PPC
Linux 2.4.18 (Debian I think) and has been verified
also by Aahz using Python 2.2.1 on Mandrake 8.1.


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

>Comment By: Tim Peters (tim_one)
Date: 2002-08-06 15:48

Message:
Logged In: YES 
user_id=31435

Back to Guido, since he's looking at this now.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-07-15 12:03

Message:
Logged In: YES 
user_id=6380

Tim can review this better, since AFAIK he rewrote the
trashcan macros most recently.

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

Comment By: Jonathan Hogg (jhogg)
Date: 2002-07-15 11:54

Message:
Logged In: YES 
user_id=10036

I updated my original patch (575073) to match recent changes
to HEAD. I also added a new patch: 581742 "Alternative
PyTRASHCAN subtype_dealloc", which wraps 'subtype_dealloc'
in the normal (though slightly modified) PyTRASHCAN macros -
but it has to do ugly things to keep the original GC semantics.

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

Comment By: Jonathan Hogg (jhogg)
Date: 2002-06-28 11:26

Message:
Logged In: YES 
user_id=10036

I've uploaded a patch (against HEAD today) that fixes this
problem by putting the objects in the slots into a temporary
list and appending that to the PyTRASHCAN 'delete_later'
chain when the maximum deallocation recursion depth is reached.

[ 575073 ] PyTRASHCAN slots deallocation


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-26 22:32

Message:
Logged In: YES 
user_id=33168

I bumped MAX up to 500000 and 2.3 didn't crash.
But then I dropped my max stack size down from 8M to 1M
and that caused the crash.  So the stack handling must be
better in 2.3, but as you point out, still not fixed.

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

Comment By: Tim Peters (tim_one)
Date: 2002-06-26 22:12

Message:
Logged In: YES 
user_id=31435

Neal, it's odd that you can't provoke a problem.  Try 
boosting MAX.  The del here triggers a chain of 
deallocations that requires call-stack space proportional to 
the length of the object chain (MAX).  This is the kind of 
situation Python's infamous TRASHCAN macros aim at 
worming around, but the slot cleanup code doesn't play 
that game (yet).

Assigned to Guido just because he'll enjoy it <wink>.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-26 21:27

Message:
Logged In: YES 
user_id=33168

I do not get this problem with current CVS.
I do get this problem with 2.2.1+ (current).
Attaching the test file I used.

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

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


From noreply@sourceforge.net  Tue Aug  6 22:05:24 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 06 Aug 2002 14:05:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-591748 ] Implementation bug
Message-ID: <E17cBW8-000432-00@usw-sf-web4.sourceforge.net>

Bugs item #591748, was opened at 2002-08-06 14:05
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=591748&group_id=5470

Category: Windows
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Abhijit Sengupta (sengupta2)
Assigned to: Tim Peters (tim_one)
Summary: Implementation bug

Initial Comment:
Using my Windows implementation, I observed that the 
following piece of code (to find union of two lists) 
modifies the first parameter value.

   
def setunion(x,y):
      l=len(y)
      p=x
      for j in range(0,l):
          z=y.pop(0)
          y.append(z)
          if(p.count(z)==0):
               p.append(z)
      return(p)

       

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

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


From noreply@sourceforge.net  Tue Aug  6 22:11:09 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 06 Aug 2002 14:11:09 -0700
Subject: [Python-bugs-list] [ python-Bugs-591748 ] Implementation bug
Message-ID: <E17cBbh-0004fs-00@usw-sf-web5.sourceforge.net>

Bugs item #591748, was opened at 2002-08-06 21:05
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=591748&group_id=5470

Category: Windows
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Abhijit Sengupta (sengupta2)
>Assigned to: Neil Schemenauer (nascheme)
Summary: Implementation bug

Initial Comment:
Using my Windows implementation, I observed that the 
following piece of code (to find union of two lists) 
modifies the first parameter value.

   
def setunion(x,y):
      l=len(y)
      p=x
      for j in range(0,l):
          z=y.pop(0)
          y.append(z)
          if(p.count(z)==0):
               p.append(z)
      return(p)

       

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

>Comment By: Neil Schemenauer (nascheme)
Date: 2002-08-06 21:11

Message:
Logged In: YES 
user_id=35752

Reset your brain: http://effbot.org/guides/python-objects.htm

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

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


From noreply@sourceforge.net  Tue Aug  6 22:26:34 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 06 Aug 2002 14:26:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-586937 ] references to email package
Message-ID: <E17cBqc-0004zF-00@usw-sf-web5.sourceforge.net>

Bugs item #586937, was opened at 2002-07-26 06:37
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=586937&group_id=5470

Category: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: references to email package

Initial Comment:
[request/wishlist report from 
http://bugs.debian.org/146880]

Should mention the 'email' module in rfc822, mimetools, 
multifile sections

I needed to parse some RFC822-format headers, so 
naturally I found the rfc822 module first.  I wrote some 
code to use it (and was frustrated by some of its 
limitations) before I discovered the much nicer 'email' 
module, which seems to replace most of the 
functionality of these modules.  It would be nice if there 
were pointers in the appropriate places to make the 
reader aware of this new module before using the older 
interfaces.

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-08-06 17:26

Message:
Logged In: YES 
user_id=3066

Excellent idea!  I've added references for both the 2.2.x
maintenance releases and 2.3.

Doc/lib/libmimetools.tex  1.20.16.1, 1.22
Doc/lib/libmultifile.tex  1.11.22.1, 1.12
Doc/lib/librfc822.tex  1.38.14.2, 1.41

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

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


From noreply@sourceforge.net  Tue Aug  6 22:37:09 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 06 Aug 2002 14:37:09 -0700
Subject: [Python-bugs-list] [ python-Bugs-576975 ] os.path.walk behavior on symlinks
Message-ID: <E17cC0r-0008Ip-00@usw-sf-web1.sourceforge.net>

Bugs item #576975, was opened at 2002-07-03 10:26
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=576975&group_id=5470

Category: Documentation
Group: Feature Request
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Damien Elmes (resolve)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: os.path.walk behavior on symlinks

Initial Comment:
os.path.walk won't recurse on symlinks pointing to
directories. That's okay - it's probably a reasonable
default behavior to have. It would be nice to point
this out in the docstring, however - something like:


"Note: os.path.walk will not recurse into symlinks
pointing to directories. You can accomplish this
yourself by checking os.path.isdir(file) and
os.path.islink(file) in func, and reinvocing walk from
there"

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-08-06 17:37

Message:
Logged In: YES 
user_id=3066

Steve fixed this, so we can close the issue report.  Thanks!

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

Comment By: Steve Holden (holdenweb)
Date: 2002-08-06 12:12

Message:
Logged In: YES 
user_id=88157

I have added a suitable note to this effect.

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

Comment By: Steve Holden (holdenweb)
Date: 2002-08-06 11:59

Message:
Logged In: YES 
user_id=88157

I have added a suitable note to this effect.

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

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


From noreply@sourceforge.net  Tue Aug  6 22:43:59 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 06 Aug 2002 14:43:59 -0700
Subject: [Python-bugs-list] [ python-Bugs-574207 ] Chained __slots__ dealloc segfault
Message-ID: <E17cC7T-0005OL-00@usw-sf-web5.sourceforge.net>

Bugs item #574207, was opened at 2002-06-26 14:35
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574207&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jonathan Hogg (jhogg)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Chained __slots__ dealloc segfault

Initial Comment:
With the following script ('foo.py'):

-----
class foo1(object):
    def __init__(self, n):
        self.n = n

class foo2(object):
    def __init__(self, n):
        self.n = n
    __slots__ = ['n']

o = None
for i in xrange(50000):
    o = foo1(o)
print 'alloc OK'
del o 
print 'dealloc OK'

o = None 
for i in xrange(50000):
    o = foo2(o)
print 'alloc OK'
del o 
print 'OK'
-----

Running this results in a segmentation fault in the
second 'del':

-----
onegood1-2% python foo.py
alloc OK
dealloc OK
alloc OK
zsh: 18593 segmentation fault  python foo.py
-----

A gdb stack trace shows:

-----
Program received signal EXC_BAD_ACCESS, Could not
access memory.
0x00037bbc in lookdict_string (mp=0xa7fb8, key=0x191d0,
hash=3882000) at Objects/dictobject.c:306
306     {
(gdb) where
#0  0x00037bbc in lookdict_string (mp=0xa7fb8,
key=0x191d0, hash=3882000) at Objects/dictobject.c:306
#1  0x00018994 in _PyType_Lookup (type=0x3d14f0,
name=0x3b3c10) at Objects/typeobject.c:1227
#2  0x00017348 in lookup_maybe (self=0xbb88f0,
attrstr=0x3d14f0 "", attrobj=0xa0228) at
Objects/typeobject.c:460
#3  0x00016f38 in call_finalizer (self=0xbb88f0) at
Objects/typeobject.c:280
#4  0x00017054 in subtype_dealloc (self=0xbb88f0) at
Objects/typeobject.c:328
#5  0x00017118 in subtype_dealloc (self=0xbb88d0) at
Objects/typeobject.c:353
#6  0x00017118 in subtype_dealloc (self=0xbb88b0) at
Objects/typeobject.c:353
[...]
#5431 0x00017118 in subtype_dealloc (self=0xbe3410) at
Objects/typeobject.c:353
#5432 0x00017118 in subtype_dealloc (self=0xbe33f0) at
Objects/typeobject.c:353
#5433 0x00017118 in subtype_dealloc (self=0xbe33d0) at
Objects/typeobject.c:353
#5434 0x000382f4 in PyDict_DelItem (op=0x3b3300,
key=0x405520) at Objects/dictobject.c:588
#5435 0x0005b348 in eval_frame (f=0x0) at
Python/ceval.c:1550
#5436 0x0005d6fc in PyEval_EvalCodeEx (co=0x3fd760,
globals=0x402d60, locals=0x3804c, args=0x0, argcount=0,
kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0)
at Python/ceval.c:2585
#5437 0x000588e0 in PyEval_EvalCode (co=0x3d14f0,
globals=0x402d60, locals=0x46257b48) at Python/ceval.c:483
#5438 0x00027850 in run_node (n=0x3bfba0,
filename=0x402d60 "", globals=0x3b3300,
locals=0x3b3300, flags=0x3d16e8) at Python/pythonrun.c:1079
#5439 0x000277f4 in run_err_node (n=0x3804c,
filename=0x402d60 "", globals=0x46257b48, locals=0x0,
flags=0x3d16e8) at Python/pythonrun.c:1066
#5440 0x000277c0 in PyRun_FileExFlags (fp=0x80008a98,
filename=0xbffffb46 "foo.py", start=1176861512,
globals=0x3b3300, locals=0x3b3300, closeit=1,
flags=0xbffff9c8) at Python/pythonrun.c:1057
#5441 0x0002683c in PyRun_SimpleFileExFlags
(fp=0x80008a98, filename=0xbffffb46 "foo.py",
closeit=1, flags=0xbffff9c8) at Python/pythonrun.c:685
#5442 0x00026254 in PyRun_AnyFileExFlags
(fp=0x80008a98, filename=0xbffffb46 "foo.py",
closeit=1, flags=0xbffff9c8) at Python/pythonrun.c:495
#5443 0x00005e10 in Py_Main (argc=2, argv=0xbffffab0)
at Modules/main.c:364
#5444 0x00001e2c in _start ()
#5445 0x00001c5c in start ()
-----

The number of objects that can be deallocated depends
on the stacksize, so it appears to be a stack overrun
problem.

This is on a Mac OS X 10.1.5 system, but was originally
reported by Glyph Lefkowitz using Python 2.2.1 on PPC
Linux 2.4.18 (Debian I think) and has been verified
also by Aahz using Python 2.2.1 on Mandrake 8.1.


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-06 17:43

Message:
Logged In: YES 
user_id=6380

Fixed in CVS. Now, what to do about 2.2? The problem still
exists in that lineage; it's not easy to backport the patch
there because the trashcan macros work very differently...

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

Comment By: Tim Peters (tim_one)
Date: 2002-08-06 15:48

Message:
Logged In: YES 
user_id=31435

Back to Guido, since he's looking at this now.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-07-15 12:03

Message:
Logged In: YES 
user_id=6380

Tim can review this better, since AFAIK he rewrote the
trashcan macros most recently.

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

Comment By: Jonathan Hogg (jhogg)
Date: 2002-07-15 11:54

Message:
Logged In: YES 
user_id=10036

I updated my original patch (575073) to match recent changes
to HEAD. I also added a new patch: 581742 "Alternative
PyTRASHCAN subtype_dealloc", which wraps 'subtype_dealloc'
in the normal (though slightly modified) PyTRASHCAN macros -
but it has to do ugly things to keep the original GC semantics.

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

Comment By: Jonathan Hogg (jhogg)
Date: 2002-06-28 11:26

Message:
Logged In: YES 
user_id=10036

I've uploaded a patch (against HEAD today) that fixes this
problem by putting the objects in the slots into a temporary
list and appending that to the PyTRASHCAN 'delete_later'
chain when the maximum deallocation recursion depth is reached.

[ 575073 ] PyTRASHCAN slots deallocation


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-26 22:32

Message:
Logged In: YES 
user_id=33168

I bumped MAX up to 500000 and 2.3 didn't crash.
But then I dropped my max stack size down from 8M to 1M
and that caused the crash.  So the stack handling must be
better in 2.3, but as you point out, still not fixed.

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

Comment By: Tim Peters (tim_one)
Date: 2002-06-26 22:12

Message:
Logged In: YES 
user_id=31435

Neal, it's odd that you can't provoke a problem.  Try 
boosting MAX.  The del here triggers a chain of 
deallocations that requires call-stack space proportional to 
the length of the object chain (MAX).  This is the kind of 
situation Python's infamous TRASHCAN macros aim at 
worming around, but the slot cleanup code doesn't play 
that game (yet).

Assigned to Guido just because he'll enjoy it <wink>.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-26 21:27

Message:
Logged In: YES 
user_id=33168

I do not get this problem with current CVS.
I do get this problem with 2.2.1+ (current).
Attaching the test file I used.

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

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


From noreply@sourceforge.net  Tue Aug  6 22:51:24 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 06 Aug 2002 14:51:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-579991 ] LibRef 2.2.1, replace zero with False
Message-ID: <E17cCEe-0004fC-00@usw-sf-web4.sourceforge.net>

Bugs item #579991, was opened at 2002-07-11 03:52
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=579991&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Yitz Gale (yitzg)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: LibRef 2.2.1, replace zero with False

Initial Comment:
In Library Refernce, 2.2.1 Truth Value Testing:

In current text "...when that method returns zero." and
the associated footnote, the word "zero" should be
replaced with "a false value".


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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-08-06 17:51

Message:
Logged In: YES 
user_id=3066

I'll add a clarification that returning an integer includes
returns a boolean.  The True and False values are integers
in 2.2.1 and instances of bool in 2.3, but bool is a
subclass of the integer type, so returning False from
__nonzero__ really is returning an integer.

I'll check this into CVS once SourceForge clears a stale
lock; leaving it open until then so I don't forget.

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

Comment By: Yitz Gale (yitzg)
Date: 2002-07-13 19:02

Message:
Logged In: YES 
user_id=576391

Hmm - in that case, there is also a bug in Ref. Guide 3.3.1
which says
that __nonzero__() is allowed to return boolean. But that would
be really quirky, are you sure boolean is not allowed?

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-12 13:16

Message:
Logged In: YES 
user_id=3066

Clarified in Doc/lib/libstdtypes.tex revisions 1.99 and
1.80.6.10.
__nonzero__() *must* return an integer.

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

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


From noreply@sourceforge.net  Tue Aug  6 22:53:01 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 06 Aug 2002 14:53:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-587087 ] ur'\u' not handled properly
Message-ID: <E17cCGD-0005c5-00@usw-sf-web5.sourceforge.net>

Bugs item #587087, was opened at 2002-07-26 12:05
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=587087&group_id=5470

Category: Parser/Compiler
Group: Python 2.2
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Jeff Epler (jepler)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: ur'\u' not handled properly

Initial Comment:
according to
http://www.python.org/doc/current/ref/strings.html, no
\-escapes have a meaning inside raw strings.

However, \u seems to be interpreted:
>>> ur'\u'
UnicodeError: Unicode-Escape decoding error: truncated
\uXXXX
>>> ur'\u0100'
u'\u0100'

I would expect the values to be
u'\u'
u'\u0100'

Tested in 2.3a0 from <2 weeks ago and python 2.2.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-08-05 01:53

Message:
Logged In: YES 
user_id=80475

Documentation patch attached for Fred's approval.

If okay, re-assign back to Raymond for a commit and 
backport to 2.2.

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-07-26 12:31

Message:
Logged In: YES 
user_id=38388

I suppose this is a documentation bug. According to PEP 100:

    u = ur'<raw-unicode-escape encoded Python string>'

    The 'raw-unicode-escape' encoding is defined as follows:

    - \uXXXX sequence represent the U+XXXX Unicode character
if and
      only if the number of leading backslashes is odd

    - all other characters represent themselves as Unicode
ordinal
      (e.g. 'b' -> U+0062)

Assigned to Fred.

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

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


From noreply@sourceforge.net  Tue Aug  6 23:40:35 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 06 Aug 2002 15:40:35 -0700
Subject: [Python-bugs-list] [ python-Bugs-587087 ] ur'\u' not handled properly
Message-ID: <E17cD0F-0006b2-00@usw-sf-web5.sourceforge.net>

Bugs item #587087, was opened at 2002-07-26 11:05
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=587087&group_id=5470

Category: Parser/Compiler
Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jeff Epler (jepler)
Assigned to: Raymond Hettinger (rhettinger)
Summary: ur'\u' not handled properly

Initial Comment:
according to
http://www.python.org/doc/current/ref/strings.html, no
\-escapes have a meaning inside raw strings.

However, \u seems to be interpreted:
>>> ur'\u'
UnicodeError: Unicode-Escape decoding error: truncated
\uXXXX
>>> ur'\u0100'
u'\u0100'

I would expect the values to be
u'\u'
u'\u0100'

Tested in 2.3a0 from <2 weeks ago and python 2.2.

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-08-06 17:40

Message:
Logged In: YES 
user_id=80475

Jeff, thanks for the bug report.
Committed patch to ref2.tex version 1.40 and 1.34.6.3.
Closing bug.




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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-08-05 00:53

Message:
Logged In: YES 
user_id=80475

Documentation patch attached for Fred's approval.

If okay, re-assign back to Raymond for a commit and 
backport to 2.2.

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-07-26 11:31

Message:
Logged In: YES 
user_id=38388

I suppose this is a documentation bug. According to PEP 100:

    u = ur'<raw-unicode-escape encoded Python string>'

    The 'raw-unicode-escape' encoding is defined as follows:

    - \uXXXX sequence represent the U+XXXX Unicode character
if and
      only if the number of leading backslashes is odd

    - all other characters represent themselves as Unicode
ordinal
      (e.g. 'b' -> U+0062)

Assigned to Fred.

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

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


From noreply@sourceforge.net  Tue Aug  6 23:54:01 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 06 Aug 2002 15:54:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-575770 ] os.spawnv() fails with underscores
Message-ID: <E17cDDF-0006vg-00@usw-sf-web5.sourceforge.net>

Bugs item #575770, was opened at 2002-06-30 22:15
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575770&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris Rodrigues (nokta_kanto)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.spawnv() fails with underscores

Initial Comment:
 I'm running Python 2.2 in Windows 98. 
 
When trying to os.spawnv() a program in a path that contains an 
underscore, the program does not run but no error message is 
printed.  This error happens in the dos version of Python 2.2, but 
not in IDLE. 
 
I detected the error by creating a DOS program that returns the 
recognizable value 111. If I call that file "c:\ret111.exe" and run it with 
the following command: 
 
os.spawnv( os.P_WAIT, progname, [progname] ) 
 
where progname is the full path and name of the program, then the 
function returns the value 111.  If I put that file in 
"c:\pulse_prog\ret111.exe", and run the same command with the new 
value of progname, then the return value is 111 in IDLE but 0 in 
dos-prompt python. 

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

>Comment By: Chris Rodrigues (nokta_kanto)
Date: 2002-08-06 22:54

Message:
Logged In: YES 
user_id=571002

I've attached the binary file.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-07-30 14:27

Message:
Logged In: YES 
user_id=21627

Can you please attach the binary to this report?

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

Comment By: Chris Rodrigues (nokta_kanto)
Date: 2002-07-19 21:22

Message:
Logged In: YES 
user_id=571002

Here's a screen dump of the error in progress.

I don't know if it makes a difference, but ret111.exe was compiled with 
djgpp.

C:\pulse_prog>type ret111.c
int main() {return 111;}

C:\pulse_prog>python
Python 2.2.1c2 (#33, Mar 26 2002, 13:04:18) [MSC 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.spawnv( os.P_WAIT, r'c:\ret111.exe', [r'c:\ret111.exe'])
111
>>> os.spawnv( os.P_WAIT, r'c:\pulse_prog\ret111.exe', 
[r'c:\pulse_prog\ret111.exe'])
0
>>>


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

Comment By: Tim Peters (tim_one)
Date: 2002-07-05 16:46

Message:
Logged In: YES 
user_id=31435

I can't reproduce this using 2.2.1 under Win98SE.  Here's 
a screen dump showing exactly what I did.  Please show us 
exactly what you did.

C:\pulse_prog>type ret111.c
int main() { return 111; }

C:\pulse_prog>cd \python22

C:\Python22>python
Python 2.2.1 (#34, Apr  9 2002, 19:34:33) [MSC 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import os
>>> prog = r"c:\pulse_prog\ret111"
>>> os.spawnv(os.P_WAIT, prog, [prog])
111
>>>


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-07-05 05:52

Message:
Logged In: YES 
user_id=21627

Can you please attach the test program to this report?

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

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


From noreply@sourceforge.net  Wed Aug  7 03:30:09 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 06 Aug 2002 19:30:09 -0700
Subject: [Python-bugs-list] [ python-Bugs-580495 ] mimetools module privacy leak
Message-ID: <E17cGaP-0007Py-00@usw-sf-web2.sourceforge.net>

Bugs item #580495, was opened at 2002-07-12 09:35
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=580495&group_id=5470

Category: Python Library
Group: None
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: mimetools module privacy leak

Initial Comment:
The mimetools "choose_boundary" function according to
its doc
returns a string of the form
'hostipaddr.uid.pid.timestamp.random'.
If this separator is actually used in a message, it
reveals the host ID
and UID of the sender.  This is a privacy breach
similar to the discovery
that Microsoft Word files contained user GUID's
revealing the user's
PC's ethernet card's MAC address (since fixed, after
the story was
published on the front page of the New York Times about
2 years ago).
Some info is at

  http://www.junkbusters.com/microsoft.html#advisory


The fix for choose_boundary is to make the boundary
string completely
random and not have it reveal personal information
about the user.


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

>Comment By: paul rubin (phr)
Date: 2002-08-07 02:30

Message:
Logged In: YES 
user_id=72053

On the occasions where the leak matters, the consequences
can be serious.

Think of an AOL user with a screen name that she uses for
work-related email, and a
separate screen name she uses to post to a mail list for
sufferers of sexually transmitted diseases.
If she sends a file attachment to a co-worker from the work
screen name, and a different attachment
to the STD list from the personal screen name, and her mail
client uses mimetools.py, a co-worker looking at the STD
mailing list's web archive can see that both attachments
came from the same person.

Former US Navy Senior Chief Petty Officer Tim McVeigh (not
related to the OKC bomber with the
same name) had his Navy career destroyed over something sort
of like this (he had an anonymous AOL profile revealing that
he was gay, and the Navy connected it to him).  Although
McVeigh stayed out of jail because a Federal judge ruled
that the Navy had violated the DoD "don't ask, don't tell,
don't pursue" policy by contacting AOL to find his identity,
if he had used mimetools.py to send file attachments like
the hypothetical person above, the Navy might have gotten
the two MIME separators without having to specially contact
anyone, and so McVeigh could possibly be in the slammer now.

Anyway, if mimetools.py is deprecated, the manual should be
updated to say so.  It wouldn't have occurred to me to not
use it if I wanted to send a MIME message.  The docs should
also mention this privacy leak.  But I think it's better to
just fix it.

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

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2002-08-06 16:22

Message:
Logged In: YES 
user_id=12800

Is this a serious concern for most applications?  In most
email messages, some identifying information will always
leak so since it takes work to anonymize messages anyway, an
application with these concerns can simply implement its own
choose_boundary() algorithm, or lop off the hostid part of
the generated one.

Besides, mimetools.py should be considered obsolete, in
favor of the email package.  When it generates a boundary it
doesn't include any identifying information (but has a
moderately higher possibility of collision in the source text).

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

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


From noreply@sourceforge.net  Wed Aug  7 06:01:21 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 06 Aug 2002 22:01:21 -0700
Subject: [Python-bugs-list] [ python-Bugs-581165 ] smtplib.SMTP.ehlo method esmtp_features
Message-ID: <E17cIwj-0000dn-00@usw-sf-web2.sourceforge.net>

Bugs item #581165, was opened at 2002-07-14 09:46
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=581165&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Piers Lauder (pierslauder)
Assigned to: Nobody/Anonymous (nobody)
Summary: smtplib.SMTP.ehlo method esmtp_features 

Initial Comment:
The ehlo() method in the smtplib class SMTP appears to
incorrectly
handle the response from Eudora Internet Mail Server
3.1.3 .

The rsponse to the "EHLO" command is:

send: 'ehlo gemini.cs.usyd.edu.au\r\n'
reply: '250-webfactory.com.au hello
gemini.cs.usyd.edu.au (129.78.111.139)\r\n'
reply: '250-EXPN\r\n'
reply: '250-PIPELINING\r\n'
reply: '250-8BITMIME\r\n'
reply: '250-BINARYMIME\r\n'
reply: '250-CHUNKING\r\n'
reply: '250-ENHANCEDSTATUSCODES\r\n'
reply: '250-ETRN\r\n'
reply: '250-AUTH CRAM-MD5 NTLM PLAIN LOGIN\r\n'
reply: '250-AUTH=LOGIN\r\n'
reply: '250 SIZE 2147483647\r\n'

which is then gathered into:

 ['webfactory.com.au hello gemini.cs.usyd.edu.au
(129.78.111.139)', 'EXPN', 'PIPELINING', '8BITMIME',
'BINARYMIME', 'CHUNKING', 'ENHANCEDSTATUSCODES',
'ETRN', 'AUTH CRAM-MD5 NTLM PLAIN LOGIN', 'AUTH=LOGIN',
'SIZE 2147483647']

which is then parsed into "self.esmtp_features as:

 {'enhancedstatuscodes': '', '8bitmime': '', 'expn':
'', 'chunking': '', 'etrn': '', 'pipelining': '',
'size': '2147483647', 'auth': '=LOGIN', 'binarymime': ''}

Note that the two lines starting "AUTH" have been
elided into the
one dictionary element 'auth':'=LOGIN'.

This prevents a subsequent call to the login() method
from correctly
identifying a suitable authentication method resulting in:

    raise SMTPException("No suitable authentication
method found.")



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

>Comment By: Piers Lauder (pierslauder)
Date: 2002-08-07 15:01

Message:
Logged In: YES 
user_id=196212

I tried the second patch. It got the same problem with "AUTH 
CRAM-MD5" ("Syntax Error, not using <cr><lf> as end of 
line.") but then I tried forcing "AUTH LOGIN" (which I think is 
what your change applied to?) and that worked. Thanks!

So, I think the <cr><lf> problem is a bug on this particular 
smtp server, and I'm now happy because I can send mail to it 
using AUTH LOGIN (and the AUTH=LOGIN feature no longer 
causes a problem for smtplib.py)

The question is - should CRAM-MD5 be the preferred 
method?

I think the answer is yes as it is more secure, but perhaps a 
note could be installed somewhere to use LOGIN 
authentication if the <cr><lf> error occurs.

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

Comment By: Gerhard Häring (ghaering)
Date: 2002-08-06 16:56

Message:
Logged In: YES 
user_id=163326

Piers, could you please try my patch again? It contained a
very stupid bug (sent the username twice, but no password).
This seems unrelated to the error message your SMTP server
sent, but maybe it's worth a try.

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

Comment By: Piers Lauder (pierslauder)
Date: 2002-07-24 21:26

Message:
Logged In: YES 
user_id=196212

I tried the patch.

It gets me further - I now get "Syntax Error, not using
<cr><lf> as end of line."

Here's the trace:

resp: ['webfactory.com.au hello gemini.cs.usyd.edu.au
(129.78.111.139)', 'EXPN', 'PIPELINING', '8BITMIME',
'BINARYMIME', 'CHUNKING', 'ENHANCEDSTATUSCODES', 'ETRN',
'AUTH CRAM-MD5 NTLM PLAIN LOGIN', 'AUTH=LOGIN', 'SIZE
2147483647']
features: {'auth=login': '', 'enhancedstatuscodes': '',
'8bitmime': '', 'expn': '', 'chunking': '', 'etrn': '',
'pipelining': '', 'size': '2147483647', 'auth': 'CRAM-MD5
NTLM PLAIN LOGIN', 'binarymime': ''}
send: 'AUTH CRAM-MD5\r\n'
reply: '334
PDExODQ1NzY3NTctNjk3MjgzMDhAd2ViZmFjdG9yeS5jb20uYXU+\r\n'
reply: retcode (334); Msg:
PDExODQ1NzY3NTctNjk3MjgzMDhAd2ViZmFjdG9yeS5jb20uYXU+
send:
'cGllcnMlY29tbXVuaXR5c29sdXRpb25zLmNvbS5hdSAzOTU2NzVmYWUwZGUxZmQyN2I3MTRjNGQ5\nYzgzOWIwNQ==\r\n'
reply: '500 Syntax error, not using <cr><lf> as end of line\r\n'
reply: retcode (500); Msg: Syntax error, not using <cr><lf>
as end of line


Which doesn't make any sense, and is probably a server
problem, since I can see that each line sent _is_ terminated
with <cr><lf>.

So I consider the patch a (qualified) success.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-07-24 08:00

Message:
Logged In: YES 
user_id=21627

Can you please try the patch in

http://sourceforge.net/tracker/index.php?
func=detail&aid=572031&group_id=5470&atid=305470

and report whether it solves this problem?

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

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


From noreply@sourceforge.net  Wed Aug  7 06:14:19 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 06 Aug 2002 22:14:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-591349 ] httplib sporadically throws a TypeError
Message-ID: <E17cJ9H-0000o7-00@usw-sf-web2.sourceforge.net>

Bugs item #591349, was opened at 2002-08-05 19:42
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=591349&group_id=5470

Category: Python Library
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Rob Green (rbgrn)
Assigned to: Jeremy Hylton (jhylton)
Summary: httplib sporadically throws a TypeError

Initial Comment:
This is the output that occurs about 1 in 500 hits to any 
particular URL. I've only seen it so far hitting servers 
running Apache 1.3.20, but I don't have enough data to 
limit it to that.

Python 2.1.2 (#1, Mar 16 2002, 18:24:08)
[GCC 2.95.3 [FreeBSD] 20010315 (release)] on freebsd4

h = httplib.HTTPConnection(host)
response = h.getresponse()
data = response.read()
File "/usr/local/lib/python2.1/httplib.py", line 246, in read
value = value + self._safe_read(chunk_left)
File "/usr/local/lib/python2.1/httplib.py", line 314, in 
_safe_read
chunk = self.fp.read(amt)
TypeError: an integer is required



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

>Comment By: Rob Green (rbgrn)
Date: 2002-08-07 00:14

Message:
Logged In: YES 
user_id=590105

I'd give you the URLs but I don't think it matters that much, 
I've seen this problem now hitting 4 different machines, all 
running linux/apache. It's not something very easy for me to 
reproduce because I only see the exception thrown once or 
maybe twice during the day where there are 20,000 hits from 
my daemon that day. I suppose that the way to reproduce it 
would be to have a list of urls, and to just have an app sit 
there and cycle through them doing a GET every 5 seconds 
or so, and eventually it should show up. I suppose to be more 
accurate the app would have to be threaded as well, maybe 
having a thread for each url that just opens an 
HTTPConnection every 5 seconds.

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

Comment By: Jeremy Hylton (jhylton)
Date: 2002-08-06 07:42

Message:
Logged In: YES 
user_id=31392

Can you provide any more information about what URLs cause
problems?  You could call set_debuglevel(1) to enable output
of all  HTTP trafffic.  Or just a list of some of the URLs
that failed.


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

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


From noreply@sourceforge.net  Wed Aug  7 07:16:49 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 06 Aug 2002 23:16:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-591349 ] httplib sporadically throws a TypeError
Message-ID: <E17cK7l-0003US-00@usw-sf-web4.sourceforge.net>

Bugs item #591349, was opened at 2002-08-05 19:42
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=591349&group_id=5470

Category: Python Library
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Rob Green (rbgrn)
Assigned to: Jeremy Hylton (jhylton)
Summary: httplib sporadically throws a TypeError

Initial Comment:
This is the output that occurs about 1 in 500 hits to any 
particular URL. I've only seen it so far hitting servers 
running Apache 1.3.20, but I don't have enough data to 
limit it to that.

Python 2.1.2 (#1, Mar 16 2002, 18:24:08)
[GCC 2.95.3 [FreeBSD] 20010315 (release)] on freebsd4

h = httplib.HTTPConnection(host)
response = h.getresponse()
data = response.read()
File "/usr/local/lib/python2.1/httplib.py", line 246, in read
value = value + self._safe_read(chunk_left)
File "/usr/local/lib/python2.1/httplib.py", line 314, in 
_safe_read
chunk = self.fp.read(amt)
TypeError: an integer is required



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

>Comment By: Rob Green (rbgrn)
Date: 2002-08-07 01:16

Message:
Logged In: YES 
user_id=590105

Ok I put together some test code that reproduced the bug in 
under an hour on my machine. Here it is...

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

Comment By: Rob Green (rbgrn)
Date: 2002-08-07 00:14

Message:
Logged In: YES 
user_id=590105

I'd give you the URLs but I don't think it matters that much, 
I've seen this problem now hitting 4 different machines, all 
running linux/apache. It's not something very easy for me to 
reproduce because I only see the exception thrown once or 
maybe twice during the day where there are 20,000 hits from 
my daemon that day. I suppose that the way to reproduce it 
would be to have a list of urls, and to just have an app sit 
there and cycle through them doing a GET every 5 seconds 
or so, and eventually it should show up. I suppose to be more 
accurate the app would have to be threaded as well, maybe 
having a thread for each url that just opens an 
HTTPConnection every 5 seconds.

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

Comment By: Jeremy Hylton (jhylton)
Date: 2002-08-06 07:42

Message:
Logged In: YES 
user_id=31392

Can you provide any more information about what URLs cause
problems?  You could call set_debuglevel(1) to enable output
of all  HTTP trafffic.  Or just a list of some of the URLs
that failed.


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

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


From noreply@sourceforge.net  Wed Aug  7 09:36:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 07 Aug 2002 01:36:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-591704 ] generators can't be weakly referenced
Message-ID: <E17cMJC-0008E3-00@usw-sf-web3.sourceforge.net>

Bugs item #591704, was opened at 2002-08-06 19:10
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=591704&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: H. Richard Harkins (hrharkins)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: generators can't be weakly referenced

Initial Comment:
I can't seem to weakly reference generators.  I can't
think of a good reason that this shouldn't work.  Here
is a code snippet to demonstrate the issue:

>>> from __future__ import generators
>>> import weakref
>>> def f():
...   yield "HELLO"
...
>>> weakref.proxy(f())
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: cannot create weak reference to 'generator'
object
>>>



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

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


From noreply@sourceforge.net  Wed Aug  7 09:49:40 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 07 Aug 2002 01:49:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-591943 ] --without-unicode hosed
Message-ID: <E17cMVg-0003nI-00@usw-sf-web1.sourceforge.net>

Bugs item #591943, was opened at 2002-08-07 08:49
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=591943&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 6
Submitted By: Michael Hudson (mwh)
Assigned to: Martin v. Löwis (loewis)
Summary: --without-unicode hosed

Initial Comment:
I would imagine this is the PEP 263 work:

$ make
gcc  -Xlinker -export-dynamic -o python \
                Modules/python.o \
                libpython2.3.a -lrt -ldl  -lpthread -lutil   -lm  
libpython2.3.a(posixmodule.o): In function `posix_tmpnam':
/home/mwh/src/python/dist/src/build-nou-debug/../Modules/posixmodule.c:5224: the use of `tmpnam_r' is dangerous, better use `mkstemp'
libpython2.3.a(posixmodule.o): In function `posix_tempnam':
/home/mwh/src/python/dist/src/build-nou-debug/../Modules/posixmodule.c:5174: the use of `tempnam' is dangerous, better use `mkstemp'
libpython2.3.a(tokenizer.o): In function `fp_readl':
/home/mwh/src/python/dist/src/build-nou-debug/../Parser/tokenizer.c:329: undefined reference to `PyUnicode_AsUTF8String'
libpython2.3.a(tokenizer.o): In function `translate_into_utf8':
/home/mwh/src/python/dist/src/build-nou-debug/../Parser/tokenizer.c:493: undefined reference to `PyUnicode_Decode'
/home/mwh/src/python/dist/src/build-nou-debug/../Parser/tokenizer.c:496: undefined reference to `PyUnicode_AsUTF8String'
libpython2.3.a(compile.o): In function `decode_utf8':
/home/mwh/src/python/dist/src/build-nou-debug/../Python/compile.c:1194: undefined reference to `PyUnicode_DecodeUTF8'
/home/mwh/src/python/dist/src/build-nou-debug/../Python/compile.c:1197: undefined reference to `PyUnicode_AsEncodedString'
libpython2.3.a(compile.o): In function `parsestr':
/home/mwh/src/python/dist/src/build-nou-debug/../Python/compile.c:1315: undefined reference to `PyUnicode_DecodeUTF8'
/home/mwh/src/python/dist/src/build-nou-debug/../Python/compile.c:1318: undefined reference to `PyUnicode_AsEncodedString'
collect2: ld returned 1 exit status
make: *** [python] Error 1

If it's not, assign back to me and I'll dig.


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

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


From noreply@sourceforge.net  Wed Aug  7 13:35:01 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 07 Aug 2002 05:35:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-591943 ] --without-unicode hosed
Message-ID: <E17cQ1l-0002fB-00@usw-sf-web4.sourceforge.net>

Bugs item #591943, was opened at 2002-08-07 10:49
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=591943&group_id=5470

Category: Build
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 6
Submitted By: Michael Hudson (mwh)
Assigned to: Martin v. Löwis (loewis)
Summary: --without-unicode hosed

Initial Comment:
I would imagine this is the PEP 263 work:

$ make
gcc  -Xlinker -export-dynamic -o python \
                Modules/python.o \
                libpython2.3.a -lrt -ldl  -lpthread -lutil   -lm  
libpython2.3.a(posixmodule.o): In function `posix_tmpnam':
/home/mwh/src/python/dist/src/build-nou-debug/../Modules/posixmodule.c:5224: the use of `tmpnam_r' is dangerous, better use `mkstemp'
libpython2.3.a(posixmodule.o): In function `posix_tempnam':
/home/mwh/src/python/dist/src/build-nou-debug/../Modules/posixmodule.c:5174: the use of `tempnam' is dangerous, better use `mkstemp'
libpython2.3.a(tokenizer.o): In function `fp_readl':
/home/mwh/src/python/dist/src/build-nou-debug/../Parser/tokenizer.c:329: undefined reference to `PyUnicode_AsUTF8String'
libpython2.3.a(tokenizer.o): In function `translate_into_utf8':
/home/mwh/src/python/dist/src/build-nou-debug/../Parser/tokenizer.c:493: undefined reference to `PyUnicode_Decode'
/home/mwh/src/python/dist/src/build-nou-debug/../Parser/tokenizer.c:496: undefined reference to `PyUnicode_AsUTF8String'
libpython2.3.a(compile.o): In function `decode_utf8':
/home/mwh/src/python/dist/src/build-nou-debug/../Python/compile.c:1194: undefined reference to `PyUnicode_DecodeUTF8'
/home/mwh/src/python/dist/src/build-nou-debug/../Python/compile.c:1197: undefined reference to `PyUnicode_AsEncodedString'
libpython2.3.a(compile.o): In function `parsestr':
/home/mwh/src/python/dist/src/build-nou-debug/../Python/compile.c:1315: undefined reference to `PyUnicode_DecodeUTF8'
/home/mwh/src/python/dist/src/build-nou-debug/../Python/compile.c:1318: undefined reference to `PyUnicode_AsEncodedString'
collect2: ld returned 1 exit status
make: *** [python] Error 1

If it's not, assign back to me and I'll dig.


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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-08-07 14:35

Message:
Logged In: YES 
user_id=21627

Fixed in tokenizer.c 2.62 and compile.c 2.251.

An open issue is what to do with Unicode literals that have
non-ASCII in a --without-unicode build. Currently, they are
silently converted to byte strings with the same bytes that
they had in the source code.

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

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


From noreply@sourceforge.net  Wed Aug  7 14:14:13 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 07 Aug 2002 06:14:13 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-592047 ] Add syntax coloring to Mac IDE
Message-ID: <E17cQdh-0002EW-00@usw-sf-web1.sourceforge.net>

Feature Requests item #592047, was opened at 2002-08-07 08:14
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=592047&group_id=5470

Category: IDLE
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dan Grassi (dgrassi)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add syntax coloring to Mac IDE

Initial Comment:
I suggest including syntax coloring (AdvancedEditor.py) into the Mac IDE.  Syntax coloring is now expected and it can be disabled easily.  I would be willing to do the work.

Also the default font need to change or be installed.  Not all fonts handle bold-ing and with the default missing a font that does not work ends up as default.

Dan

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

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


From noreply@sourceforge.net  Wed Aug  7 14:58:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 07 Aug 2002 06:58:03 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-592047 ] Add syntax coloring to Mac IDE
Message-ID: <E17cRK7-0007Fs-00@usw-sf-web5.sourceforge.net>

Feature Requests item #592047, was opened at 2002-08-07 15:14
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=592047&group_id=5470

>Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dan Grassi (dgrassi)
>Assigned to: Just van Rossum (jvr)
Summary: Add syntax coloring to Mac IDE

Initial Comment:
I suggest including syntax coloring (AdvancedEditor.py) into the Mac IDE.  Syntax coloring is now expected and it can be disabled easily.  I would be willing to do the work.

Also the default font need to change or be installed.  Not all fonts handle bold-ing and with the default missing a font that does not work ends up as default.

Dan

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

>Comment By: Jack Jansen (jackjansen)
Date: 2002-08-07 15:58

Message:
Logged In: YES 
user_id=45365

This is a request for the Mac IDE, not for tkinter-based IDLE. Also, assigning it to Just.

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

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


From noreply@sourceforge.net  Wed Aug  7 16:00:28 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 07 Aug 2002 08:00:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-584695 ] no doc for os.fsync and os.fdatasync
Message-ID: <E17cSIW-000673-00@usw-sf-web4.sourceforge.net>

Bugs item #584695, was opened at 2002-07-21 20:26
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=584695&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: no doc for os.fsync and os.fdatasync

Initial Comment:
These are actually in the posix module.  I needed to
use fsync or fdatasync to synchronize a database and
they weren't in the manual.  I was about to enter a
feature request to add these calls to the os module but
it turns out they are already there, just undocumented.
 The docs should list them.  There are probably other
calls in dir(os) that aren't in the docs, so they
should be documented too.

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-08-07 10:00

Message:
Logged In: YES 
user_id=80475

Documentation patch attach attached for Fred's approval.

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

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


From noreply@sourceforge.net  Wed Aug  7 16:17:55 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 07 Aug 2002 08:17:55 -0700
Subject: [Python-bugs-list] [ python-Bugs-500704 ] Tutorial does not describe nested scope
Message-ID: <E17cSZP-0006Xd-00@usw-sf-web4.sourceforge.net>

Bugs item #500704, was opened at 2002-01-07 22:27
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=500704&group_id=5470

Category: Documentation
Group: Python 2.2
Status: Open
>Resolution: Accepted
Priority: 7
Submitted By: Pierre Rouleau (pierre_rouleau)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: Tutorial does not describe nested scope

Initial Comment:
The current copy of the tuturial for Python 2.2 states, in chapter 9.2
(Python Scopes and Name Spaces):

"""Although scopes are determined statically, they are used dynamically.
At any time during execution, exactly three nested scopes are in use
(exactly three namespaces are directly accessible): the innermost scope,
which is searched first, contains the local names, the middle scope,
searched next, contains the current module's global names, and the
outermost scope (searched last) is the namespace containing built-in
names."""

I believe the above text should be updated to reflect the fact that Python 2.2 supports nested 
scopes.

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-08-07 11:17

Message:
Logged In: YES 
user_id=3066

It's probably worth noting that variables found in outer
non-scopes are read-only:

def outer():
    var = 1
    def inner():
        var = 2
    inner()
    print var

prints 1, not 2.

If you can add a note about that, you should be all set to
check in; no need for further review since I'll see the
checkin msg.

Thanks!

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-08-05 11:33

Message:
Logged In: YES 
user_id=80475

Patch attached for Fred's approval. If okay, re-assign to 
me and I'll make the same change to the trunk.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-03-13 01:03

Message:
Logged In: YES 
user_id=3066

Bumped priority since this can cause real confusion for
someone learning Python.  The corrections need to be part of
Python 2.2.1 and the trunk.

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

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


From noreply@sourceforge.net  Wed Aug  7 16:23:44 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 07 Aug 2002 08:23:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-584695 ] no doc for os.fsync and os.fdatasync
Message-ID: <E17cSf2-0006fo-00@usw-sf-web4.sourceforge.net>

Bugs item #584695, was opened at 2002-07-21 21:26
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=584695&group_id=5470

Category: Documentation
Group: None
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: paul rubin (phr)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: no doc for os.fsync and os.fdatasync

Initial Comment:
These are actually in the posix module.  I needed to
use fsync or fdatasync to synchronize a database and
they weren't in the manual.  I was about to enter a
feature request to add these calls to the os module but
it turns out they are already there, just undocumented.
 The docs should list them.  There are probably other
calls in dir(os) that aren't in the docs, so they
should be documented too.

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-08-07 11:23

Message:
Logged In: YES 
user_id=3066

Both of the descriptions need \end{funcdesc} at the end. 
Fix that and check it in!

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-08-07 11:00

Message:
Logged In: YES 
user_id=80475

Documentation patch attach attached for Fred's approval.

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

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


From noreply@sourceforge.net  Wed Aug  7 16:28:06 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 07 Aug 2002 08:28:06 -0700
Subject: [Python-bugs-list] [ python-Bugs-586931 ] pydoc -w fails with path specified
Message-ID: <E17cSjG-0000nM-00@usw-sf-web3.sourceforge.net>

Bugs item #586931, was opened at 2002-07-26 06:31
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=586931&group_id=5470

>Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
>Assigned to: Tim Peters (tim_one)
Summary: pydoc -w fails with path specified

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

If I specify a path (ie, ./dictclient.py) and use -w, it will 
fail.  If -w
is not used, or a module (ie, dictclient) is specified, it 
will work. 
Example:

$ pydoc2.2 -w ./dictclient.py
Traceback (most recent call last):
  File "/usr/bin/pydoc2.2", line 4, in ?
    pydoc.cli()
  File "/usr/lib/python2.2/pydoc.py", line 2074, in cli
    writedoc(arg)
  File "/usr/lib/python2.2/pydoc.py", line 1345, in writedoc
    object = locate(key, forceload)
  File "/usr/lib/python2.2/pydoc.py", line 1297, in locate
    parts = split(path, '.')
  File "/usr/lib/python2.2/string.py", line 117, in split
    return s.split(sep, maxsplit)
AttributeError: 'module' object has no attribute 'split'


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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-08-07 11:28

Message:
Logged In: YES 
user_id=3066

Tim is friends with pydoc.  ;-)

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

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


From noreply@sourceforge.net  Wed Aug  7 16:31:47 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 07 Aug 2002 08:31:47 -0700
Subject: [Python-bugs-list] [ python-Bugs-592112 ] Hint for speeding up cPickle
Message-ID: <E17cSmp-0006r2-00@usw-sf-web4.sourceforge.net>

Bugs item #592112, was opened at 2002-08-07 15:31
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592112&group_id=5470

Category: Python Library
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Jiba (jiba)
Assigned to: Nobody/Anonymous (nobody)
Summary: Hint for speeding up cPickle

Initial Comment:
There is a strange behaviour in cPickle (in Python 2.2.1).
For big serialized file, the following:

        cPickle.loads(open("my_file").read())

can be much (e.g. 7 times) faster than:

        cPickle.load(open("my_file"))

It seems that cPickle use unbuffered reading or what ?
The pickle implementation doesn't have this behaviour,
and can even be
faster than the C one!

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

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


From noreply@sourceforge.net  Wed Aug  7 16:39:44 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 07 Aug 2002 08:39:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-586583 ] Two corrects for weakref docs
Message-ID: <E17cSuW-00011F-00@usw-sf-web3.sourceforge.net>

Bugs item #586583, was opened at 2002-07-25 11:59
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=586583&group_id=5470

Category: Documentation
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Stephan R.A. Deibel (sdeibel)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Two corrects for weakref docs

Initial Comment:
The Python manual (I'm looking at 2.2.1, but I think
it's true since 2.1) omits one detail for creating weak
references on extension types:

It fails to indicate that the tp_flags field of the
PyTypeObject has to
have Py_TPFLAGS_HAVE_WEAKREFS added into it as well. 
Without this, it doesn't work.

So the second code block would read as follows:

PyTypeObject PyInstance_Type = {
    PyObject_HEAD_INIT(&PyType_Type)
    0,   
    "module.instance",

    /* Lots of stuff omitted for brevity... */

    Py_TPFLAGS_HAVE_WEAKREFS, /* tp_flags */
    NULL, /*doc*/
    0L,0L,0L,
    offsetof(PyInstanceObject, in_weakreflist) /*
tp_weaklistoffset */
  
    /* Possibly more stuff here... */
};
  
----------------------
 
You may also want to emphasize that the in_weakreflist
field that is added should be initialized in the object
constructor.  Since you show the code in
instance_dealloc(), it might make sense to show the
allocation function too, with the code that sets the
in_weakreflist field to NULL.

Yea, I know this should be obvious and it is mentioned
in the first
paragraph, but somehow I got confused into thinking it
would be initialize for me because there wasn't a
seperate code example.

Here is another code block that could be shown before
the instance_dealloc block, to make this clear for
dummies like me:

static PyObject *
instance_new() {

  /* Code removed for brevity */

  self = (PyInstance_Object
*)PyObject_NEW(PyInstance_Object,
                                          
&PyInstance_Type);
  if (self == NULL)
    return NULL;
  
  /* More code removed for brevity */
  
  self->in_weakreflist = NULL;

  return (PyObject *) self;
}

Hope that helps...

- Stephan

------------------------------------------------------------------------
 
Wing IDE for Python                         
Archaeopteryx Software, Inc
www.wingide.com                              Take Flight!



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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-08-07 10:39

Message:
Logged In: YES 
user_id=80475

Documentation patch attached for Fred's approval for 
both 2.2 and 2.3.

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

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


From noreply@sourceforge.net  Wed Aug  7 16:41:58 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 07 Aug 2002 08:41:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-579991 ] LibRef 2.2.1, replace zero with False
Message-ID: <E17cSwg-00078a-00@usw-sf-web4.sourceforge.net>

Bugs item #579991, was opened at 2002-07-11 03:52
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=579991&group_id=5470

Category: Documentation
Group: Python 2.3
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Yitz Gale (yitzg)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: LibRef 2.2.1, replace zero with False

Initial Comment:
In Library Refernce, 2.2.1 Truth Value Testing:

In current text "...when that method returns zero." and
the associated footnote, the word "zero" should be
replaced with "a false value".


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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-08-07 11:41

Message:
Logged In: YES 
user_id=3066

Checked in as Doc/lib/libstdtypes.tex revisions 1.104,
1.80.6.11.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-08-06 17:51

Message:
Logged In: YES 
user_id=3066

I'll add a clarification that returning an integer includes
returns a boolean.  The True and False values are integers
in 2.2.1 and instances of bool in 2.3, but bool is a
subclass of the integer type, so returning False from
__nonzero__ really is returning an integer.

I'll check this into CVS once SourceForge clears a stale
lock; leaving it open until then so I don't forget.

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

Comment By: Yitz Gale (yitzg)
Date: 2002-07-13 19:02

Message:
Logged In: YES 
user_id=576391

Hmm - in that case, there is also a bug in Ref. Guide 3.3.1
which says
that __nonzero__() is allowed to return boolean. But that would
be really quirky, are you sure boolean is not allowed?

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-07-12 13:16

Message:
Logged In: YES 
user_id=3066

Clarified in Doc/lib/libstdtypes.tex revisions 1.99 and
1.80.6.10.
__nonzero__() *must* return an integer.

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

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


From noreply@sourceforge.net  Wed Aug  7 16:52:49 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 07 Aug 2002 08:52:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-586583 ] Two corrects for weakref docs
Message-ID: <E17cT7B-0007OG-00@usw-sf-web4.sourceforge.net>

Bugs item #586583, was opened at 2002-07-25 12:59
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=586583&group_id=5470

Category: Documentation
Group: Python 2.2.1
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Stephan R.A. Deibel (sdeibel)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: Two corrects for weakref docs

Initial Comment:
The Python manual (I'm looking at 2.2.1, but I think
it's true since 2.1) omits one detail for creating weak
references on extension types:

It fails to indicate that the tp_flags field of the
PyTypeObject has to
have Py_TPFLAGS_HAVE_WEAKREFS added into it as well. 
Without this, it doesn't work.

So the second code block would read as follows:

PyTypeObject PyInstance_Type = {
    PyObject_HEAD_INIT(&PyType_Type)
    0,   
    "module.instance",

    /* Lots of stuff omitted for brevity... */

    Py_TPFLAGS_HAVE_WEAKREFS, /* tp_flags */
    NULL, /*doc*/
    0L,0L,0L,
    offsetof(PyInstanceObject, in_weakreflist) /*
tp_weaklistoffset */
  
    /* Possibly more stuff here... */
};
  
----------------------
 
You may also want to emphasize that the in_weakreflist
field that is added should be initialized in the object
constructor.  Since you show the code in
instance_dealloc(), it might make sense to show the
allocation function too, with the code that sets the
in_weakreflist field to NULL.

Yea, I know this should be obvious and it is mentioned
in the first
paragraph, but somehow I got confused into thinking it
would be initialize for me because there wasn't a
seperate code example.

Here is another code block that could be shown before
the instance_dealloc block, to make this clear for
dummies like me:

static PyObject *
instance_new() {

  /* Code removed for brevity */

  self = (PyInstance_Object
*)PyObject_NEW(PyInstance_Object,
                                          
&PyInstance_Type);
  if (self == NULL)
    return NULL;
  
  /* More code removed for brevity */
  
  self->in_weakreflist = NULL;

  return (PyObject *) self;
}

Hope that helps...

- Stephan

------------------------------------------------------------------------
 
Wing IDE for Python                         
Archaeopteryx Software, Inc
www.wingide.com                              Take Flight!



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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-08-07 11:52

Message:
Logged In: YES 
user_id=3066

Only one comment:  Py_TPFLAGS_HAVE_WEAKREFS should be marked
as \constant{Py_TPFLAGS_HAVE_WEAKREFS}.  Thanks!

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-08-07 11:39

Message:
Logged In: YES 
user_id=80475

Documentation patch attached for Fred's approval for 
both 2.2 and 2.3.

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

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


From noreply@sourceforge.net  Wed Aug  7 16:50:50 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 07 Aug 2002 08:50:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-584695 ] no doc for os.fsync and os.fdatasync
Message-ID: <E17cT5G-0001FA-00@usw-sf-web3.sourceforge.net>

Bugs item #584695, was opened at 2002-07-21 20:26
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=584695&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Raymond Hettinger (rhettinger)
Summary: no doc for os.fsync and os.fdatasync

Initial Comment:
These are actually in the posix module.  I needed to
use fsync or fdatasync to synchronize a database and
they weren't in the manual.  I was about to enter a
feature request to add these calls to the os module but
it turns out they are already there, just undocumented.
 The docs should list them.  There are probably other
calls in dir(os) that aren't in the docs, so they
should be documented too.

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-08-07 10:50

Message:
Logged In: YES 
user_id=80475

Added \end{funcdesc}.
Committed to libos.tex versions 1.94 and 1.74.2.1.2.6
Closing bug.


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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-08-07 10:23

Message:
Logged In: YES 
user_id=3066

Both of the descriptions need \end{funcdesc} at the end. 
Fix that and check it in!

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-08-07 10:00

Message:
Logged In: YES 
user_id=80475

Documentation patch attach attached for Fred's approval.

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

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


From noreply@sourceforge.net  Wed Aug  7 17:10:22 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 07 Aug 2002 09:10:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-500704 ] Tutorial does not describe nested scope
Message-ID: <E17cTOA-0007k5-00@usw-sf-web1.sourceforge.net>

Bugs item #500704, was opened at 2002-01-07 22:27
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=500704&group_id=5470

Category: Documentation
Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Pierre Rouleau (pierre_rouleau)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Tutorial does not describe nested scope

Initial Comment:
The current copy of the tuturial for Python 2.2 states, in chapter 9.2
(Python Scopes and Name Spaces):

"""Although scopes are determined statically, they are used dynamically.
At any time during execution, exactly three nested scopes are in use
(exactly three namespaces are directly accessible): the innermost scope,
which is searched first, contains the local names, the middle scope,
searched next, contains the current module's global names, and the
outermost scope (searched last) is the namespace containing built-in
names."""

I believe the above text should be updated to reflect the fact that Python 2.2 supports nested 
scopes.

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-08-07 11:10

Message:
Logged In: YES 
user_id=80475

Added note about read-only variables.
Commited as tut.tex versions 1.167 and 1.156.4.1.2.7
Marking as fixed and closing bug.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-08-07 10:17

Message:
Logged In: YES 
user_id=3066

It's probably worth noting that variables found in outer
non-scopes are read-only:

def outer():
    var = 1
    def inner():
        var = 2
    inner()
    print var

prints 1, not 2.

If you can add a note about that, you should be all set to
check in; no need for further review since I'll see the
checkin msg.

Thanks!

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-08-05 10:33

Message:
Logged In: YES 
user_id=80475

Patch attached for Fred's approval. If okay, re-assign to 
me and I'll make the same change to the trunk.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-03-13 01:03

Message:
Logged In: YES 
user_id=3066

Bumped priority since this can cause real confusion for
someone learning Python.  The corrections need to be part of
Python 2.2.1 and the trunk.

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

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


From noreply@sourceforge.net  Wed Aug  7 17:22:28 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 07 Aug 2002 09:22:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-586583 ] Two corrects for weakref docs
Message-ID: <E17cTZs-0001y4-00@usw-sf-web3.sourceforge.net>

Bugs item #586583, was opened at 2002-07-25 11:59
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=586583&group_id=5470

Category: Documentation
Group: Python 2.2.1
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Stephan R.A. Deibel (sdeibel)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Two corrects for weakref docs

Initial Comment:
The Python manual (I'm looking at 2.2.1, but I think
it's true since 2.1) omits one detail for creating weak
references on extension types:

It fails to indicate that the tp_flags field of the
PyTypeObject has to
have Py_TPFLAGS_HAVE_WEAKREFS added into it as well. 
Without this, it doesn't work.

So the second code block would read as follows:

PyTypeObject PyInstance_Type = {
    PyObject_HEAD_INIT(&PyType_Type)
    0,   
    "module.instance",

    /* Lots of stuff omitted for brevity... */

    Py_TPFLAGS_HAVE_WEAKREFS, /* tp_flags */
    NULL, /*doc*/
    0L,0L,0L,
    offsetof(PyInstanceObject, in_weakreflist) /*
tp_weaklistoffset */
  
    /* Possibly more stuff here... */
};
  
----------------------
 
You may also want to emphasize that the in_weakreflist
field that is added should be initialized in the object
constructor.  Since you show the code in
instance_dealloc(), it might make sense to show the
allocation function too, with the code that sets the
in_weakreflist field to NULL.

Yea, I know this should be obvious and it is mentioned
in the first
paragraph, but somehow I got confused into thinking it
would be initialize for me because there wasn't a
seperate code example.

Here is another code block that could be shown before
the instance_dealloc block, to make this clear for
dummies like me:

static PyObject *
instance_new() {

  /* Code removed for brevity */

  self = (PyInstance_Object
*)PyObject_NEW(PyInstance_Object,
                                          
&PyInstance_Type);
  if (self == NULL)
    return NULL;
  
  /* More code removed for brevity */
  
  self->in_weakreflist = NULL;

  return (PyObject *) self;
}

Hope that helps...

- Stephan

------------------------------------------------------------------------
 
Wing IDE for Python                         
Archaeopteryx Software, Inc
www.wingide.com                              Take Flight!



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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-08-07 11:22

Message:
Logged In: YES 
user_id=80475

Added \constant{}.
Committed as libweakref.tex versions 1.18 and 1.17.6.1. 
Marking as fixed and closing bug.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-08-07 10:52

Message:
Logged In: YES 
user_id=3066

Only one comment:  Py_TPFLAGS_HAVE_WEAKREFS should be marked
as \constant{Py_TPFLAGS_HAVE_WEAKREFS}.  Thanks!

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-08-07 10:39

Message:
Logged In: YES 
user_id=80475

Documentation patch attached for Fred's approval for 
both 2.2 and 2.3.

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

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


From noreply@sourceforge.net  Wed Aug  7 17:39:45 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 07 Aug 2002 09:39:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-592161 ] installation errors
Message-ID: <E17cTqb-0002Nd-00@usw-sf-web3.sourceforge.net>

Bugs item #592161, was opened at 2002-08-07 11:39
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592161&group_id=5470

Category: Distutils
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Alicia C. Hopkins (aliciahopkins)
Assigned to: Nobody/Anonymous (nobody)
Summary: installation errors

Initial Comment:
with the use of
  python2 setup.py install, I get the following errors


 File "setup.py", line 30, in ?
    packages = ['distutils', 'distutils.command'],
  File "distutils/core.py", line 101, in setup
    _setup_distribution = dist = klass(attrs)
  File "distutils/dist.py", line 130, in __init__
    setattr(self, method_name, getattr(self.metadata, 
method_name))
AttributeError: DistributionMetadata instance has no 
attribute 'get___doc__'


HELP!

Alicia Hopkins

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

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


From noreply@sourceforge.net  Wed Aug  7 18:06:17 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 07 Aug 2002 10:06:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-449093 ] docs need to discuss // and __future__.division
Message-ID: <E17cUGH-0008LF-00@usw-sf-web4.sourceforge.net>

Bugs item #449093, was opened at 2001-08-08 07:39
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=449093&group_id=5470

Category: Documentation
Group: Python 2.2
Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: docs need to discuss // and __future__.division

Initial Comment:
The operator needs to get new interfaces added in
support of truediv and floordiv.

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-08-07 12:06

Message:
Logged In: YES 
user_id=80475

Can this be closed?

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-10 10:58

Message:
Logged In: YES 
user_id=3066

Added documentation for the operator.floordiv() and
operator.truediv() in Doc/lib/liboperator.tex revision 1.20.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-09 15:22

Message:
Logged In: YES 
user_id=3066

Added floordiv() and truediv() in Modules/operator.c
revision 2.18.  There's still plenty of documentation to be
written regarding the changes in division, so I'm
re-classifying this as a documentation request.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-08 07:40

Message:
Logged In: YES 
user_id=6380

Also a reminder for Fred to add more docs for this.

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

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


From noreply@sourceforge.net  Wed Aug  7 18:28:18 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 07 Aug 2002 10:28:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-556025 ] list(xrange(1e9))  -->  seg fault
Message-ID: <E17cUba-0003MM-00@usw-sf-web5.sourceforge.net>

Bugs item #556025, was opened at 2002-05-14 12:41
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=556025&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Neal Norwitz (nnorwitz)
Summary: list(xrange(1e9))  -->  seg fault

Initial Comment:
>From c.lang.py:

'''
 Python 2.2.1 (#2, Apr 21 2002, 22:22:55) 
[GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.62mdk)] 
on linux2
Type "help", "copyright", "credits" or "license" for 
more information.
>>> list(xrange(1e9))
Segmentation fault
'''

I've reproduced the same fault on Windows ME using 
Py2.2.0 and Py2.3a.

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

>Comment By: Steve Holden (holdenweb)
Date: 2002-08-07 13:28

Message:
Logged In: YES 
user_id=88157

I hope re-opening this is the right thing to do (I'm new here).

Current CVS fails under Win2000+Cygwin with a 
segmentation fault in the updated test_b1.py. Easily 
reproduced:

$ ./python.exe
Python 2.3a0 (#1, Aug  7 2002, 12:18:38)
[GCC 2.95.3-5 (cygwin special)] on cygwin
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import sys
>>> list(xrange(sys.maxint/4))
Segmentation fault (core dumped)

This does seem to be size-related, as:

>>> s = sys.maxint/8
>>> list(xrange(s))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
MemoryError

which is as expected in test_b1.py


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-22 19:20

Message:
Logged In: YES 
user_id=33168

Checked in as:
  listobject.c 2.106
  test_b1.py 1.46

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-21 08:59

Message:
Logged In: YES 
user_id=80475

Good plan!  Thx for squashing this bug. 

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-21 08:52

Message:
Logged In: YES 
user_id=33168

How about using sys.maxint / 4?  Does that make more sense
than 1e9?  This assumption is a little better, that the data
and address sizes are the same.  I can add a comment to this
effect.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-20 23:37

Message:
Logged In: YES 
user_id=80475

When you load the fix, please commit the regression test 
patch also.  Thx,  Raymond

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

Comment By: Tim Peters (tim_one)
Date: 2002-05-20 22:51

Message:
Logged In: YES 
user_id=31435

Yup, lookin' better.  Python does assume 8-bit bytes in 
several places, and also 2's-complement integers.  Since 
size_t is guaranteed (by C) to be an unsigned type, the 
largest value of type size_t is more easily expressed as

(~(size_t)0)

The C part of the patch looks fine then.  The test is a 
little dubious:  who says the machine can't create a 
billion-integer list?  The idea that 1e9 necessarily 
overflows in this context is a 32-bit address-space 
assumption.  But I'm willing to delay fixing that until a 
machine with a usable larger address space appears <wink>.

So marked Accepted and assigned to you for checkin.  Thanks!

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-20 11:43

Message:
Logged In: YES 
user_id=33168

Ok, there were other problems, too:
  * Need to divide by the size of the type, 
    not >> 4 which was completely broken.
  * There was a missing PyErr_NoMemory().

I uploaded a new patch.

I'm not sure the size_t fix is correct.
I hope we can at least assume 8-bit machines: :-)

if (_new_size <= ((1 << (sizeof(size_t)*8 - 1)) / sizeof(type)))



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

Comment By: Tim Peters (tim_one)
Date: 2002-05-20 00:48

Message:
Logged In: YES 
user_id=31435

The code patch has some problems:  you can't assume any 
relation between a size_t and an unsigned long; C simply 
doesn't define how big size_t is, and relative sizes do 
vary on 64-bit platforms.  However that gets fixed, if you 
decide it's "too big", var should be set to NULL (not 0 -- 
this is a "Guido thing" <wink>), and no exception should be 
set.  It's the caller's responsibility to check var for 
NULL after the macro is invoked, and set an appropriate 
exception.  listobject.c sometimes doesn't check the result 
for NULL, but that should only be when it knows it's 
*shrinking* a memory area, so that realloc can't fail.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-17 20:12

Message:
Logged In: YES 
user_id=80475

Added a patch to add this bug to the testbank.

Shallow code review:  Patch compiles okay (applied to 
Py2.3a0). Fixes the original problem.  Passes the smell 
test.  Macro style good (only the "var" operand is used 
more than once; no side-effects except setting "var" to 
zero upon a resize error).  Passes the standard regression 
tests.  Passes regression testing versus my personal (real 
code) testbank.

Will give it a deeper look this week-end.

One other thought: should the ValueError be replaced with a 
MemoryError to make the message consistent with PyList_New?



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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 17:03

Message:
Logged In: YES 
user_id=33168

Ok, this time I have a patch.  The patch only fixes listobject.

I looked over the other uses of PyMem_R{ESIZE,ALLOC}() and
they don't appear to be nearly as problematic as list.  For
example, if the grammar has 1e9 nodes, there are going to be
other problems well before then (ie, memory will probably be
gone).

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 16:25

Message:
Logged In: YES 
user_id=33168

Oops, sorry about that last comment.  That was something I
was playing with.  The CVS version is fine for [x]range(float).

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 16:22

Message:
Logged In: YES 
user_id=33168

Note, this problem is even more generic in CVS version:

>>> range(1.1)
Segmentation fault (core dumped)
>>> xrange(1.1)
Segmentation fault (core dumped)

[x]xrange(float) work fine in 2.2.1.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-14 20:44

Message:
Logged In: YES 
user_id=80475

Would there be some merit to converting PyMem_RESIZE to a 
function with an overflow check?  

I would guess that the time spent on a realloc dwarfs the 
overhead of a short wrapper function.

OTOH, I'll bet this core dump only occurs in toy examples 
and never in real code.



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

Comment By: Tim Peters (tim_one)
Date: 2002-05-14 18:15

Message:
Logged In: YES 
user_id=31435

Heh.  This is an instance of a general flaw:  the 
PyMem_RESIZE macro doesn't check for int overflow in its

    (n) * sizeof(type)

subexpression. The basic deal is that 1000000000 fits in an 
int, but 4 times that (silently) overflows.  In more 
detail, for this specific test case, listobject.c'.s 
roundupsize rounds 1e9 up to 0x40000000, which silently 
underflows to 0!() when PyMem_RESIZE multiplies it by 4.

Hard to know how to fix this in general; PyMem_RESIZE 
callers don't generally worry about overflow now.

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

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


From noreply@sourceforge.net  Wed Aug  7 19:20:38 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 07 Aug 2002 11:20:38 -0700
Subject: [Python-bugs-list] [ python-Bugs-556025 ] list(xrange(1e9))  -->  seg fault
Message-ID: <E17cVQE-00074H-00@usw-sf-web2.sourceforge.net>

Bugs item #556025, was opened at 2002-05-14 12:41
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=556025&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
>Assigned to: Tim Peters (tim_one)
Summary: list(xrange(1e9))  -->  seg fault

Initial Comment:
>From c.lang.py:

'''
 Python 2.2.1 (#2, Apr 21 2002, 22:22:55) 
[GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.62mdk)] 
on linux2
Type "help", "copyright", "credits" or "license" for 
more information.
>>> list(xrange(1e9))
Segmentation fault
'''

I've reproduced the same fault on Windows ME using 
Py2.2.0 and Py2.3a.

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-07 14:20

Message:
Logged In: YES 
user_id=33168

Hmmm, Tim can you reproduce this?  I luckily don't have a
windows box. :-)

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

Comment By: Steve Holden (holdenweb)
Date: 2002-08-07 13:28

Message:
Logged In: YES 
user_id=88157

I hope re-opening this is the right thing to do (I'm new here).

Current CVS fails under Win2000+Cygwin with a 
segmentation fault in the updated test_b1.py. Easily 
reproduced:

$ ./python.exe
Python 2.3a0 (#1, Aug  7 2002, 12:18:38)
[GCC 2.95.3-5 (cygwin special)] on cygwin
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import sys
>>> list(xrange(sys.maxint/4))
Segmentation fault (core dumped)

This does seem to be size-related, as:

>>> s = sys.maxint/8
>>> list(xrange(s))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
MemoryError

which is as expected in test_b1.py


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-22 19:20

Message:
Logged In: YES 
user_id=33168

Checked in as:
  listobject.c 2.106
  test_b1.py 1.46

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-21 08:59

Message:
Logged In: YES 
user_id=80475

Good plan!  Thx for squashing this bug. 

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-21 08:52

Message:
Logged In: YES 
user_id=33168

How about using sys.maxint / 4?  Does that make more sense
than 1e9?  This assumption is a little better, that the data
and address sizes are the same.  I can add a comment to this
effect.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-20 23:37

Message:
Logged In: YES 
user_id=80475

When you load the fix, please commit the regression test 
patch also.  Thx,  Raymond

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

Comment By: Tim Peters (tim_one)
Date: 2002-05-20 22:51

Message:
Logged In: YES 
user_id=31435

Yup, lookin' better.  Python does assume 8-bit bytes in 
several places, and also 2's-complement integers.  Since 
size_t is guaranteed (by C) to be an unsigned type, the 
largest value of type size_t is more easily expressed as

(~(size_t)0)

The C part of the patch looks fine then.  The test is a 
little dubious:  who says the machine can't create a 
billion-integer list?  The idea that 1e9 necessarily 
overflows in this context is a 32-bit address-space 
assumption.  But I'm willing to delay fixing that until a 
machine with a usable larger address space appears <wink>.

So marked Accepted and assigned to you for checkin.  Thanks!

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-20 11:43

Message:
Logged In: YES 
user_id=33168

Ok, there were other problems, too:
  * Need to divide by the size of the type, 
    not >> 4 which was completely broken.
  * There was a missing PyErr_NoMemory().

I uploaded a new patch.

I'm not sure the size_t fix is correct.
I hope we can at least assume 8-bit machines: :-)

if (_new_size <= ((1 << (sizeof(size_t)*8 - 1)) / sizeof(type)))



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

Comment By: Tim Peters (tim_one)
Date: 2002-05-20 00:48

Message:
Logged In: YES 
user_id=31435

The code patch has some problems:  you can't assume any 
relation between a size_t and an unsigned long; C simply 
doesn't define how big size_t is, and relative sizes do 
vary on 64-bit platforms.  However that gets fixed, if you 
decide it's "too big", var should be set to NULL (not 0 -- 
this is a "Guido thing" <wink>), and no exception should be 
set.  It's the caller's responsibility to check var for 
NULL after the macro is invoked, and set an appropriate 
exception.  listobject.c sometimes doesn't check the result 
for NULL, but that should only be when it knows it's 
*shrinking* a memory area, so that realloc can't fail.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-17 20:12

Message:
Logged In: YES 
user_id=80475

Added a patch to add this bug to the testbank.

Shallow code review:  Patch compiles okay (applied to 
Py2.3a0). Fixes the original problem.  Passes the smell 
test.  Macro style good (only the "var" operand is used 
more than once; no side-effects except setting "var" to 
zero upon a resize error).  Passes the standard regression 
tests.  Passes regression testing versus my personal (real 
code) testbank.

Will give it a deeper look this week-end.

One other thought: should the ValueError be replaced with a 
MemoryError to make the message consistent with PyList_New?



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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 17:03

Message:
Logged In: YES 
user_id=33168

Ok, this time I have a patch.  The patch only fixes listobject.

I looked over the other uses of PyMem_R{ESIZE,ALLOC}() and
they don't appear to be nearly as problematic as list.  For
example, if the grammar has 1e9 nodes, there are going to be
other problems well before then (ie, memory will probably be
gone).

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 16:25

Message:
Logged In: YES 
user_id=33168

Oops, sorry about that last comment.  That was something I
was playing with.  The CVS version is fine for [x]range(float).

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 16:22

Message:
Logged In: YES 
user_id=33168

Note, this problem is even more generic in CVS version:

>>> range(1.1)
Segmentation fault (core dumped)
>>> xrange(1.1)
Segmentation fault (core dumped)

[x]xrange(float) work fine in 2.2.1.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-14 20:44

Message:
Logged In: YES 
user_id=80475

Would there be some merit to converting PyMem_RESIZE to a 
function with an overflow check?  

I would guess that the time spent on a realloc dwarfs the 
overhead of a short wrapper function.

OTOH, I'll bet this core dump only occurs in toy examples 
and never in real code.



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

Comment By: Tim Peters (tim_one)
Date: 2002-05-14 18:15

Message:
Logged In: YES 
user_id=31435

Heh.  This is an instance of a general flaw:  the 
PyMem_RESIZE macro doesn't check for int overflow in its

    (n) * sizeof(type)

subexpression. The basic deal is that 1000000000 fits in an 
int, but 4 times that (silently) overflows.  In more 
detail, for this specific test case, listobject.c'.s 
roundupsize rounds 1e9 up to 0x40000000, which silently 
underflows to 0!() when PyMem_RESIZE multiplies it by 4.

Hard to know how to fix this in general; PyMem_RESIZE 
callers don't generally worry about overflow now.

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

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


From noreply@sourceforge.net  Wed Aug  7 19:49:09 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 07 Aug 2002 11:49:09 -0700
Subject: [Python-bugs-list] [ python-Bugs-592236 ] Under windows, isdir('c:') = 0. A bug?
Message-ID: <E17cVrp-0005PA-00@usw-sf-web3.sourceforge.net>

Bugs item #592236, was opened at 2002-08-07 20:49
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592236&group_id=5470

Category: Python Library
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Roberto Ferreras (eindh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Under windows, isdir('c:') = 0. A bug?

Initial Comment:
Under windows, os.path.isdir('c:') returns 0. Is it 
intended or it's a bug and should return 1? (Note: 
os.path.isdir('c:\') returns 1.)

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

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


From noreply@sourceforge.net  Wed Aug  7 21:11:08 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 07 Aug 2002 13:11:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-556025 ] list(xrange(1e9))  -->  seg fault
Message-ID: <E17cX9A-0002pn-00@usw-sf-web4.sourceforge.net>

Bugs item #556025, was opened at 2002-05-14 12:41
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=556025&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
>Assigned to: Jason Tishler (jlt63)
Summary: list(xrange(1e9))  -->  seg fault

Initial Comment:
>From c.lang.py:

'''
 Python 2.2.1 (#2, Apr 21 2002, 22:22:55) 
[GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.62mdk)] 
on linux2
Type "help", "copyright", "credits" or "license" for 
more information.
>>> list(xrange(1e9))
Segmentation fault
'''

I've reproduced the same fault on Windows ME using 
Py2.2.0 and Py2.3a.

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-07 16:11

Message:
Logged In: YES 
user_id=33168

Actually, I think Jason may be more appropriate, since this
is a cygwin problem.  Jason, can you test/replicate this?

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-07 14:20

Message:
Logged In: YES 
user_id=33168

Hmmm, Tim can you reproduce this?  I luckily don't have a
windows box. :-)

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

Comment By: Steve Holden (holdenweb)
Date: 2002-08-07 13:28

Message:
Logged In: YES 
user_id=88157

I hope re-opening this is the right thing to do (I'm new here).

Current CVS fails under Win2000+Cygwin with a 
segmentation fault in the updated test_b1.py. Easily 
reproduced:

$ ./python.exe
Python 2.3a0 (#1, Aug  7 2002, 12:18:38)
[GCC 2.95.3-5 (cygwin special)] on cygwin
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import sys
>>> list(xrange(sys.maxint/4))
Segmentation fault (core dumped)

This does seem to be size-related, as:

>>> s = sys.maxint/8
>>> list(xrange(s))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
MemoryError

which is as expected in test_b1.py


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-22 19:20

Message:
Logged In: YES 
user_id=33168

Checked in as:
  listobject.c 2.106
  test_b1.py 1.46

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-21 08:59

Message:
Logged In: YES 
user_id=80475

Good plan!  Thx for squashing this bug. 

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-21 08:52

Message:
Logged In: YES 
user_id=33168

How about using sys.maxint / 4?  Does that make more sense
than 1e9?  This assumption is a little better, that the data
and address sizes are the same.  I can add a comment to this
effect.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-20 23:37

Message:
Logged In: YES 
user_id=80475

When you load the fix, please commit the regression test 
patch also.  Thx,  Raymond

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

Comment By: Tim Peters (tim_one)
Date: 2002-05-20 22:51

Message:
Logged In: YES 
user_id=31435

Yup, lookin' better.  Python does assume 8-bit bytes in 
several places, and also 2's-complement integers.  Since 
size_t is guaranteed (by C) to be an unsigned type, the 
largest value of type size_t is more easily expressed as

(~(size_t)0)

The C part of the patch looks fine then.  The test is a 
little dubious:  who says the machine can't create a 
billion-integer list?  The idea that 1e9 necessarily 
overflows in this context is a 32-bit address-space 
assumption.  But I'm willing to delay fixing that until a 
machine with a usable larger address space appears <wink>.

So marked Accepted and assigned to you for checkin.  Thanks!

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-20 11:43

Message:
Logged In: YES 
user_id=33168

Ok, there were other problems, too:
  * Need to divide by the size of the type, 
    not >> 4 which was completely broken.
  * There was a missing PyErr_NoMemory().

I uploaded a new patch.

I'm not sure the size_t fix is correct.
I hope we can at least assume 8-bit machines: :-)

if (_new_size <= ((1 << (sizeof(size_t)*8 - 1)) / sizeof(type)))



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

Comment By: Tim Peters (tim_one)
Date: 2002-05-20 00:48

Message:
Logged In: YES 
user_id=31435

The code patch has some problems:  you can't assume any 
relation between a size_t and an unsigned long; C simply 
doesn't define how big size_t is, and relative sizes do 
vary on 64-bit platforms.  However that gets fixed, if you 
decide it's "too big", var should be set to NULL (not 0 -- 
this is a "Guido thing" <wink>), and no exception should be 
set.  It's the caller's responsibility to check var for 
NULL after the macro is invoked, and set an appropriate 
exception.  listobject.c sometimes doesn't check the result 
for NULL, but that should only be when it knows it's 
*shrinking* a memory area, so that realloc can't fail.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-17 20:12

Message:
Logged In: YES 
user_id=80475

Added a patch to add this bug to the testbank.

Shallow code review:  Patch compiles okay (applied to 
Py2.3a0). Fixes the original problem.  Passes the smell 
test.  Macro style good (only the "var" operand is used 
more than once; no side-effects except setting "var" to 
zero upon a resize error).  Passes the standard regression 
tests.  Passes regression testing versus my personal (real 
code) testbank.

Will give it a deeper look this week-end.

One other thought: should the ValueError be replaced with a 
MemoryError to make the message consistent with PyList_New?



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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 17:03

Message:
Logged In: YES 
user_id=33168

Ok, this time I have a patch.  The patch only fixes listobject.

I looked over the other uses of PyMem_R{ESIZE,ALLOC}() and
they don't appear to be nearly as problematic as list.  For
example, if the grammar has 1e9 nodes, there are going to be
other problems well before then (ie, memory will probably be
gone).

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 16:25

Message:
Logged In: YES 
user_id=33168

Oops, sorry about that last comment.  That was something I
was playing with.  The CVS version is fine for [x]range(float).

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 16:22

Message:
Logged In: YES 
user_id=33168

Note, this problem is even more generic in CVS version:

>>> range(1.1)
Segmentation fault (core dumped)
>>> xrange(1.1)
Segmentation fault (core dumped)

[x]xrange(float) work fine in 2.2.1.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-14 20:44

Message:
Logged In: YES 
user_id=80475

Would there be some merit to converting PyMem_RESIZE to a 
function with an overflow check?  

I would guess that the time spent on a realloc dwarfs the 
overhead of a short wrapper function.

OTOH, I'll bet this core dump only occurs in toy examples 
and never in real code.



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

Comment By: Tim Peters (tim_one)
Date: 2002-05-14 18:15

Message:
Logged In: YES 
user_id=31435

Heh.  This is an instance of a general flaw:  the 
PyMem_RESIZE macro doesn't check for int overflow in its

    (n) * sizeof(type)

subexpression. The basic deal is that 1000000000 fits in an 
int, but 4 times that (silently) overflows.  In more 
detail, for this specific test case, listobject.c'.s 
roundupsize rounds 1e9 up to 0x40000000, which silently 
underflows to 0!() when PyMem_RESIZE multiplies it by 4.

Hard to know how to fix this in general; PyMem_RESIZE 
callers don't generally worry about overflow now.

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

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


From noreply@sourceforge.net  Wed Aug  7 21:22:53 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 07 Aug 2002 13:22:53 -0700
Subject: [Python-bugs-list] [ python-Bugs-586931 ] pydoc -w fails with path specified
Message-ID: <E17cXKX-0006zJ-00@usw-sf-web3.sourceforge.net>

Bugs item #586931, was opened at 2002-07-26 10:31
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=586931&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Tim Peters (tim_one)
Summary: pydoc -w fails with path specified

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

If I specify a path (ie, ./dictclient.py) and use -w, it will 
fail.  If -w
is not used, or a module (ie, dictclient) is specified, it 
will work. 
Example:

$ pydoc2.2 -w ./dictclient.py
Traceback (most recent call last):
  File "/usr/bin/pydoc2.2", line 4, in ?
    pydoc.cli()
  File "/usr/lib/python2.2/pydoc.py", line 2074, in cli
    writedoc(arg)
  File "/usr/lib/python2.2/pydoc.py", line 1345, in writedoc
    object = locate(key, forceload)
  File "/usr/lib/python2.2/pydoc.py", line 1297, in locate
    parts = split(path, '.')
  File "/usr/lib/python2.2/string.py", line 117, in split
    return s.split(sep, maxsplit)
AttributeError: 'module' object has no attribute 'split'


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

>Comment By: Matthias Klose (doko)
Date: 2002-08-07 20:22

Message:
Logged In: YES 
user_id=60903

sorry for attaching the patch here (submitted on 
http://bugs.debian.org/143462)

[problem is found in 2.1, 2,2 and 2.3]

--- pydoc.py.old        Wed Aug  7 15:52:08 2002 
+++ pydoc.py    Wed Aug  7 15:51:10 2002 
@@ -1114,6 +1114,8 @@                
  
 def writedoc(key, forceload=0):                               
     """Write HTML documentation to a file in the current 
directory.""" 
+    if not isinstance(key, type('')):                      
+        key = key.__name__ 
     try: 
         object = locate(key, forceload) 
     except ErrorDuringImport, value: 


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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-08-07 15:28

Message:
Logged In: YES 
user_id=3066

Tim is friends with pydoc.  ;-)

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

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


From noreply@sourceforge.net  Thu Aug  8 00:26:34 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 07 Aug 2002 16:26:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-592236 ] Under windows, isdir('c:') = 0. A bug?
Message-ID: <E17caCI-0001q6-00@usw-sf-web1.sourceforge.net>

Bugs item #592236, was opened at 2002-08-07 14:49
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592236&group_id=5470

>Category: Windows
Group: Platform-specific
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Roberto Ferreras (eindh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Under windows, isdir('c:') = 0. A bug?

Initial Comment:
Under windows, os.path.isdir('c:') returns 0. Is it 
intended or it's a bug and should return 1? (Note: 
os.path.isdir('c:\') returns 1.)

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

>Comment By: Tim Peters (tim_one)
Date: 2002-08-07 19:26

Message:
Logged In: YES 
user_id=31435

Ya. this is a mess, because Microsoft's stat() function 
refuses to believe that 'c:' is a directory.  Closing as 
Duplicate, since there are at least two other bugs open on 
this:

513572
516232 


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

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


From noreply@sourceforge.net  Thu Aug  8 04:51:38 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 07 Aug 2002 20:51:38 -0700
Subject: [Python-bugs-list] [ python-Bugs-591349 ] httplib sporadically throws a TypeError
Message-ID: <E17ceKo-00072Q-00@usw-sf-web5.sourceforge.net>

Bugs item #591349, was opened at 2002-08-05 19:42
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=591349&group_id=5470

Category: Python Library
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Rob Green (rbgrn)
Assigned to: Jeremy Hylton (jhylton)
Summary: httplib sporadically throws a TypeError

Initial Comment:
This is the output that occurs about 1 in 500 hits to any 
particular URL. I've only seen it so far hitting servers 
running Apache 1.3.20, but I don't have enough data to 
limit it to that.

Python 2.1.2 (#1, Mar 16 2002, 18:24:08)
[GCC 2.95.3 [FreeBSD] 20010315 (release)] on freebsd4

h = httplib.HTTPConnection(host)
response = h.getresponse()
data = response.read()
File "/usr/local/lib/python2.1/httplib.py", line 246, in read
value = value + self._safe_read(chunk_left)
File "/usr/local/lib/python2.1/httplib.py", line 314, in 
_safe_read
chunk = self.fp.read(amt)
TypeError: an integer is required



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

>Comment By: Rob Green (rbgrn)
Date: 2002-08-07 22:51

Message:
Logged In: YES 
user_id=590105

Ok I figured out what causes this. It's not a threading issue or 
anything like that, basically what happens is this:

When httplib connects to a server and the hostname is good 
and the port is open and connects, but the server 
immediately disconnects without printing any text or 
anything, this exception is then thrown.

I was able to reproduce it by running netcat -l -p <port> 
locally and starting an HTTPConnection to that port, then 
punting netcat which causes python to throw the exception.

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

Comment By: Rob Green (rbgrn)
Date: 2002-08-07 01:16

Message:
Logged In: YES 
user_id=590105

Ok I put together some test code that reproduced the bug in 
under an hour on my machine. Here it is...

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

Comment By: Rob Green (rbgrn)
Date: 2002-08-07 00:14

Message:
Logged In: YES 
user_id=590105

I'd give you the URLs but I don't think it matters that much, 
I've seen this problem now hitting 4 different machines, all 
running linux/apache. It's not something very easy for me to 
reproduce because I only see the exception thrown once or 
maybe twice during the day where there are 20,000 hits from 
my daemon that day. I suppose that the way to reproduce it 
would be to have a list of urls, and to just have an app sit 
there and cycle through them doing a GET every 5 seconds 
or so, and eventually it should show up. I suppose to be more 
accurate the app would have to be threaded as well, maybe 
having a thread for each url that just opens an 
HTTPConnection every 5 seconds.

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

Comment By: Jeremy Hylton (jhylton)
Date: 2002-08-06 07:42

Message:
Logged In: YES 
user_id=31392

Can you provide any more information about what URLs cause
problems?  You could call set_debuglevel(1) to enable output
of all  HTTP trafffic.  Or just a list of some of the URLs
that failed.


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

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


From noreply@sourceforge.net  Thu Aug  8 04:52:45 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 07 Aug 2002 20:52:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-591349 ] httplib throws a TypeError when the target host disconnects
Message-ID: <E17ceLt-00073R-00@usw-sf-web5.sourceforge.net>

Bugs item #591349, was opened at 2002-08-05 19:42
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=591349&group_id=5470

Category: Python Library
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Rob Green (rbgrn)
Assigned to: Jeremy Hylton (jhylton)
>Summary: httplib throws a TypeError when the target host disconnects

Initial Comment:
This is the output that occurs about 1 in 500 hits to any 
particular URL. I've only seen it so far hitting servers 
running Apache 1.3.20, but I don't have enough data to 
limit it to that.

Python 2.1.2 (#1, Mar 16 2002, 18:24:08)
[GCC 2.95.3 [FreeBSD] 20010315 (release)] on freebsd4

h = httplib.HTTPConnection(host)
response = h.getresponse()
data = response.read()
File "/usr/local/lib/python2.1/httplib.py", line 246, in read
value = value + self._safe_read(chunk_left)
File "/usr/local/lib/python2.1/httplib.py", line 314, in 
_safe_read
chunk = self.fp.read(amt)
TypeError: an integer is required



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

Comment By: Rob Green (rbgrn)
Date: 2002-08-07 22:51

Message:
Logged In: YES 
user_id=590105

Ok I figured out what causes this. It's not a threading issue or 
anything like that, basically what happens is this:

When httplib connects to a server and the hostname is good 
and the port is open and connects, but the server 
immediately disconnects without printing any text or 
anything, this exception is then thrown.

I was able to reproduce it by running netcat -l -p <port> 
locally and starting an HTTPConnection to that port, then 
punting netcat which causes python to throw the exception.

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

Comment By: Rob Green (rbgrn)
Date: 2002-08-07 01:16

Message:
Logged In: YES 
user_id=590105

Ok I put together some test code that reproduced the bug in 
under an hour on my machine. Here it is...

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

Comment By: Rob Green (rbgrn)
Date: 2002-08-07 00:14

Message:
Logged In: YES 
user_id=590105

I'd give you the URLs but I don't think it matters that much, 
I've seen this problem now hitting 4 different machines, all 
running linux/apache. It's not something very easy for me to 
reproduce because I only see the exception thrown once or 
maybe twice during the day where there are 20,000 hits from 
my daemon that day. I suppose that the way to reproduce it 
would be to have a list of urls, and to just have an app sit 
there and cycle through them doing a GET every 5 seconds 
or so, and eventually it should show up. I suppose to be more 
accurate the app would have to be threaded as well, maybe 
having a thread for each url that just opens an 
HTTPConnection every 5 seconds.

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

Comment By: Jeremy Hylton (jhylton)
Date: 2002-08-06 07:42

Message:
Logged In: YES 
user_id=31392

Can you provide any more information about what URLs cause
problems?  You could call set_debuglevel(1) to enable output
of all  HTTP trafffic.  Or just a list of some of the URLs
that failed.


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

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


From noreply@sourceforge.net  Thu Aug  8 05:14:07 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 07 Aug 2002 21:14:07 -0700
Subject: [Python-bugs-list] [ python-Bugs-591349 ] httplib throws a TypeError when the target host disconnects
Message-ID: <E17cegZ-0004uJ-00@usw-sf-web3.sourceforge.net>

Bugs item #591349, was opened at 2002-08-05 19:42
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=591349&group_id=5470

Category: Python Library
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Rob Green (rbgrn)
Assigned to: Jeremy Hylton (jhylton)
Summary: httplib throws a TypeError when the target host disconnects

Initial Comment:
This is the output that occurs about 1 in 500 hits to any 
particular URL. I've only seen it so far hitting servers 
running Apache 1.3.20, but I don't have enough data to 
limit it to that.

Python 2.1.2 (#1, Mar 16 2002, 18:24:08)
[GCC 2.95.3 [FreeBSD] 20010315 (release)] on freebsd4

h = httplib.HTTPConnection(host)
response = h.getresponse()
data = response.read()
File "/usr/local/lib/python2.1/httplib.py", line 246, in read
value = value + self._safe_read(chunk_left)
File "/usr/local/lib/python2.1/httplib.py", line 314, in 
_safe_read
chunk = self.fp.read(amt)
TypeError: an integer is required



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

>Comment By: Rob Green (rbgrn)
Date: 2002-08-07 23:14

Message:
Logged In: YES 
user_id=590105

Line 245 should be "if chunk_left is not _UNKNOWN:"
And the next block up to line 259 should be indented. This 
causes an IncompleteRead exception to be thrown, which is 
IMO the correct one in this case.

I attached a diff that patches the Python 2.1.2 httplib.

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

Comment By: Rob Green (rbgrn)
Date: 2002-08-07 22:51

Message:
Logged In: YES 
user_id=590105

Ok I figured out what causes this. It's not a threading issue or 
anything like that, basically what happens is this:

When httplib connects to a server and the hostname is good 
and the port is open and connects, but the server 
immediately disconnects without printing any text or 
anything, this exception is then thrown.

I was able to reproduce it by running netcat -l -p <port> 
locally and starting an HTTPConnection to that port, then 
punting netcat which causes python to throw the exception.

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

Comment By: Rob Green (rbgrn)
Date: 2002-08-07 01:16

Message:
Logged In: YES 
user_id=590105

Ok I put together some test code that reproduced the bug in 
under an hour on my machine. Here it is...

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

Comment By: Rob Green (rbgrn)
Date: 2002-08-07 00:14

Message:
Logged In: YES 
user_id=590105

I'd give you the URLs but I don't think it matters that much, 
I've seen this problem now hitting 4 different machines, all 
running linux/apache. It's not something very easy for me to 
reproduce because I only see the exception thrown once or 
maybe twice during the day where there are 20,000 hits from 
my daemon that day. I suppose that the way to reproduce it 
would be to have a list of urls, and to just have an app sit 
there and cycle through them doing a GET every 5 seconds 
or so, and eventually it should show up. I suppose to be more 
accurate the app would have to be threaded as well, maybe 
having a thread for each url that just opens an 
HTTPConnection every 5 seconds.

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

Comment By: Jeremy Hylton (jhylton)
Date: 2002-08-06 07:42

Message:
Logged In: YES 
user_id=31392

Can you provide any more information about what URLs cause
problems?  You could call set_debuglevel(1) to enable output
of all  HTTP trafffic.  Or just a list of some of the URLs
that failed.


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

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


From noreply@sourceforge.net  Thu Aug  8 05:40:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 07 Aug 2002 21:40:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-592441 ] Webchecker error on http://www.naleo.org
Message-ID: <E17cf63-00076d-00@usw-sf-web1.sourceforge.net>

Bugs item #592441, was opened at 2002-08-08 00:40
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592441&group_id=5470

Category: Demos and Tools
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Carlos Conti (mcsolrac)
Assigned to: Nobody/Anonymous (nobody)
Summary: Webchecker error on http://www.naleo.org

Initial Comment:
Webchecker version 1.25.6.1 on Windows 2000 
Professional. 

Run webchecker with this argument 
http://www.naleo.org/WSJArticle002.htm 
Webchecker will return this traceback: 

Traceback (most recent call last):
  File "C:\Python22\Tools\webchecker\webchecker.py", 
line 858, in ?
    main()
  File "C:\Python22\Tools\webchecker\webchecker.py", 
line 222, in main
    c.run()
  File "C:\Python22\Tools\webchecker\webchecker.py", 
line 349, in run
    self.dopage(url)
  File "C:\Python22\Tools\webchecker\webchecker.py", 
line 403, in dopage
    page = self.getpage(url_pair)
  File "C:\Python22\Tools\webchecker\webchecker.py", 
line 507, in getpage
    return Page(text, url, maxpage=self.maxpage, 
checker=self)
  File "C:\Python22\Tools\webchecker\webchecker.py", 
line 671, in __init__
    self.parser.feed(self.text)
  File "C:\Python22\lib\sgmllib.py", line 95, in feed
    self.goahead(0)
  File "C:\Python22\lib\sgmllib.py", line 161, in goahead
    k = self.parse_declaration(i)
  File "C:\Python22\lib\markupbase.py", line 66, in 
parse_declaration
    decltype, j = self._scan_name(j, i)
  File "C:\Python22\lib\markupbase.py", line 313, in 
_scan_name
    self.error("expected name token")
  File "C:\Python22\lib\sgmllib.py", line 102, in error
    raise SGMLParseError(message)
sgmllib.SGMLParseError: expected name token

I believe this is because of the xml in the source code 
(see WSJArticle002_source.txt attached to this bug 
report).

Even if the code in this page is poorly formatted, 
webchecker should be able continue checking other 
links in this domain (rather than stopping). For example 
webchecker could report “unable to check 
http://www.naleo.org/WSJArticle002.htm” and return 
traceback like the above, and then continue with the rest 
of the domain. 


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

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


From noreply@sourceforge.net  Thu Aug  8 06:51:26 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 07 Aug 2002 22:51:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-592446 ] missing extern "C"
Message-ID: <E17cgCk-00022k-00@usw-sf-web2.sourceforge.net>

Bugs item #592446, was opened at 2002-08-08 00:51
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592446&group_id=5470

Category: None
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: David Abrahams (david_abrahams)
Assigned to: Nobody/Anonymous (nobody)
Summary: missing extern "C"

Initial Comment:
cxx: Error: ../../../libs/python/src/object/function.cpp, 
line 276: #144-D a
          value of type "PyObject *(*)(PyObject *, void *) 
C" cannot be used
          to initialize an entity of type "getter"
        {"__doc__", function_get_doc, (setter)
function_set_doc},

This indicates that the typedef "getter" for the function 
pointer type PyObject* (*)(PyObject*, void*) is missing 
the

 #ifdef __cplusplus
 extern "C" {
 #endif
  ...

 #ifdef __cplusplus
 }
 #endif

brackets

-Dave

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592446&group_id=5470


From noreply@sourceforge.net  Thu Aug  8 09:11:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 08 Aug 2002 01:11:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-592489 ] CRLF ignored in package email
Message-ID: <E17ciOK-0000Re-00@usw-sf-web3.sourceforge.net>

Bugs item #592489, was opened at 2002-08-08 10:11
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592489&group_id=5470

Category: Python Library
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Jan Rosczak (rosczak)
Assigned to: Nobody/Anonymous (nobody)
Summary: CRLF ignored in package email

Initial Comment:
When parsing a MIME message with the class
email.Parser.Parser the different body parts are not
separated correctly if the boundary strings are
enclosed with CRLF as demanded by RFC2046. 

The Parser class only works with the '\n' character.
Reading RFC2046
I would expect it to use '\r\n' instead.

I am using Python 2.2.1 on Redhat Linux 7.3

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592489&group_id=5470


From noreply@sourceforge.net  Thu Aug  8 09:45:40 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 08 Aug 2002 01:45:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-592161 ] installation errors
Message-ID: <E17civM-0007El-00@usw-sf-web4.sourceforge.net>

Bugs item #592161, was opened at 2002-08-07 16:39
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592161&group_id=5470

Category: Distutils
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Alicia C. Hopkins (aliciahopkins)
Assigned to: Nobody/Anonymous (nobody)
Summary: installation errors

Initial Comment:
with the use of
  python2 setup.py install, I get the following errors


 File "setup.py", line 30, in ?
    packages = ['distutils', 'distutils.command'],
  File "distutils/core.py", line 101, in setup
    _setup_distribution = dist = klass(attrs)
  File "distutils/dist.py", line 130, in __init__
    setattr(self, method_name, getattr(self.metadata, 
method_name))
AttributeError: DistributionMetadata instance has no 
attribute 'get___doc__'


HELP!

Alicia Hopkins

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-08-08 08:45

Message:
Logged In: YES 
user_id=6656

Which setup.py is that?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592161&group_id=5470


From noreply@sourceforge.net  Thu Aug  8 11:11:19 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 08 Aug 2002 03:11:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-592527 ] comments taken as values in ConfigParser
Message-ID: <E17ckGF-0002cS-00@usw-sf-web3.sourceforge.net>

Bugs item #592527, was opened at 2002-08-08 12:11
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592527&group_id=5470

Category: Python Library
Group: 3rd Party
Status: Open
Resolution: None
Priority: 5
Submitted By: Art&#363;ras Kriukovas (drugelis)
Assigned to: Nobody/Anonymous (nobody)
Summary: comments taken as values in ConfigParser

Initial Comment:
Let's say we have config file config.conf with contents:


[forms]
....
myParameter = myValue # my comment here :) 
# and my comment here
....

[other sections]
.......


We run python code:

    import sys, os
    from ConfigParser import *
    fileLocations = ['......./config.conf']
    parser = ConfigParser()
    parser.read(fileLocations)
    parser.sections()

and when we run:
    parser.get('forms', 'manoParameter')

we get:
    'myValue # my comment here :)'

The comment is also included as key value. The second
comment is left out as it should be.
The simpliest way to fix it probaby would be remove all
string after the first '#' char (that is to leave
string part to first '#' char).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592527&group_id=5470


From noreply@sourceforge.net  Thu Aug  8 13:11:55 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 08 Aug 2002 05:11:55 -0700
Subject: [Python-bugs-list] [ python-Bugs-556025 ] list(xrange(1e9))  -->  seg fault
Message-ID: <E17cm8x-0006zz-00@usw-sf-web1.sourceforge.net>

Bugs item #556025, was opened at 2002-05-14 08:41
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=556025&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Jason Tishler (jlt63)
Summary: list(xrange(1e9))  -->  seg fault

Initial Comment:
>From c.lang.py:

'''
 Python 2.2.1 (#2, Apr 21 2002, 22:22:55) 
[GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.62mdk)] 
on linux2
Type "help", "copyright", "credits" or "license" for 
more information.
>>> list(xrange(1e9))
Segmentation fault
'''

I've reproduced the same fault on Windows ME using 
Py2.2.0 and Py2.3a.

----------------------------------------------------------------------

>Comment By: Jason Tishler (jlt63)
Date: 2002-08-08 04:11

Message:
Logged In: YES 
user_id=86216

> Jason, can you test/replicate this?

Yes, I've already been working on this one. See
the following mailing list threads for the details:

http://cygwin.com/ml/cygwin-developers/2002-07/msg00124.html
http://sources.redhat.com/ml/newlib/2002/msg00369.html

To summarize the above, the problem is actually
in newlib which provides Cygwin's libc (and
libm).  Unfortunately, Chris Falyor (the Cygwin
lead developer) has not been able to convince
the newlib maintainer to fix this problem.
Additionally, my first patch has been rejected.

I will continue my efforts to get this problem
resolved.  Any assistance will be greatly
appreciated.  I never expected to become an
expert in Doug Lea's malloc routines.  Sigh...

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-07 12:11

Message:
Logged In: YES 
user_id=33168

Actually, I think Jason may be more appropriate, since this
is a cygwin problem.  Jason, can you test/replicate this?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-07 10:20

Message:
Logged In: YES 
user_id=33168

Hmmm, Tim can you reproduce this?  I luckily don't have a
windows box. :-)

----------------------------------------------------------------------

Comment By: Steve Holden (holdenweb)
Date: 2002-08-07 09:28

Message:
Logged In: YES 
user_id=88157

I hope re-opening this is the right thing to do (I'm new here).

Current CVS fails under Win2000+Cygwin with a 
segmentation fault in the updated test_b1.py. Easily 
reproduced:

$ ./python.exe
Python 2.3a0 (#1, Aug  7 2002, 12:18:38)
[GCC 2.95.3-5 (cygwin special)] on cygwin
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import sys
>>> list(xrange(sys.maxint/4))
Segmentation fault (core dumped)

This does seem to be size-related, as:

>>> s = sys.maxint/8
>>> list(xrange(s))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
MemoryError

which is as expected in test_b1.py


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-22 15:20

Message:
Logged In: YES 
user_id=33168

Checked in as:
  listobject.c 2.106
  test_b1.py 1.46

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-21 04:59

Message:
Logged In: YES 
user_id=80475

Good plan!  Thx for squashing this bug. 

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-21 04:52

Message:
Logged In: YES 
user_id=33168

How about using sys.maxint / 4?  Does that make more sense
than 1e9?  This assumption is a little better, that the data
and address sizes are the same.  I can add a comment to this
effect.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-20 19:37

Message:
Logged In: YES 
user_id=80475

When you load the fix, please commit the regression test 
patch also.  Thx,  Raymond

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-05-20 18:51

Message:
Logged In: YES 
user_id=31435

Yup, lookin' better.  Python does assume 8-bit bytes in 
several places, and also 2's-complement integers.  Since 
size_t is guaranteed (by C) to be an unsigned type, the 
largest value of type size_t is more easily expressed as

(~(size_t)0)

The C part of the patch looks fine then.  The test is a 
little dubious:  who says the machine can't create a 
billion-integer list?  The idea that 1e9 necessarily 
overflows in this context is a 32-bit address-space 
assumption.  But I'm willing to delay fixing that until a 
machine with a usable larger address space appears <wink>.

So marked Accepted and assigned to you for checkin.  Thanks!

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-20 07:43

Message:
Logged In: YES 
user_id=33168

Ok, there were other problems, too:
  * Need to divide by the size of the type, 
    not >> 4 which was completely broken.
  * There was a missing PyErr_NoMemory().

I uploaded a new patch.

I'm not sure the size_t fix is correct.
I hope we can at least assume 8-bit machines: :-)

if (_new_size <= ((1 << (sizeof(size_t)*8 - 1)) / sizeof(type)))



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-05-19 20:48

Message:
Logged In: YES 
user_id=31435

The code patch has some problems:  you can't assume any 
relation between a size_t and an unsigned long; C simply 
doesn't define how big size_t is, and relative sizes do 
vary on 64-bit platforms.  However that gets fixed, if you 
decide it's "too big", var should be set to NULL (not 0 -- 
this is a "Guido thing" <wink>), and no exception should be 
set.  It's the caller's responsibility to check var for 
NULL after the macro is invoked, and set an appropriate 
exception.  listobject.c sometimes doesn't check the result 
for NULL, but that should only be when it knows it's 
*shrinking* a memory area, so that realloc can't fail.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-17 16:12

Message:
Logged In: YES 
user_id=80475

Added a patch to add this bug to the testbank.

Shallow code review:  Patch compiles okay (applied to 
Py2.3a0). Fixes the original problem.  Passes the smell 
test.  Macro style good (only the "var" operand is used 
more than once; no side-effects except setting "var" to 
zero upon a resize error).  Passes the standard regression 
tests.  Passes regression testing versus my personal (real 
code) testbank.

Will give it a deeper look this week-end.

One other thought: should the ValueError be replaced with a 
MemoryError to make the message consistent with PyList_New?



----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 13:03

Message:
Logged In: YES 
user_id=33168

Ok, this time I have a patch.  The patch only fixes listobject.

I looked over the other uses of PyMem_R{ESIZE,ALLOC}() and
they don't appear to be nearly as problematic as list.  For
example, if the grammar has 1e9 nodes, there are going to be
other problems well before then (ie, memory will probably be
gone).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 12:25

Message:
Logged In: YES 
user_id=33168

Oops, sorry about that last comment.  That was something I
was playing with.  The CVS version is fine for [x]range(float).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 12:22

Message:
Logged In: YES 
user_id=33168

Note, this problem is even more generic in CVS version:

>>> range(1.1)
Segmentation fault (core dumped)
>>> xrange(1.1)
Segmentation fault (core dumped)

[x]xrange(float) work fine in 2.2.1.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-14 16:44

Message:
Logged In: YES 
user_id=80475

Would there be some merit to converting PyMem_RESIZE to a 
function with an overflow check?  

I would guess that the time spent on a realloc dwarfs the 
overhead of a short wrapper function.

OTOH, I'll bet this core dump only occurs in toy examples 
and never in real code.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-05-14 14:15

Message:
Logged In: YES 
user_id=31435

Heh.  This is an instance of a general flaw:  the 
PyMem_RESIZE macro doesn't check for int overflow in its

    (n) * sizeof(type)

subexpression. The basic deal is that 1000000000 fits in an 
int, but 4 times that (silently) overflows.  In more 
detail, for this specific test case, listobject.c'.s 
roundupsize rounds 1e9 up to 0x40000000, which silently 
underflows to 0!() when PyMem_RESIZE multiplies it by 4.

Hard to know how to fix this in general; PyMem_RESIZE 
callers don't generally worry about overflow now.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=556025&group_id=5470


From noreply@sourceforge.net  Thu Aug  8 13:42:12 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 08 Aug 2002 05:42:12 -0700
Subject: [Python-bugs-list] [ python-Bugs-592567 ] Bug with deepcopy and new style objects
Message-ID: <E17cmcG-0005M0-00@usw-sf-web3.sourceforge.net>

Bugs item #592567, was opened at 2002-08-08 12:42
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592567&group_id=5470

Category: Python Library
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Jiba (jiba)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bug with deepcopy and new style objects

Initial Comment:
Deepcopying new style objects can bug if more than one
of such objects are deep copied at the same time (E.g.
you are deepcopying a list of two new style objects).

It seems that , in copy._reconstruct, the "state" 
variable should be "kept alive" (by passing it to the
"_keep_alive" function), since this state may be gc'ed,
and another state may be created later with the same
address memory / ID.

BTW, the same problem may arise with the "args"
variable, in the same function.

The included file demonstrates the bug.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592567&group_id=5470


From noreply@sourceforge.net  Thu Aug  8 13:48:28 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 08 Aug 2002 05:48:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-592573 ] UserString is mutable via +=
Message-ID: <E17cmiK-0007r2-00@usw-sf-web1.sourceforge.net>

Bugs item #592573, was opened at 2002-08-08 14:48
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592573&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bernhard Herzog (bernhard)
Assigned to: Nobody/Anonymous (nobody)
Summary: UserString is mutable via +=

Initial Comment:
UserString is mutable with augmented assignment:

Python 2.2 (#1, Jan 17 2002, 21:04:07) 
[GCC 2.95.4 20011006 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import UserString
>>> s = t = UserString.UserString("abc")
>>> s += "def"
>>> s
'abcdef'
>>> t
'abcdef'
>>> 


The __iadd__ and __imul__ methods should be in the
MutableString class I think.

OTOH, nowadays the string types can be sub-classed so
that UserString behaving exactly like a builtin string
may not be that important anymore.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592573&group_id=5470


From noreply@sourceforge.net  Thu Aug  8 13:56:00 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 08 Aug 2002 05:56:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-592489 ] CRLF ignored in package email
Message-ID: <E17cmpc-0005cx-00@usw-sf-web3.sourceforge.net>

Bugs item #592489, was opened at 2002-08-08 04:11
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592489&group_id=5470

Category: Python Library
Group: Python 2.2.1
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Jan Rosczak (rosczak)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: CRLF ignored in package email

Initial Comment:
When parsing a MIME message with the class
email.Parser.Parser the different body parts are not
separated correctly if the boundary strings are
enclosed with CRLF as demanded by RFC2046. 

The Parser class only works with the '\n' character.
Reading RFC2046
I would expect it to use '\r\n' instead.

I am using Python 2.2.1 on Redhat Linux 7.3

----------------------------------------------------------------------

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2002-08-08 08:56

Message:
Logged In: YES 
user_id=12800

You can either grab the standalone version in the mimelib
project

http://sf.net/projects/mimelib

or wait until Python 2.3.  email package 2.2 recognizes all
types of common line endings.  It's likely that email 2.2
will be backported to Python 2.2.2 if there is one.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592489&group_id=5470


From noreply@sourceforge.net  Thu Aug  8 16:02:11 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 08 Aug 2002 08:02:11 -0700
Subject: [Python-bugs-list] [ python-Bugs-592161 ] installation errors
Message-ID: <E17conj-0003dT-00@usw-sf-web2.sourceforge.net>

Bugs item #592161, was opened at 2002-08-07 09:39
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592161&group_id=5470

Category: Distutils
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Alicia C. Hopkins (aliciahopkins)
Assigned to: Nobody/Anonymous (nobody)
Summary: installation errors

Initial Comment:
with the use of
  python2 setup.py install, I get the following errors


 File "setup.py", line 30, in ?
    packages = ['distutils', 'distutils.command'],
  File "distutils/core.py", line 101, in setup
    _setup_distribution = dist = klass(attrs)
  File "distutils/dist.py", line 130, in __init__
    setattr(self, method_name, getattr(self.metadata, 
method_name))
AttributeError: DistributionMetadata instance has no 
attribute 'get___doc__'


HELP!

Alicia Hopkins

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-08-08 08:02

Message:
Logged In: NO 

The setup.py is in the main directory Distutils-1.0.2



----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-08-08 01:45

Message:
Logged In: YES 
user_id=6656

Which setup.py is that?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592161&group_id=5470


From noreply@sourceforge.net  Thu Aug  8 16:34:51 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 08 Aug 2002 08:34:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-592645 ] memory leak in socket.getaddrinfo
Message-ID: <E17cpJL-00046z-00@usw-sf-web2.sourceforge.net>

Bugs item #592645, was opened at 2002-08-08 17:34
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592645&group_id=5470

Category: Extension Modules
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Jean-Claude Rimbault (jcrimbault)
Assigned to: Nobody/Anonymous (nobody)
Summary: memory leak in socket.getaddrinfo

Initial Comment:
Function getaddrinfo of the socket module
fails to free system allocated result when the call is
successful
(but it does on error). Il should call freeaddrinfo to
free res0
before returning Python result.

This leak is also affecting httplib and urllib because
since Python 2.2, httplib.HTTPConnection.connect method
does call socket.getaddrinfo.

Small test program showing off the leak:

import socket, time

while 1:
    res = socket.getaddrinfo('localhost', 80, 0,
socket.SOCK_STREAM)
    time.sleep(0.01)


Tested with Python 2.2.1 under Linux 2.4

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592645&group_id=5470


From noreply@sourceforge.net  Thu Aug  8 18:03:20 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 08 Aug 2002 10:03:20 -0700
Subject: [Python-bugs-list] [ python-Bugs-592703 ] HTTPS does not handle pipelined requests
Message-ID: <E17cqgy-0003is-00@usw-sf-web3.sourceforge.net>

Bugs item #592703, was opened at 2002-08-08 17:03
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592703&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Jeremy Hylton (jhylton)
Summary: HTTPS does not handle pipelined requests

Initial Comment:
No test case yet, but the buffering code for SSLFile
looks like it will break pipelined requests.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592703&group_id=5470


From noreply@sourceforge.net  Thu Aug  8 18:15:18 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 08 Aug 2002 10:15:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-592112 ] Hint for speeding up cPickle
Message-ID: <E17cqsY-0006Qq-00@usw-sf-web2.sourceforge.net>

Bugs item #592112, was opened at 2002-08-07 15:31
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592112&group_id=5470

Category: Python Library
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Jiba (jiba)
Assigned to: Nobody/Anonymous (nobody)
Summary: Hint for speeding up cPickle

Initial Comment:
There is a strange behaviour in cPickle (in Python 2.2.1).
For big serialized file, the following:

        cPickle.loads(open("my_file").read())

can be much (e.g. 7 times) faster than:

        cPickle.load(open("my_file"))

It seems that cPickle use unbuffered reading or what ?
The pickle implementation doesn't have this behaviour,
and can even be
faster than the C one!

----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-08-08 17:15

Message:
Logged In: YES 
user_id=31392

I expect this has to do with extra overhead in Python to
read from the file, independent of buffering.  The cPickle
code is trying to read small numbers of bytes at a time. 
Each read used fread().  This is slow, because fread is slow
for small numbers of bytes.  It's also slow because cPickle
releases and acquires the global interpeter lock around the
fread() calls.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592112&group_id=5470


From noreply@sourceforge.net  Thu Aug  8 18:51:49 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 08 Aug 2002 10:51:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-592573 ] UserString is mutable via +=
Message-ID: <E17crRt-0000Vf-00@usw-sf-web5.sourceforge.net>

Bugs item #592573, was opened at 2002-08-08 07:48
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592573&group_id=5470

Category: Python Library
>Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Bernhard Herzog (bernhard)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: UserString is mutable via +=

Initial Comment:
UserString is mutable with augmented assignment:

Python 2.2 (#1, Jan 17 2002, 21:04:07) 
[GCC 2.95.4 20011006 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import UserString
>>> s = t = UserString.UserString("abc")
>>> s += "def"
>>> s
'abcdef'
>>> t
'abcdef'
>>> 


The __iadd__ and __imul__ methods should be in the
MutableString class I think.

OTOH, nowadays the string types can be sub-classed so
that UserString behaving exactly like a builtin string
may not be that important anymore.


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-08-08 12:51

Message:
Logged In: YES 
user_id=80475

Thanks for the bug report.

Will patch to bring behavior back in-line with string 
methods as promised by the docs.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592573&group_id=5470


From noreply@sourceforge.net  Thu Aug  8 19:25:18 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 08 Aug 2002 11:25:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-589262 ] socket.py wrapper needs a class
Message-ID: <E17cryI-0006Jm-00@usw-sf-web1.sourceforge.net>

Bugs item #589262, was opened at 2002-07-31 13:50
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=589262&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Guido van Rossum (gvanrossum)
Summary: socket.py wrapper needs a class

Initial Comment:
An easy one for the mildly ambitious <wink>:

"""
[Guido]
There's another change we should really make --
instead of a socket function, there should be a class
socket whose constructor does the work.  That's
necessary so that isinstance(s, socket.socket) works
on Windows; this currently works on Unix but not on 
Windows.
"""

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-08 14:25

Message:
Logged In: YES 
user_id=6380

I've checked this in now.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-07-31 16:44

Message:
Logged In: YES 
user_id=6380

Just email me the patch. (I think SF won't let you do this
because you didn't create the issue. sigh.)

----------------------------------------------------------------------

Comment By: Michael Gilfix (mgilfix)
Date: 2002-07-31 16:36

Message:
Logged In: YES 
user_id=116038

I have a patch for this but can't seem to attach a file
because it's assigned to Guido. Can you change the assignment?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=589262&group_id=5470


From noreply@sourceforge.net  Thu Aug  8 20:20:37 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 08 Aug 2002 12:20:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-592441 ] Webchecker error on http://www.naleo.org
Message-ID: <E17cspp-0000KA-00@usw-sf-web2.sourceforge.net>

Bugs item #592441, was opened at 2002-08-08 04:40
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592441&group_id=5470

Category: Demos and Tools
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Carlos Conti (mcsolrac)
Assigned to: Nobody/Anonymous (nobody)
Summary: Webchecker error on http://www.naleo.org

Initial Comment:
Webchecker version 1.25.6.1 on Windows 2000 
Professional. 

Run webchecker with this argument 
http://www.naleo.org/WSJArticle002.htm 
Webchecker will return this traceback: 

Traceback (most recent call last):
  File "C:\Python22\Tools\webchecker\webchecker.py", 
line 858, in ?
    main()
  File "C:\Python22\Tools\webchecker\webchecker.py", 
line 222, in main
    c.run()
  File "C:\Python22\Tools\webchecker\webchecker.py", 
line 349, in run
    self.dopage(url)
  File "C:\Python22\Tools\webchecker\webchecker.py", 
line 403, in dopage
    page = self.getpage(url_pair)
  File "C:\Python22\Tools\webchecker\webchecker.py", 
line 507, in getpage
    return Page(text, url, maxpage=self.maxpage, 
checker=self)
  File "C:\Python22\Tools\webchecker\webchecker.py", 
line 671, in __init__
    self.parser.feed(self.text)
  File "C:\Python22\lib\sgmllib.py", line 95, in feed
    self.goahead(0)
  File "C:\Python22\lib\sgmllib.py", line 161, in goahead
    k = self.parse_declaration(i)
  File "C:\Python22\lib\markupbase.py", line 66, in 
parse_declaration
    decltype, j = self._scan_name(j, i)
  File "C:\Python22\lib\markupbase.py", line 313, in 
_scan_name
    self.error("expected name token")
  File "C:\Python22\lib\sgmllib.py", line 102, in error
    raise SGMLParseError(message)
sgmllib.SGMLParseError: expected name token

I believe this is because of the xml in the source code 
(see WSJArticle002_source.txt attached to this bug 
report).

Even if the code in this page is poorly formatted, 
webchecker should be able continue checking other 
links in this domain (rather than stopping). For example 
webchecker could report “unable to check 
http://www.naleo.org/WSJArticle002.htm” and return 
traceback like the above, and then continue with the rest 
of the domain. 


----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-08-08 19:20

Message:
Logged In: YES 
user_id=31392

I've seen a variety of parsing problems kill webchecker.  I
agree that these exceptions should be caught somewhere so
that they are not fatal.  Care to submit a patch?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592441&group_id=5470


From noreply@sourceforge.net  Thu Aug  8 23:06:30 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 08 Aug 2002 15:06:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-592441 ] Webchecker error on http://www.naleo.org
Message-ID: <E17cvQM-000191-00@usw-sf-web3.sourceforge.net>

Bugs item #592441, was opened at 2002-08-08 00:40
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592441&group_id=5470

Category: Demos and Tools
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Carlos Conti (mcsolrac)
Assigned to: Nobody/Anonymous (nobody)
Summary: Webchecker error on http://www.naleo.org

Initial Comment:
Webchecker version 1.25.6.1 on Windows 2000 
Professional. 

Run webchecker with this argument 
http://www.naleo.org/WSJArticle002.htm 
Webchecker will return this traceback: 

Traceback (most recent call last):
  File "C:\Python22\Tools\webchecker\webchecker.py", 
line 858, in ?
    main()
  File "C:\Python22\Tools\webchecker\webchecker.py", 
line 222, in main
    c.run()
  File "C:\Python22\Tools\webchecker\webchecker.py", 
line 349, in run
    self.dopage(url)
  File "C:\Python22\Tools\webchecker\webchecker.py", 
line 403, in dopage
    page = self.getpage(url_pair)
  File "C:\Python22\Tools\webchecker\webchecker.py", 
line 507, in getpage
    return Page(text, url, maxpage=self.maxpage, 
checker=self)
  File "C:\Python22\Tools\webchecker\webchecker.py", 
line 671, in __init__
    self.parser.feed(self.text)
  File "C:\Python22\lib\sgmllib.py", line 95, in feed
    self.goahead(0)
  File "C:\Python22\lib\sgmllib.py", line 161, in goahead
    k = self.parse_declaration(i)
  File "C:\Python22\lib\markupbase.py", line 66, in 
parse_declaration
    decltype, j = self._scan_name(j, i)
  File "C:\Python22\lib\markupbase.py", line 313, in 
_scan_name
    self.error("expected name token")
  File "C:\Python22\lib\sgmllib.py", line 102, in error
    raise SGMLParseError(message)
sgmllib.SGMLParseError: expected name token

I believe this is because of the xml in the source code 
(see WSJArticle002_source.txt attached to this bug 
report).

Even if the code in this page is poorly formatted, 
webchecker should be able continue checking other 
links in this domain (rather than stopping). For example 
webchecker could report “unable to check 
http://www.naleo.org/WSJArticle002.htm” and return 
traceback like the above, and then continue with the rest 
of the domain. 


----------------------------------------------------------------------

>Comment By: Carlos Conti (mcsolrac)
Date: 2002-08-08 18:06

Message:
Logged In: YES 
user_id=591396

I'd love to submit a patch, but I am a newbie to both Python 
and programming. I apologize if this space is only intended 
for programmers; I am a QA engineer just getting acquainted 
to the wonderful world of Python. 

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-08-08 15:20

Message:
Logged In: YES 
user_id=31392

I've seen a variety of parsing problems kill webchecker.  I
agree that these exceptions should be caught somewhere so
that they are not fatal.  Care to submit a patch?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592441&group_id=5470


From noreply@sourceforge.net  Thu Aug  8 23:46:25 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 08 Aug 2002 15:46:25 -0700
Subject: [Python-bugs-list] [ python-Bugs-592859 ] os.chmod is underdocumented :-)
Message-ID: <E17cw2z-0004Eb-00@usw-sf-web2.sourceforge.net>

Bugs item #592859, was opened at 2002-08-08 15:46
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592859&group_id=5470

Category: Documentation
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Bjorn Pettersen (bpettersen)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: os.chmod is underdocumented :-)

Initial Comment:
Currently it says: "Change the mode of path to the 
numeric mode." I spent some time trying to figure out 
what mode should be on Windows before I looked in 
MSDN and did a grep over the Python Lib.

Could we add: "Constants defined for the numeric mode 
parameter are defined in the stat module. E.g. to make 
a file writable:

  os.chmod(filename, S_IWUSR|S_IWGRP|S_IWOTH)

or simply

  os.chmod(filename, S_IWRITE)

on Windows.
"

It would probably be a good idea to list the names for 
the permission bits in the stat docs also...

-- bjorn


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592859&group_id=5470


From noreply@sourceforge.net  Thu Aug  8 23:56:28 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 08 Aug 2002 15:56:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-592645 ] memory leak in socket.getaddrinfo
Message-ID: <E17cwCi-0007Gz-00@usw-sf-web4.sourceforge.net>

Bugs item #592645, was opened at 2002-08-08 17:34
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592645&group_id=5470

Category: Extension Modules
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Jean-Claude Rimbault (jcrimbault)
>Assigned to: Martin v. Löwis (loewis)
Summary: memory leak in socket.getaddrinfo

Initial Comment:
Function getaddrinfo of the socket module
fails to free system allocated result when the call is
successful
(but it does on error). Il should call freeaddrinfo to
free res0
before returning Python result.

This leak is also affecting httplib and urllib because
since Python 2.2, httplib.HTTPConnection.connect method
does call socket.getaddrinfo.

Small test program showing off the leak:

import socket, time

while 1:
    res = socket.getaddrinfo('localhost', 80, 0,
socket.SOCK_STREAM)
    time.sleep(0.01)


Tested with Python 2.2.1 under Linux 2.4

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592645&group_id=5470


From noreply@sourceforge.net  Fri Aug  9 00:09:44 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 08 Aug 2002 16:09:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-592446 ] missing extern "C"
Message-ID: <E17cwPY-0007Rk-00@usw-sf-web4.sourceforge.net>

Bugs item #592446, was opened at 2002-08-08 07:51
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592446&group_id=5470

Category: None
Group: Python 2.2.1
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: David Abrahams (david_abrahams)
Assigned to: Nobody/Anonymous (nobody)
>Summary: missing extern "C"

Initial Comment:
cxx: Error: ../../../libs/python/src/object/function.cpp, 
line 276: #144-D a
          value of type "PyObject *(*)(PyObject *, void *) 
C" cannot be used
          to initialize an entity of type "getter"
        {"__doc__", function_get_doc, (setter)
function_set_doc},

This indicates that the typedef "getter" for the function 
pointer type PyObject* (*)(PyObject*, void*) is missing 
the

 #ifdef __cplusplus
 extern "C" {
 #endif
  ...

 #ifdef __cplusplus
 }
 #endif

brackets

-Dave

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-08-09 01:09

Message:
Logged In: YES 
user_id=21627

This was fixed in descrobject.h 1.9, in response to your
patch 536908; to be released with Python 2.3.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592446&group_id=5470


From noreply@sourceforge.net  Fri Aug  9 00:12:35 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 08 Aug 2002 16:12:35 -0700
Subject: [Python-bugs-list] [ python-Bugs-589149 ] Memory leakage in SAX with exception
Message-ID: <E17cwSJ-0007VQ-00@usw-sf-web4.sourceforge.net>

Bugs item #589149, was opened at 2002-07-31 17:02
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=589149&group_id=5470

Category: XML
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Paolo Andreetto (pandreetto)
>Assigned to: Martin v. Löwis (loewis)
Summary: Memory leakage in SAX with exception

Initial Comment:
Trying the following test:

#!/usr/bin/python

import sys,string,StringIO,traceback,time,gc
import xml.sax,xml.sax.handler
gc.set_debug(gc.DEBUG_SAVEALL)

class SimpleHandler(xml.sax.handler.ContentHandler):
    def __init__(self):
        pass

    def startElement(self,name,attrs):
        print 'start ',name

    def endElement(self,name):
        print 'end ',name

    def characters(self,content):
        print content

class SimpleErrorHandler(xml.sax.handler.ErrorHandler):
    def __init__(self):
        pass
        
    def fatalError(self,e):
        print e

myHandler=SimpleHandler()
myErrHandler=SimpleErrorHandler()
data='<test>something</>'
while 1:
    gc.collect()
    print len(gc.garbage)
    
    try:
        #xml.sax.parseString(data,myHandler,myErrHandler)
        xml.sax.parseString(data,myHandler)
    except Exception, e:
        sinfo=sys.exc_info()
	traceback.print_tb(sinfo[2],None)
    time.sleep(1)

it seems that lots of object remain uncollectable.
Using the SimpleErrorHandler the behaviour of gc is
good but a memory leakage still remain (4Kb every 30
seconds).
Tests run on i386 with debian/Linux (sid), python 2.1.3
(Build of July 29th).

Thanks

----------------------------------------------------------------------

Comment By: Paolo Andreetto (pandreetto)
Date: 2002-08-05 10:25

Message:
Logged In: YES 
user_id=551296

This is correct, it's my fault, but removing the
gc.set_dubug instruction the situation doesn't change. The
script is just a simple test, my trouble comes from a memory
leakage into SOAPpy module which uses another SAX-based
XML-parser.
If you think the problem doesn't depends on the python core,
please close this bug.
Thanks

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-05 04:06

Message:
Logged In: YES 
user_id=21627

Your analysis of this result is wrong. Instead, the result
shows that all objects *are* collectible, and that there is
merely cyclic garbage in case of a parser error - this
garbage *will* be collected, unless you explicitly ask the
GC to save it (which you do in your example).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=589149&group_id=5470


From noreply@sourceforge.net  Fri Aug  9 01:56:09 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 08 Aug 2002 17:56:09 -0700
Subject: [Python-bugs-list] [ python-Bugs-556025 ] list(xrange(1e9))  -->  seg fault
Message-ID: <E17cy4X-0005fq-00@usw-sf-web1.sourceforge.net>

Bugs item #556025, was opened at 2002-05-14 12:41
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=556025&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Jason Tishler (jlt63)
Summary: list(xrange(1e9))  -->  seg fault

Initial Comment:
>From c.lang.py:

'''
 Python 2.2.1 (#2, Apr 21 2002, 22:22:55) 
[GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.62mdk)] 
on linux2
Type "help", "copyright", "credits" or "license" for 
more information.
>>> list(xrange(1e9))
Segmentation fault
'''

I've reproduced the same fault on Windows ME using 
Py2.2.0 and Py2.3a.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-08 20:56

Message:
Logged In: YES 
user_id=33168

I looked at the links.  I don't know what I can do to help.
 It seems like you proposed a reasonable solution and even
if it wasn't perfect, you still demonstrated a problem.  I
suppose I can only commiserate with you.

----------------------------------------------------------------------

Comment By: Jason Tishler (jlt63)
Date: 2002-08-08 08:11

Message:
Logged In: YES 
user_id=86216

> Jason, can you test/replicate this?

Yes, I've already been working on this one. See
the following mailing list threads for the details:

http://cygwin.com/ml/cygwin-developers/2002-07/msg00124.html
http://sources.redhat.com/ml/newlib/2002/msg00369.html

To summarize the above, the problem is actually
in newlib which provides Cygwin's libc (and
libm).  Unfortunately, Chris Falyor (the Cygwin
lead developer) has not been able to convince
the newlib maintainer to fix this problem.
Additionally, my first patch has been rejected.

I will continue my efforts to get this problem
resolved.  Any assistance will be greatly
appreciated.  I never expected to become an
expert in Doug Lea's malloc routines.  Sigh...

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-07 16:11

Message:
Logged In: YES 
user_id=33168

Actually, I think Jason may be more appropriate, since this
is a cygwin problem.  Jason, can you test/replicate this?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-07 14:20

Message:
Logged In: YES 
user_id=33168

Hmmm, Tim can you reproduce this?  I luckily don't have a
windows box. :-)

----------------------------------------------------------------------

Comment By: Steve Holden (holdenweb)
Date: 2002-08-07 13:28

Message:
Logged In: YES 
user_id=88157

I hope re-opening this is the right thing to do (I'm new here).

Current CVS fails under Win2000+Cygwin with a 
segmentation fault in the updated test_b1.py. Easily 
reproduced:

$ ./python.exe
Python 2.3a0 (#1, Aug  7 2002, 12:18:38)
[GCC 2.95.3-5 (cygwin special)] on cygwin
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import sys
>>> list(xrange(sys.maxint/4))
Segmentation fault (core dumped)

This does seem to be size-related, as:

>>> s = sys.maxint/8
>>> list(xrange(s))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
MemoryError

which is as expected in test_b1.py


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-22 19:20

Message:
Logged In: YES 
user_id=33168

Checked in as:
  listobject.c 2.106
  test_b1.py 1.46

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-21 08:59

Message:
Logged In: YES 
user_id=80475

Good plan!  Thx for squashing this bug. 

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-21 08:52

Message:
Logged In: YES 
user_id=33168

How about using sys.maxint / 4?  Does that make more sense
than 1e9?  This assumption is a little better, that the data
and address sizes are the same.  I can add a comment to this
effect.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-20 23:37

Message:
Logged In: YES 
user_id=80475

When you load the fix, please commit the regression test 
patch also.  Thx,  Raymond

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-05-20 22:51

Message:
Logged In: YES 
user_id=31435

Yup, lookin' better.  Python does assume 8-bit bytes in 
several places, and also 2's-complement integers.  Since 
size_t is guaranteed (by C) to be an unsigned type, the 
largest value of type size_t is more easily expressed as

(~(size_t)0)

The C part of the patch looks fine then.  The test is a 
little dubious:  who says the machine can't create a 
billion-integer list?  The idea that 1e9 necessarily 
overflows in this context is a 32-bit address-space 
assumption.  But I'm willing to delay fixing that until a 
machine with a usable larger address space appears <wink>.

So marked Accepted and assigned to you for checkin.  Thanks!

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-20 11:43

Message:
Logged In: YES 
user_id=33168

Ok, there were other problems, too:
  * Need to divide by the size of the type, 
    not >> 4 which was completely broken.
  * There was a missing PyErr_NoMemory().

I uploaded a new patch.

I'm not sure the size_t fix is correct.
I hope we can at least assume 8-bit machines: :-)

if (_new_size <= ((1 << (sizeof(size_t)*8 - 1)) / sizeof(type)))



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-05-20 00:48

Message:
Logged In: YES 
user_id=31435

The code patch has some problems:  you can't assume any 
relation between a size_t and an unsigned long; C simply 
doesn't define how big size_t is, and relative sizes do 
vary on 64-bit platforms.  However that gets fixed, if you 
decide it's "too big", var should be set to NULL (not 0 -- 
this is a "Guido thing" <wink>), and no exception should be 
set.  It's the caller's responsibility to check var for 
NULL after the macro is invoked, and set an appropriate 
exception.  listobject.c sometimes doesn't check the result 
for NULL, but that should only be when it knows it's 
*shrinking* a memory area, so that realloc can't fail.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-17 20:12

Message:
Logged In: YES 
user_id=80475

Added a patch to add this bug to the testbank.

Shallow code review:  Patch compiles okay (applied to 
Py2.3a0). Fixes the original problem.  Passes the smell 
test.  Macro style good (only the "var" operand is used 
more than once; no side-effects except setting "var" to 
zero upon a resize error).  Passes the standard regression 
tests.  Passes regression testing versus my personal (real 
code) testbank.

Will give it a deeper look this week-end.

One other thought: should the ValueError be replaced with a 
MemoryError to make the message consistent with PyList_New?



----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 17:03

Message:
Logged In: YES 
user_id=33168

Ok, this time I have a patch.  The patch only fixes listobject.

I looked over the other uses of PyMem_R{ESIZE,ALLOC}() and
they don't appear to be nearly as problematic as list.  For
example, if the grammar has 1e9 nodes, there are going to be
other problems well before then (ie, memory will probably be
gone).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 16:25

Message:
Logged In: YES 
user_id=33168

Oops, sorry about that last comment.  That was something I
was playing with.  The CVS version is fine for [x]range(float).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 16:22

Message:
Logged In: YES 
user_id=33168

Note, this problem is even more generic in CVS version:

>>> range(1.1)
Segmentation fault (core dumped)
>>> xrange(1.1)
Segmentation fault (core dumped)

[x]xrange(float) work fine in 2.2.1.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-14 20:44

Message:
Logged In: YES 
user_id=80475

Would there be some merit to converting PyMem_RESIZE to a 
function with an overflow check?  

I would guess that the time spent on a realloc dwarfs the 
overhead of a short wrapper function.

OTOH, I'll bet this core dump only occurs in toy examples 
and never in real code.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-05-14 18:15

Message:
Logged In: YES 
user_id=31435

Heh.  This is an instance of a general flaw:  the 
PyMem_RESIZE macro doesn't check for int overflow in its

    (n) * sizeof(type)

subexpression. The basic deal is that 1000000000 fits in an 
int, but 4 times that (silently) overflows.  In more 
detail, for this specific test case, listobject.c'.s 
roundupsize rounds 1e9 up to 0x40000000, which silently 
underflows to 0!() when PyMem_RESIZE multiplies it by 4.

Hard to know how to fix this in general; PyMem_RESIZE 
callers don't generally worry about overflow now.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=556025&group_id=5470


From noreply@sourceforge.net  Fri Aug  9 02:09:35 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 08 Aug 2002 18:09:35 -0700
Subject: [Python-bugs-list] [ python-Bugs-592573 ] UserString is mutable via +=
Message-ID: <E17cyHX-0005qN-00@usw-sf-web1.sourceforge.net>

Bugs item #592573, was opened at 2002-08-08 07:48
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592573&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Bernhard Herzog (bernhard)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: UserString is mutable via +=

Initial Comment:
UserString is mutable with augmented assignment:

Python 2.2 (#1, Jan 17 2002, 21:04:07) 
[GCC 2.95.4 20011006 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import UserString
>>> s = t = UserString.UserString("abc")
>>> s += "def"
>>> s
'abcdef'
>>> t
'abcdef'
>>> 


The __iadd__ and __imul__ methods should be in the
MutableString class I think.

OTOH, nowadays the string types can be sub-classed so
that UserString behaving exactly like a builtin string
may not be that important anymore.


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-08-08 20:09

Message:
Logged In: YES 
user_id=80475

Patch and unittest attached for review.
Possible 2.2 release-maint candidate.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-08-08 12:51

Message:
Logged In: YES 
user_id=80475

Thanks for the bug report.

Will patch to bring behavior back in-line with string 
methods as promised by the docs.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592573&group_id=5470


From noreply@sourceforge.net  Fri Aug  9 02:17:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 08 Aug 2002 18:17:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-586931 ] pydoc -w fails with path specified
Message-ID: <E17cyPS-0005xQ-00@usw-sf-web1.sourceforge.net>

Bugs item #586931, was opened at 2002-07-26 06:31
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=586931&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
>Assigned to: Ka-Ping Yee (ping)
Summary: pydoc -w fails with path specified

Initial Comment:
[from http://bugs.debian.org/143462]

If I specify a path (ie, ./dictclient.py) and use -w, it will 
fail.  If -w
is not used, or a module (ie, dictclient) is specified, it 
will work. 
Example:

$ pydoc2.2 -w ./dictclient.py
Traceback (most recent call last):
  File "/usr/bin/pydoc2.2", line 4, in ?
    pydoc.cli()
  File "/usr/lib/python2.2/pydoc.py", line 2074, in cli
    writedoc(arg)
  File "/usr/lib/python2.2/pydoc.py", line 1345, in writedoc
    object = locate(key, forceload)
  File "/usr/lib/python2.2/pydoc.py", line 1297, in locate
    parts = split(path, '.')
  File "/usr/lib/python2.2/string.py", line 117, in split
    return s.split(sep, maxsplit)
AttributeError: 'module' object has no attribute 'split'


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-08-08 21:17

Message:
Logged In: YES 
user_id=31435

Ping, if you're there, would you please take a look at this?  I 
didn't even know pydoc had a -w argument <0.9 wink> ...

----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2002-08-07 16:22

Message:
Logged In: YES 
user_id=60903

sorry for attaching the patch here (submitted on 
http://bugs.debian.org/143462)

[problem is found in 2.1, 2,2 and 2.3]

--- pydoc.py.old        Wed Aug  7 15:52:08 2002 
+++ pydoc.py    Wed Aug  7 15:51:10 2002 
@@ -1114,6 +1114,8 @@                
  
 def writedoc(key, forceload=0):                               
     """Write HTML documentation to a file in the current 
directory.""" 
+    if not isinstance(key, type('')):                      
+        key = key.__name__ 
     try: 
         object = locate(key, forceload) 
     except ErrorDuringImport, value: 


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-08-07 11:28

Message:
Logged In: YES 
user_id=3066

Tim is friends with pydoc.  ;-)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=586931&group_id=5470


From noreply@sourceforge.net  Fri Aug  9 02:22:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 08 Aug 2002 18:22:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-592573 ] UserString is mutable via +=
Message-ID: <E17cyTz-0006Ur-00@usw-sf-web2.sourceforge.net>

Bugs item #592573, was opened at 2002-08-08 08:48
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592573&group_id=5470

Category: Python Library
>Group: Python 2.3
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Bernhard Herzog (bernhard)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: UserString is mutable via +=

Initial Comment:
UserString is mutable with augmented assignment:

Python 2.2 (#1, Jan 17 2002, 21:04:07) 
[GCC 2.95.4 20011006 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import UserString
>>> s = t = UserString.UserString("abc")
>>> s += "def"
>>> s
'abcdef'
>>> t
'abcdef'
>>> 


The __iadd__ and __imul__ methods should be in the
MutableString class I think.

OTOH, nowadays the string types can be sub-classed so
that UserString behaving exactly like a builtin string
may not be that important anymore.


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-08 21:22

Message:
Logged In: YES 
user_id=6380

Hm, I think this is indeed a bug. I've never used UserString
myself nor reviewed the code. I think your patch is okay, so
go ahead in 2.3.

This will create a backwards incompatibility; I'm not sure
it's a good idea to "fix" it in 2.2.2.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-08-08 21:09

Message:
Logged In: YES 
user_id=80475

Patch and unittest attached for review.
Possible 2.2 release-maint candidate.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-08-08 13:51

Message:
Logged In: YES 
user_id=80475

Thanks for the bug report.

Will patch to bring behavior back in-line with string 
methods as promised by the docs.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592573&group_id=5470


From noreply@sourceforge.net  Fri Aug  9 02:41:00 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 08 Aug 2002 18:41:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-592573 ] UserString is mutable via +=
Message-ID: <E17cylw-000185-00@usw-sf-web4.sourceforge.net>

Bugs item #592573, was opened at 2002-08-08 07:48
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592573&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Bernhard Herzog (bernhard)
Assigned to: Raymond Hettinger (rhettinger)
Summary: UserString is mutable via +=

Initial Comment:
UserString is mutable with augmented assignment:

Python 2.2 (#1, Jan 17 2002, 21:04:07) 
[GCC 2.95.4 20011006 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import UserString
>>> s = t = UserString.UserString("abc")
>>> s += "def"
>>> s
'abcdef'
>>> t
'abcdef'
>>> 


The __iadd__ and __imul__ methods should be in the
MutableString class I think.

OTOH, nowadays the string types can be sub-classed so
that UserString behaving exactly like a builtin string
may not be that important anymore.


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-08-08 20:41

Message:
Logged In: YES 
user_id=80475

Thanks for the review.
Committed patch as:
  UserString 1.15
  string_tests.py 1.23
  test_string.py 1.19
  test_userstring.py 1.9

Agree that it should not be backported.
Marking bug as fixed and closing.

Bernhard, thanks for the clear bug report.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-08 20:22

Message:
Logged In: YES 
user_id=6380

Hm, I think this is indeed a bug. I've never used UserString
myself nor reviewed the code. I think your patch is okay, so
go ahead in 2.3.

This will create a backwards incompatibility; I'm not sure
it's a good idea to "fix" it in 2.2.2.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-08-08 20:09

Message:
Logged In: YES 
user_id=80475

Patch and unittest attached for review.
Possible 2.2 release-maint candidate.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-08-08 12:51

Message:
Logged In: YES 
user_id=80475

Thanks for the bug report.

Will patch to bring behavior back in-line with string 
methods as promised by the docs.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592573&group_id=5470


From noreply@sourceforge.net  Fri Aug  9 02:44:12 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 08 Aug 2002 18:44:12 -0700
Subject: [Python-bugs-list] [ python-Bugs-592859 ] os.chmod is underdocumented :-)
Message-ID: <E17cyp2-0001Ac-00@usw-sf-web4.sourceforge.net>

Bugs item #592859, was opened at 2002-08-08 17:46
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592859&group_id=5470

Category: Documentation
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Bjorn Pettersen (bpettersen)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: os.chmod is underdocumented :-)

Initial Comment:
Currently it says: "Change the mode of path to the 
numeric mode." I spent some time trying to figure out 
what mode should be on Windows before I looked in 
MSDN and did a grep over the Python Lib.

Could we add: "Constants defined for the numeric mode 
parameter are defined in the stat module. E.g. to make 
a file writable:

  os.chmod(filename, S_IWUSR|S_IWGRP|S_IWOTH)

or simply

  os.chmod(filename, S_IWRITE)

on Windows.
"

It would probably be a good idea to list the names for 
the permission bits in the stat docs also...

-- bjorn


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-08-08 20:44

Message:
Logged In: YES 
user_id=80475

I agree that the current docs are as clear as mud.
Will draft a clarification.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592859&group_id=5470


From noreply@sourceforge.net  Fri Aug  9 04:38:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 08 Aug 2002 20:38:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-592645 ] memory leak in socket.getaddrinfo
Message-ID: <E17d0bb-000836-00@usw-sf-web2.sourceforge.net>

Bugs item #592645, was opened at 2002-08-08 11:34
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592645&group_id=5470

Category: Extension Modules
Group: Python 2.2.1
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jean-Claude Rimbault (jcrimbault)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: memory leak in socket.getaddrinfo

Initial Comment:
Function getaddrinfo of the socket module
fails to free system allocated result when the call is
successful
(but it does on error). Il should call freeaddrinfo to
free res0
before returning Python result.

This leak is also affecting httplib and urllib because
since Python 2.2, httplib.HTTPConnection.connect method
does call socket.getaddrinfo.

Small test program showing off the leak:

import socket, time

while 1:
    res = socket.getaddrinfo('localhost', 80, 0,
socket.SOCK_STREAM)
    time.sleep(0.01)


Tested with Python 2.2.1 under Linux 2.4

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-08 23:38

Message:
Logged In: YES 
user_id=33168

You are correct.  Thanks!

Checked in as Modules/socketmodule.c 1.243 and 1.200.6.8.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592645&group_id=5470


From noreply@sourceforge.net  Fri Aug  9 04:43:56 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 08 Aug 2002 20:43:56 -0700
Subject: [Python-bugs-list] [ python-Bugs-592567 ] Bug with deepcopy and new style objects
Message-ID: <E17d0gu-0008Pn-00@usw-sf-web1.sourceforge.net>

Bugs item #592567, was opened at 2002-08-08 07:42
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592567&group_id=5470

Category: Python Library
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Jiba (jiba)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bug with deepcopy and new style objects

Initial Comment:
Deepcopying new style objects can bug if more than one
of such objects are deep copied at the same time (E.g.
you are deepcopying a list of two new style objects).

It seems that , in copy._reconstruct, the "state" 
variable should be "kept alive" (by passing it to the
"_keep_alive" function), since this state may be gc'ed,
and another state may be created later with the same
address memory / ID.

BTW, the same problem may arise with the "args"
variable, in the same function.

The included file demonstrates the bug.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-08-08 22:43

Message:
Logged In: YES 
user_id=80475

Confirmed on 2.2.1 and 2.3a:

Before deepcopying :
[11, 12, 13]
[21, 22, 23]
[31, 32, 33]

After deepcopying :
[11, 12, 13]
[11, 12, 13]
[11, 12, 13]


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592567&group_id=5470


From noreply@sourceforge.net  Fri Aug  9 09:26:08 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 09 Aug 2002 01:26:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-570044 ] "python -u" not binary on cygwin
Message-ID: <E17d560-0006vw-00@usw-sf-web4.sourceforge.net>

Bugs item #570044, was opened at 2002-06-17 15:56
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=570044&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Sjoerd Mullender (sjoerd)
>Assigned to: Jason Tishler (jlt63)
>Summary: "python -u" not binary on cygwin

Initial Comment:
python -u is supposed to put sys.stdin and sys.stdout
in binary mode on systems where such things matter.
This does not happen on Window under Cygwin.

Try
python -u -c 'import sys;
open("x","wb").write(sys.stdin.read())' < some-text-file

and notice that the newly created file "x" has just \n
line endings instead of \r\n.

A patch is included.

----------------------------------------------------------------------

>Comment By: Sjoerd Mullender (sjoerd)
Date: 2002-08-09 10:26

Message:
Logged In: YES 
user_id=43607

Assigned to Jason, since he seems to be the Cygwin expert. :-)
Does the patch make sense on other Cygwin installations than
my own?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=570044&group_id=5470


From noreply@sourceforge.net  Fri Aug  9 14:10:49 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 09 Aug 2002 06:10:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-570044 ] "python -u" not binary on cygwin
Message-ID: <E17d9XV-000452-00@usw-sf-web4.sourceforge.net>

Bugs item #570044, was opened at 2002-06-17 05:56
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=570044&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Sjoerd Mullender (sjoerd)
>Assigned to: Martin v. Löwis (loewis)
>Summary: "python -u" not binary on cygwin

Initial Comment:
python -u is supposed to put sys.stdin and sys.stdout
in binary mode on systems where such things matter.
This does not happen on Window under Cygwin.

Try
python -u -c 'import sys;
open("x","wb").write(sys.stdin.read())' < some-text-file

and notice that the newly created file "x" has just \n
line endings instead of \r\n.

A patch is included.

----------------------------------------------------------------------

>Comment By: Jason Tishler (jlt63)
Date: 2002-08-09 05:10

Message:
Logged In: YES 
user_id=86216

Martin,

This looks good.  Can I commit it?

Sjoerd,

> Does the patch make sense on other Cygwin
> installations than my own?

Yes, see below for the details.

My WAG is that you are using text mode mounts. Is
this correct? In my testing, I could only reproduce
this problem under text mode mounts -- never under
binary mode mounts.  Nevertheless, this patch
should be applied to guarantee proper behavior
regardless of the user's mount table.

Thanks for tracking down this issue and providing
a patch to fix it.

I wonder if there are any other binary vs. text
mode issues lurking...

BTW, the man page states the following:

-u     Force  stdin,  stdout  and  stderr  to  be
       totally unbuffered.

However, after reading the code, it is clear that
the "-u" option does more... :,)


----------------------------------------------------------------------

Comment By: Sjoerd Mullender (sjoerd)
Date: 2002-08-09 00:26

Message:
Logged In: YES 
user_id=43607

Assigned to Jason, since he seems to be the Cygwin expert. :-)
Does the patch make sense on other Cygwin installations than
my own?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=570044&group_id=5470


From noreply@sourceforge.net  Fri Aug  9 14:18:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 09 Aug 2002 06:18:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-570044 ] "python -u" not binary on cygwin
Message-ID: <E17d9eU-0002ro-00@usw-sf-web1.sourceforge.net>

Bugs item #570044, was opened at 2002-06-17 15:56
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=570044&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Sjoerd Mullender (sjoerd)
>Assigned to: Jason Tishler (jlt63)
>Summary: "python -u" not binary on cygwin

Initial Comment:
python -u is supposed to put sys.stdin and sys.stdout
in binary mode on systems where such things matter.
This does not happen on Window under Cygwin.

Try
python -u -c 'import sys;
open("x","wb").write(sys.stdin.read())' < some-text-file

and notice that the newly created file "x" has just \n
line endings instead of \r\n.

A patch is included.

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-08-09 15:18

Message:
Logged In: YES 
user_id=21627

The patch is fine, please apply it. Also add a note to
python.man documenting that this changes the streams to
binary mode.

----------------------------------------------------------------------

Comment By: Jason Tishler (jlt63)
Date: 2002-08-09 15:10

Message:
Logged In: YES 
user_id=86216

Martin,

This looks good.  Can I commit it?

Sjoerd,

> Does the patch make sense on other Cygwin
> installations than my own?

Yes, see below for the details.

My WAG is that you are using text mode mounts. Is
this correct? In my testing, I could only reproduce
this problem under text mode mounts -- never under
binary mode mounts.  Nevertheless, this patch
should be applied to guarantee proper behavior
regardless of the user's mount table.

Thanks for tracking down this issue and providing
a patch to fix it.

I wonder if there are any other binary vs. text
mode issues lurking...

BTW, the man page states the following:

-u     Force  stdin,  stdout  and  stderr  to  be
       totally unbuffered.

However, after reading the code, it is clear that
the "-u" option does more... :,)


----------------------------------------------------------------------

Comment By: Sjoerd Mullender (sjoerd)
Date: 2002-08-09 10:26

Message:
Logged In: YES 
user_id=43607

Assigned to Jason, since he seems to be the Cygwin expert. :-)
Does the patch make sense on other Cygwin installations than
my own?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=570044&group_id=5470


From noreply@sourceforge.net  Fri Aug  9 14:26:22 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 09 Aug 2002 06:26:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-570044 ] "python -u" not binary on cygwin
Message-ID: <E17d9mY-0001xA-00@usw-sf-web2.sourceforge.net>

Bugs item #570044, was opened at 2002-06-17 15:56
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=570044&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Sjoerd Mullender (sjoerd)
>Assigned to: Martin v. Löwis (loewis)
>Summary: "python -u" not binary on cygwin

Initial Comment:
python -u is supposed to put sys.stdin and sys.stdout
in binary mode on systems where such things matter.
This does not happen on Window under Cygwin.

Try
python -u -c 'import sys;
open("x","wb").write(sys.stdin.read())' < some-text-file

and notice that the newly created file "x" has just \n
line endings instead of \r\n.

A patch is included.

----------------------------------------------------------------------

>Comment By: Sjoerd Mullender (sjoerd)
Date: 2002-08-09 15:26

Message:
Logged In: YES 
user_id=43607

If a execute the command "mount" it mentions "binmode" on
every line, so I guess that means I'm not using text mode.

I think the documentation should be extended to mention this
binary mode stuff, but that should be a separate bug report.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-09 15:18

Message:
Logged In: YES 
user_id=21627

The patch is fine, please apply it. Also add a note to
python.man documenting that this changes the streams to
binary mode.

----------------------------------------------------------------------

Comment By: Jason Tishler (jlt63)
Date: 2002-08-09 15:10

Message:
Logged In: YES 
user_id=86216

Martin,

This looks good.  Can I commit it?

Sjoerd,

> Does the patch make sense on other Cygwin
> installations than my own?

Yes, see below for the details.

My WAG is that you are using text mode mounts. Is
this correct? In my testing, I could only reproduce
this problem under text mode mounts -- never under
binary mode mounts.  Nevertheless, this patch
should be applied to guarantee proper behavior
regardless of the user's mount table.

Thanks for tracking down this issue and providing
a patch to fix it.

I wonder if there are any other binary vs. text
mode issues lurking...

BTW, the man page states the following:

-u     Force  stdin,  stdout  and  stderr  to  be
       totally unbuffered.

However, after reading the code, it is clear that
the "-u" option does more... :,)


----------------------------------------------------------------------

Comment By: Sjoerd Mullender (sjoerd)
Date: 2002-08-09 10:26

Message:
Logged In: YES 
user_id=43607

Assigned to Jason, since he seems to be the Cygwin expert. :-)
Does the patch make sense on other Cygwin installations than
my own?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=570044&group_id=5470


From noreply@sourceforge.net  Fri Aug  9 14:38:21 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 09 Aug 2002 06:38:21 -0700
Subject: [Python-bugs-list] [ python-Bugs-570044 ] "python -u" not binary on cygwin
Message-ID: <E17d9y9-0004fr-00@usw-sf-web4.sourceforge.net>

Bugs item #570044, was opened at 2002-06-17 15:56
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=570044&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Sjoerd Mullender (sjoerd)
Assigned to: Martin v. Löwis (loewis)
>Summary: "python -u" not binary on cygwin

Initial Comment:
python -u is supposed to put sys.stdin and sys.stdout
in binary mode on systems where such things matter.
This does not happen on Window under Cygwin.

Try
python -u -c 'import sys;
open("x","wb").write(sys.stdin.read())' < some-text-file

and notice that the newly created file "x" has just \n
line endings instead of \r\n.

A patch is included.

----------------------------------------------------------------------

>Comment By: Sjoerd Mullender (sjoerd)
Date: 2002-08-09 15:38

Message:
Logged In: YES 
user_id=43607

I checked in the changes.

----------------------------------------------------------------------

Comment By: Sjoerd Mullender (sjoerd)
Date: 2002-08-09 15:26

Message:
Logged In: YES 
user_id=43607

If a execute the command "mount" it mentions "binmode" on
every line, so I guess that means I'm not using text mode.

I think the documentation should be extended to mention this
binary mode stuff, but that should be a separate bug report.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-09 15:18

Message:
Logged In: YES 
user_id=21627

The patch is fine, please apply it. Also add a note to
python.man documenting that this changes the streams to
binary mode.

----------------------------------------------------------------------

Comment By: Jason Tishler (jlt63)
Date: 2002-08-09 15:10

Message:
Logged In: YES 
user_id=86216

Martin,

This looks good.  Can I commit it?

Sjoerd,

> Does the patch make sense on other Cygwin
> installations than my own?

Yes, see below for the details.

My WAG is that you are using text mode mounts. Is
this correct? In my testing, I could only reproduce
this problem under text mode mounts -- never under
binary mode mounts.  Nevertheless, this patch
should be applied to guarantee proper behavior
regardless of the user's mount table.

Thanks for tracking down this issue and providing
a patch to fix it.

I wonder if there are any other binary vs. text
mode issues lurking...

BTW, the man page states the following:

-u     Force  stdin,  stdout  and  stderr  to  be
       totally unbuffered.

However, after reading the code, it is clear that
the "-u" option does more... :,)


----------------------------------------------------------------------

Comment By: Sjoerd Mullender (sjoerd)
Date: 2002-08-09 10:26

Message:
Logged In: YES 
user_id=43607

Assigned to Jason, since he seems to be the Cygwin expert. :-)
Does the patch make sense on other Cygwin installations than
my own?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=570044&group_id=5470


From noreply@sourceforge.net  Fri Aug  9 15:16:33 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 09 Aug 2002 07:16:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-590456 ] preconvert AppleSingle resource files
Message-ID: <E17dAZ7-0008AV-00@usw-sf-web3.sourceforge.net>

Bugs item #590456, was opened at 2002-08-03 08:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=590456&group_id=5470

Category: Macintosh
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Jack Jansen (jackjansen)
Summary: preconvert AppleSingle resource files

Initial Comment:
IDLE fails to start when using a recent Python 2.3 snapshot 
because it tries to write files in the Python.framework, which is not 
writeable by normal users. 

A traceback:

IOError: [Errno 13] Permission denied: '/Library/Frameworks/
Python.framework/Versions/2.3/Mac/Tools/IDE/Widgets.rsrc.
df.rsrc'
Traceback (most recent call last):
  File "./Mac/Tools/IDE/PythonIDE.py", line 35, in ?
  File "./Mac/Tools/IDE/PythonIDE.py", line 23, in init
  File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/
Lib/macresource.py"
, line 64, in need
    refno = open_pathname(pathname)
  File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/
Lib/macresource.py"
, line 92, in open_pathname
    pathname = _decode(pathname)
  File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/
Lib/macresource.py"
, line 104, in _decode
    applesingle.decode(pathname, newpathname, resonly=1)
  File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/
Lib/applesingle.py"
, line 74, in decode
    fp = open(output, 'wb')
IOError: [Errno 13] Permission denied: '/Library/Frameworks/
Python.framework/Versions/2.3/Mac/Tools/IDE/Widgets.rsrc.
df.rsrc'
Traceback (most recent call last):
  File "./Mac/Tools/IDE/PythonIDE.py", line 35, in ?
  File "./Mac/Tools/IDE/PythonIDE.py", line 23, in init
  File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/
Lib/macresource.py"
, line 64, in need
    refno = open_pathname(pathname)
  File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/
Lib/macresource.py"
, line 92, in open_pathname
    pathname = _decode(pathname)
  File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/
Lib/macresource.py"
, line 104, in _decode
    applesingle.decode(pathname, newpathname, resonly=1)
  File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/
Lib/applesingle.py"
, line 74, in decode
    fp = open(output, 'wb')


Initial reaction from Jack:

Ah! That's an interesting problem...

Here's what's going on, maybe someone here has good ideas on 
how to solve it.

The ".rsrc" files in the CVS tree aren't actually resource files: 
they're resource files encoded as AppleSingle. This is the way 
MacCVS manages to store two-fork files on a CVS server that is 
blissfully unaware of this Apple-ism. The macresourced module is 
aware that a .rsrc file can be either a bona-fide resource file or an 
AppleSingle file. In the latter case it decodes the file and caches 
the result as a ".rsrc.df.rsrc" file, with the resources in the data 
fork. But: if you can't write the directory where the .rsrc resides 
this fails.

Storing the files as datafork-based .rsrc files in CVS will make life 
miserable for me when building on OS9.

Checking the files out with MacCVS will make the standard unix 
tarball distribution non-functional on OSX.

Hmm, I could probably pre-convert the files while installing, similar 
to the precompilation step for .pyc and .pyo files....

Could you file a sourceforge bug report for this, please, so I won't 
forget?



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=590456&group_id=5470


From noreply@sourceforge.net  Fri Aug  9 15:17:21 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 09 Aug 2002 07:17:21 -0700
Subject: [Python-bugs-list] [ python-Bugs-590456 ] preconvert AppleSingle resource files
Message-ID: <E17dAZt-0008Bg-00@usw-sf-web3.sourceforge.net>

Bugs item #590456, was opened at 2002-08-03 08:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=590456&group_id=5470

Category: Macintosh
Group: Python 2.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Jack Jansen (jackjansen)
Summary: preconvert AppleSingle resource files

Initial Comment:
IDLE fails to start when using a recent Python 2.3 snapshot 
because it tries to write files in the Python.framework, which is not 
writeable by normal users. 

A traceback:

IOError: [Errno 13] Permission denied: '/Library/Frameworks/
Python.framework/Versions/2.3/Mac/Tools/IDE/Widgets.rsrc.
df.rsrc'
Traceback (most recent call last):
  File "./Mac/Tools/IDE/PythonIDE.py", line 35, in ?
  File "./Mac/Tools/IDE/PythonIDE.py", line 23, in init
  File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/
Lib/macresource.py"
, line 64, in need
    refno = open_pathname(pathname)
  File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/
Lib/macresource.py"
, line 92, in open_pathname
    pathname = _decode(pathname)
  File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/
Lib/macresource.py"
, line 104, in _decode
    applesingle.decode(pathname, newpathname, resonly=1)
  File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/
Lib/applesingle.py"
, line 74, in decode
    fp = open(output, 'wb')
IOError: [Errno 13] Permission denied: '/Library/Frameworks/
Python.framework/Versions/2.3/Mac/Tools/IDE/Widgets.rsrc.
df.rsrc'
Traceback (most recent call last):
  File "./Mac/Tools/IDE/PythonIDE.py", line 35, in ?
  File "./Mac/Tools/IDE/PythonIDE.py", line 23, in init
  File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/
Lib/macresource.py"
, line 64, in need
    refno = open_pathname(pathname)
  File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/
Lib/macresource.py"
, line 92, in open_pathname
    pathname = _decode(pathname)
  File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/
Lib/macresource.py"
, line 104, in _decode
    applesingle.decode(pathname, newpathname, resonly=1)
  File "/Library/Frameworks/Python.framework/Versions/2.3/Mac/
Lib/applesingle.py"
, line 74, in decode
    fp = open(output, 'wb')


Initial reaction from Jack:

Ah! That's an interesting problem...

Here's what's going on, maybe someone here has good ideas on 
how to solve it.

The ".rsrc" files in the CVS tree aren't actually resource files: 
they're resource files encoded as AppleSingle. This is the way 
MacCVS manages to store two-fork files on a CVS server that is 
blissfully unaware of this Apple-ism. The macresourced module is 
aware that a .rsrc file can be either a bona-fide resource file or an 
AppleSingle file. In the latter case it decodes the file and caches 
the result as a ".rsrc.df.rsrc" file, with the resources in the data 
fork. But: if you can't write the directory where the .rsrc resides 
this fails.

Storing the files as datafork-based .rsrc files in CVS will make life 
miserable for me when building on OS9.

Checking the files out with MacCVS will make the standard unix 
tarball distribution non-functional on OSX.

Hmm, I could probably pre-convert the files while installing, similar 
to the precompilation step for .pyc and .pyo files....

Could you file a sourceforge bug report for this, please, so I won't 
forget?



----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2002-08-09 16:17

Message:
Logged In: YES 
user_id=45365

Fixed in Mac/OSX/Makefile rev 1.21. We also repcompile the .py files now.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=590456&group_id=5470


From noreply@sourceforge.net  Fri Aug  9 15:24:17 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 09 Aug 2002 07:24:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-570044 ] "python -u" not binary on cygwin
Message-ID: <E17dAgb-0003Kh-00@usw-sf-web2.sourceforge.net>

Bugs item #570044, was opened at 2002-06-17 05:56
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=570044&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Sjoerd Mullender (sjoerd)
Assigned to: Martin v. Löwis (loewis)
>Summary: "python -u" not binary on cygwin

Initial Comment:
python -u is supposed to put sys.stdin and sys.stdout
in binary mode on systems where such things matter.
This does not happen on Window under Cygwin.

Try
python -u -c 'import sys;
open("x","wb").write(sys.stdin.read())' < some-text-file

and notice that the newly created file "x" has just \n
line endings instead of \r\n.

A patch is included.

----------------------------------------------------------------------

>Comment By: Jason Tishler (jlt63)
Date: 2002-08-09 06:24

Message:
Logged In: YES 
user_id=86216

> I checked in the changes.

Thanks!

> If a execute the command "mount" it mentions
> "binmode" on every line, so I guess that means
> I'm not using text mode.

What does "mount -p" indicate?  If textmode, was
your current working directory under the cygdrive
prefix?  If so, then we completely under this
issue. If not, then I'm at a loss to explain your
reported behavior.


----------------------------------------------------------------------

Comment By: Sjoerd Mullender (sjoerd)
Date: 2002-08-09 05:38

Message:
Logged In: YES 
user_id=43607

I checked in the changes.

----------------------------------------------------------------------

Comment By: Sjoerd Mullender (sjoerd)
Date: 2002-08-09 05:26

Message:
Logged In: YES 
user_id=43607

If a execute the command "mount" it mentions "binmode" on
every line, so I guess that means I'm not using text mode.

I think the documentation should be extended to mention this
binary mode stuff, but that should be a separate bug report.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-09 05:18

Message:
Logged In: YES 
user_id=21627

The patch is fine, please apply it. Also add a note to
python.man documenting that this changes the streams to
binary mode.

----------------------------------------------------------------------

Comment By: Jason Tishler (jlt63)
Date: 2002-08-09 05:10

Message:
Logged In: YES 
user_id=86216

Martin,

This looks good.  Can I commit it?

Sjoerd,

> Does the patch make sense on other Cygwin
> installations than my own?

Yes, see below for the details.

My WAG is that you are using text mode mounts. Is
this correct? In my testing, I could only reproduce
this problem under text mode mounts -- never under
binary mode mounts.  Nevertheless, this patch
should be applied to guarantee proper behavior
regardless of the user's mount table.

Thanks for tracking down this issue and providing
a patch to fix it.

I wonder if there are any other binary vs. text
mode issues lurking...

BTW, the man page states the following:

-u     Force  stdin,  stdout  and  stderr  to  be
       totally unbuffered.

However, after reading the code, it is clear that
the "-u" option does more... :,)


----------------------------------------------------------------------

Comment By: Sjoerd Mullender (sjoerd)
Date: 2002-08-09 00:26

Message:
Logged In: YES 
user_id=43607

Assigned to Jason, since he seems to be the Cygwin expert. :-)
Does the patch make sense on other Cygwin installations than
my own?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=570044&group_id=5470


From noreply@sourceforge.net  Fri Aug  9 15:41:24 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 09 Aug 2002 07:41:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-570044 ] "python -u" not binary on cygwin
Message-ID: <E17dAxA-0003nf-00@usw-sf-web2.sourceforge.net>

Bugs item #570044, was opened at 2002-06-17 15:56
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=570044&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Sjoerd Mullender (sjoerd)
Assigned to: Martin v. Löwis (loewis)
>Summary: "python -u" not binary on cygwin

Initial Comment:
python -u is supposed to put sys.stdin and sys.stdout
in binary mode on systems where such things matter.
This does not happen on Window under Cygwin.

Try
python -u -c 'import sys;
open("x","wb").write(sys.stdin.read())' < some-text-file

and notice that the newly created file "x" has just \n
line endings instead of \r\n.

A patch is included.

----------------------------------------------------------------------

>Comment By: Sjoerd Mullender (sjoerd)
Date: 2002-08-09 16:41

Message:
Logged In: YES 
user_id=43607

mount -p says
Prefix              Type         Flags
/cygdrive           system       binmode

Now that I look more carefully at the mount output, I see
that my current directory was mounted twice, once in
textmode and once in binmode.  To make a long story short,
the python I tried this on was running on textmode mount.

I guess we can close this now?

----------------------------------------------------------------------

Comment By: Jason Tishler (jlt63)
Date: 2002-08-09 16:24

Message:
Logged In: YES 
user_id=86216

> I checked in the changes.

Thanks!

> If a execute the command "mount" it mentions
> "binmode" on every line, so I guess that means
> I'm not using text mode.

What does "mount -p" indicate?  If textmode, was
your current working directory under the cygdrive
prefix?  If so, then we completely under this
issue. If not, then I'm at a loss to explain your
reported behavior.


----------------------------------------------------------------------

Comment By: Sjoerd Mullender (sjoerd)
Date: 2002-08-09 15:38

Message:
Logged In: YES 
user_id=43607

I checked in the changes.

----------------------------------------------------------------------

Comment By: Sjoerd Mullender (sjoerd)
Date: 2002-08-09 15:26

Message:
Logged In: YES 
user_id=43607

If a execute the command "mount" it mentions "binmode" on
every line, so I guess that means I'm not using text mode.

I think the documentation should be extended to mention this
binary mode stuff, but that should be a separate bug report.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-09 15:18

Message:
Logged In: YES 
user_id=21627

The patch is fine, please apply it. Also add a note to
python.man documenting that this changes the streams to
binary mode.

----------------------------------------------------------------------

Comment By: Jason Tishler (jlt63)
Date: 2002-08-09 15:10

Message:
Logged In: YES 
user_id=86216

Martin,

This looks good.  Can I commit it?

Sjoerd,

> Does the patch make sense on other Cygwin
> installations than my own?

Yes, see below for the details.

My WAG is that you are using text mode mounts. Is
this correct? In my testing, I could only reproduce
this problem under text mode mounts -- never under
binary mode mounts.  Nevertheless, this patch
should be applied to guarantee proper behavior
regardless of the user's mount table.

Thanks for tracking down this issue and providing
a patch to fix it.

I wonder if there are any other binary vs. text
mode issues lurking...

BTW, the man page states the following:

-u     Force  stdin,  stdout  and  stderr  to  be
       totally unbuffered.

However, after reading the code, it is clear that
the "-u" option does more... :,)


----------------------------------------------------------------------

Comment By: Sjoerd Mullender (sjoerd)
Date: 2002-08-09 10:26

Message:
Logged In: YES 
user_id=43607

Assigned to Jason, since he seems to be the Cygwin expert. :-)
Does the patch make sense on other Cygwin installations than
my own?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=570044&group_id=5470


From noreply@sourceforge.net  Fri Aug  9 15:50:43 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 09 Aug 2002 07:50:43 -0700
Subject: [Python-bugs-list] [ python-Bugs-558072 ] faqwiz.py could do email obfuscation
Message-ID: <E17dB6B-000597-00@usw-sf-web1.sourceforge.net>

Bugs item #558072, was opened at 2002-05-19 16:50
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=558072&group_id=5470

Category: Demos and Tools
Group: Feature Request
Status: Open
Resolution: None
>Priority: 3
Submitted By: Christian Reis (kiko_async)
Assigned to: Guido van Rossum (gvanrossum)
Summary: faqwiz.py could do email obfuscation

Initial Comment:
Faqwiz.py could obfuscate emails very easily, simply by
replacing @ by some other symbol in it's output. I've
homecooked a solution that basically involves:

adding to faqconf.py:

 # Obfuscate @ symbol as

 OBFUSCATE="-at-"

and changing interpolate() in faqwiz.py:

 def _interpolate(format, args, kw):
    try:
        quote = kw['_quote']
    except KeyError:
        quote = 1 
    d = (kw,) + args + (faqconf.__dict__,)
    m = MagicDict(d, quote)
    return string.replace(format % m, '@', OBFUSCATE)

This isn't my favourite solution, though, but since I
find the code a bit hard to follow, it suffices for
now. I'm willing to work a bit more on this if it
interests people.

----------------------------------------------------------------------

Comment By: Christian Reis (kiko_async)
Date: 2002-06-13 07:22

Message:
Logged In: YES 
user_id=222305

You're right, I did. The patch attached does it in a less
broken way, though I don't like the way I have to
permanently change last_changed_email - I just wanted to
obfuscate on the printing.

Anyway, since the link can't be a mailto anymore (which may
be considered a regression) I've removed the relevant link
from faqconf.py.

I've kept the faqconf.py OBFUSCATE symbol but am unsure as
to where it should go.

I've also rolled in two changes I did locally to my faqwiz.
The first one is a simple CSS mod that avoids the need for
an external image and makes the PRE sections highlight.

The second one is adding LABEL to the radiobuttons on the
front page and removing the "/"s and <BR> between the first
"query argument" options. It was confusing users at the
office. The LABEL tag allows you to click on the label and
have the radiobutton select, and is supported on superior
browsers (cough mozilla cough).

I'd appreciate comments, thanks.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-10 16:45

Message:
Logged In: YES 
user_id=6380

Clearly this does too much -- interpolate is used in a
number of contexts where a @ shouldn't be obfuscated, e.g.
commands to be executed by the shell.

I'm unclear on *where* you'd like to obfuscate email
addresses. Do you only want to obfuscate the email address
of the person who modified the entry, or do you want to
obfuscate all @ signs anywhere in the text? The latter seems
overkill, and can cause breakage in code samples that happen
to use @ signs.

BTW, you're right that this code is hard to follow! It could
benefit from a few comments here or there... :-(

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-05 14:46

Message:
Logged In: YES 
user_id=6380

Good idea.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=558072&group_id=5470


From noreply@sourceforge.net  Fri Aug  9 16:03:15 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 09 Aug 2002 08:03:15 -0700
Subject: [Python-bugs-list] [ python-Bugs-570044 ] "python -u" not binary on cygwin
Message-ID: <E17dBIJ-0005VS-00@usw-sf-web1.sourceforge.net>

Bugs item #570044, was opened at 2002-06-17 05:56
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=570044&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Sjoerd Mullender (sjoerd)
Assigned to: Martin v. Löwis (loewis)
>Summary: "python -u" not binary on cygwin

Initial Comment:
python -u is supposed to put sys.stdin and sys.stdout
in binary mode on systems where such things matter.
This does not happen on Window under Cygwin.

Try
python -u -c 'import sys;
open("x","wb").write(sys.stdin.read())' < some-text-file

and notice that the newly created file "x" has just \n
line endings instead of \r\n.

A patch is included.

----------------------------------------------------------------------

>Comment By: Jason Tishler (jlt63)
Date: 2002-08-09 07:03

Message:
Logged In: YES 
user_id=86216

> I guess we can close this now?

Yes.

----------------------------------------------------------------------

Comment By: Sjoerd Mullender (sjoerd)
Date: 2002-08-09 06:41

Message:
Logged In: YES 
user_id=43607

mount -p says
Prefix              Type         Flags
/cygdrive           system       binmode

Now that I look more carefully at the mount output, I see
that my current directory was mounted twice, once in
textmode and once in binmode.  To make a long story short,
the python I tried this on was running on textmode mount.

I guess we can close this now?

----------------------------------------------------------------------

Comment By: Jason Tishler (jlt63)
Date: 2002-08-09 06:24

Message:
Logged In: YES 
user_id=86216

> I checked in the changes.

Thanks!

> If a execute the command "mount" it mentions
> "binmode" on every line, so I guess that means
> I'm not using text mode.

What does "mount -p" indicate?  If textmode, was
your current working directory under the cygdrive
prefix?  If so, then we completely under this
issue. If not, then I'm at a loss to explain your
reported behavior.


----------------------------------------------------------------------

Comment By: Sjoerd Mullender (sjoerd)
Date: 2002-08-09 05:38

Message:
Logged In: YES 
user_id=43607

I checked in the changes.

----------------------------------------------------------------------

Comment By: Sjoerd Mullender (sjoerd)
Date: 2002-08-09 05:26

Message:
Logged In: YES 
user_id=43607

If a execute the command "mount" it mentions "binmode" on
every line, so I guess that means I'm not using text mode.

I think the documentation should be extended to mention this
binary mode stuff, but that should be a separate bug report.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-09 05:18

Message:
Logged In: YES 
user_id=21627

The patch is fine, please apply it. Also add a note to
python.man documenting that this changes the streams to
binary mode.

----------------------------------------------------------------------

Comment By: Jason Tishler (jlt63)
Date: 2002-08-09 05:10

Message:
Logged In: YES 
user_id=86216

Martin,

This looks good.  Can I commit it?

Sjoerd,

> Does the patch make sense on other Cygwin
> installations than my own?

Yes, see below for the details.

My WAG is that you are using text mode mounts. Is
this correct? In my testing, I could only reproduce
this problem under text mode mounts -- never under
binary mode mounts.  Nevertheless, this patch
should be applied to guarantee proper behavior
regardless of the user's mount table.

Thanks for tracking down this issue and providing
a patch to fix it.

I wonder if there are any other binary vs. text
mode issues lurking...

BTW, the man page states the following:

-u     Force  stdin,  stdout  and  stderr  to  be
       totally unbuffered.

However, after reading the code, it is clear that
the "-u" option does more... :,)


----------------------------------------------------------------------

Comment By: Sjoerd Mullender (sjoerd)
Date: 2002-08-09 00:26

Message:
Logged In: YES 
user_id=43607

Assigned to Jason, since he seems to be the Cygwin expert. :-)
Does the patch make sense on other Cygwin installations than
my own?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=570044&group_id=5470


From noreply@sourceforge.net  Fri Aug  9 16:10:21 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 09 Aug 2002 08:10:21 -0700
Subject: [Python-bugs-list] [ python-Bugs-570044 ] "python -u" not binary on cygwin
Message-ID: <E17dBPB-0001gW-00@usw-sf-web5.sourceforge.net>

Bugs item #570044, was opened at 2002-06-17 15:56
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=570044&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Sjoerd Mullender (sjoerd)
Assigned to: Martin v. Löwis (loewis)
>Summary: "python -u" not binary on cygwin

Initial Comment:
python -u is supposed to put sys.stdin and sys.stdout
in binary mode on systems where such things matter.
This does not happen on Window under Cygwin.

Try
python -u -c 'import sys;
open("x","wb").write(sys.stdin.read())' < some-text-file

and notice that the newly created file "x" has just \n
line endings instead of \r\n.

A patch is included.

----------------------------------------------------------------------

>Comment By: Sjoerd Mullender (sjoerd)
Date: 2002-08-09 17:10

Message:
Logged In: YES 
user_id=43607

Closed this bug.

----------------------------------------------------------------------

Comment By: Jason Tishler (jlt63)
Date: 2002-08-09 17:03

Message:
Logged In: YES 
user_id=86216

> I guess we can close this now?

Yes.

----------------------------------------------------------------------

Comment By: Sjoerd Mullender (sjoerd)
Date: 2002-08-09 16:41

Message:
Logged In: YES 
user_id=43607

mount -p says
Prefix              Type         Flags
/cygdrive           system       binmode

Now that I look more carefully at the mount output, I see
that my current directory was mounted twice, once in
textmode and once in binmode.  To make a long story short,
the python I tried this on was running on textmode mount.

I guess we can close this now?

----------------------------------------------------------------------

Comment By: Jason Tishler (jlt63)
Date: 2002-08-09 16:24

Message:
Logged In: YES 
user_id=86216

> I checked in the changes.

Thanks!

> If a execute the command "mount" it mentions
> "binmode" on every line, so I guess that means
> I'm not using text mode.

What does "mount -p" indicate?  If textmode, was
your current working directory under the cygdrive
prefix?  If so, then we completely under this
issue. If not, then I'm at a loss to explain your
reported behavior.


----------------------------------------------------------------------

Comment By: Sjoerd Mullender (sjoerd)
Date: 2002-08-09 15:38

Message:
Logged In: YES 
user_id=43607

I checked in the changes.

----------------------------------------------------------------------

Comment By: Sjoerd Mullender (sjoerd)
Date: 2002-08-09 15:26

Message:
Logged In: YES 
user_id=43607

If a execute the command "mount" it mentions "binmode" on
every line, so I guess that means I'm not using text mode.

I think the documentation should be extended to mention this
binary mode stuff, but that should be a separate bug report.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-09 15:18

Message:
Logged In: YES 
user_id=21627

The patch is fine, please apply it. Also add a note to
python.man documenting that this changes the streams to
binary mode.

----------------------------------------------------------------------

Comment By: Jason Tishler (jlt63)
Date: 2002-08-09 15:10

Message:
Logged In: YES 
user_id=86216

Martin,

This looks good.  Can I commit it?

Sjoerd,

> Does the patch make sense on other Cygwin
> installations than my own?

Yes, see below for the details.

My WAG is that you are using text mode mounts. Is
this correct? In my testing, I could only reproduce
this problem under text mode mounts -- never under
binary mode mounts.  Nevertheless, this patch
should be applied to guarantee proper behavior
regardless of the user's mount table.

Thanks for tracking down this issue and providing
a patch to fix it.

I wonder if there are any other binary vs. text
mode issues lurking...

BTW, the man page states the following:

-u     Force  stdin,  stdout  and  stderr  to  be
       totally unbuffered.

However, after reading the code, it is clear that
the "-u" option does more... :,)


----------------------------------------------------------------------

Comment By: Sjoerd Mullender (sjoerd)
Date: 2002-08-09 10:26

Message:
Logged In: YES 
user_id=43607

Assigned to Jason, since he seems to be the Cygwin expert. :-)
Does the patch make sense on other Cygwin installations than
my own?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=570044&group_id=5470


From noreply@sourceforge.net  Fri Aug  9 18:02:43 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 09 Aug 2002 10:02:43 -0700
Subject: [Python-bugs-list] [ python-Bugs-518846 ] exception cannot be new-style class
Message-ID: <E17dD9v-0006in-00@usw-sf-web2.sourceforge.net>

Bugs item #518846, was opened at 2002-02-17 15:09
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=518846&group_id=5470

Category: Type/class unification
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Heino (magnusheino)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: exception cannot be new-style class

Initial Comment:
[magnus@gills magnus]$ python2.2
Python 2.2 (#1, Jan 26 2002, 14:27:24)
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class foo(object):
...     pass
...
>>> raise foo()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: exceptions must be strings, classes, or instances, not foo
>>>


----------------------------------------------------------------------

Comment By: Phillip J. Eby (pje)
Date: 2002-07-11 16:12

Message:
Logged In: YES 
user_id=56214

Just to make things even more interesting, the current
'raise' code *will* let you raise a new-style instance that
derives from 'tuple'...  of course, what it actually raises
is the first element of said tuple-like thing.

It seems to me that the very first thing that should be
checked is whether the first argument to 'raise' is an
instance of Exception, and if so, take its type and go from
there.  This would support both old and new-style instances
of Exception subclasses, and I believe is the recommended
approach to using 'raise'.  (I.e., raise an instance of
something that subclasses Exception.)  All the other items
like strings, tuples, etc., should be checked *after* a
check for the "standard" approach, yes?


----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2002-07-11 13:07

Message:
Logged In: YES 
user_id=89016

test.py is a little script that executes various test cases.

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2002-07-11 12:12

Message:
Logged In: YES 
user_id=89016

What about the following patch (diff.txt):

It allows new style objects as exceptions and makes catching
exceptions by basetype possible:
    class newint(int):
        pass
    try:
        raise newint(42)
    except int, exc:
        print exc

With this patch subinstances of str become raisable and will
be caught be type not identity. This could be changed to
explicitely forbid str subinstances.

And
  raise type(None), None
becomes ambiguous: It is interpreted as
  raise type(None)
i.e. it raises the type(None) object as an exception, not
the object None (which is of type type(None))

As soon as Exception is a new style class we could limit the
allowed objects to (sub)instances of Exception.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-05 19:07

Message:
Logged In: YES 
user_id=6380

Sorry, HEAPTYPE is not the proper way to check for a
new-style class; it would exclude any new-style classes
defined by C code.  I also think that if you want to do this
it should done properly, and allow "raise C, C()" as well.

At best there's agreement that it's not worth trying to fix
Python to allow new-style classes as exceptions when we're
also trying to encourage that exceptions derive from
Exception.

If your module declares its exceptions as deriving from
Exception, a __metaclass__ = type should not have any effect
on the exceptions you declare.  So I'm not sure what your
problem is?

Here's another idea for a patch: a new-style class is
allowed as long as it also inherits from Exception.  (This
is possible!)

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-04-05 18:49

Message:
Logged In: YES 
user_id=31392

I don't realize there was agreement on this.  (I didn't 
follow the discussion closely.)  I don't understand why 
exceptions need to pass an isinstance() test on Exception.  
It didn't used to be this way, and it makes it hard to 
convert a module using __metaclass__ = type.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-04-05 18:44

Message:
Logged In: YES 
user_id=21627

I thought the agreement was that this is not a bug: You
cannot really expect exceptions to work unless you inherit
from Exception.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-04-05 18:38

Message:
Logged In: YES 
user_id=31392

Martin, I think the attached patch is sufficient.  It checks
object type's for Py_TPFLAGS_HEAPTYPE.  I believe this is
the current way to spell "new-style class" although the
spelling is odd if that's the meaning <0.2 wink>.

If this patch makes sense to you, I'll flesh it out with
some test cases and check it in.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-02-17 18:44

Message:
Logged In: YES 
user_id=21627

Interesting. I think we need to deprecate, then remove
string exception before allowing arbitrary objects as
exceptions. Or we could allow strings to be caught either by
__builtin__.str, or by an identical string.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=518846&group_id=5470


From noreply@sourceforge.net  Fri Aug  9 18:55:30 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 09 Aug 2002 10:55:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-593154 ] Can't assign to __name__ or __bases__
Message-ID: <E17dDz0-0000ek-00@usw-sf-web1.sourceforge.net>

Bugs item #593154, was opened at 2002-08-09 13:55
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=593154&group_id=5470

Category: Type/class unification
Group: Python 2.3
Status: Open
Resolution: None
Priority: 3
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Can't assign to __name__ or __bases__

Initial Comment:
While it's rarely useful, there *are* situations where
assigning to __name__ or __bases__ of a class might
make sense.  So maybe this should be allowed.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=593154&group_id=5470


From noreply@sourceforge.net  Fri Aug  9 19:09:42 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 09 Aug 2002 11:09:42 -0700
Subject: [Python-bugs-list] [ python-Bugs-556025 ] list(xrange(1e9))  -->  seg fault
Message-ID: <E17dECk-0000s2-00@usw-sf-web1.sourceforge.net>

Bugs item #556025, was opened at 2002-05-14 08:41
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=556025&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Jason Tishler (jlt63)
Summary: list(xrange(1e9))  -->  seg fault

Initial Comment:
>From c.lang.py:

'''
 Python 2.2.1 (#2, Apr 21 2002, 22:22:55) 
[GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.62mdk)] 
on linux2
Type "help", "copyright", "credits" or "license" for 
more information.
>>> list(xrange(1e9))
Segmentation fault
'''

I've reproduced the same fault on Windows ME using 
Py2.2.0 and Py2.3a.

----------------------------------------------------------------------

>Comment By: Jason Tishler (jlt63)
Date: 2002-08-09 10:09

Message:
Logged In: YES 
user_id=86216

Thanks for the sympathy.

I've tried, tried again:

http://sources.redhat.com/ml/newlib/2002/msg00390.html

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-08 16:56

Message:
Logged In: YES 
user_id=33168

I looked at the links.  I don't know what I can do to help.
 It seems like you proposed a reasonable solution and even
if it wasn't perfect, you still demonstrated a problem.  I
suppose I can only commiserate with you.

----------------------------------------------------------------------

Comment By: Jason Tishler (jlt63)
Date: 2002-08-08 04:11

Message:
Logged In: YES 
user_id=86216

> Jason, can you test/replicate this?

Yes, I've already been working on this one. See
the following mailing list threads for the details:

http://cygwin.com/ml/cygwin-developers/2002-07/msg00124.html
http://sources.redhat.com/ml/newlib/2002/msg00369.html

To summarize the above, the problem is actually
in newlib which provides Cygwin's libc (and
libm).  Unfortunately, Chris Falyor (the Cygwin
lead developer) has not been able to convince
the newlib maintainer to fix this problem.
Additionally, my first patch has been rejected.

I will continue my efforts to get this problem
resolved.  Any assistance will be greatly
appreciated.  I never expected to become an
expert in Doug Lea's malloc routines.  Sigh...

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-07 12:11

Message:
Logged In: YES 
user_id=33168

Actually, I think Jason may be more appropriate, since this
is a cygwin problem.  Jason, can you test/replicate this?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-07 10:20

Message:
Logged In: YES 
user_id=33168

Hmmm, Tim can you reproduce this?  I luckily don't have a
windows box. :-)

----------------------------------------------------------------------

Comment By: Steve Holden (holdenweb)
Date: 2002-08-07 09:28

Message:
Logged In: YES 
user_id=88157

I hope re-opening this is the right thing to do (I'm new here).

Current CVS fails under Win2000+Cygwin with a 
segmentation fault in the updated test_b1.py. Easily 
reproduced:

$ ./python.exe
Python 2.3a0 (#1, Aug  7 2002, 12:18:38)
[GCC 2.95.3-5 (cygwin special)] on cygwin
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import sys
>>> list(xrange(sys.maxint/4))
Segmentation fault (core dumped)

This does seem to be size-related, as:

>>> s = sys.maxint/8
>>> list(xrange(s))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
MemoryError

which is as expected in test_b1.py


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-22 15:20

Message:
Logged In: YES 
user_id=33168

Checked in as:
  listobject.c 2.106
  test_b1.py 1.46

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-21 04:59

Message:
Logged In: YES 
user_id=80475

Good plan!  Thx for squashing this bug. 

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-21 04:52

Message:
Logged In: YES 
user_id=33168

How about using sys.maxint / 4?  Does that make more sense
than 1e9?  This assumption is a little better, that the data
and address sizes are the same.  I can add a comment to this
effect.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-20 19:37

Message:
Logged In: YES 
user_id=80475

When you load the fix, please commit the regression test 
patch also.  Thx,  Raymond

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-05-20 18:51

Message:
Logged In: YES 
user_id=31435

Yup, lookin' better.  Python does assume 8-bit bytes in 
several places, and also 2's-complement integers.  Since 
size_t is guaranteed (by C) to be an unsigned type, the 
largest value of type size_t is more easily expressed as

(~(size_t)0)

The C part of the patch looks fine then.  The test is a 
little dubious:  who says the machine can't create a 
billion-integer list?  The idea that 1e9 necessarily 
overflows in this context is a 32-bit address-space 
assumption.  But I'm willing to delay fixing that until a 
machine with a usable larger address space appears <wink>.

So marked Accepted and assigned to you for checkin.  Thanks!

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-20 07:43

Message:
Logged In: YES 
user_id=33168

Ok, there were other problems, too:
  * Need to divide by the size of the type, 
    not >> 4 which was completely broken.
  * There was a missing PyErr_NoMemory().

I uploaded a new patch.

I'm not sure the size_t fix is correct.
I hope we can at least assume 8-bit machines: :-)

if (_new_size <= ((1 << (sizeof(size_t)*8 - 1)) / sizeof(type)))



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-05-19 20:48

Message:
Logged In: YES 
user_id=31435

The code patch has some problems:  you can't assume any 
relation between a size_t and an unsigned long; C simply 
doesn't define how big size_t is, and relative sizes do 
vary on 64-bit platforms.  However that gets fixed, if you 
decide it's "too big", var should be set to NULL (not 0 -- 
this is a "Guido thing" <wink>), and no exception should be 
set.  It's the caller's responsibility to check var for 
NULL after the macro is invoked, and set an appropriate 
exception.  listobject.c sometimes doesn't check the result 
for NULL, but that should only be when it knows it's 
*shrinking* a memory area, so that realloc can't fail.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-17 16:12

Message:
Logged In: YES 
user_id=80475

Added a patch to add this bug to the testbank.

Shallow code review:  Patch compiles okay (applied to 
Py2.3a0). Fixes the original problem.  Passes the smell 
test.  Macro style good (only the "var" operand is used 
more than once; no side-effects except setting "var" to 
zero upon a resize error).  Passes the standard regression 
tests.  Passes regression testing versus my personal (real 
code) testbank.

Will give it a deeper look this week-end.

One other thought: should the ValueError be replaced with a 
MemoryError to make the message consistent with PyList_New?



----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 13:03

Message:
Logged In: YES 
user_id=33168

Ok, this time I have a patch.  The patch only fixes listobject.

I looked over the other uses of PyMem_R{ESIZE,ALLOC}() and
they don't appear to be nearly as problematic as list.  For
example, if the grammar has 1e9 nodes, there are going to be
other problems well before then (ie, memory will probably be
gone).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 12:25

Message:
Logged In: YES 
user_id=33168

Oops, sorry about that last comment.  That was something I
was playing with.  The CVS version is fine for [x]range(float).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 12:22

Message:
Logged In: YES 
user_id=33168

Note, this problem is even more generic in CVS version:

>>> range(1.1)
Segmentation fault (core dumped)
>>> xrange(1.1)
Segmentation fault (core dumped)

[x]xrange(float) work fine in 2.2.1.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-14 16:44

Message:
Logged In: YES 
user_id=80475

Would there be some merit to converting PyMem_RESIZE to a 
function with an overflow check?  

I would guess that the time spent on a realloc dwarfs the 
overhead of a short wrapper function.

OTOH, I'll bet this core dump only occurs in toy examples 
and never in real code.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-05-14 14:15

Message:
Logged In: YES 
user_id=31435

Heh.  This is an instance of a general flaw:  the 
PyMem_RESIZE macro doesn't check for int overflow in its

    (n) * sizeof(type)

subexpression. The basic deal is that 1000000000 fits in an 
int, but 4 times that (silently) overflows.  In more 
detail, for this specific test case, listobject.c'.s 
roundupsize rounds 1e9 up to 0x40000000, which silently 
underflows to 0!() when PyMem_RESIZE multiplies it by 4.

Hard to know how to fix this in general; PyMem_RESIZE 
callers don't generally worry about overflow now.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=556025&group_id=5470


From noreply@sourceforge.net  Fri Aug  9 19:38:41 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 09 Aug 2002 11:38:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-591704 ] generators can't be weakly referenced
Message-ID: <E17dEen-000075-00@usw-sf-web2.sourceforge.net>

Bugs item #591704, was opened at 2002-08-06 15:10
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=591704&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: H. Richard Harkins (hrharkins)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: generators can't be weakly referenced

Initial Comment:
I can't seem to weakly reference generators.  I can't
think of a good reason that this shouldn't work.  Here
is a code snippet to demonstrate the issue:

>>> from __future__ import generators
>>> import weakref
>>> def f():
...   yield "HELLO"
...
>>> weakref.proxy(f())
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: cannot create weak reference to 'generator'
object
>>>



----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-08-09 14:38

Message:
Logged In: YES 
user_id=3066

I don't see any reason a generator-iterator shouldn't be
weakly referencable.  Fixing this and making the resulting
proxy useful involved:

Adding iterator protocol support to weakref.proxy objects:
Objects/weakrefobject.c 1.10

Adding weakref support to generator-iterator objects:
Python/ceval.c 2.323

Adding tests:
Lib/test/test_generators.py 1.37

I'm not sure if this counts as a new feature or not; I'll
leave that up to whoever's thinking about Python 2.2.2 (not me).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=591704&group_id=5470


From noreply@sourceforge.net  Fri Aug  9 21:16:30 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 09 Aug 2002 13:16:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-593154 ] Can't assign to __name__ or __bases__
Message-ID: <E17dGBS-0007Hi-00@usw-sf-web5.sourceforge.net>

Bugs item #593154, was opened at 2002-08-09 13:55
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=593154&group_id=5470

Category: Type/class unification
Group: Python 2.3
Status: Open
Resolution: None
Priority: 3
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Can't assign to __name__ or __bases__

Initial Comment:
While it's rarely useful, there *are* situations where
assigning to __name__ or __bases__ of a class might
make sense.  So maybe this should be allowed.

----------------------------------------------------------------------

Comment By: Gregory Smith (gregsmith)
Date: 2002-08-09 16:16

Message:
Logged In: YES 
user_id=292741

e.g.
def mkclass(cname,something):
    class lcl:
        def __init__(self):
       ... yada...
        def f(self, parm = something):
         ... yada ...

   ... yada...
    lcl.__name__ = cname
    return lcl


My understanding is that this function returns a different
class object (each cut from the same cloth, as it were)
each time it is called, but they all have the same name
by default.
If you are doing this (which is a cool thing to be able to do)
it certainly makes sense to give each class a different
name.  I just tried this,  however, and it seems to work.
__name__ got changed, and instances have the new name
in their default repr(). 



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=593154&group_id=5470


From noreply@sourceforge.net  Fri Aug  9 21:21:35 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 09 Aug 2002 13:21:35 -0700
Subject: [Python-bugs-list] [ python-Bugs-593154 ] Can't assign to __name__ or __bases__ of new class
Message-ID: <E17dGGN-0004Fs-00@usw-sf-web4.sourceforge.net>

Bugs item #593154, was opened at 2002-08-09 13:55
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=593154&group_id=5470

Category: Type/class unification
Group: Python 2.3
Status: Open
Resolution: None
Priority: 3
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Guido van Rossum (gvanrossum)
>Summary: Can't assign to __name__ or __bases__ of new class

Initial Comment:
While it's rarely useful, there *are* situations where
assigning to __name__ or __bases__ of a class might
make sense.  So maybe this should be allowed.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-09 16:21

Message:
Logged In: YES 
user_id=6380

I should've mentioned that this is only a problem for
new-style classes. To see the difference, try "class
lcl(object):" instead of "class lcl:" in your example.

But perhaps you should consider using a metaclass if you
really want the class objects to have different names.

----------------------------------------------------------------------

Comment By: Gregory Smith (gregsmith)
Date: 2002-08-09 16:16

Message:
Logged In: YES 
user_id=292741

e.g.
def mkclass(cname,something):
    class lcl:
        def __init__(self):
       ... yada...
        def f(self, parm = something):
         ... yada ...

   ... yada...
    lcl.__name__ = cname
    return lcl


My understanding is that this function returns a different
class object (each cut from the same cloth, as it were)
each time it is called, but they all have the same name
by default.
If you are doing this (which is a cool thing to be able to do)
it certainly makes sense to give each class a different
name.  I just tried this,  however, and it seems to work.
__name__ got changed, and instances have the new name
in their default repr(). 



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=593154&group_id=5470


From noreply@sourceforge.net  Fri Aug  9 21:24:19 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 09 Aug 2002 13:24:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-567576 ] tarball to untar into a single dir
Message-ID: <E17dGJ1-0007jx-00@usw-sf-web3.sourceforge.net>

Bugs item #567576, was opened at 2002-06-11 15:54
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=567576&group_id=5470

Category: Documentation
>Group: Feature Request
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: andrei kulakov (rainy)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: tarball to untar into a single dir

Initial Comment:
Python documentation tarball untars into many dirs and
files. Unix programs and archives usually untar into
one dir so as not to clutter ~user when untarred there.
Please fix!

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-08-09 16:24

Message:
Logged In: YES 
user_id=3066

I've made changes to the packaging that will be used for the
Python 2.3 documentation.  Each documentation package will
now unpack into a single directory, Python-Docs-$RELEASE,
which will contain all the files for the documentation
format which was downloaded.  I think it's safe to overlap
unpacking of multiple formats of the same release.

These changes will not be included in future releases of the
2.2.x series.

Changes committed to CVS:
Doc/Makefile 1.245
Doc/tools/mksourcepkg 1.6

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=567576&group_id=5470


From noreply@sourceforge.net  Fri Aug  9 22:28:26 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 09 Aug 2002 14:28:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-586926 ] Empty genindex.html pages
Message-ID: <E17dHJ4-0002f8-00@usw-sf-web2.sourceforge.net>

Bugs item #586926, was opened at 2002-07-26 06:25
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=586926&group_id=5470

Category: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Out of Date
Priority: 6
Submitted By: Matthias Klose (doko)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Empty genindex.html pages

Initial Comment:
When building the html docs, empty index pages are 
generated.

$ ls -l html/*/genindex.html
-rw-r--r--    1 doko     doko         3341 Jul 26 11:53 
html/api/genindex.html
-rw-r--r--    1 doko     doko         3433 Jul 26 11:59 
html/lib/genindex.html
-rw-r--r--    1 doko     doko         3436 Jul 26 12:00 
html/mac/genindex.html
-rw-r--r--    1 doko     doko         3322 Jul 26 12:00 
html/ref/genindex.html

compared to 2.1.3, built with texinfo-4.1:

$ ls -l html/*/genindex.html
-rw-r--r--    1 doko     doko        51726 Jul 26 11:42 
html/api/genindex.html
-rw-r--r--    1 doko     doko       310251 Jul 26 11:47 
html/lib/genindex.html
-rw-r--r--    1 doko     doko        28449 Jul 26 11:48 
html/mac/genindex.html
-rw-r--r--    1 doko     doko        73766 Jul 26 11:48 
html/ref/genindex.html

building the 2.1.3 docs with texinfo-4.2 fails as well. For 
2.2.1 and current CVS the empty files are generated 
independent of the texinfo version.

An account on a build environment can be provided 
(Debian 3.0).

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-08-09 17:28

Message:
Logged In: YES 
user_id=3066

This problem appears to have disappeared in the development
versions of the documentation at some point since the report
was filed.

If you see this only on documentation you generate rather
than the standarad documentation from python.org, please let
me know.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=586926&group_id=5470


From noreply@sourceforge.net  Fri Aug  9 23:53:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 09 Aug 2002 15:53:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-574939 ] Tex Macro Error
Message-ID: <E17dIcx-0006lb-00@usw-sf-web4.sourceforge.net>

Bugs item #574939, was opened at 2002-06-28 00:37
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574939&group_id=5470

Category: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Tex Macro Error

Initial Comment:
David Abrahams reported missing right parens for 
list.pop() and list.sort() in the docs at 
http://www.python.org/dev/doc/devel/lib/typesseq-
mutable.html 

I scanned forward and also found them missing for 
dict.get() and dict.setdefault().

The parens *are* in the tex files.  It appears that 
there is a strange interaction between the \optional 
macro and the enclosing \lineiii macro resulting in 
the paren being consumed.

Older versions of the docs are okay, so the bug is new.


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-08-09 18:53

Message:
Logged In: YES 
user_id=3066

Finally!  This was a bug in a modified version of the
support for the \optional macro in my working directory, and
was never checked in.  I've removed the changes from my
working directory, and will update the online version shortly.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574939&group_id=5470


From noreply@sourceforge.net  Fri Aug  9 23:58:48 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 09 Aug 2002 15:58:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-474986 ] minidom doesn't implement importNode()
Message-ID: <E17dIiW-0004Ol-00@usw-sf-web2.sourceforge.net>

Bugs item #474986, was opened at 2001-10-25 14:22
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=474986&group_id=5470

Category: XML
Group: Feature Request
Status: Open
Resolution: None
>Priority: 4
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: minidom doesn't implement importNode()

Initial Comment:
The Document.importNode() method has not been
implemented; this would be very useful for many
applications.

See:
http://mail.python.org/pipermail/xml-sig/2001-October/006252.html

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-08-09 18:58

Message:
Logged In: YES 
user_id=3066

This has been fixed in PyXML 0.8, and will be integrated in
Python before the 2.3 release cycle begins.  Left open so I
don't forget.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=474986&group_id=5470


From noreply@sourceforge.net  Sat Aug 10 02:02:43 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 09 Aug 2002 18:02:43 -0700
Subject: [Python-bugs-list] [ python-Bugs-556025 ] list(xrange(1e9))  -->  seg fault
Message-ID: <E17dKeR-0008QM-00@usw-sf-web4.sourceforge.net>

Bugs item #556025, was opened at 2002-05-14 08:41
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=556025&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Jason Tishler (jlt63)
Summary: list(xrange(1e9))  -->  seg fault

Initial Comment:
>From c.lang.py:

'''
 Python 2.2.1 (#2, Apr 21 2002, 22:22:55) 
[GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.62mdk)] 
on linux2
Type "help", "copyright", "credits" or "license" for 
more information.
>>> list(xrange(1e9))
Segmentation fault
'''

I've reproduced the same fault on Windows ME using 
Py2.2.0 and Py2.3a.

----------------------------------------------------------------------

>Comment By: Jason Tishler (jlt63)
Date: 2002-08-09 17:02

Message:
Logged In: YES 
user_id=86216

I guess that my perseverance paid off:

http://sources.redhat.com/ml/newlib/2002/msg00391.html

Hence, this bug will be fixed in Cygwin 1.3.13.

Can we close this bug now? Or, should we wait until
Cygwin 1.3.13 is released?

----------------------------------------------------------------------

Comment By: Jason Tishler (jlt63)
Date: 2002-08-09 10:09

Message:
Logged In: YES 
user_id=86216

Thanks for the sympathy.

I've tried, tried again:

http://sources.redhat.com/ml/newlib/2002/msg00390.html

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-08 16:56

Message:
Logged In: YES 
user_id=33168

I looked at the links.  I don't know what I can do to help.
 It seems like you proposed a reasonable solution and even
if it wasn't perfect, you still demonstrated a problem.  I
suppose I can only commiserate with you.

----------------------------------------------------------------------

Comment By: Jason Tishler (jlt63)
Date: 2002-08-08 04:11

Message:
Logged In: YES 
user_id=86216

> Jason, can you test/replicate this?

Yes, I've already been working on this one. See
the following mailing list threads for the details:

http://cygwin.com/ml/cygwin-developers/2002-07/msg00124.html
http://sources.redhat.com/ml/newlib/2002/msg00369.html

To summarize the above, the problem is actually
in newlib which provides Cygwin's libc (and
libm).  Unfortunately, Chris Falyor (the Cygwin
lead developer) has not been able to convince
the newlib maintainer to fix this problem.
Additionally, my first patch has been rejected.

I will continue my efforts to get this problem
resolved.  Any assistance will be greatly
appreciated.  I never expected to become an
expert in Doug Lea's malloc routines.  Sigh...

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-07 12:11

Message:
Logged In: YES 
user_id=33168

Actually, I think Jason may be more appropriate, since this
is a cygwin problem.  Jason, can you test/replicate this?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-07 10:20

Message:
Logged In: YES 
user_id=33168

Hmmm, Tim can you reproduce this?  I luckily don't have a
windows box. :-)

----------------------------------------------------------------------

Comment By: Steve Holden (holdenweb)
Date: 2002-08-07 09:28

Message:
Logged In: YES 
user_id=88157

I hope re-opening this is the right thing to do (I'm new here).

Current CVS fails under Win2000+Cygwin with a 
segmentation fault in the updated test_b1.py. Easily 
reproduced:

$ ./python.exe
Python 2.3a0 (#1, Aug  7 2002, 12:18:38)
[GCC 2.95.3-5 (cygwin special)] on cygwin
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import sys
>>> list(xrange(sys.maxint/4))
Segmentation fault (core dumped)

This does seem to be size-related, as:

>>> s = sys.maxint/8
>>> list(xrange(s))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
MemoryError

which is as expected in test_b1.py


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-22 15:20

Message:
Logged In: YES 
user_id=33168

Checked in as:
  listobject.c 2.106
  test_b1.py 1.46

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-21 04:59

Message:
Logged In: YES 
user_id=80475

Good plan!  Thx for squashing this bug. 

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-21 04:52

Message:
Logged In: YES 
user_id=33168

How about using sys.maxint / 4?  Does that make more sense
than 1e9?  This assumption is a little better, that the data
and address sizes are the same.  I can add a comment to this
effect.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-20 19:37

Message:
Logged In: YES 
user_id=80475

When you load the fix, please commit the regression test 
patch also.  Thx,  Raymond

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-05-20 18:51

Message:
Logged In: YES 
user_id=31435

Yup, lookin' better.  Python does assume 8-bit bytes in 
several places, and also 2's-complement integers.  Since 
size_t is guaranteed (by C) to be an unsigned type, the 
largest value of type size_t is more easily expressed as

(~(size_t)0)

The C part of the patch looks fine then.  The test is a 
little dubious:  who says the machine can't create a 
billion-integer list?  The idea that 1e9 necessarily 
overflows in this context is a 32-bit address-space 
assumption.  But I'm willing to delay fixing that until a 
machine with a usable larger address space appears <wink>.

So marked Accepted and assigned to you for checkin.  Thanks!

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-20 07:43

Message:
Logged In: YES 
user_id=33168

Ok, there were other problems, too:
  * Need to divide by the size of the type, 
    not >> 4 which was completely broken.
  * There was a missing PyErr_NoMemory().

I uploaded a new patch.

I'm not sure the size_t fix is correct.
I hope we can at least assume 8-bit machines: :-)

if (_new_size <= ((1 << (sizeof(size_t)*8 - 1)) / sizeof(type)))



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-05-19 20:48

Message:
Logged In: YES 
user_id=31435

The code patch has some problems:  you can't assume any 
relation between a size_t and an unsigned long; C simply 
doesn't define how big size_t is, and relative sizes do 
vary on 64-bit platforms.  However that gets fixed, if you 
decide it's "too big", var should be set to NULL (not 0 -- 
this is a "Guido thing" <wink>), and no exception should be 
set.  It's the caller's responsibility to check var for 
NULL after the macro is invoked, and set an appropriate 
exception.  listobject.c sometimes doesn't check the result 
for NULL, but that should only be when it knows it's 
*shrinking* a memory area, so that realloc can't fail.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-17 16:12

Message:
Logged In: YES 
user_id=80475

Added a patch to add this bug to the testbank.

Shallow code review:  Patch compiles okay (applied to 
Py2.3a0). Fixes the original problem.  Passes the smell 
test.  Macro style good (only the "var" operand is used 
more than once; no side-effects except setting "var" to 
zero upon a resize error).  Passes the standard regression 
tests.  Passes regression testing versus my personal (real 
code) testbank.

Will give it a deeper look this week-end.

One other thought: should the ValueError be replaced with a 
MemoryError to make the message consistent with PyList_New?



----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 13:03

Message:
Logged In: YES 
user_id=33168

Ok, this time I have a patch.  The patch only fixes listobject.

I looked over the other uses of PyMem_R{ESIZE,ALLOC}() and
they don't appear to be nearly as problematic as list.  For
example, if the grammar has 1e9 nodes, there are going to be
other problems well before then (ie, memory will probably be
gone).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 12:25

Message:
Logged In: YES 
user_id=33168

Oops, sorry about that last comment.  That was something I
was playing with.  The CVS version is fine for [x]range(float).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 12:22

Message:
Logged In: YES 
user_id=33168

Note, this problem is even more generic in CVS version:

>>> range(1.1)
Segmentation fault (core dumped)
>>> xrange(1.1)
Segmentation fault (core dumped)

[x]xrange(float) work fine in 2.2.1.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-14 16:44

Message:
Logged In: YES 
user_id=80475

Would there be some merit to converting PyMem_RESIZE to a 
function with an overflow check?  

I would guess that the time spent on a realloc dwarfs the 
overhead of a short wrapper function.

OTOH, I'll bet this core dump only occurs in toy examples 
and never in real code.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-05-14 14:15

Message:
Logged In: YES 
user_id=31435

Heh.  This is an instance of a general flaw:  the 
PyMem_RESIZE macro doesn't check for int overflow in its

    (n) * sizeof(type)

subexpression. The basic deal is that 1000000000 fits in an 
int, but 4 times that (silently) overflows.  In more 
detail, for this specific test case, listobject.c'.s 
roundupsize rounds 1e9 up to 0x40000000, which silently 
underflows to 0!() when PyMem_RESIZE multiplies it by 4.

Hard to know how to fix this in general; PyMem_RESIZE 
callers don't generally worry about overflow now.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=556025&group_id=5470


From noreply@sourceforge.net  Sat Aug 10 04:08:28 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 09 Aug 2002 20:08:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-556025 ] list(xrange(1e9))  -->  seg fault
Message-ID: <E17dMc8-0002fW-00@usw-sf-web1.sourceforge.net>

Bugs item #556025, was opened at 2002-05-14 11:41
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=556025&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Jason Tishler (jlt63)
Summary: list(xrange(1e9))  -->  seg fault

Initial Comment:
>From c.lang.py:

'''
 Python 2.2.1 (#2, Apr 21 2002, 22:22:55) 
[GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.62mdk)] 
on linux2
Type "help", "copyright", "credits" or "license" for 
more information.
>>> list(xrange(1e9))
Segmentation fault
'''

I've reproduced the same fault on Windows ME using 
Py2.2.0 and Py2.3a.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-08-09 22:08

Message:
Logged In: YES 
user_id=80475

My thought is to close the bug, but add a unittest that 
says in effect:  if os is cygwin and version(cygwin) >= 
1.3.13 and the bug still exists, then fail with a message 
saying that SF 556025 was not successfully resolved.

This way, we can close the bug (since it is not a python 
bug) and still get a regression test to raise the concern if 
the expected solution either doesn't materialize or 
sometime later dematerializes.


----------------------------------------------------------------------

Comment By: Jason Tishler (jlt63)
Date: 2002-08-09 20:02

Message:
Logged In: YES 
user_id=86216

I guess that my perseverance paid off:

http://sources.redhat.com/ml/newlib/2002/msg00391.html

Hence, this bug will be fixed in Cygwin 1.3.13.

Can we close this bug now? Or, should we wait until
Cygwin 1.3.13 is released?

----------------------------------------------------------------------

Comment By: Jason Tishler (jlt63)
Date: 2002-08-09 13:09

Message:
Logged In: YES 
user_id=86216

Thanks for the sympathy.

I've tried, tried again:

http://sources.redhat.com/ml/newlib/2002/msg00390.html

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-08 19:56

Message:
Logged In: YES 
user_id=33168

I looked at the links.  I don't know what I can do to help.
 It seems like you proposed a reasonable solution and even
if it wasn't perfect, you still demonstrated a problem.  I
suppose I can only commiserate with you.

----------------------------------------------------------------------

Comment By: Jason Tishler (jlt63)
Date: 2002-08-08 07:11

Message:
Logged In: YES 
user_id=86216

> Jason, can you test/replicate this?

Yes, I've already been working on this one. See
the following mailing list threads for the details:

http://cygwin.com/ml/cygwin-developers/2002-07/msg00124.html
http://sources.redhat.com/ml/newlib/2002/msg00369.html

To summarize the above, the problem is actually
in newlib which provides Cygwin's libc (and
libm).  Unfortunately, Chris Falyor (the Cygwin
lead developer) has not been able to convince
the newlib maintainer to fix this problem.
Additionally, my first patch has been rejected.

I will continue my efforts to get this problem
resolved.  Any assistance will be greatly
appreciated.  I never expected to become an
expert in Doug Lea's malloc routines.  Sigh...

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-07 15:11

Message:
Logged In: YES 
user_id=33168

Actually, I think Jason may be more appropriate, since this
is a cygwin problem.  Jason, can you test/replicate this?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-07 13:20

Message:
Logged In: YES 
user_id=33168

Hmmm, Tim can you reproduce this?  I luckily don't have a
windows box. :-)

----------------------------------------------------------------------

Comment By: Steve Holden (holdenweb)
Date: 2002-08-07 12:28

Message:
Logged In: YES 
user_id=88157

I hope re-opening this is the right thing to do (I'm new here).

Current CVS fails under Win2000+Cygwin with a 
segmentation fault in the updated test_b1.py. Easily 
reproduced:

$ ./python.exe
Python 2.3a0 (#1, Aug  7 2002, 12:18:38)
[GCC 2.95.3-5 (cygwin special)] on cygwin
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import sys
>>> list(xrange(sys.maxint/4))
Segmentation fault (core dumped)

This does seem to be size-related, as:

>>> s = sys.maxint/8
>>> list(xrange(s))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
MemoryError

which is as expected in test_b1.py


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-22 18:20

Message:
Logged In: YES 
user_id=33168

Checked in as:
  listobject.c 2.106
  test_b1.py 1.46

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-21 07:59

Message:
Logged In: YES 
user_id=80475

Good plan!  Thx for squashing this bug. 

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-21 07:52

Message:
Logged In: YES 
user_id=33168

How about using sys.maxint / 4?  Does that make more sense
than 1e9?  This assumption is a little better, that the data
and address sizes are the same.  I can add a comment to this
effect.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-20 22:37

Message:
Logged In: YES 
user_id=80475

When you load the fix, please commit the regression test 
patch also.  Thx,  Raymond

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-05-20 21:51

Message:
Logged In: YES 
user_id=31435

Yup, lookin' better.  Python does assume 8-bit bytes in 
several places, and also 2's-complement integers.  Since 
size_t is guaranteed (by C) to be an unsigned type, the 
largest value of type size_t is more easily expressed as

(~(size_t)0)

The C part of the patch looks fine then.  The test is a 
little dubious:  who says the machine can't create a 
billion-integer list?  The idea that 1e9 necessarily 
overflows in this context is a 32-bit address-space 
assumption.  But I'm willing to delay fixing that until a 
machine with a usable larger address space appears <wink>.

So marked Accepted and assigned to you for checkin.  Thanks!

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-20 10:43

Message:
Logged In: YES 
user_id=33168

Ok, there were other problems, too:
  * Need to divide by the size of the type, 
    not >> 4 which was completely broken.
  * There was a missing PyErr_NoMemory().

I uploaded a new patch.

I'm not sure the size_t fix is correct.
I hope we can at least assume 8-bit machines: :-)

if (_new_size <= ((1 << (sizeof(size_t)*8 - 1)) / sizeof(type)))



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-05-19 23:48

Message:
Logged In: YES 
user_id=31435

The code patch has some problems:  you can't assume any 
relation between a size_t and an unsigned long; C simply 
doesn't define how big size_t is, and relative sizes do 
vary on 64-bit platforms.  However that gets fixed, if you 
decide it's "too big", var should be set to NULL (not 0 -- 
this is a "Guido thing" <wink>), and no exception should be 
set.  It's the caller's responsibility to check var for 
NULL after the macro is invoked, and set an appropriate 
exception.  listobject.c sometimes doesn't check the result 
for NULL, but that should only be when it knows it's 
*shrinking* a memory area, so that realloc can't fail.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-17 19:12

Message:
Logged In: YES 
user_id=80475

Added a patch to add this bug to the testbank.

Shallow code review:  Patch compiles okay (applied to 
Py2.3a0). Fixes the original problem.  Passes the smell 
test.  Macro style good (only the "var" operand is used 
more than once; no side-effects except setting "var" to 
zero upon a resize error).  Passes the standard regression 
tests.  Passes regression testing versus my personal (real 
code) testbank.

Will give it a deeper look this week-end.

One other thought: should the ValueError be replaced with a 
MemoryError to make the message consistent with PyList_New?



----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 16:03

Message:
Logged In: YES 
user_id=33168

Ok, this time I have a patch.  The patch only fixes listobject.

I looked over the other uses of PyMem_R{ESIZE,ALLOC}() and
they don't appear to be nearly as problematic as list.  For
example, if the grammar has 1e9 nodes, there are going to be
other problems well before then (ie, memory will probably be
gone).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 15:25

Message:
Logged In: YES 
user_id=33168

Oops, sorry about that last comment.  That was something I
was playing with.  The CVS version is fine for [x]range(float).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 15:22

Message:
Logged In: YES 
user_id=33168

Note, this problem is even more generic in CVS version:

>>> range(1.1)
Segmentation fault (core dumped)
>>> xrange(1.1)
Segmentation fault (core dumped)

[x]xrange(float) work fine in 2.2.1.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-14 19:44

Message:
Logged In: YES 
user_id=80475

Would there be some merit to converting PyMem_RESIZE to a 
function with an overflow check?  

I would guess that the time spent on a realloc dwarfs the 
overhead of a short wrapper function.

OTOH, I'll bet this core dump only occurs in toy examples 
and never in real code.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-05-14 17:15

Message:
Logged In: YES 
user_id=31435

Heh.  This is an instance of a general flaw:  the 
PyMem_RESIZE macro doesn't check for int overflow in its

    (n) * sizeof(type)

subexpression. The basic deal is that 1000000000 fits in an 
int, but 4 times that (silently) overflows.  In more 
detail, for this specific test case, listobject.c'.s 
roundupsize rounds 1e9 up to 0x40000000, which silently 
underflows to 0!() when PyMem_RESIZE multiplies it by 4.

Hard to know how to fix this in general; PyMem_RESIZE 
callers don't generally worry about overflow now.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=556025&group_id=5470


From noreply@sourceforge.net  Sat Aug 10 04:17:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 09 Aug 2002 20:17:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-592527 ] comments taken as values in ConfigParser
Message-ID: <E17dMkQ-0002o9-00@usw-sf-web1.sourceforge.net>

Bugs item #592527, was opened at 2002-08-08 05:11
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592527&group_id=5470

Category: Python Library
Group: 3rd Party
Status: Open
Resolution: None
Priority: 5
Submitted By: Art&#363;ras Kriukovas (drugelis)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: comments taken as values in ConfigParser

Initial Comment:
Let's say we have config file config.conf with contents:


[forms]
....
myParameter = myValue # my comment here :) 
# and my comment here
....

[other sections]
.......


We run python code:

    import sys, os
    from ConfigParser import *
    fileLocations = ['......./config.conf']
    parser = ConfigParser()
    parser.read(fileLocations)
    parser.sections()

and when we run:
    parser.get('forms', 'manoParameter')

we get:
    'myValue # my comment here :)'

The comment is also included as key value. The second
comment is left out as it should be.
The simpliest way to fix it probaby would be remove all
string after the first '#' char (that is to leave
string part to first '#' char).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592527&group_id=5470


From noreply@sourceforge.net  Sat Aug 10 07:12:10 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 09 Aug 2002 23:12:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-586926 ] Empty genindex.html pages
Message-ID: <E17dPTu-0007OS-00@usw-sf-web5.sourceforge.net>

Bugs item #586926, was opened at 2002-07-26 10:25
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=586926&group_id=5470

Category: Documentation
Group: Python 2.3
>Status: Open
>Resolution: Invalid
Priority: 6
Submitted By: Matthias Klose (doko)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Empty genindex.html pages

Initial Comment:
When building the html docs, empty index pages are 
generated.

$ ls -l html/*/genindex.html
-rw-r--r--    1 doko     doko         3341 Jul 26 11:53 
html/api/genindex.html
-rw-r--r--    1 doko     doko         3433 Jul 26 11:59 
html/lib/genindex.html
-rw-r--r--    1 doko     doko         3436 Jul 26 12:00 
html/mac/genindex.html
-rw-r--r--    1 doko     doko         3322 Jul 26 12:00 
html/ref/genindex.html

compared to 2.1.3, built with texinfo-4.1:

$ ls -l html/*/genindex.html
-rw-r--r--    1 doko     doko        51726 Jul 26 11:42 
html/api/genindex.html
-rw-r--r--    1 doko     doko       310251 Jul 26 11:47 
html/lib/genindex.html
-rw-r--r--    1 doko     doko        28449 Jul 26 11:48 
html/mac/genindex.html
-rw-r--r--    1 doko     doko        73766 Jul 26 11:48 
html/ref/genindex.html

building the 2.1.3 docs with texinfo-4.2 fails as well. For 
2.2.1 and current CVS the empty files are generated 
independent of the texinfo version.

An account on a build environment can be provided 
(Debian 3.0).

----------------------------------------------------------------------

>Comment By: Matthias Klose (doko)
Date: 2002-08-10 06:12

Message:
Logged In: YES 
user_id=60903

Just rechecked. The problem is still there (trying to
generate the documentation for today's CVS).


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-08-09 21:28

Message:
Logged In: YES 
user_id=3066

This problem appears to have disappeared in the development
versions of the documentation at some point since the report
was filed.

If you see this only on documentation you generate rather
than the standarad documentation from python.org, please let
me know.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=586926&group_id=5470


From noreply@sourceforge.net  Sat Aug 10 07:21:10 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 09 Aug 2002 23:21:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-591104 ] os.tmpfile() can fail on win32
Message-ID: <E17dPcc-000421-00@usw-sf-web4.sourceforge.net>

Bugs item #591104, was opened at 2002-08-05 09:23
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=591104&group_id=5470

Category: Windows
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Joseph Barillari (jdbarillari)
Assigned to: Mark Hammond (mhammond)
Summary: os.tmpfile() can fail on win32

Initial Comment:
I've discovered what appears to be a bug in Python 2.2.1 
on Win32. I'm
using the 2.2.1 build that I downloaded from python.org. 
I'm running
Windows 2000.

If os.tmpfile() is exceuted when the CWD is a UNC path, 
the base of
which is not writeable by the current user, tmpfile will
fail. tempfile.TemporaryFile will work, so I suspect this is 
a bug in os.tmpfile().

For example:

C:\>pwd  
/cygdrive/c   #I use cygwin

C:\>bash    # I have to use bash; the DOS shell doesn't 
support UNC paths
bash: .bashrc: No such file or directory
bash-2.05a$ cd //bopp/jbarilla
bash-2.05a$ pwd
//bopp/jbarilla
bash-2.05a$ python
Python 2.2.1 (#34, Apr  9 2002, 19:34:33) [MSC 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import os; os.tmpfile()
<open file '<tmpfile>', mode 'w+' at 0x007762C0> # It 
works.
>>> ^Z

If I chmod 555 //bopp/jbarilla (from unix via NFS; 
incidentally,
"chmod 555 ." from cygwin is ineffectual), then tmpfile 
fails:

bash-2.05a$ pwd
//bopp/jbarilla
bash-2.05a$ python
Python 2.2.1 (#34, Apr  9 2002, 19:34:33) [MSC 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import os; os.tmpfile()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OSError: [Errno 13] Permission denied # Oops.

# However, tempfile.TemporaryFile works:

>>> import tempfile; tempfile.TemporaryFile()
<open file 'c:\DOCUME~1\jbarilla\LOCALS~1
\Temp\~1880-0', mode 'w+b' at 0x00779B00>

--Joe

----------------------------------------------------------------------

Comment By: Jonathan Simms (slyphon)
Date: 2002-08-10 01:21

Message:
Logged In: YES 
user_id=404786

Hi, I'm a bit new here, but I'd like to help...

This like a cygwin issue. I've been using cygwin as a 
development environment for about a year, and nothing 
has driven me more crazy than the consistent problems 
converting between unc and win32 paths. There's the 
cygpath utility that you can put to use, it'll convert 
posix to win32 paths and vice-versa. Also, if you want 
to use chmod and unix-style permissions with cygwin, 
you need to make sure that the $CYGWIN variable has 
been set to include 'ntsec'.

related to the cygwin environment variable:
http://cygwin.com/cygwin-ug-net/using-cygwinenv.html


...This advice comes with no warranty, and I apologise 
if I'm mistakenly off-the-mark...

Cheers
--Jonathan

----------------------------------------------------------------------

Comment By: Joseph Barillari (jdbarillari)
Date: 2002-08-06 09:40

Message:
Logged In: YES 
user_id=589825

\quote{BTW, do you really think this has something to do 
with UNC 
paths?  From what you said it seems to be a matter of 
having sufficient permission to scribble in the current 
directory.}

Oops. You're right:

Z:\>touch a
touch: creating `a': Permission denied

Z:\>python
Python 2.2.1 (#34, Apr  9 2002, 19:34:33) [MSC 32 bit (Intel)] 
on win32
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import os; os.tmpfile()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OSError: [Errno 13] Permission denied
>>>

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-08-05 22:19

Message:
Logged In: YES 
user_id=31435

Assigned to Mark in case he has another idea, but I think 
you're out of luck.  os.tmpfile() does nothing except call 
Microsoft's tmpfile() function, and that doesn't allow 
specifying a directory.  If you don't have permission to 
create a file in the current directory, you lose, and Python's 
behavior here will change when Microsoft's does.

tempfile.TemporaryFile() "simulates" a temp file via other 
means, and can control which directory it uses.

BTW, do you really think this has something to do with UNC 
paths?  From what you said it seems to be a matter of 
having sufficient permission to scribble in the current 
directory.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=591104&group_id=5470


From noreply@sourceforge.net  Sat Aug 10 15:27:48 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 10 Aug 2002 07:27:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-556025 ] list(xrange(1e9))  -->  seg fault
Message-ID: <E17dXDY-0004Cd-00@usw-sf-web1.sourceforge.net>

Bugs item #556025, was opened at 2002-05-14 12:41
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=556025&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Jason Tishler (jlt63)
Summary: list(xrange(1e9))  -->  seg fault

Initial Comment:
>From c.lang.py:

'''
 Python 2.2.1 (#2, Apr 21 2002, 22:22:55) 
[GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.62mdk)] 
on linux2
Type "help", "copyright", "credits" or "license" for 
more information.
>>> list(xrange(1e9))
Segmentation fault
'''

I've reproduced the same fault on Windows ME using 
Py2.2.0 and Py2.3a.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-10 10:27

Message:
Logged In: YES 
user_id=33168

I'm not sure if the test should fail, be skipped, or not run
for cygwin < 1.3.13.  But let's at least put a comment in
the test and close this bug report.  Jason, can you do that?

Good persistence Jason!

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-08-09 23:08

Message:
Logged In: YES 
user_id=80475

My thought is to close the bug, but add a unittest that 
says in effect:  if os is cygwin and version(cygwin) >= 
1.3.13 and the bug still exists, then fail with a message 
saying that SF 556025 was not successfully resolved.

This way, we can close the bug (since it is not a python 
bug) and still get a regression test to raise the concern if 
the expected solution either doesn't materialize or 
sometime later dematerializes.


----------------------------------------------------------------------

Comment By: Jason Tishler (jlt63)
Date: 2002-08-09 21:02

Message:
Logged In: YES 
user_id=86216

I guess that my perseverance paid off:

http://sources.redhat.com/ml/newlib/2002/msg00391.html

Hence, this bug will be fixed in Cygwin 1.3.13.

Can we close this bug now? Or, should we wait until
Cygwin 1.3.13 is released?

----------------------------------------------------------------------

Comment By: Jason Tishler (jlt63)
Date: 2002-08-09 14:09

Message:
Logged In: YES 
user_id=86216

Thanks for the sympathy.

I've tried, tried again:

http://sources.redhat.com/ml/newlib/2002/msg00390.html

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-08 20:56

Message:
Logged In: YES 
user_id=33168

I looked at the links.  I don't know what I can do to help.
 It seems like you proposed a reasonable solution and even
if it wasn't perfect, you still demonstrated a problem.  I
suppose I can only commiserate with you.

----------------------------------------------------------------------

Comment By: Jason Tishler (jlt63)
Date: 2002-08-08 08:11

Message:
Logged In: YES 
user_id=86216

> Jason, can you test/replicate this?

Yes, I've already been working on this one. See
the following mailing list threads for the details:

http://cygwin.com/ml/cygwin-developers/2002-07/msg00124.html
http://sources.redhat.com/ml/newlib/2002/msg00369.html

To summarize the above, the problem is actually
in newlib which provides Cygwin's libc (and
libm).  Unfortunately, Chris Falyor (the Cygwin
lead developer) has not been able to convince
the newlib maintainer to fix this problem.
Additionally, my first patch has been rejected.

I will continue my efforts to get this problem
resolved.  Any assistance will be greatly
appreciated.  I never expected to become an
expert in Doug Lea's malloc routines.  Sigh...

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-07 16:11

Message:
Logged In: YES 
user_id=33168

Actually, I think Jason may be more appropriate, since this
is a cygwin problem.  Jason, can you test/replicate this?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-07 14:20

Message:
Logged In: YES 
user_id=33168

Hmmm, Tim can you reproduce this?  I luckily don't have a
windows box. :-)

----------------------------------------------------------------------

Comment By: Steve Holden (holdenweb)
Date: 2002-08-07 13:28

Message:
Logged In: YES 
user_id=88157

I hope re-opening this is the right thing to do (I'm new here).

Current CVS fails under Win2000+Cygwin with a 
segmentation fault in the updated test_b1.py. Easily 
reproduced:

$ ./python.exe
Python 2.3a0 (#1, Aug  7 2002, 12:18:38)
[GCC 2.95.3-5 (cygwin special)] on cygwin
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import sys
>>> list(xrange(sys.maxint/4))
Segmentation fault (core dumped)

This does seem to be size-related, as:

>>> s = sys.maxint/8
>>> list(xrange(s))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
MemoryError

which is as expected in test_b1.py


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-22 19:20

Message:
Logged In: YES 
user_id=33168

Checked in as:
  listobject.c 2.106
  test_b1.py 1.46

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-21 08:59

Message:
Logged In: YES 
user_id=80475

Good plan!  Thx for squashing this bug. 

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-21 08:52

Message:
Logged In: YES 
user_id=33168

How about using sys.maxint / 4?  Does that make more sense
than 1e9?  This assumption is a little better, that the data
and address sizes are the same.  I can add a comment to this
effect.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-20 23:37

Message:
Logged In: YES 
user_id=80475

When you load the fix, please commit the regression test 
patch also.  Thx,  Raymond

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-05-20 22:51

Message:
Logged In: YES 
user_id=31435

Yup, lookin' better.  Python does assume 8-bit bytes in 
several places, and also 2's-complement integers.  Since 
size_t is guaranteed (by C) to be an unsigned type, the 
largest value of type size_t is more easily expressed as

(~(size_t)0)

The C part of the patch looks fine then.  The test is a 
little dubious:  who says the machine can't create a 
billion-integer list?  The idea that 1e9 necessarily 
overflows in this context is a 32-bit address-space 
assumption.  But I'm willing to delay fixing that until a 
machine with a usable larger address space appears <wink>.

So marked Accepted and assigned to you for checkin.  Thanks!

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-20 11:43

Message:
Logged In: YES 
user_id=33168

Ok, there were other problems, too:
  * Need to divide by the size of the type, 
    not >> 4 which was completely broken.
  * There was a missing PyErr_NoMemory().

I uploaded a new patch.

I'm not sure the size_t fix is correct.
I hope we can at least assume 8-bit machines: :-)

if (_new_size <= ((1 << (sizeof(size_t)*8 - 1)) / sizeof(type)))



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-05-20 00:48

Message:
Logged In: YES 
user_id=31435

The code patch has some problems:  you can't assume any 
relation between a size_t and an unsigned long; C simply 
doesn't define how big size_t is, and relative sizes do 
vary on 64-bit platforms.  However that gets fixed, if you 
decide it's "too big", var should be set to NULL (not 0 -- 
this is a "Guido thing" <wink>), and no exception should be 
set.  It's the caller's responsibility to check var for 
NULL after the macro is invoked, and set an appropriate 
exception.  listobject.c sometimes doesn't check the result 
for NULL, but that should only be when it knows it's 
*shrinking* a memory area, so that realloc can't fail.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-17 20:12

Message:
Logged In: YES 
user_id=80475

Added a patch to add this bug to the testbank.

Shallow code review:  Patch compiles okay (applied to 
Py2.3a0). Fixes the original problem.  Passes the smell 
test.  Macro style good (only the "var" operand is used 
more than once; no side-effects except setting "var" to 
zero upon a resize error).  Passes the standard regression 
tests.  Passes regression testing versus my personal (real 
code) testbank.

Will give it a deeper look this week-end.

One other thought: should the ValueError be replaced with a 
MemoryError to make the message consistent with PyList_New?



----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 17:03

Message:
Logged In: YES 
user_id=33168

Ok, this time I have a patch.  The patch only fixes listobject.

I looked over the other uses of PyMem_R{ESIZE,ALLOC}() and
they don't appear to be nearly as problematic as list.  For
example, if the grammar has 1e9 nodes, there are going to be
other problems well before then (ie, memory will probably be
gone).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 16:25

Message:
Logged In: YES 
user_id=33168

Oops, sorry about that last comment.  That was something I
was playing with.  The CVS version is fine for [x]range(float).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 16:22

Message:
Logged In: YES 
user_id=33168

Note, this problem is even more generic in CVS version:

>>> range(1.1)
Segmentation fault (core dumped)
>>> xrange(1.1)
Segmentation fault (core dumped)

[x]xrange(float) work fine in 2.2.1.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-14 20:44

Message:
Logged In: YES 
user_id=80475

Would there be some merit to converting PyMem_RESIZE to a 
function with an overflow check?  

I would guess that the time spent on a realloc dwarfs the 
overhead of a short wrapper function.

OTOH, I'll bet this core dump only occurs in toy examples 
and never in real code.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-05-14 18:15

Message:
Logged In: YES 
user_id=31435

Heh.  This is an instance of a general flaw:  the 
PyMem_RESIZE macro doesn't check for int overflow in its

    (n) * sizeof(type)

subexpression. The basic deal is that 1000000000 fits in an 
int, but 4 times that (silently) overflows.  In more 
detail, for this specific test case, listobject.c'.s 
roundupsize rounds 1e9 up to 0x40000000, which silently 
underflows to 0!() when PyMem_RESIZE multiplies it by 4.

Hard to know how to fix this in general; PyMem_RESIZE 
callers don't generally worry about overflow now.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=556025&group_id=5470


From noreply@sourceforge.net  Sun Aug 11 05:35:01 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 10 Aug 2002 21:35:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-593581 ] u'%c' % large value: broken result
Message-ID: <E17dkRR-0004z1-00@usw-sf-web4.sourceforge.net>

Bugs item #593581, was opened at 2002-08-11 00:35
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=593581&group_id=5470

Category: Unicode
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: M.-A. Lemburg (lemburg)
Summary: u'%c' % large value: broken result

Initial Comment:
The unicode implementation of '%c' % x does no range
checking on x, and out-of-range values can cause weird
effects. You might want to implement the same range
checking as 8-bit strings use, restricting x to values
in range(256). Or you might want to implement
unichr(x), restricting x to values in range(0xffff).
But right now it's a mess:

>>> u'%c' % 100
u'd'
>>> u'%c' % 300
u','
>>> u'%c' % 900
u'\uff84'
>>> u'%c' % -900
u'|'
>>> 


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=593581&group_id=5470


From noreply@sourceforge.net  Sun Aug 11 13:10:51 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 11 Aug 2002 05:10:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-574057 ] pydoc(.org) does not find file.flush()
Message-ID: <E17drYZ-00067q-00@usw-sf-web3.sourceforge.net>

Bugs item #574057, was opened at 2002-06-26 04:06
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574057&group_id=5470

Category: Python Library
Group: Python 2.2.1
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Eric Maryniak (maryniak)
Assigned to: Ka-Ping Yee (ping)
Summary: pydoc(.org) does not find file.flush()

Initial Comment:
Dear reader(s),

On http://pydoc.org/ a search for 'flush'
(of the builtin File object) does not find it
(I knew Python had to have a C-ish fflush()
 and of course I did find it in the end).

This is strange, because 'class __builtin__.file' does
occur in pydoc, e.g. search on 'open' and it finds:

  http://web.pydoc.org/2.2/__builtin__.html#file

And there flush() is also sitting there:

  http://web.pydoc.org/2.2/__builtin__.html#file-flush

A grateful pydoc(.org) user, kind regards,

Eric
-- 
Eric Maryniak <e.maryniak@pobox.com>
WWW homepage: http://pobox.com/~e.maryniak/


----------------------------------------------------------------------

>Comment By: Ka-Ping Yee (ping)
Date: 2002-08-11 05:10

Message:
Logged In: YES 
user_id=45338

I fixed this a while ago, but didn't come back here to close the issue.

Searching for "flush" now returns the method of the built-in 'file' object as 
the first hit, as expected.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-26 16:17

Message:
Logged In: YES 
user_id=31435

Sorry, we've got no connection with pydoc.org, and I have 
no idea how they programmed their search function.  I 
suggest you contact Ping directly:

mailto:ping@lfw.org


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-26 07:32

Message:
Logged In: YES 
user_id=3066

pydoc is Tim's favorite module.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574057&group_id=5470


From noreply@sourceforge.net  Sun Aug 11 13:23:37 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 11 Aug 2002 05:23:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-593581 ] u'%c' % large value: broken result
Message-ID: <E17drkv-0006HX-00@usw-sf-web3.sourceforge.net>

Bugs item #593581, was opened at 2002-08-11 04:35
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=593581&group_id=5470

Category: Unicode
Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: M.-A. Lemburg (lemburg)
Summary: u'%c' % large value: broken result

Initial Comment:
The unicode implementation of '%c' % x does no range
checking on x, and out-of-range values can cause weird
effects. You might want to implement the same range
checking as 8-bit strings use, restricting x to values
in range(256). Or you might want to implement
unichr(x), restricting x to values in range(0xffff).
But right now it's a mess:

>>> u'%c' % 100
u'd'
>>> u'%c' % 300
u','
>>> u'%c' % 900
u'\uff84'
>>> u'%c' % -900
u'|'
>>> 


----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2002-08-11 12:23

Message:
Logged In: YES 
user_id=38388

Fix checked in. u"%c" will now apply the same checks as
unichr().

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=593581&group_id=5470


From noreply@sourceforge.net  Sun Aug 11 14:50:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 11 Aug 2002 06:50:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-593656 ] pickle/cPickle incompatibility
Message-ID: <E17dt7G-0005sI-00@usw-sf-web5.sourceforge.net>

Bugs item #593656, was opened at 2002-08-11 22:50
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=593656&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: atsuo ishimoto (ishimoto)
Assigned to: Nobody/Anonymous (nobody)
Summary: pickle/cPickle incompatibility

Initial Comment:
In the following case, I found pickle doesn't detect 
insecure string
whereas cPickle does.

>>> import pickle, cPickle
>>> pickle.loads("S'\x5c'\np0\n.")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.1/pickle.py", line 
951, in loads
    return Unpickler(file).load()
  File "/usr/local/lib/python2.1/pickle.py", line 
567, in load
    dispatch[key](self)
  File "/usr/local/lib/python2.1/pickle.py", line 
635, in load_string
    {'__builtins__': {}})) # Let's be careful
  File "<string>", line 1
    '\'
     ^
SyntaxError: invalid token
>>> cPickle.loads("S'\x5c'\np0\n.")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ValueError: insecure string pickle
>>>


This is because pickle.Unpickler._is_string_secure() 
return 1 if string
contains one or more quote characters, whether 
they are escaped or not.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=593656&group_id=5470


From noreply@sourceforge.net  Sun Aug 11 15:10:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 11 Aug 2002 07:10:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-593656 ] pickle/cPickle incompatibility
Message-ID: <E17dtPu-00035z-00@usw-sf-web2.sourceforge.net>

Bugs item #593656, was opened at 2002-08-11 09:50
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=593656&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: atsuo ishimoto (ishimoto)
Assigned to: Nobody/Anonymous (nobody)
Summary: pickle/cPickle incompatibility

Initial Comment:
In the following case, I found pickle doesn't detect 
insecure string
whereas cPickle does.

>>> import pickle, cPickle
>>> pickle.loads("S'\x5c'\np0\n.")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.1/pickle.py", line 
951, in loads
    return Unpickler(file).load()
  File "/usr/local/lib/python2.1/pickle.py", line 
567, in load
    dispatch[key](self)
  File "/usr/local/lib/python2.1/pickle.py", line 
635, in load_string
    {'__builtins__': {}})) # Let's be careful
  File "<string>", line 1
    '\'
     ^
SyntaxError: invalid token
>>> cPickle.loads("S'\x5c'\np0\n.")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ValueError: insecure string pickle
>>>


This is because pickle.Unpickler._is_string_secure() 
return 1 if string
contains one or more quote characters, whether 
they are escaped or not.


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-11 10:10

Message:
Logged In: YES 
user_id=6380

I assume patch #505705 will fix this too.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=593656&group_id=5470


From noreply@sourceforge.net  Sun Aug 11 16:04:59 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 11 Aug 2002 08:04:59 -0700
Subject: [Python-bugs-list] [ python-Bugs-539175 ] resolver not thread safe
Message-ID: <E17duH5-0004F9-00@usw-sf-web2.sourceforge.net>

Bugs item #539175, was opened at 2002-04-04 04:54
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=539175&group_id=5470

Category: Threads
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: dustin sallings (dustin)
Assigned to: Nobody/Anonymous (nobody)
Summary: resolver not thread safe

Initial Comment:
I've got an application that does SNMP monitoring and
has a thread listening with SimpleXMLRPCServer for
remote control.  I noticed the XMLRPC listener logging
an incorrect address while snmp jobs were processing:

sw1.west.spy.net - - [04/Apr/2002 01:16:37] "POST /RPC2
HTTP/1.0" 200 -
localhost.west.spy.net - - [04/Apr/2002 01:16:43] "POST
/RPC2 HTTP/1.0" 200 -

sw1 is one of the machines that is being queried, but
the XMLRPC requests are happening over localhost.

gethostbyname() and gethostbyaddr() both return static
data, thus they aren't reentrant.

As a workaround, I copied socket.py to my working
directory and added the following to it:

try:
    import threading
except ImportError, ie:
    sys.stderr.write(str(ie) + "\n")

# mutex for DNS lookups
__dns_mutex=None
try:
    __dns_mutex=threading.Lock()
except NameError:
    pass

def __lock():
    if __dns_mutex!=None:
        __dns_mutex.acquire()
    
def __unlock():
    if __dns_mutex!=None:
        __dns_mutex.release()
    
def gethostbyaddr(addr):
    """Override gethostbyaddr to try to get some thread
safety."""
    rv=None
    try:
        __lock()
        rv=_socket.gethostbyaddr(addr)
    finally:
        __unlock()
    return rv

def gethostbyname(name):
    """Override gethostbyname to try to get some thread
safety."""
    rv=None
    try:
        __lock()
        rv=_socket.gethostbyname(name)
    finally:
        __unlock()
    return rv


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-11 11:04

Message:
Logged In: YES 
user_id=33168

Dustin, any progress on a patch or diagnosing this further?

----------------------------------------------------------------------

Comment By: dustin sallings (dustin)
Date: 2002-04-05 16:44

Message:
Logged In: YES 
user_id=43919

I first noticed this problem on my OS X box.

Since it's affecting me, it's not obvious to anyone else,
and I'm perfectly capable of fixing it myself, I'll try to
spend some time figuring out what's going on this weekend. 
It seems like it might be making a decision to not use the
lock at compile time.  I will investigate further and submit
a patch.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-05 16:31

Message:
Logged In: YES 
user_id=31435

Just a reminder that the first thing to try on any SGI box 
is to recompile Python with optimization disabled.  I can't 
remember the last time we had "a Python bug" on SGI that 
wasn't traced to a compiler -O bug.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-04-05 03:56

Message:
Logged In: YES 
user_id=21627

Can you spot the error in the Python socket module? I still
fail to see our bug, and I would assume it is a C library
bug; I also cannot reproduce the problem on any of my machines.

Can you please report the settings of the various HAVE_
defines for irix?

----------------------------------------------------------------------

Comment By: dustin sallings (dustin)
Date: 2002-04-04 17:21

Message:
Logged In: YES 
user_id=43919

Looking over the code a bit more, I see that my last message
wasn't entirely accurate.  There does seem to be only one
lock for both gethostbyname and gethostbyaddr
(gethostbyname_lock is used for both).

This is a pretty simple test that illustrates the problem
I'm seeing.  My previous work was on my OS X machine, but
this is Python 2.2 (#3, Mar  6 2002, 18:30:37) [C] on irix6.

#!/usr/bin/env python
#
# Copyright (c) 2002  Dustin Sallings <dustin@spy.net>
# $Id$

import threading
import socket
import time

class ResolveMe(threading.Thread):

    hosts=['propaganda.spy.net', 'bleu.west.spy.net',
'mail.west.spy.net']

    def __init__(self):
        threading.Thread.__init__(self)
        self.setDaemon(1)

    def run(self):
        # Run 100 times
        for i in range(100):
            for h in self.hosts:
                nrv=socket.gethostbyname_ex(h)
                arv=socket.gethostbyaddr(nrv[2][0])

                try:
                    # Verify the hostname is correct
                    assert(h==nrv[0])
                    # Verify the two hostnames match
                    assert(nrv[0]==arv[0])
                    # Verify the two addresses match
                    assert(nrv[2]==arv[2])
                except AssertionError:
                    print "Failed!  Checking " + `h` + "
got, " \
                        + `nrv` + " and " + `arv`

if __name__=='__main__':
    for i in range(1,10):
        print "Starting " + `i` + " threads."
        threads=[]
        for n in range(i):
            rm=ResolveMe()
            rm.start()
            threads.append(rm)
        for t in threads:
            t.join()
        print `i` + " threads complete."
    time.sleep(60)

The output looks like this:

verde:/tmp 190> ./pytest.py
Starting 1 threads.
1 threads complete.
Starting 2 threads.
Failed!  Checking 'propaganda.spy.net' got,
('mail.west.spy.net', [], ['66.149.231.226']) and
('mail.west.spy.net', [], ['66.149.231.226'])
Failed!  Checking 'bleu.west.spy.net' got,
('mail.west.spy.net', [], ['66.149.231.226']) and
('mail.west.spy.net', [], ['66.149.231.226'])

[...]

----------------------------------------------------------------------

Comment By: dustin sallings (dustin)
Date: 2002-04-04 16:08

Message:
Logged In: YES 
user_id=43919

The XMLRPC request is clearly being logged as coming from my
cisco switch when it was, in fact, coming from localhost.

I can't find any clear documentation, but it seems that on
at least some systems gethostbyname and gethostbyaddr
reference the same static variable, so having separate locks
for each one (as seen in socketmodule.c) doesn't help
anything.  It's not so much that they're not reentrant, but
you can't call any combination of the two of them at the
same time.  Here's some test code:

#include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h>
#include <assert.h>

int main(int argc, char **argv) {
    struct hostent *byaddr, *byname;
    unsigned int addr;
    struct sockaddr *sa = (struct sockaddr *)&addr;

    addr=1117120483;

    byaddr=gethostbyaddr(sa, sizeof(addr), AF_INET);
    assert(byaddr);
    printf("byaddr:  %s\n", byaddr->h_name);

    byname=gethostbyname("mail.west.spy.net");
    assert(byname);
    printf("byname:  %s\n", byname->h_name);

    printf("\nReprinting:\n\n");

    printf("byaddr:  %s\n", byaddr->h_name);
    printf("byname:  %s\n", byname->h_name);
}


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-04-04 15:06

Message:
Logged In: YES 
user_id=21627

I'm not sure what problem you are reporting. Python does not
attempt to invoke gethostbyname from two threads
simultaneously; this is prevented by the GIL.

On some systems, gethostname is reentrant (in the
gethostname_r incarnation); Python uses that where
available, and releases the GIL before calling it.

So I fail to see the bug.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=539175&group_id=5470


From noreply@sourceforge.net  Sun Aug 11 16:05:54 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 11 Aug 2002 08:05:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-585792 ] Invalid mmap crashes Python interpreter
Message-ID: <E17duHy-0004Fr-00@usw-sf-web2.sourceforge.net>

Bugs item #585792, was opened at 2002-07-24 04:52
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=585792&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: paul rubin (phr)
>Assigned to: Martin v. Löwis (loewis)
Summary: Invalid mmap crashes Python interpreter

Initial Comment:
This is under Red Hat 7.2, Linux kernel 2.4.7.   "x" is
an empty file, i.e. zero bytes long.

import mmap
f = open(x,"r+")m = mmap.mmap(f.fileno(), 10)
print m[1]

Crashes Python with a bus error.  Python should catch
the bus error signal
and raise an appropriate exception that the script can
catch.


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-11 11:05

Message:
Logged In: YES 
user_id=33168

Martin, could you please review the patch?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-07-28 11:00

Message:
Logged In: YES 
user_id=33168

Attached is a patch which fixes this problem.  I'm not sure
this patch it correct nor appropriate.  But it stops the
crash.  I'm hoping some mmap expert can shed some light on this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=585792&group_id=5470


From noreply@sourceforge.net  Sun Aug 11 16:13:51 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 11 Aug 2002 08:13:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-586931 ] pydoc -w fails with path specified
Message-ID: <E17duPf-0007US-00@usw-sf-web5.sourceforge.net>

Bugs item #586931, was opened at 2002-07-26 03:31
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=586931&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Ka-Ping Yee (ping)
Summary: pydoc -w fails with path specified

Initial Comment:
[from http://bugs.debian.org/143462]

If I specify a path (ie, ./dictclient.py) and use -w, it will 
fail.  If -w
is not used, or a module (ie, dictclient) is specified, it 
will work. 
Example:

$ pydoc2.2 -w ./dictclient.py
Traceback (most recent call last):
  File "/usr/bin/pydoc2.2", line 4, in ?
    pydoc.cli()
  File "/usr/lib/python2.2/pydoc.py", line 2074, in cli
    writedoc(arg)
  File "/usr/lib/python2.2/pydoc.py", line 1345, in writedoc
    object = locate(key, forceload)
  File "/usr/lib/python2.2/pydoc.py", line 1297, in locate
    parts = split(path, '.')
  File "/usr/lib/python2.2/string.py", line 117, in split
    return s.split(sep, maxsplit)
AttributeError: 'module' object has no attribute 'split'


----------------------------------------------------------------------

>Comment By: Ka-Ping Yee (ping)
Date: 2002-08-11 08:13

Message:
Logged In: YES 
user_id=45338

I have tested and checked in a fix that addresses this problem; it also 
factors out the code for resolving names, so it's not duplicated in doc() and 
writedoc() anymore.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-08-08 18:17

Message:
Logged In: YES 
user_id=31435

Ping, if you're there, would you please take a look at this?  I 
didn't even know pydoc had a -w argument <0.9 wink> ...

----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2002-08-07 13:22

Message:
Logged In: YES 
user_id=60903

sorry for attaching the patch here (submitted on 
http://bugs.debian.org/143462)

[problem is found in 2.1, 2,2 and 2.3]

--- pydoc.py.old        Wed Aug  7 15:52:08 2002 
+++ pydoc.py    Wed Aug  7 15:51:10 2002 
@@ -1114,6 +1114,8 @@                
  
 def writedoc(key, forceload=0):                               
     """Write HTML documentation to a file in the current 
directory.""" 
+    if not isinstance(key, type('')):                      
+        key = key.__name__ 
     try: 
         object = locate(key, forceload) 
     except ErrorDuringImport, value: 


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-08-07 08:28

Message:
Logged In: YES 
user_id=3066

Tim is friends with pydoc.  ;-)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=586931&group_id=5470


From noreply@sourceforge.net  Sun Aug 11 16:16:00 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 11 Aug 2002 08:16:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-588768 ] add main to py_pycompile
Message-ID: <E17duRk-0004SO-00@usw-sf-web2.sourceforge.net>

Bugs item #588768, was opened at 2002-07-30 16:34
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=588768&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
>Assigned to: Tim Peters (tim_one)
Summary: add main to py_pycompile

Initial Comment:
[From http://bugs.debian.org/139971]

This is a request for a _script_ to compile a single
(or more) .py files instead of compiling a complete
directory. The proposal is to add a main to
py_pycompile.py which compiles all files given on the
command line.


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-11 11:16

Message:
Logged In: YES 
user_id=33168

I don't know if this should really be done, but it's easy
enough to add.  Patch attached.  Tim, is this worthwhile or
should it be rejected?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=588768&group_id=5470


From noreply@sourceforge.net  Sun Aug 11 16:18:29 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 11 Aug 2002 08:18:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-575229 ] multiple inheritance w/ slots dumps core
Message-ID: <E17duU9-0004Vd-00@usw-sf-web2.sourceforge.net>

Bugs item #575229, was opened at 2002-06-28 19:33
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575229&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Cesar Douady (douady)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: multiple inheritance w/ slots dumps core

Initial Comment:
The following script dumps a core (revision 2.2.1) :

class A(object): __slots__=()
class B(object): pass
class C(A,B) : __slots__=()
C().x=2

basic sizes for those classes are:
A => 8 (correct : no dict, no weakref)
B => 16 (correct : dict and weakref slots added)
C => 8 (incorrect : dict and weakref not inherited from
B)

in the last lines of type_new, variables add_dict and
add_weak
are exploited to add those slots, but only when
slots==NULL.
The best base selected for C is A, which is correct in
my opinion
since slots come from it, but dict and weak refs must
be treated
specially and can come from another base.

I have seen nothing in the cvs repository which may fix
this bug.

I did not submit a patch since this is a touchy part of
the interpreter,
but I may do it upon request.

----------------------------------------------------------------------

Comment By: Greg Chapman (glchapman)
Date: 2002-07-07 13:25

Message:
Logged In: YES 
user_id=86307

FWIW, using the 2.2.1 windows binary release, I don't get an 
access violation.  However, under a debug build of 2.2.1, I do 
get an access violation.  Under the debug build (and using the 
original example), C's tp_dictoffset == tp_basicsize == 16 (all 
Python objects in a debug build have two extra pointers).  
Thus _PyObject_GetDictPtr (called when setting the 'x' 
attribute) returns a pointer which points beyond the allocated 
memory, and the access violation is generated (because 
MSVC fills the area after the allocated area with a garbage 
value).  This almost certainly means the regular build is also 
accessing memory beyond what it allocates, but it just 
happens to work in this case.  At any rate, there definitely 
appears to be a bug here.

----------------------------------------------------------------------

Comment By: Cesar Douady (douady)
Date: 2002-07-03 12:51

Message:
Logged In: YES 
user_id=428521

oops!
I meant C.__basicsize__ is now 12 (it has slot 'a'), but
this is still less than 16.

----------------------------------------------------------------------

Comment By: Cesar Douady (douady)
Date: 2002-07-03 12:47

Message:
Logged In: YES 
user_id=428521

I could not replicate the core dump with the latest 2.2 from
CVS,  but the problem still exist : C.__basicsize__ still is
8, which should not possible when
deriving from a class whose basic size is 16.
The following script show an abnormal behavior (actually the
one I had initially in my application):

class A(object): __slots__=('a')
class B(object): pass
class C(A,B) : __slots__=()
c=C()
c.x=2
c.a  ==> {'x':2}

In the original example, the B.__dictoffset__ would point
out of C objects, which may or may not create a core dump,
depending on a lot of factors.
In this script, B.__dictoffset__ points to slot 'a' of C,
hence 'c.x=2' creates the dictionary which is then seen as
the 'a' slot of c.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-07-02 15:13

Message:
Logged In: YES 
user_id=33168

I could not replicate this problem from current CVS
nor from 2.2.1+ (cvs).  Can you test with the CVS
versions to see if you still have a problem?

for 2.2.1+ the tag is release22-maint

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575229&group_id=5470


From noreply@sourceforge.net  Sun Aug 11 16:20:19 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 11 Aug 2002 08:20:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-577777 ] System Error with slots and multi-inh
Message-ID: <E17duVv-0004Xz-00@usw-sf-web2.sourceforge.net>

Bugs item #577777, was opened at 2002-07-05 09:36
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=577777&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Arthur Siegel (aj_siegel)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: System Error with slots and multi-inh

Initial Comment:
May be just another version of report 575229.

>>> class A(object):
 __slots__="a"
>>> class B(object):
 pass
>>> class C(A,B):
 __slots__=("b")
>>> c=C()
>>> c.a=1
>>> c.b=2
>>> c.c=3
Traceback (most recent call last):
  File "<pyshell#12>", line 1, in ?
    c.c=3
SystemError: C:\Code\221\Objects\dictobject.c:511: 
bad argument to internal function

If B is a classic class and I do the same multi-
inheritance I get the expected error message:

AttributeError: 'C' object has no attribute 'c'



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=577777&group_id=5470


From noreply@sourceforge.net  Sun Aug 11 16:22:51 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 11 Aug 2002 08:22:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-548845 ] pydoc doesn't show C types
Message-ID: <E17duYN-0004ao-00@usw-sf-web2.sourceforge.net>

Bugs item #548845, was opened at 2002-04-25 18:58
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=548845&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
>Assigned to: Ka-Ping Yee (ping)
Summary: pydoc doesn't show C types

Initial Comment:
If you define a type in C and add it to a module's 
dictionary, it will not be displayed by pydoc.  Now 
that calling such types can serve as the constructor 
for the type's instances, I think pydoc should ensure 
that the types are displayed.

Pydoc sees such types as classes because 
inspect.isclass returns true for them:

def isclass(object):
    return isinstance(object, types.ClassType) or  
        hasattr(object, '__bases__')

(The above succeeds for because C types have a 
__bases__ attribute).  However, when pydoc checks to 
see if the type/class is defined in the module being 
documented, it uses the type's __module__ attribute to 
look up the module in sys.modules.  By default, C 
types always return "__builtin__" as their __module__, 
so pydoc concludes the type was actually declared in 
the __builtin__ module and does not show it.

(Perhaps this is really a documentation bug -- there 
does not seem to be anything indicating that types 
which wish to expose themselves to pydoc should 
redefine the __module__ attribute.)


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-11 11:22

Message:
Logged In: YES 
user_id=33168

Ping, is this a pydoc problem?

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2002-04-26 13:19

Message:
Logged In: YES 
user_id=11105

As the most recent documentation (which is just a few days 
old) shows, it's a bug in the extensions module IMO ;-).
You have to use "<module>.<name>" as the tp_name slot in 
the extension type, and __module__ will automatically be 
set. pydoc then also documents this type.

http://starship.python.net/crew/theller/pyhelp.cgi?
keyword=tp_name&version=devel

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=548845&group_id=5470


From noreply@sourceforge.net  Sun Aug 11 16:23:43 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 11 Aug 2002 08:23:43 -0700
Subject: [Python-bugs-list] [ python-Bugs-592567 ] Bug with deepcopy and new style objects
Message-ID: <E17duZD-0004c6-00@usw-sf-web2.sourceforge.net>

Bugs item #592567, was opened at 2002-08-08 08:42
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592567&group_id=5470

>Category: Type/class unification
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Jiba (jiba)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: Bug with deepcopy and new style objects

Initial Comment:
Deepcopying new style objects can bug if more than one
of such objects are deep copied at the same time (E.g.
you are deepcopying a list of two new style objects).

It seems that , in copy._reconstruct, the "state" 
variable should be "kept alive" (by passing it to the
"_keep_alive" function), since this state may be gc'ed,
and another state may be created later with the same
address memory / ID.

BTW, the same problem may arise with the "args"
variable, in the same function.

The included file demonstrates the bug.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-08-08 23:43

Message:
Logged In: YES 
user_id=80475

Confirmed on 2.2.1 and 2.3a:

Before deepcopying :
[11, 12, 13]
[21, 22, 23]
[31, 32, 33]

After deepcopying :
[11, 12, 13]
[11, 12, 13]
[11, 12, 13]


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592567&group_id=5470


From noreply@sourceforge.net  Sun Aug 11 16:30:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 11 Aug 2002 08:30:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-581529 ] bug in splituser(host) in urllib
Message-ID: <E17dufK-0004k5-00@usw-sf-web2.sourceforge.net>

Bugs item #581529, was opened at 2002-07-15 00:36
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=581529&group_id=5470

Category: Python Library
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Chetan Sarva (csarva)
>Assigned to: Jeremy Hylton (jhylton)
Summary: bug in splituser(host) in urllib

Initial Comment:
The splituser() method splits on the very first "@" it encounters 
which can lead to inaccurate results in certain cases (i.e. if the 
username portion contains an e-mail address). Splitting on the last 
"@" in the string will give the desired results every time.

 I'm 
not very good with regex's so I've given my simple solution as a 
sample below:

_userprog = None
def 
splituser(host):
    """splituser('user[:passwd]@host[:port]') --> 
'user[:passwd]', 'host[:port]'."""
    global _userprog
    if 
_userprog is None:
        x = host.rfind('@')
        if x != -1:
            return 
host[:x], host[x+1:]
        else:
            return None, host
            
        
#import re
        #_userprog = re.compile('^([^@]*)@(.*)$')

    
#match = _userprog.match(host)
    #if match: return 
map(unquote, match.group(1, 2))
    return None, host

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-11 11:30

Message:
Logged In: YES 
user_id=33168

Jeremy, how should this be fixed?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=581529&group_id=5470


From noreply@sourceforge.net  Sun Aug 11 16:33:51 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 11 Aug 2002 08:33:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-574235 ] convert_path fails with empty pathname
Message-ID: <E17duj1-0004oy-00@usw-sf-web2.sourceforge.net>

Bugs item #574235, was opened at 2002-06-26 15:48
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574235&group_id=5470

Category: Distutils
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Aneesh Dalvi (adalvi)
>Assigned to: Martin v. Löwis (loewis)
Summary: convert_path fails with empty pathname

Initial Comment:
In distutils/util.py, in the function convert_path, I find I 
have to add the following two lines:

def convert_path (pathname):
    ...
    if os.sep == '/':
        return pathname
>>    if pathname=='':
>>        return pathname

This is required when installing piddle-1.0.15 on a Win32 
platform.  It is required under Python 2.1.2 as well as 
2.2.1.

I don't know if it is something specific to piddle, Win32, 
or something else.


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-11 11:33

Message:
Logged In: YES 
user_id=33168

Martin, could you please review this patch?  Should this be
implemented?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-26 22:02

Message:
Logged In: YES 
user_id=33168

This approach seems reasonable.
I've attached a patch.
I'm not sure why an empty path would
be passed, but I suppose it can't hurt to check.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574235&group_id=5470


From noreply@sourceforge.net  Sun Aug 11 16:38:12 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 11 Aug 2002 08:38:12 -0700
Subject: [Python-bugs-list] [ python-Bugs-571845 ] test_import crashes/hangs for MacPython
Message-ID: <E17dunE-0004un-00@usw-sf-web2.sourceforge.net>

Bugs item #571845, was opened at 2002-06-20 17:30
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=571845&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: test_import crashes/hangs for MacPython

Initial Comment:
Test_import breaks for MacPython after the patches for bug #561858 were committed.
On Mac OS 9 the test runs into an out-of-memory situation (after gobbling up 23MB), on Mac OS X it hangs (or, at least, it doesn't respond for 15 minutes).

I think this is unrelated to the original bug, so I'm putting this in a separate report. For now I am disabling the specific test when running under MacPython, but this should be fixed eventually.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-11 11:38

Message:
Logged In: YES 
user_id=33168

Jack, I wanted to make sure this was forgotten.  Has this
been fixed with the other memory allocation changes?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=571845&group_id=5470


From noreply@sourceforge.net  Sun Aug 11 16:42:37 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 11 Aug 2002 08:42:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-557028 ] illegal use of malloc/free
Message-ID: <E17durV-00050L-00@usw-sf-web2.sourceforge.net>

Bugs item #557028, was opened at 2002-05-16 20:31
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=557028&group_id=5470

Category: Parser/Compiler
Group: Python 2.2.1
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Gustav Hållberg (gurra-g)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: illegal use of malloc/free

Initial Comment:
com_factor() in compiler.c uses malloc/free, but should
use PyMem_Malloc/_Free.

The use of malloc/free is fatal when one has changed
Python's allocators to use something else than
malloc/free since the stuff malloc:ed there can later
on be (attempted to be) freed through a call to PyMem_Free.


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-11 11:42

Message:
Logged In: YES 
user_id=33168

Checked in as Python/compile.c 2.234.4.4.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-05 14:40

Message:
Logged In: YES 
user_id=6380

Yup, should be backported.

But note that pymalloc is known to be buggy in 2.2.x, and 
we're not going to fix that.

----------------------------------------------------------------------

Comment By: Gustav Hållberg (gurra-g)
Date: 2002-05-17 06:46

Message:
Logged In: YES 
user_id=546849

Ah, that should definitely be backported to releasebranches.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-05-16 21:19

Message:
Logged In: YES 
user_id=31435

Just noting that current CVS already uses PyMem_ in 
com_factor.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=557028&group_id=5470


From noreply@sourceforge.net  Sun Aug 11 16:48:47 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 11 Aug 2002 08:48:47 -0700
Subject: [Python-bugs-list] [ python-Bugs-544740 ] test_commands test fails under Cygwin
Message-ID: <E17duxT-00057N-00@usw-sf-web2.sourceforge.net>

Bugs item #544740, was opened at 2002-04-16 12:00
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=544740&group_id=5470

Category: None
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason Tishler (jlt63)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_commands test fails under Cygwin

Initial Comment:
The Python 2.2.1 test_commands regression test
fails under Cygwin 1.3.10 because the regular
expression is pickier now and because Cygwin can
have spaces in user and/or group names. See the
following for some more details:

http://cygwin.com/ml/cygwin/2002-04/msg00774.html

and a workaround.

I'm submitting this as a bug report instead of a
patch because I don't know the best way to fix
this issue.  Can test_commands use numeric IDs
instead of names?  Should I discuss this issue
on python-dev instead of here?

BTW, please add a "Test" category to the
available choices for Bugs.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-11 11:48

Message:
Logged In: YES 
user_id=33168

Jason, I presume this is still a problem.  It probably would
be a good idea to discuss on python-dev.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=544740&group_id=5470


From noreply@sourceforge.net  Sun Aug 11 16:55:43 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 11 Aug 2002 08:55:43 -0700
Subject: [Python-bugs-list] [ python-Bugs-548845 ] pydoc doesn't show C types
Message-ID: <E17dv4B-0008Dt-00@usw-sf-web5.sourceforge.net>

Bugs item #548845, was opened at 2002-04-25 14:58
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=548845&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Ka-Ping Yee (ping)
Summary: pydoc doesn't show C types

Initial Comment:
If you define a type in C and add it to a module's 
dictionary, it will not be displayed by pydoc.  Now 
that calling such types can serve as the constructor 
for the type's instances, I think pydoc should ensure 
that the types are displayed.

Pydoc sees such types as classes because 
inspect.isclass returns true for them:

def isclass(object):
    return isinstance(object, types.ClassType) or  
        hasattr(object, '__bases__')

(The above succeeds for because C types have a 
__bases__ attribute).  However, when pydoc checks to 
see if the type/class is defined in the module being 
documented, it uses the type's __module__ attribute to 
look up the module in sys.modules.  By default, C 
types always return "__builtin__" as their __module__, 
so pydoc concludes the type was actually declared in 
the __builtin__ module and does not show it.

(Perhaps this is really a documentation bug -- there 
does not seem to be anything indicating that types 
which wish to expose themselves to pydoc should 
redefine the __module__ attribute.)


----------------------------------------------------------------------

>Comment By: Greg Chapman (glchapman)
Date: 2002-08-11 07:55

Message:
Logged In: YES 
user_id=86307

FWIW, I agree with Thomas Heller that this was really a bug 
in the C type: it did not have a properly formed tp_name.  As 
far as I am concerned, this report should be considered "not a 
bug" and closed.  (As the original poster, am I allowed to 
close it?)

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-11 07:22

Message:
Logged In: YES 
user_id=33168

Ping, is this a pydoc problem?

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2002-04-26 09:19

Message:
Logged In: YES 
user_id=11105

As the most recent documentation (which is just a few days 
old) shows, it's a bug in the extensions module IMO ;-).
You have to use "<module>.<name>" as the tp_name slot in 
the extension type, and __module__ will automatically be 
set. pydoc then also documents this type.

http://starship.python.net/crew/theller/pyhelp.cgi?
keyword=tp_name&version=devel

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=548845&group_id=5470


From noreply@sourceforge.net  Sun Aug 11 17:06:45 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 11 Aug 2002 09:06:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-548845 ] pydoc doesn't show C types
Message-ID: <E17dvEr-0005Mg-00@usw-sf-web2.sourceforge.net>

Bugs item #548845, was opened at 2002-04-25 18:58
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=548845&group_id=5470

Category: Python Library
Group: Python 2.2
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Greg Chapman (glchapman)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: pydoc doesn't show C types

Initial Comment:
If you define a type in C and add it to a module's 
dictionary, it will not be displayed by pydoc.  Now 
that calling such types can serve as the constructor 
for the type's instances, I think pydoc should ensure 
that the types are displayed.

Pydoc sees such types as classes because 
inspect.isclass returns true for them:

def isclass(object):
    return isinstance(object, types.ClassType) or  
        hasattr(object, '__bases__')

(The above succeeds for because C types have a 
__bases__ attribute).  However, when pydoc checks to 
see if the type/class is defined in the module being 
documented, it uses the type's __module__ attribute to 
look up the module in sys.modules.  By default, C 
types always return "__builtin__" as their __module__, 
so pydoc concludes the type was actually declared in 
the __builtin__ module and does not show it.

(Perhaps this is really a documentation bug -- there 
does not seem to be anything indicating that types 
which wish to expose themselves to pydoc should 
redefine the __module__ attribute.)


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-11 12:06

Message:
Logged In: YES 
user_id=33168

Greg, your wish is my command.  Closed.  :-)

I think you can close the bug, but I'm not sure.  SF is
flaky about some things.

----------------------------------------------------------------------

Comment By: Greg Chapman (glchapman)
Date: 2002-08-11 11:55

Message:
Logged In: YES 
user_id=86307

FWIW, I agree with Thomas Heller that this was really a bug 
in the C type: it did not have a properly formed tp_name.  As 
far as I am concerned, this report should be considered "not a 
bug" and closed.  (As the original poster, am I allowed to 
close it?)

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-11 11:22

Message:
Logged In: YES 
user_id=33168

Ping, is this a pydoc problem?

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2002-04-26 13:19

Message:
Logged In: YES 
user_id=11105

As the most recent documentation (which is just a few days 
old) shows, it's a bug in the extensions module IMO ;-).
You have to use "<module>.<name>" as the tp_name slot in 
the extension type, and __module__ will automatically be 
set. pydoc then also documents this type.

http://starship.python.net/crew/theller/pyhelp.cgi?
keyword=tp_name&version=devel

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=548845&group_id=5470


From noreply@sourceforge.net  Sun Aug 11 17:31:24 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 11 Aug 2002 09:31:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-588768 ] add main to py_pycompile
Message-ID: <E17dvci-0000QA-00@usw-sf-web5.sourceforge.net>

Bugs item #588768, was opened at 2002-07-30 16:34
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=588768&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: add main to py_pycompile

Initial Comment:
[From http://bugs.debian.org/139971]

This is a request for a _script_ to compile a single
(or more) .py files instead of compiling a complete
directory. The proposal is to add a main to
py_pycompile.py which compiles all files given on the
command line.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-08-11 12:31

Message:
Logged In: YES 
user_id=31435

Reassigned to Fred as I've never used this script -- it 
sounds harmless enough that the real question may be 
whether Fred wants to document it <wink>.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-11 11:16

Message:
Logged In: YES 
user_id=33168

I don't know if this should really be done, but it's easy
enough to add.  Patch attached.  Tim, is this worthwhile or
should it be rejected?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=588768&group_id=5470


From noreply@sourceforge.net  Sun Aug 11 17:42:09 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 11 Aug 2002 09:42:09 -0700
Subject: [Python-bugs-list] [ python-Bugs-217195 ] Broken \ref link in documentation
Message-ID: <E17dvn7-0005rP-00@usw-sf-web2.sourceforge.net>

Bugs item #217195, was opened at 2000-10-18 14:51
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=217195&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Broken \ref link in documentation

Initial Comment:
[Report received by python-docs.]

From: Roy Smith <rsmith@micromuse.com>
Date: Wed, 18 Oct 2000 14:45:25 -0700

On the page http://www.python.org/doc/current/ref/exceptions.html, if I
click on the link for secion 7.4
(http://www.python.org/doc/current/ref/node83.html#try), I get an Error
404: file not found.


----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2002-08-11 12:42

Message:
Logged In: YES 
user_id=593130

The page in question is '4.2 Exceptions'
http://www.python.org/doc/current/ref/exceptions.html

The line in question is:
See also the description of the try statement in section 7.4 
and raise statement in section 6.9. 

6.9 links to '6.9 The raise statement' 
http://www.python.org/doc/current/ref/raise.html#raise
which works fine

7.4 links to the now obsolete URL
http://www.python.org/doc/current/ref/node83.html#try
It should link to the current '7.4 The try statement '
http://www.python.org/doc/current/ref/try.html
or maybe?
http://www.python.org/doc/current/ref/try.html#try

Isn't this a simple update so that the 7.4 ref works like the 
6.9 ref?

PS. I would like also like references from 7.4 to 4.2 and 6.9


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-01 17:32

Message:
Logged In: YES 
user_id=31392

Was it a LaTeX2HTML bug or not?


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-01-29 19:51

Message:
Logged In: NO 

ergdfvgdfdfgsdgff

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2000-12-12 16:54

Message:
I'll note that I think this is a LaTeX2HTML bug, but I need to spend some time digging into the \ref{} handling.  It seems to have other problems as well.  ;-(

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=217195&group_id=5470


From noreply@sourceforge.net  Sun Aug 11 17:57:00 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 11 Aug 2002 09:57:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-593696 ] telnetlib raises UnboundLocalError
Message-ID: <E17dw1U-0001tr-00@usw-sf-web3.sourceforge.net>

Bugs item #593696, was opened at 2002-08-11 16:57
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=593696&group_id=5470

Category: Python Library
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Noah Spurrier (noah)
Assigned to: Nobody/Anonymous (nobody)
Summary: telnetlib raises UnboundLocalError

Initial Comment:
I have a tiny test script that causes telnetlib to
crash due to an UnboundLocalError exception.
I tested this on Python 2.2.1 on Linux and OpenBSD.
Here is the uname output of both test machines:
OpenBSD ark2 2.9 GENERIC#653 i386
Linux starship.python.net 2.2.19-6.2.12smp #1 SMP Fri 
Oct 26 11:29:57 EDT 2001 i686 unknown

Here is the script:

import telnetlib
tn = telnetlib.Telnet ("surfers.org", 4242)
tn.read_until ("Please enter your name:")
tn.write ("Mongo\n")
tn.read_until ("just connect to Surfers:")

Here is the exact error:

# python term.py
Traceback (most recent call last):
  File "term.py", line 6, in ?
    tn.read_until ("just connect to Surfers:")
  File "/usr/local/lib/python2.2/telnetlib.py", line 297, in 
read_until
    self.process_rawq()
  File "/usr/local/lib/python2.2/telnetlib.py", line 424, in 
process_rawq
    self.msg('IAC %d not recognized' % ord(opt))
UnboundLocalError: local variable 'opt' referenced before 
assignment

Let me know if I can provide more information.

Yours,
Noah


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=593696&group_id=5470


From noreply@sourceforge.net  Sun Aug 11 19:16:15 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 11 Aug 2002 11:16:15 -0700
Subject: [Python-bugs-list] [ python-Bugs-411881 ] Use of "except:" in modules
Message-ID: <E17dxGB-00068z-00@usw-sf-web1.sourceforge.net>

Bugs item #411881, was opened at 2001-03-28 07:58
You can respond by visiting: 
https://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: Skip Montanaro (montanaro)
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: Terry J. Reedy (tjreedy)
Date: 2002-08-11 14:16

Message:
Logged In: YES 
user_id=593130

Remove types.py from the list.  As distributed with 2.2.1, it 
has 5 'except xxxError:' statements but no offending bare 
except:'s.

Skip (or anyone else): if/when you pursue this, I volunteer 
to do occasional sleuthing and send reports with 
suggestions and/or questions.  Example: getpass.py has 
one 'offense':
   try:
        fd = sys.stdin.fileno()
    except:
        return default_getpass(prompt)
According to lib doc 2.2.8 File Objects (as I interpret) fileno
() should either work without exception or *not* be 
implemented. Suggestion: insert AttributeError .  Question: 
do we protect against pseudofile objects that ignore doc 
and have fake .fileno() that raises NotImplementedError or 
whatever?


----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-03-23 01:02

Message:
Logged In: YES 
user_id=44345

as partial fix, checked in changes for the following
modules:

  mimetools.py (1.24)
  popen2.py (1.23)
  quopripy (1.19)
  CGIHTTPServer.py (1.22)


----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-03-20 16:24

Message:
Logged In: YES 
user_id=44345

Here is a context diff with proposed changes for the
following modules: CGIHTTPServer, cgi, cmd, code, 
fileinput, httplib, inspect, locale, mimetools, popen2,
quopri


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-08-11 11:06

Message:
Logged In: YES 
user_id=21627

Fixed urllib in 1.131 and types in 1.19.


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-07-04 03:11

Message:
Logged In: YES 
user_id=3066

Fixed modules mhlib and rfc822 (SF is having a problem
generating the checkin emails, though).

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-05-11 15:40

Message:
Logged In: YES 
user_id=3066

OK, I've fixed up a few more modules:

anydbm
chunk
formatter
htmllib
mailcap
pre
pty

I made one change to asyncore as well, but other bare except
clauses remain there; I'm not sufficiently familiar with
that code to just go digging into those.

I also fixed an infraction in pstats, but left others for now.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-04-23 04: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 03: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 10: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 05: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 11: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 13: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 13: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 13: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 11: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 05: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-30 01: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: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=411881&group_id=5470


From noreply@sourceforge.net  Sun Aug 11 19:38:07 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 11 Aug 2002 11:38:07 -0700
Subject: [Python-bugs-list] [ python-Bugs-484967 ] bad links at Ref Guide
Message-ID: <E17dxbL-0003Ej-00@usw-sf-web3.sourceforge.net>

Bugs item #484967, was opened at 2001-11-23 14:43
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=484967&group_id=5470

Category: Documentation
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: bad links at Ref Guide

Initial Comment:
There are broken links and bad formed urls at a couple 
of html files in the Ref manual.
 
On file: Doc/ref/atom-literals.html
node20.html#tok-stringliteral
node23.html#tok-longinteger

On file: Doc/ref/integers.html
<pyGrammarToken><><integer>

Are the same problems as the #217195 bug report?


----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2002-08-11 14:38

Message:
Logged In: YES 
user_id=593130

The pages are different but the symptoms certainly look 
the same: some links are good, some aren't because they 
use old 'node##' names instead of newer names.


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-12-05 16:45

Message:
Logged In: YES 
user_id=3066

These are definately different from bug #217195.  ;-(

----------------------------------------------------------------------

Comment By: Hernan Martinez Foffani (hfoffani)
Date: 2001-11-23 14:47

Message:
Logged In: YES 
user_id=112690

"nobody/anonymous" was me: Hernan Foffani. :-)

and the errors are in python 2.2b2 docs (windows distrib)




----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=484967&group_id=5470


From noreply@sourceforge.net  Sun Aug 11 20:27:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 11 Aug 2002 12:27:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-539175 ] resolver not thread safe
Message-ID: <E17dyNA-00044e-00@usw-sf-web3.sourceforge.net>

Bugs item #539175, was opened at 2002-04-04 01:54
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=539175&group_id=5470

Category: Threads
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: dustin sallings (dustin)
Assigned to: Nobody/Anonymous (nobody)
Summary: resolver not thread safe

Initial Comment:
I've got an application that does SNMP monitoring and
has a thread listening with SimpleXMLRPCServer for
remote control.  I noticed the XMLRPC listener logging
an incorrect address while snmp jobs were processing:

sw1.west.spy.net - - [04/Apr/2002 01:16:37] "POST /RPC2
HTTP/1.0" 200 -
localhost.west.spy.net - - [04/Apr/2002 01:16:43] "POST
/RPC2 HTTP/1.0" 200 -

sw1 is one of the machines that is being queried, but
the XMLRPC requests are happening over localhost.

gethostbyname() and gethostbyaddr() both return static
data, thus they aren't reentrant.

As a workaround, I copied socket.py to my working
directory and added the following to it:

try:
    import threading
except ImportError, ie:
    sys.stderr.write(str(ie) + "\n")

# mutex for DNS lookups
__dns_mutex=None
try:
    __dns_mutex=threading.Lock()
except NameError:
    pass

def __lock():
    if __dns_mutex!=None:
        __dns_mutex.acquire()
    
def __unlock():
    if __dns_mutex!=None:
        __dns_mutex.release()
    
def gethostbyaddr(addr):
    """Override gethostbyaddr to try to get some thread
safety."""
    rv=None
    try:
        __lock()
        rv=_socket.gethostbyaddr(addr)
    finally:
        __unlock()
    return rv

def gethostbyname(name):
    """Override gethostbyname to try to get some thread
safety."""
    rv=None
    try:
        __lock()
        rv=_socket.gethostbyname(name)
    finally:
        __unlock()
    return rv


----------------------------------------------------------------------

>Comment By: dustin sallings (dustin)
Date: 2002-08-11 12:27

Message:
Logged In: YES 
user_id=43919

No, unfortunately, I haven't been able to look at it in a
while.  Short of locking it in python, I wasn't able to
avoid the failure.

I'm sorry I haven't updated this at all.  As far as I can
tell, it's still a problem, but I haven't not been able to
find a solution in the C code.  I supposely I spoke with too
much haste when I said I was perfectly capable of fixing the
problem myself.  The locking in the C code did seem correct,
but the memory was still getting stomped.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-11 08:04

Message:
Logged In: YES 
user_id=33168

Dustin, any progress on a patch or diagnosing this further?

----------------------------------------------------------------------

Comment By: dustin sallings (dustin)
Date: 2002-04-05 13:44

Message:
Logged In: YES 
user_id=43919

I first noticed this problem on my OS X box.

Since it's affecting me, it's not obvious to anyone else,
and I'm perfectly capable of fixing it myself, I'll try to
spend some time figuring out what's going on this weekend. 
It seems like it might be making a decision to not use the
lock at compile time.  I will investigate further and submit
a patch.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-05 13:31

Message:
Logged In: YES 
user_id=31435

Just a reminder that the first thing to try on any SGI box 
is to recompile Python with optimization disabled.  I can't 
remember the last time we had "a Python bug" on SGI that 
wasn't traced to a compiler -O bug.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-04-05 00:56

Message:
Logged In: YES 
user_id=21627

Can you spot the error in the Python socket module? I still
fail to see our bug, and I would assume it is a C library
bug; I also cannot reproduce the problem on any of my machines.

Can you please report the settings of the various HAVE_
defines for irix?

----------------------------------------------------------------------

Comment By: dustin sallings (dustin)
Date: 2002-04-04 14:21

Message:
Logged In: YES 
user_id=43919

Looking over the code a bit more, I see that my last message
wasn't entirely accurate.  There does seem to be only one
lock for both gethostbyname and gethostbyaddr
(gethostbyname_lock is used for both).

This is a pretty simple test that illustrates the problem
I'm seeing.  My previous work was on my OS X machine, but
this is Python 2.2 (#3, Mar  6 2002, 18:30:37) [C] on irix6.

#!/usr/bin/env python
#
# Copyright (c) 2002  Dustin Sallings <dustin@spy.net>
# $Id$

import threading
import socket
import time

class ResolveMe(threading.Thread):

    hosts=['propaganda.spy.net', 'bleu.west.spy.net',
'mail.west.spy.net']

    def __init__(self):
        threading.Thread.__init__(self)
        self.setDaemon(1)

    def run(self):
        # Run 100 times
        for i in range(100):
            for h in self.hosts:
                nrv=socket.gethostbyname_ex(h)
                arv=socket.gethostbyaddr(nrv[2][0])

                try:
                    # Verify the hostname is correct
                    assert(h==nrv[0])
                    # Verify the two hostnames match
                    assert(nrv[0]==arv[0])
                    # Verify the two addresses match
                    assert(nrv[2]==arv[2])
                except AssertionError:
                    print "Failed!  Checking " + `h` + "
got, " \
                        + `nrv` + " and " + `arv`

if __name__=='__main__':
    for i in range(1,10):
        print "Starting " + `i` + " threads."
        threads=[]
        for n in range(i):
            rm=ResolveMe()
            rm.start()
            threads.append(rm)
        for t in threads:
            t.join()
        print `i` + " threads complete."
    time.sleep(60)

The output looks like this:

verde:/tmp 190> ./pytest.py
Starting 1 threads.
1 threads complete.
Starting 2 threads.
Failed!  Checking 'propaganda.spy.net' got,
('mail.west.spy.net', [], ['66.149.231.226']) and
('mail.west.spy.net', [], ['66.149.231.226'])
Failed!  Checking 'bleu.west.spy.net' got,
('mail.west.spy.net', [], ['66.149.231.226']) and
('mail.west.spy.net', [], ['66.149.231.226'])

[...]

----------------------------------------------------------------------

Comment By: dustin sallings (dustin)
Date: 2002-04-04 13:08

Message:
Logged In: YES 
user_id=43919

The XMLRPC request is clearly being logged as coming from my
cisco switch when it was, in fact, coming from localhost.

I can't find any clear documentation, but it seems that on
at least some systems gethostbyname and gethostbyaddr
reference the same static variable, so having separate locks
for each one (as seen in socketmodule.c) doesn't help
anything.  It's not so much that they're not reentrant, but
you can't call any combination of the two of them at the
same time.  Here's some test code:

#include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h>
#include <assert.h>

int main(int argc, char **argv) {
    struct hostent *byaddr, *byname;
    unsigned int addr;
    struct sockaddr *sa = (struct sockaddr *)&addr;

    addr=1117120483;

    byaddr=gethostbyaddr(sa, sizeof(addr), AF_INET);
    assert(byaddr);
    printf("byaddr:  %s\n", byaddr->h_name);

    byname=gethostbyname("mail.west.spy.net");
    assert(byname);
    printf("byname:  %s\n", byname->h_name);

    printf("\nReprinting:\n\n");

    printf("byaddr:  %s\n", byaddr->h_name);
    printf("byname:  %s\n", byname->h_name);
}


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-04-04 12:06

Message:
Logged In: YES 
user_id=21627

I'm not sure what problem you are reporting. Python does not
attempt to invoke gethostbyname from two threads
simultaneously; this is prevented by the GIL.

On some systems, gethostname is reentrant (in the
gethostname_r incarnation); Python uses that where
available, and releases the GIL before calling it.

So I fail to see the bug.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=539175&group_id=5470


From noreply@sourceforge.net  Sun Aug 11 20:31:36 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 11 Aug 2002 12:31:36 -0700
Subject: [Python-bugs-list] [ python-Bugs-593696 ] telnetlib raises UnboundLocalError
Message-ID: <E17dyR6-0000LO-00@usw-sf-web2.sourceforge.net>

Bugs item #593696, was opened at 2002-08-11 12:57
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=593696&group_id=5470

Category: Python Library
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Noah Spurrier (noah)
Assigned to: Nobody/Anonymous (nobody)
Summary: telnetlib raises UnboundLocalError

Initial Comment:
I have a tiny test script that causes telnetlib to
crash due to an UnboundLocalError exception.
I tested this on Python 2.2.1 on Linux and OpenBSD.
Here is the uname output of both test machines:
OpenBSD ark2 2.9 GENERIC#653 i386
Linux starship.python.net 2.2.19-6.2.12smp #1 SMP Fri 
Oct 26 11:29:57 EDT 2001 i686 unknown

Here is the script:

import telnetlib
tn = telnetlib.Telnet ("surfers.org", 4242)
tn.read_until ("Please enter your name:")
tn.write ("Mongo\n")
tn.read_until ("just connect to Surfers:")

Here is the exact error:

# python term.py
Traceback (most recent call last):
  File "term.py", line 6, in ?
    tn.read_until ("just connect to Surfers:")
  File "/usr/local/lib/python2.2/telnetlib.py", line 297, in 
read_until
    self.process_rawq()
  File "/usr/local/lib/python2.2/telnetlib.py", line 424, in 
process_rawq
    self.msg('IAC %d not recognized' % ord(opt))
UnboundLocalError: local variable 'opt' referenced before 
assignment

Let me know if I can provide more information.

Yours,
Noah


----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2002-08-11 15:31

Message:
Logged In: YES 
user_id=593130

This appears to be trivial fix in telnetlib.py, line 424:
  self.msg('IAC %d not recognized' % ord(opt)) 
I believe 'opt' should be changed to 'c' since it is c that is 
not recognized in the if-elif series above this line.  Opt is 
only set for certain  values of c.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=593696&group_id=5470


From noreply@sourceforge.net  Sun Aug 11 21:09:41 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 11 Aug 2002 13:09:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-593696 ] telnetlib raises UnboundLocalError
Message-ID: <E17dz1x-0004Qu-00@usw-sf-web5.sourceforge.net>

Bugs item #593696, was opened at 2002-08-11 12:57
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=593696&group_id=5470

Category: Python Library
Group: Python 2.2.1
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Noah Spurrier (noah)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: telnetlib raises UnboundLocalError

Initial Comment:
I have a tiny test script that causes telnetlib to
crash due to an UnboundLocalError exception.
I tested this on Python 2.2.1 on Linux and OpenBSD.
Here is the uname output of both test machines:
OpenBSD ark2 2.9 GENERIC#653 i386
Linux starship.python.net 2.2.19-6.2.12smp #1 SMP Fri 
Oct 26 11:29:57 EDT 2001 i686 unknown

Here is the script:

import telnetlib
tn = telnetlib.Telnet ("surfers.org", 4242)
tn.read_until ("Please enter your name:")
tn.write ("Mongo\n")
tn.read_until ("just connect to Surfers:")

Here is the exact error:

# python term.py
Traceback (most recent call last):
  File "term.py", line 6, in ?
    tn.read_until ("just connect to Surfers:")
  File "/usr/local/lib/python2.2/telnetlib.py", line 297, in 
read_until
    self.process_rawq()
  File "/usr/local/lib/python2.2/telnetlib.py", line 424, in 
process_rawq
    self.msg('IAC %d not recognized' % ord(opt))
UnboundLocalError: local variable 'opt' referenced before 
assignment

Let me know if I can provide more information.

Yours,
Noah


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-11 16:09

Message:
Logged In: YES 
user_id=33168

Checked in as 1.16.10.2.
Thanks!

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2002-08-11 15:31

Message:
Logged In: YES 
user_id=593130

This appears to be trivial fix in telnetlib.py, line 424:
  self.msg('IAC %d not recognized' % ord(opt)) 
I believe 'opt' should be changed to 'c' since it is c that is 
not recognized in the if-elif series above this line.  Opt is 
only set for certain  values of c.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=593696&group_id=5470


From noreply@sourceforge.net  Sun Aug 11 22:07:15 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 11 Aug 2002 14:07:15 -0700
Subject: [Python-bugs-list] [ python-Bugs-574235 ] convert_path fails with empty pathname
Message-ID: <E17dzvf-0005Sc-00@usw-sf-web5.sourceforge.net>

Bugs item #574235, was opened at 2002-06-26 21:48
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574235&group_id=5470

Category: Distutils
Group: Python 2.1.2
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Aneesh Dalvi (adalvi)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: convert_path fails with empty pathname

Initial Comment:
In distutils/util.py, in the function convert_path, I find I 
have to add the following two lines:

def convert_path (pathname):
    ...
    if os.sep == '/':
        return pathname
>>    if pathname=='':
>>        return pathname

This is required when installing piddle-1.0.15 on a Win32 
platform.  It is required under Python 2.1.2 as well as 
2.2.1.

I don't know if it is something specific to piddle, Win32, 
or something else.


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-08-11 23:07

Message:
Logged In: YES 
user_id=21627

I've checked piddle, and the traceback is

Traceback (most recent call last):
  File "setup.py", line 28, in ?
    packages = ['piddle', 'piddle.piddleGTK',
'piddle.piddleSVG', 'piddle.piddleTK2'] )
  File "/usr/local/lib/python2.3/distutils/core.py", line
140, in setup
    dist.run_commands()
  File "/usr/local/lib/python2.3/distutils/dist.py", line
886, in run_commands
    self.run_command(cmd)
  File "/usr/local/lib/python2.3/distutils/dist.py", line
906, in run_command
    cmd_obj.run()
  File
"/usr/local/lib/python2.3/distutils/command/install.py",
line 504, in run
    self.run_command(cmd_name)
  File "/usr/local/lib/python2.3/distutils/cmd.py", line
334, in run_command
    self.distribution.run_command(command)
  File "/usr/local/lib/python2.3/distutils/dist.py", line
906, in run_command
    cmd_obj.run()
  File
"/usr/local/lib/python2.3/distutils/command/install_data.py",
line 61, in run
    dir = convert_path(f[0])
  File "/usr/local/lib/python2.3/distutils/util.py", line
85, in convert_path
    assert pathname
AssertionError

(the assertion is a local change). This in turn results from

      data_files = [ ('piddle/pilfonts', pilfontsList),
                     ('piddle', ['src/piddle/python.gif']),
                     ('', ['src/piddle.pth']) ],

i.e. it tries to install piddle.pth into install_dir.

So the change is ok, although I'm not sure whether
install_data's usage of convert_path is correct. E.g. it
tries to support absolute paths, which are rejected in
convert_path.


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-11 17:33

Message:
Logged In: YES 
user_id=33168

Martin, could you please review this patch?  Should this be
implemented?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-27 04:02

Message:
Logged In: YES 
user_id=33168

This approach seems reasonable.
I've attached a patch.
I'm not sure why an empty path would
be passed, but I suppose it can't hurt to check.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574235&group_id=5470


From noreply@sourceforge.net  Sun Aug 11 22:13:04 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 11 Aug 2002 14:13:04 -0700
Subject: [Python-bugs-list] [ python-Bugs-491888 ] whichdb lies about db type
Message-ID: <E17e01I-0002Uv-00@usw-sf-web2.sourceforge.net>

Bugs item #491888, was opened at 2001-12-12 04:22
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=491888&group_id=5470

Category: Python Library
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Jones (richard)
Assigned to: Martin v. Löwis (loewis)
Summary: whichdb lies about db type

Initial Comment:
>>> import dbm
>>> d = dbm.open('foo', 'n')
>>> d['a'] = 'b'
>>> d.close()
>>> import whichdb
>>> whichdb.whichdb('foo.db')
'dbhash'

I'm currently testing for the existence of "foo.db" 
instead of "foo" and hard-code my routines to use dbm 
if there is a "foo.db" file (since all other db 
modules that I've tested do no append ".db")

Might it also be possible to have anydbm perform a 
whichdb check in its open function, so that older 
databases are usable with newer, more feature-full 
installations that might include "better" dbm 
backends?



----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-08-11 23:13

Message:
Logged In: YES 
user_id=21627

Skip, I think you misunderstand the complaint. It's not
about the way in which an error message is given, but that
the error message is given at all.

The file is a dbm file, and the dbm module is capable of
opening it, so no error should be reported at all.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-07-25 17:03

Message:
Logged In: YES 
user_id=44345

Martin's comment in bug 584409 reminded me that I have a patched 
whichdb module which should cure this problem.  (At the moment my 
dbm module is linked with gdbm, not BerkDB, however, so while I've 
tested this in the past, I can't provide you with an interactive 
demonstration at the moment.)  Note that Richard was forced to do 
something for which whichdb was not designed. I believe with this 
patch he should be able to once again ask for simply "foo" and not 
wonder what extensions the underlying db package add to the files.

I still don't think version information would help here.  Richard's tests 
are flawed.  Berkeley DB only adds ".db" to the end of the file when 
using the dbm-compatibility API.  He should have called

    dbhash.open('foo', 'r')

as he later demonstrated.  While somewhat mystifying, the bsddb.error 
is more or less correct.  We should probably trap that and raise a "file 
not found" error or just try a stat() call if the db file is to be opened for 
reading.

Assigning to Martin for consideration.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-12-13 10:43

Message:
Logged In: YES 
user_id=21627

I see. The problem appears to be that your BSDDB
installation, which implements hash version 7, does not
simultaneously support hash version 5 anymore. This
primarily is a problem in the Sleepycat version shipped with
your system (for not supporting old databases), and in glibc
(for not incorporating a newer bsd db). Python can work
around this problem, at best - there might always be DBHASH
files that none of the DB implementations on a system can open.

bsddb should expose version information, like DB_HASHVERSION
and DB_HASHOLDVER (the current and the minimum hash
version). Unfortunately, db_185.h, as used by bsddb.c, do
not provide these constants, and db_185.h cannot be used
simultaneously with db.h. db_185.h exposes a HASHVERSION
constant, but that seems to stay at 2 regardless of the file
version that the compatibility API uses.

The right solution seems to drop support for the DB1 API,
and mandate a DB2-or-better db.h. I'd personally recommend
to integrate pybsddb.sf.net into Python 2.3, adding
portability to BSDDB 2 if necessary (it could be a
build-time decision to build either source module as bsddb).

For the moment, I cannot recommend a good work-around; I see
two options:
- find out magically (by looking at db.h) what hash versions
dbhash will support, then check the version of the hash
file, and refuse to use dbash if the version won't be
supported. Since this requires magic, such code should not
be added to Python, but left to the application.
- catch bsddb.error on dbhash.open, and retry with dbm.open.
 This is a heuristic which also shouldn't be added to
Python, but which may be acceptable to the application.

----------------------------------------------------------------------

Comment By: Richard Jones (richard)
Date: 2001-12-13 08:05

Message:
Logged In: YES 
user_id=6405

Sorry about the anydbm/whichdb confusion - reading the 
source a little closer would have avoided my confusion.

Regardless, there is still a problem that on my system, 
dbm files are reported as dbhash, and dbhash can't open 
the dbm files...

[richard@co3044991-a tmp]$ python
Python 2.1.1 (#1, Aug 30 2001, 17:36:05) 
[GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.61mdk)] on 
linux-i386
Type "copyright", "credits" or "license" for more 
information.
>>> import dbm
>>> dbm.open('foo','n')
<dbm object at 0x812a0f0>
>>> import dbhash
>>> dbhash.open('bar', 'n')
<bsddb object at 0x812b870>
>>> 
>>> import whichdb
>>> whichdb.whichdb('foo.db')
'dbhash'
>>> whichdb.whichdb('bar')
'dbhash'
>>> dbhash.open('foo.db', 'r')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.1/dbhash.py", line 16, in open
    return bsddb.hashopen(file, flag, mode)
bsddb.error: (-30990, 'Unknown error 4294936306')
>>> dbhash.open('bar', 'r')
<bsddb object at 0x812ef48>
>>> 
[richard@co3044991-a tmp]$ file foo.db
foo.db: Berkeley DB (Hash, version 5, native byte-order)
[richard@co3044991-a tmp]$ file bar
bar: Berkeley DB (Hash, version 7, native byte-order)



----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-12-13 00:28

Message:
Logged In: YES 
user_id=21627

I fail to see the problem altogether. What system are you
on? Why do you think dbm does not create dbhash files? It is
not just that the magic says they are BSDDB DB_HASH files,
they really are of that kind?

Also, which of the APIs (dbm, dbhash) do you consider
"better"? I'd say that dbhash is better, since it builds
upon bsddb. So whichdbm, and anydbm, do use the "better" dbm
backend already?

Where is the bug?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-12 05:28

Message:
Logged In: YES 
user_id=6380

Hm. anydmb *does* use whichdb. The problem seems to be that
the dbm file really *does* look like a BSD hash -- the Unix
file(1) command has the same problem.

But I'm not sure I understand your question. Do you have a
particular patch in mind?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=491888&group_id=5470


From noreply@sourceforge.net  Mon Aug 12 03:28:18 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 11 Aug 2002 19:28:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-577777 ] System Error with slots and multi-inh
Message-ID: <E17e4wM-0000jA-00@usw-sf-web3.sourceforge.net>

Bugs item #577777, was opened at 2002-07-05 09:36
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=577777&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Arthur Siegel (aj_siegel)
Assigned to: Guido van Rossum (gvanrossum)
Summary: System Error with slots and multi-inh

Initial Comment:
May be just another version of report 575229.

>>> class A(object):
 __slots__="a"
>>> class B(object):
 pass
>>> class C(A,B):
 __slots__=("b")
>>> c=C()
>>> c.a=1
>>> c.b=2
>>> c.c=3
Traceback (most recent call last):
  File "<pyshell#12>", line 1, in ?
    c.c=3
SystemError: C:\Code\221\Objects\dictobject.c:511: 
bad argument to internal function

If B is a classic class and I do the same multi-
inheritance I get the expected error message:

AttributeError: 'C' object has no attribute 'c'



----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-11 22:28

Message:
Logged In: YES 
user_id=6380

Yes, I'm sure this is a dup of 575229. Please refer to that
one for resolution.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=577777&group_id=5470


From noreply@sourceforge.net  Mon Aug 12 03:30:44 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 11 Aug 2002 19:30:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-575229 ] multiple inheritance w/ slots dumps core
Message-ID: <E17e4yi-0000l8-00@usw-sf-web3.sourceforge.net>

Bugs item #575229, was opened at 2002-06-28 19:33
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575229&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Cesar Douady (douady)
Assigned to: Guido van Rossum (gvanrossum)
Summary: multiple inheritance w/ slots dumps core

Initial Comment:
The following script dumps a core (revision 2.2.1) :

class A(object): __slots__=()
class B(object): pass
class C(A,B) : __slots__=()
C().x=2

basic sizes for those classes are:
A => 8 (correct : no dict, no weakref)
B => 16 (correct : dict and weakref slots added)
C => 8 (incorrect : dict and weakref not inherited from
B)

in the last lines of type_new, variables add_dict and
add_weak
are exploited to add those slots, but only when
slots==NULL.
The best base selected for C is A, which is correct in
my opinion
since slots come from it, but dict and weak refs must
be treated
specially and can come from another base.

I have seen nothing in the cvs repository which may fix
this bug.

I did not submit a patch since this is a touchy part of
the interpreter,
but I may do it upon request.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-11 22:30

Message:
Logged In: YES 
user_id=6380

Thanks! Definitely a bug, and your analysis hits the nail
right on the head. I'll come up with a fix shortly. I can
still reproduce this in a debug build of 2.3 (i.e. current CVS).

----------------------------------------------------------------------

Comment By: Greg Chapman (glchapman)
Date: 2002-07-07 13:25

Message:
Logged In: YES 
user_id=86307

FWIW, using the 2.2.1 windows binary release, I don't get an 
access violation.  However, under a debug build of 2.2.1, I do 
get an access violation.  Under the debug build (and using the 
original example), C's tp_dictoffset == tp_basicsize == 16 (all 
Python objects in a debug build have two extra pointers).  
Thus _PyObject_GetDictPtr (called when setting the 'x' 
attribute) returns a pointer which points beyond the allocated 
memory, and the access violation is generated (because 
MSVC fills the area after the allocated area with a garbage 
value).  This almost certainly means the regular build is also 
accessing memory beyond what it allocates, but it just 
happens to work in this case.  At any rate, there definitely 
appears to be a bug here.

----------------------------------------------------------------------

Comment By: Cesar Douady (douady)
Date: 2002-07-03 12:51

Message:
Logged In: YES 
user_id=428521

oops!
I meant C.__basicsize__ is now 12 (it has slot 'a'), but
this is still less than 16.

----------------------------------------------------------------------

Comment By: Cesar Douady (douady)
Date: 2002-07-03 12:47

Message:
Logged In: YES 
user_id=428521

I could not replicate the core dump with the latest 2.2 from
CVS,  but the problem still exist : C.__basicsize__ still is
8, which should not possible when
deriving from a class whose basic size is 16.
The following script show an abnormal behavior (actually the
one I had initially in my application):

class A(object): __slots__=('a')
class B(object): pass
class C(A,B) : __slots__=()
c=C()
c.x=2
c.a  ==> {'x':2}

In the original example, the B.__dictoffset__ would point
out of C objects, which may or may not create a core dump,
depending on a lot of factors.
In this script, B.__dictoffset__ points to slot 'a' of C,
hence 'c.x=2' creates the dictionary which is then seen as
the 'a' slot of c.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-07-02 15:13

Message:
Logged In: YES 
user_id=33168

I could not replicate this problem from current CVS
nor from 2.2.1+ (cvs).  Can you test with the CVS
versions to see if you still have a problem?

for 2.2.1+ the tag is release22-maint

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575229&group_id=5470


From noreply@sourceforge.net  Mon Aug 12 08:15:12 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 12 Aug 2002 00:15:12 -0700
Subject: [Python-bugs-list] [ python-Bugs-585792 ] Invalid mmap crashes Python interpreter
Message-ID: <E17e9Q0-0003so-00@usw-sf-web4.sourceforge.net>

Bugs item #585792, was opened at 2002-07-24 10:52
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=585792&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Martin v. Löwis (loewis)
Summary: Invalid mmap crashes Python interpreter

Initial Comment:
This is under Red Hat 7.2, Linux kernel 2.4.7.   "x" is
an empty file, i.e. zero bytes long.

import mmap
f = open(x,"r+")m = mmap.mmap(f.fileno(), 10)
print m[1]

Crashes Python with a bus error.  Python should catch
the bus error signal
and raise an appropriate exception that the script can
catch.


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-08-12 09:15

Message:
Logged In: YES 
user_id=21627

Ah, an old-style diff. I assume that goes into mmap_item?

I'd rather avoid the stat call on every access, and check
the size on map creation.

The Solaris man page says this about changing files:

     If the size of the mapped file changes  after  the 
call  to
     mmap()  as  a  result  of some other operation on the
mapped
     file, the effect of references to  portions  of  the 
mapped
     region  that  correspond to added or removed portions
of the
     file is unspecified.

So it appears that this is a case of "don"t do this, then",
and that it atleast won't crash - but we might want to
perform a few experiments.



----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-11 17:05

Message:
Logged In: YES 
user_id=33168

Martin, could you please review the patch?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-07-28 17:00

Message:
Logged In: YES 
user_id=33168

Attached is a patch which fixes this problem.  I'm not sure
this patch it correct nor appropriate.  But it stops the
crash.  I'm hoping some mmap expert can shed some light on this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=585792&group_id=5470


From noreply@sourceforge.net  Mon Aug 12 08:17:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 12 Aug 2002 00:17:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-585792 ] Invalid mmap crashes Python interpreter
Message-ID: <E17e9SB-0003vD-00@usw-sf-web4.sourceforge.net>

Bugs item #585792, was opened at 2002-07-24 10:52
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=585792&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: paul rubin (phr)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: Invalid mmap crashes Python interpreter

Initial Comment:
This is under Red Hat 7.2, Linux kernel 2.4.7.   "x" is
an empty file, i.e. zero bytes long.

import mmap
f = open(x,"r+")m = mmap.mmap(f.fileno(), 10)
print m[1]

Crashes Python with a bus error.  Python should catch
the bus error signal
and raise an appropriate exception that the script can
catch.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-12 09:15

Message:
Logged In: YES 
user_id=21627

Ah, an old-style diff. I assume that goes into mmap_item?

I'd rather avoid the stat call on every access, and check
the size on map creation.

The Solaris man page says this about changing files:

     If the size of the mapped file changes  after  the 
call  to
     mmap()  as  a  result  of some other operation on the
mapped
     file, the effect of references to  portions  of  the 
mapped
     region  that  correspond to added or removed portions
of the
     file is unspecified.

So it appears that this is a case of "don"t do this, then",
and that it atleast won't crash - but we might want to
perform a few experiments.



----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-11 17:05

Message:
Logged In: YES 
user_id=33168

Martin, could you please review the patch?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-07-28 17:00

Message:
Logged In: YES 
user_id=33168

Attached is a patch which fixes this problem.  I'm not sure
this patch it correct nor appropriate.  But it stops the
crash.  I'm hoping some mmap expert can shed some light on this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=585792&group_id=5470


From noreply@sourceforge.net  Mon Aug 12 08:22:57 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 12 Aug 2002 00:22:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-411881 ] Use of "except:" in modules
Message-ID: <E17e9XV-00040Z-00@usw-sf-web4.sourceforge.net>

Bugs item #411881, was opened at 2001-03-28 14:58
You can respond by visiting: 
https://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: Skip Montanaro (montanaro)
>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: 2002-08-12 09:22

Message:
Logged In: YES 
user_id=21627

My proposal would be to track this under a different issue:
Terry, if you volunteer, please produce a new list of
offenders (perhaps in an attachment to the report so it can
be updated), and attach any fixes that you have to that report.

People with CVS write access can then apply those patches
and delete them from the report.

If you do so, please post the new issue number in this
report, so we have a link.

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2002-08-11 20:16

Message:
Logged In: YES 
user_id=593130

Remove types.py from the list.  As distributed with 2.2.1, it 
has 5 'except xxxError:' statements but no offending bare 
except:'s.

Skip (or anyone else): if/when you pursue this, I volunteer 
to do occasional sleuthing and send reports with 
suggestions and/or questions.  Example: getpass.py has 
one 'offense':
   try:
        fd = sys.stdin.fileno()
    except:
        return default_getpass(prompt)
According to lib doc 2.2.8 File Objects (as I interpret) fileno
() should either work without exception or *not* be 
implemented. Suggestion: insert AttributeError .  Question: 
do we protect against pseudofile objects that ignore doc 
and have fake .fileno() that raises NotImplementedError or 
whatever?


----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-03-23 07:02

Message:
Logged In: YES 
user_id=44345

as partial fix, checked in changes for the following
modules:

  mimetools.py (1.24)
  popen2.py (1.23)
  quopripy (1.19)
  CGIHTTPServer.py (1.22)


----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-03-20 22:24

Message:
Logged In: YES 
user_id=44345

Here is a context diff with proposed changes for the
following modules: CGIHTTPServer, cgi, cmd, code, 
fileinput, httplib, inspect, locale, mimetools, popen2,
quopri


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-08-11 17:06

Message:
Logged In: YES 
user_id=21627

Fixed urllib in 1.131 and types in 1.19.


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-07-04 09:11

Message:
Logged In: YES 
user_id=3066

Fixed modules mhlib and rfc822 (SF is having a problem
generating the checkin emails, though).

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-05-11 21:40

Message:
Logged In: YES 
user_id=3066

OK, I've fixed up a few more modules:

anydbm
chunk
formatter
htmllib
mailcap
pre
pty

I made one change to asyncore as well, but other bare except
clauses remain there; I'm not sufficiently familiar with
that code to just go digging into those.

I also fixed an infraction in pstats, but left others for now.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-04-23 10: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 09: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 16: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 11: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 17: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 19: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 19: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 19: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 17: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 12: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-30 08: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: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=411881&group_id=5470


From noreply@sourceforge.net  Mon Aug 12 08:45:12 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 12 Aug 2002 00:45:12 -0700
Subject: [Python-bugs-list] [ python-Bugs-585792 ] Invalid mmap crashes Python interpreter
Message-ID: <E17e9t2-0004RC-00@usw-sf-web4.sourceforge.net>

Bugs item #585792, was opened at 2002-07-24 01:52
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=585792&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Invalid mmap crashes Python interpreter

Initial Comment:
This is under Red Hat 7.2, Linux kernel 2.4.7.   "x" is
an empty file, i.e. zero bytes long.

import mmap
f = open(x,"r+")m = mmap.mmap(f.fileno(), 10)
print m[1]

Crashes Python with a bus error.  Python should catch
the bus error signal
and raise an appropriate exception that the script can
catch.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-08-12 00:45

Message:
Logged In: NO 

Please don't even think of adding a stat call to every
access.  The whole idea of mmap is to speed up access by
eliminating system calls when you touch the file contents. 
Checking the file size at map creation is reasonable.  Some
note should also be added to the mmap doc about possible
crashes if the file size changes.

>From a Python script writer's viewpoint, the most convenient
fix is for Python to catch the bus error signal and inspect
the stack to figure out that the trap occurred in the mmap
routine, then generate and return an appropriate Python
exception.  However, doing that is pretty
platform-dependent, and attempting it in all the Python
ports that support mmap doesn't sound practical.  

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-12 00:15

Message:
Logged In: YES 
user_id=21627

Ah, an old-style diff. I assume that goes into mmap_item?

I'd rather avoid the stat call on every access, and check
the size on map creation.

The Solaris man page says this about changing files:

     If the size of the mapped file changes  after  the 
call  to
     mmap()  as  a  result  of some other operation on the
mapped
     file, the effect of references to  portions  of  the 
mapped
     region  that  correspond to added or removed portions
of the
     file is unspecified.

So it appears that this is a case of "don"t do this, then",
and that it atleast won't crash - but we might want to
perform a few experiments.



----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-11 08:05

Message:
Logged In: YES 
user_id=33168

Martin, could you please review the patch?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-07-28 08:00

Message:
Logged In: YES 
user_id=33168

Attached is a patch which fixes this problem.  I'm not sure
this patch it correct nor appropriate.  But it stops the
crash.  I'm hoping some mmap expert can shed some light on this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=585792&group_id=5470


From noreply@sourceforge.net  Mon Aug 12 12:26:36 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 12 Aug 2002 04:26:36 -0700
Subject: [Python-bugs-list] [ python-Bugs-556025 ] list(xrange(1e9))  -->  seg fault
Message-ID: <E17eDLI-0000KU-00@usw-sf-web3.sourceforge.net>

Bugs item #556025, was opened at 2002-05-14 08:41
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=556025&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Jason Tishler (jlt63)
Summary: list(xrange(1e9))  -->  seg fault

Initial Comment:
>From c.lang.py:

'''
 Python 2.2.1 (#2, Apr 21 2002, 22:22:55) 
[GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.62mdk)] 
on linux2
Type "help", "copyright", "credits" or "license" for 
more information.
>>> list(xrange(1e9))
Segmentation fault
'''

I've reproduced the same fault on Windows ME using 
Py2.2.0 and Py2.3a.

----------------------------------------------------------------------

>Comment By: Jason Tishler (jlt63)
Date: 2002-08-12 03:26

Message:
Logged In: YES 
user_id=86216

rhettinger wrote:
> My thought is to close the bug, but add a
> unittest that says in effect:  if os is cygwin
> and version(cygwin) >= 1.3.13 and the bug still
> exists, then fail with a message saying that SF
> 556025 was not successfully resolved.

Do we really want to add cruft that is not only
Cygwin specific but Cygwin version specific?

nnorwitz wrote:
> I'm not sure if the test should fail, be
> skipped, or not run for cygwin < 1.3.13.

Agreed.

> But let's at least put a comment in the test and
> close this bug report.  Jason, can you do that?

Yes, but I only have pre-approved commit access to
the CVS repository. Can you approve the attached
patch?

> Good persistence Jason!

Thanks.


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-10 06:27

Message:
Logged In: YES 
user_id=33168

I'm not sure if the test should fail, be skipped, or not run
for cygwin < 1.3.13.  But let's at least put a comment in
the test and close this bug report.  Jason, can you do that?

Good persistence Jason!

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-08-09 19:08

Message:
Logged In: YES 
user_id=80475

My thought is to close the bug, but add a unittest that 
says in effect:  if os is cygwin and version(cygwin) >= 
1.3.13 and the bug still exists, then fail with a message 
saying that SF 556025 was not successfully resolved.

This way, we can close the bug (since it is not a python 
bug) and still get a regression test to raise the concern if 
the expected solution either doesn't materialize or 
sometime later dematerializes.


----------------------------------------------------------------------

Comment By: Jason Tishler (jlt63)
Date: 2002-08-09 17:02

Message:
Logged In: YES 
user_id=86216

I guess that my perseverance paid off:

http://sources.redhat.com/ml/newlib/2002/msg00391.html

Hence, this bug will be fixed in Cygwin 1.3.13.

Can we close this bug now? Or, should we wait until
Cygwin 1.3.13 is released?

----------------------------------------------------------------------

Comment By: Jason Tishler (jlt63)
Date: 2002-08-09 10:09

Message:
Logged In: YES 
user_id=86216

Thanks for the sympathy.

I've tried, tried again:

http://sources.redhat.com/ml/newlib/2002/msg00390.html

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-08 16:56

Message:
Logged In: YES 
user_id=33168

I looked at the links.  I don't know what I can do to help.
 It seems like you proposed a reasonable solution and even
if it wasn't perfect, you still demonstrated a problem.  I
suppose I can only commiserate with you.

----------------------------------------------------------------------

Comment By: Jason Tishler (jlt63)
Date: 2002-08-08 04:11

Message:
Logged In: YES 
user_id=86216

> Jason, can you test/replicate this?

Yes, I've already been working on this one. See
the following mailing list threads for the details:

http://cygwin.com/ml/cygwin-developers/2002-07/msg00124.html
http://sources.redhat.com/ml/newlib/2002/msg00369.html

To summarize the above, the problem is actually
in newlib which provides Cygwin's libc (and
libm).  Unfortunately, Chris Falyor (the Cygwin
lead developer) has not been able to convince
the newlib maintainer to fix this problem.
Additionally, my first patch has been rejected.

I will continue my efforts to get this problem
resolved.  Any assistance will be greatly
appreciated.  I never expected to become an
expert in Doug Lea's malloc routines.  Sigh...

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-07 12:11

Message:
Logged In: YES 
user_id=33168

Actually, I think Jason may be more appropriate, since this
is a cygwin problem.  Jason, can you test/replicate this?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-07 10:20

Message:
Logged In: YES 
user_id=33168

Hmmm, Tim can you reproduce this?  I luckily don't have a
windows box. :-)

----------------------------------------------------------------------

Comment By: Steve Holden (holdenweb)
Date: 2002-08-07 09:28

Message:
Logged In: YES 
user_id=88157

I hope re-opening this is the right thing to do (I'm new here).

Current CVS fails under Win2000+Cygwin with a 
segmentation fault in the updated test_b1.py. Easily 
reproduced:

$ ./python.exe
Python 2.3a0 (#1, Aug  7 2002, 12:18:38)
[GCC 2.95.3-5 (cygwin special)] on cygwin
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import sys
>>> list(xrange(sys.maxint/4))
Segmentation fault (core dumped)

This does seem to be size-related, as:

>>> s = sys.maxint/8
>>> list(xrange(s))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
MemoryError

which is as expected in test_b1.py


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-22 15:20

Message:
Logged In: YES 
user_id=33168

Checked in as:
  listobject.c 2.106
  test_b1.py 1.46

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-21 04:59

Message:
Logged In: YES 
user_id=80475

Good plan!  Thx for squashing this bug. 

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-21 04:52

Message:
Logged In: YES 
user_id=33168

How about using sys.maxint / 4?  Does that make more sense
than 1e9?  This assumption is a little better, that the data
and address sizes are the same.  I can add a comment to this
effect.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-20 19:37

Message:
Logged In: YES 
user_id=80475

When you load the fix, please commit the regression test 
patch also.  Thx,  Raymond

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-05-20 18:51

Message:
Logged In: YES 
user_id=31435

Yup, lookin' better.  Python does assume 8-bit bytes in 
several places, and also 2's-complement integers.  Since 
size_t is guaranteed (by C) to be an unsigned type, the 
largest value of type size_t is more easily expressed as

(~(size_t)0)

The C part of the patch looks fine then.  The test is a 
little dubious:  who says the machine can't create a 
billion-integer list?  The idea that 1e9 necessarily 
overflows in this context is a 32-bit address-space 
assumption.  But I'm willing to delay fixing that until a 
machine with a usable larger address space appears <wink>.

So marked Accepted and assigned to you for checkin.  Thanks!

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-20 07:43

Message:
Logged In: YES 
user_id=33168

Ok, there were other problems, too:
  * Need to divide by the size of the type, 
    not >> 4 which was completely broken.
  * There was a missing PyErr_NoMemory().

I uploaded a new patch.

I'm not sure the size_t fix is correct.
I hope we can at least assume 8-bit machines: :-)

if (_new_size <= ((1 << (sizeof(size_t)*8 - 1)) / sizeof(type)))



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-05-19 20:48

Message:
Logged In: YES 
user_id=31435

The code patch has some problems:  you can't assume any 
relation between a size_t and an unsigned long; C simply 
doesn't define how big size_t is, and relative sizes do 
vary on 64-bit platforms.  However that gets fixed, if you 
decide it's "too big", var should be set to NULL (not 0 -- 
this is a "Guido thing" <wink>), and no exception should be 
set.  It's the caller's responsibility to check var for 
NULL after the macro is invoked, and set an appropriate 
exception.  listobject.c sometimes doesn't check the result 
for NULL, but that should only be when it knows it's 
*shrinking* a memory area, so that realloc can't fail.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-17 16:12

Message:
Logged In: YES 
user_id=80475

Added a patch to add this bug to the testbank.

Shallow code review:  Patch compiles okay (applied to 
Py2.3a0). Fixes the original problem.  Passes the smell 
test.  Macro style good (only the "var" operand is used 
more than once; no side-effects except setting "var" to 
zero upon a resize error).  Passes the standard regression 
tests.  Passes regression testing versus my personal (real 
code) testbank.

Will give it a deeper look this week-end.

One other thought: should the ValueError be replaced with a 
MemoryError to make the message consistent with PyList_New?



----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 13:03

Message:
Logged In: YES 
user_id=33168

Ok, this time I have a patch.  The patch only fixes listobject.

I looked over the other uses of PyMem_R{ESIZE,ALLOC}() and
they don't appear to be nearly as problematic as list.  For
example, if the grammar has 1e9 nodes, there are going to be
other problems well before then (ie, memory will probably be
gone).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 12:25

Message:
Logged In: YES 
user_id=33168

Oops, sorry about that last comment.  That was something I
was playing with.  The CVS version is fine for [x]range(float).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 12:22

Message:
Logged In: YES 
user_id=33168

Note, this problem is even more generic in CVS version:

>>> range(1.1)
Segmentation fault (core dumped)
>>> xrange(1.1)
Segmentation fault (core dumped)

[x]xrange(float) work fine in 2.2.1.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-14 16:44

Message:
Logged In: YES 
user_id=80475

Would there be some merit to converting PyMem_RESIZE to a 
function with an overflow check?  

I would guess that the time spent on a realloc dwarfs the 
overhead of a short wrapper function.

OTOH, I'll bet this core dump only occurs in toy examples 
and never in real code.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-05-14 14:15

Message:
Logged In: YES 
user_id=31435

Heh.  This is an instance of a general flaw:  the 
PyMem_RESIZE macro doesn't check for int overflow in its

    (n) * sizeof(type)

subexpression. The basic deal is that 1000000000 fits in an 
int, but 4 times that (silently) overflows.  In more 
detail, for this specific test case, listobject.c'.s 
roundupsize rounds 1e9 up to 0x40000000, which silently 
underflows to 0!() when PyMem_RESIZE multiplies it by 4.

Hard to know how to fix this in general; PyMem_RESIZE 
callers don't generally worry about overflow now.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=556025&group_id=5470


From noreply@sourceforge.net  Mon Aug 12 14:30:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 12 Aug 2002 06:30:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-585792 ] Invalid mmap crashes Python interpreter
Message-ID: <E17eFHE-0002po-00@usw-sf-web4.sourceforge.net>

Bugs item #585792, was opened at 2002-07-24 04:52
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=585792&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: paul rubin (phr)
>Assigned to: Martin v. Löwis (loewis)
Summary: Invalid mmap crashes Python interpreter

Initial Comment:
This is under Red Hat 7.2, Linux kernel 2.4.7.   "x" is
an empty file, i.e. zero bytes long.

import mmap
f = open(x,"r+")m = mmap.mmap(f.fileno(), 10)
print m[1]

Crashes Python with a bus error.  Python should catch
the bus error signal
and raise an appropriate exception that the script can
catch.


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-12 09:30

Message:
Logged In: YES 
user_id=33168

I wasn't sure if I could change the size.  For Solaris at
least, it seems this is the right thing to do.  Is it likely
that other systems allow the file size to change?  I've
forced the size to be the max(size_arg, size_of_file).  This
has the added benefit of working for writing too.  Prior to
this patch, writing past the end crashed on Linux.

There are 2 comments in the patch:  one worrying about the
file changing, the other producing a warning message if the
size argument is larger than the file.  Do we have to worry
about the size changing?  Should we tell the user what they did?

Sorry about the old style diff.  I remembered to do the cvs
-f diff part, but forgot the -C5.  My defaults are unified.
New context patch attached.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-08-12 03:45

Message:
Logged In: NO 

Please don't even think of adding a stat call to every
access.  The whole idea of mmap is to speed up access by
eliminating system calls when you touch the file contents. 
Checking the file size at map creation is reasonable.  Some
note should also be added to the mmap doc about possible
crashes if the file size changes.

>From a Python script writer's viewpoint, the most convenient
fix is for Python to catch the bus error signal and inspect
the stack to figure out that the trap occurred in the mmap
routine, then generate and return an appropriate Python
exception.  However, doing that is pretty
platform-dependent, and attempting it in all the Python
ports that support mmap doesn't sound practical.  

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-12 03:15

Message:
Logged In: YES 
user_id=21627

Ah, an old-style diff. I assume that goes into mmap_item?

I'd rather avoid the stat call on every access, and check
the size on map creation.

The Solaris man page says this about changing files:

     If the size of the mapped file changes  after  the 
call  to
     mmap()  as  a  result  of some other operation on the
mapped
     file, the effect of references to  portions  of  the 
mapped
     region  that  correspond to added or removed portions
of the
     file is unspecified.

So it appears that this is a case of "don"t do this, then",
and that it atleast won't crash - but we might want to
perform a few experiments.



----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-11 11:05

Message:
Logged In: YES 
user_id=33168

Martin, could you please review the patch?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-07-28 11:00

Message:
Logged In: YES 
user_id=33168

Attached is a patch which fixes this problem.  I'm not sure
this patch it correct nor appropriate.  But it stops the
crash.  I'm hoping some mmap expert can shed some light on this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=585792&group_id=5470


From noreply@sourceforge.net  Mon Aug 12 14:38:15 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 12 Aug 2002 06:38:15 -0700
Subject: [Python-bugs-list] [ python-Bugs-556025 ] list(xrange(1e9))  -->  seg fault
Message-ID: <E17eFOh-000310-00@usw-sf-web4.sourceforge.net>

Bugs item #556025, was opened at 2002-05-14 12:41
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=556025&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Jason Tishler (jlt63)
Summary: list(xrange(1e9))  -->  seg fault

Initial Comment:
>From c.lang.py:

'''
 Python 2.2.1 (#2, Apr 21 2002, 22:22:55) 
[GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.62mdk)] 
on linux2
Type "help", "copyright", "credits" or "license" for 
more information.
>>> list(xrange(1e9))
Segmentation fault
'''

I've reproduced the same fault on Windows ME using 
Py2.2.0 and Py2.3a.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-12 09:38

Message:
Logged In: YES 
user_id=33168

You should probably add that it fails due to a bug in newlib
and not python.  Go ahead and check it in and close the bug
report.  Thanks.

----------------------------------------------------------------------

Comment By: Jason Tishler (jlt63)
Date: 2002-08-12 07:26

Message:
Logged In: YES 
user_id=86216

rhettinger wrote:
> My thought is to close the bug, but add a
> unittest that says in effect:  if os is cygwin
> and version(cygwin) >= 1.3.13 and the bug still
> exists, then fail with a message saying that SF
> 556025 was not successfully resolved.

Do we really want to add cruft that is not only
Cygwin specific but Cygwin version specific?

nnorwitz wrote:
> I'm not sure if the test should fail, be
> skipped, or not run for cygwin < 1.3.13.

Agreed.

> But let's at least put a comment in the test and
> close this bug report.  Jason, can you do that?

Yes, but I only have pre-approved commit access to
the CVS repository. Can you approve the attached
patch?

> Good persistence Jason!

Thanks.


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-10 10:27

Message:
Logged In: YES 
user_id=33168

I'm not sure if the test should fail, be skipped, or not run
for cygwin < 1.3.13.  But let's at least put a comment in
the test and close this bug report.  Jason, can you do that?

Good persistence Jason!

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-08-09 23:08

Message:
Logged In: YES 
user_id=80475

My thought is to close the bug, but add a unittest that 
says in effect:  if os is cygwin and version(cygwin) >= 
1.3.13 and the bug still exists, then fail with a message 
saying that SF 556025 was not successfully resolved.

This way, we can close the bug (since it is not a python 
bug) and still get a regression test to raise the concern if 
the expected solution either doesn't materialize or 
sometime later dematerializes.


----------------------------------------------------------------------

Comment By: Jason Tishler (jlt63)
Date: 2002-08-09 21:02

Message:
Logged In: YES 
user_id=86216

I guess that my perseverance paid off:

http://sources.redhat.com/ml/newlib/2002/msg00391.html

Hence, this bug will be fixed in Cygwin 1.3.13.

Can we close this bug now? Or, should we wait until
Cygwin 1.3.13 is released?

----------------------------------------------------------------------

Comment By: Jason Tishler (jlt63)
Date: 2002-08-09 14:09

Message:
Logged In: YES 
user_id=86216

Thanks for the sympathy.

I've tried, tried again:

http://sources.redhat.com/ml/newlib/2002/msg00390.html

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-08 20:56

Message:
Logged In: YES 
user_id=33168

I looked at the links.  I don't know what I can do to help.
 It seems like you proposed a reasonable solution and even
if it wasn't perfect, you still demonstrated a problem.  I
suppose I can only commiserate with you.

----------------------------------------------------------------------

Comment By: Jason Tishler (jlt63)
Date: 2002-08-08 08:11

Message:
Logged In: YES 
user_id=86216

> Jason, can you test/replicate this?

Yes, I've already been working on this one. See
the following mailing list threads for the details:

http://cygwin.com/ml/cygwin-developers/2002-07/msg00124.html
http://sources.redhat.com/ml/newlib/2002/msg00369.html

To summarize the above, the problem is actually
in newlib which provides Cygwin's libc (and
libm).  Unfortunately, Chris Falyor (the Cygwin
lead developer) has not been able to convince
the newlib maintainer to fix this problem.
Additionally, my first patch has been rejected.

I will continue my efforts to get this problem
resolved.  Any assistance will be greatly
appreciated.  I never expected to become an
expert in Doug Lea's malloc routines.  Sigh...

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-07 16:11

Message:
Logged In: YES 
user_id=33168

Actually, I think Jason may be more appropriate, since this
is a cygwin problem.  Jason, can you test/replicate this?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-07 14:20

Message:
Logged In: YES 
user_id=33168

Hmmm, Tim can you reproduce this?  I luckily don't have a
windows box. :-)

----------------------------------------------------------------------

Comment By: Steve Holden (holdenweb)
Date: 2002-08-07 13:28

Message:
Logged In: YES 
user_id=88157

I hope re-opening this is the right thing to do (I'm new here).

Current CVS fails under Win2000+Cygwin with a 
segmentation fault in the updated test_b1.py. Easily 
reproduced:

$ ./python.exe
Python 2.3a0 (#1, Aug  7 2002, 12:18:38)
[GCC 2.95.3-5 (cygwin special)] on cygwin
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import sys
>>> list(xrange(sys.maxint/4))
Segmentation fault (core dumped)

This does seem to be size-related, as:

>>> s = sys.maxint/8
>>> list(xrange(s))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
MemoryError

which is as expected in test_b1.py


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-22 19:20

Message:
Logged In: YES 
user_id=33168

Checked in as:
  listobject.c 2.106
  test_b1.py 1.46

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-21 08:59

Message:
Logged In: YES 
user_id=80475

Good plan!  Thx for squashing this bug. 

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-21 08:52

Message:
Logged In: YES 
user_id=33168

How about using sys.maxint / 4?  Does that make more sense
than 1e9?  This assumption is a little better, that the data
and address sizes are the same.  I can add a comment to this
effect.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-20 23:37

Message:
Logged In: YES 
user_id=80475

When you load the fix, please commit the regression test 
patch also.  Thx,  Raymond

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-05-20 22:51

Message:
Logged In: YES 
user_id=31435

Yup, lookin' better.  Python does assume 8-bit bytes in 
several places, and also 2's-complement integers.  Since 
size_t is guaranteed (by C) to be an unsigned type, the 
largest value of type size_t is more easily expressed as

(~(size_t)0)

The C part of the patch looks fine then.  The test is a 
little dubious:  who says the machine can't create a 
billion-integer list?  The idea that 1e9 necessarily 
overflows in this context is a 32-bit address-space 
assumption.  But I'm willing to delay fixing that until a 
machine with a usable larger address space appears <wink>.

So marked Accepted and assigned to you for checkin.  Thanks!

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-20 11:43

Message:
Logged In: YES 
user_id=33168

Ok, there were other problems, too:
  * Need to divide by the size of the type, 
    not >> 4 which was completely broken.
  * There was a missing PyErr_NoMemory().

I uploaded a new patch.

I'm not sure the size_t fix is correct.
I hope we can at least assume 8-bit machines: :-)

if (_new_size <= ((1 << (sizeof(size_t)*8 - 1)) / sizeof(type)))



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-05-20 00:48

Message:
Logged In: YES 
user_id=31435

The code patch has some problems:  you can't assume any 
relation between a size_t and an unsigned long; C simply 
doesn't define how big size_t is, and relative sizes do 
vary on 64-bit platforms.  However that gets fixed, if you 
decide it's "too big", var should be set to NULL (not 0 -- 
this is a "Guido thing" <wink>), and no exception should be 
set.  It's the caller's responsibility to check var for 
NULL after the macro is invoked, and set an appropriate 
exception.  listobject.c sometimes doesn't check the result 
for NULL, but that should only be when it knows it's 
*shrinking* a memory area, so that realloc can't fail.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-17 20:12

Message:
Logged In: YES 
user_id=80475

Added a patch to add this bug to the testbank.

Shallow code review:  Patch compiles okay (applied to 
Py2.3a0). Fixes the original problem.  Passes the smell 
test.  Macro style good (only the "var" operand is used 
more than once; no side-effects except setting "var" to 
zero upon a resize error).  Passes the standard regression 
tests.  Passes regression testing versus my personal (real 
code) testbank.

Will give it a deeper look this week-end.

One other thought: should the ValueError be replaced with a 
MemoryError to make the message consistent with PyList_New?



----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 17:03

Message:
Logged In: YES 
user_id=33168

Ok, this time I have a patch.  The patch only fixes listobject.

I looked over the other uses of PyMem_R{ESIZE,ALLOC}() and
they don't appear to be nearly as problematic as list.  For
example, if the grammar has 1e9 nodes, there are going to be
other problems well before then (ie, memory will probably be
gone).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 16:25

Message:
Logged In: YES 
user_id=33168

Oops, sorry about that last comment.  That was something I
was playing with.  The CVS version is fine for [x]range(float).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 16:22

Message:
Logged In: YES 
user_id=33168

Note, this problem is even more generic in CVS version:

>>> range(1.1)
Segmentation fault (core dumped)
>>> xrange(1.1)
Segmentation fault (core dumped)

[x]xrange(float) work fine in 2.2.1.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-14 20:44

Message:
Logged In: YES 
user_id=80475

Would there be some merit to converting PyMem_RESIZE to a 
function with an overflow check?  

I would guess that the time spent on a realloc dwarfs the 
overhead of a short wrapper function.

OTOH, I'll bet this core dump only occurs in toy examples 
and never in real code.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-05-14 18:15

Message:
Logged In: YES 
user_id=31435

Heh.  This is an instance of a general flaw:  the 
PyMem_RESIZE macro doesn't check for int overflow in its

    (n) * sizeof(type)

subexpression. The basic deal is that 1000000000 fits in an 
int, but 4 times that (silently) overflows.  In more 
detail, for this specific test case, listobject.c'.s 
roundupsize rounds 1e9 up to 0x40000000, which silently 
underflows to 0!() when PyMem_RESIZE multiplies it by 4.

Hard to know how to fix this in general; PyMem_RESIZE 
callers don't generally worry about overflow now.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=556025&group_id=5470


From noreply@sourceforge.net  Mon Aug 12 15:32:59 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 12 Aug 2002 07:32:59 -0700
Subject: [Python-bugs-list] [ python-Bugs-594063 ] r'\' => Syntax error
Message-ID: <E17eGFf-0007tU-00@usw-sf-web5.sourceforge.net>

Bugs item #594063, was opened at 2002-08-12 14:32
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594063&group_id=5470

Category: Parser/Compiler
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: a.hofkamp (axhlkhb)
Assigned to: Nobody/Anonymous (nobody)
Summary: r'\' => Syntax error

Initial Comment:
The raw string is supposed to treat \ as literal
characters. It does that with

>>> print r'\aslkjv'
\aslkjv

and

>>> print r'\'kdsr'
\'kdsr

but not with

>>> print r'\'
  File "<stdin>", line 1
    print r'\'
             ^
SyntaxError: invalid token

In the last case, I intend to have a string containing
a \ only.

This happens with Python 1.5.2 and 2.1.1
(on FreeBSD and/or Linux)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594063&group_id=5470


From noreply@sourceforge.net  Mon Aug 12 15:45:53 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 12 Aug 2002 07:45:53 -0700
Subject: [Python-bugs-list] [ python-Bugs-585792 ] Invalid mmap crashes Python interpreter
Message-ID: <E17eGS9-0004bV-00@usw-sf-web4.sourceforge.net>

Bugs item #585792, was opened at 2002-07-24 10:52
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=585792&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: paul rubin (phr)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: Invalid mmap crashes Python interpreter

Initial Comment:
This is under Red Hat 7.2, Linux kernel 2.4.7.   "x" is
an empty file, i.e. zero bytes long.

import mmap
f = open(x,"r+")m = mmap.mmap(f.fileno(), 10)
print m[1]

Crashes Python with a bus error.  Python should catch
the bus error signal
and raise an appropriate exception that the script can
catch.


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-08-12 16:45

Message:
Logged In: YES 
user_id=21627

I'd say it is a ValueError if the map size is larger than
the file size, instead of silently decreasing the size:
Errors should never pass silently, Unless explicitly silenced.

On the trick of new_buffersize: I'm not sure I understand
what you are referring to: we don't use stdio in mmap at all.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-12 15:30

Message:
Logged In: YES 
user_id=33168

I wasn't sure if I could change the size.  For Solaris at
least, it seems this is the right thing to do.  Is it likely
that other systems allow the file size to change?  I've
forced the size to be the max(size_arg, size_of_file).  This
has the added benefit of working for writing too.  Prior to
this patch, writing past the end crashed on Linux.

There are 2 comments in the patch:  one worrying about the
file changing, the other producing a warning message if the
size argument is larger than the file.  Do we have to worry
about the size changing?  Should we tell the user what they did?

Sorry about the old style diff.  I remembered to do the cvs
-f diff part, but forgot the -C5.  My defaults are unified.
New context patch attached.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-08-12 09:45

Message:
Logged In: NO 

Please don't even think of adding a stat call to every
access.  The whole idea of mmap is to speed up access by
eliminating system calls when you touch the file contents. 
Checking the file size at map creation is reasonable.  Some
note should also be added to the mmap doc about possible
crashes if the file size changes.

>From a Python script writer's viewpoint, the most convenient
fix is for Python to catch the bus error signal and inspect
the stack to figure out that the trap occurred in the mmap
routine, then generate and return an appropriate Python
exception.  However, doing that is pretty
platform-dependent, and attempting it in all the Python
ports that support mmap doesn't sound practical.  

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-12 09:15

Message:
Logged In: YES 
user_id=21627

Ah, an old-style diff. I assume that goes into mmap_item?

I'd rather avoid the stat call on every access, and check
the size on map creation.

The Solaris man page says this about changing files:

     If the size of the mapped file changes  after  the 
call  to
     mmap()  as  a  result  of some other operation on the
mapped
     file, the effect of references to  portions  of  the 
mapped
     region  that  correspond to added or removed portions
of the
     file is unspecified.

So it appears that this is a case of "don"t do this, then",
and that it atleast won't crash - but we might want to
perform a few experiments.



----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-11 17:05

Message:
Logged In: YES 
user_id=33168

Martin, could you please review the patch?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-07-28 17:00

Message:
Logged In: YES 
user_id=33168

Attached is a patch which fixes this problem.  I'm not sure
this patch it correct nor appropriate.  But it stops the
crash.  I'm hoping some mmap expert can shed some light on this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=585792&group_id=5470


From noreply@sourceforge.net  Mon Aug 12 16:26:17 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 12 Aug 2002 08:26:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-594063 ] r'\' => Syntax error
Message-ID: <E17eH5F-0005gT-00@usw-sf-web1.sourceforge.net>

Bugs item #594063, was opened at 2002-08-12 10:32
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594063&group_id=5470

Category: Parser/Compiler
>Group: Not a Bug
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: a.hofkamp (axhlkhb)
Assigned to: Nobody/Anonymous (nobody)
Summary: r'\' => Syntax error

Initial Comment:
The raw string is supposed to treat \ as literal
characters. It does that with

>>> print r'\aslkjv'
\aslkjv

and

>>> print r'\'kdsr'
\'kdsr

but not with

>>> print r'\'
  File "<stdin>", line 1
    print r'\'
             ^
SyntaxError: invalid token

In the last case, I intend to have a string containing
a \ only.

This happens with Python 1.5.2 and 2.1.1
(on FreeBSD and/or Linux)


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-08-12 11:26

Message:
Logged In: YES 
user_id=31435

Sorry, you're out of luck -- raw strings can't end with an odd 
number of backslashes, else there would be no way to write 
a raw string containing the quoting character.  See FAQ 
entry 6.29:

<http://www.python.org/cgi-bin/faqw.py?
req=show&file=faq06.029.htp>

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594063&group_id=5470


From noreply@sourceforge.net  Mon Aug 12 16:47:01 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 12 Aug 2002 08:47:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-585792 ] Invalid mmap crashes Python interpreter
Message-ID: <E17eHPJ-0005E7-00@usw-sf-web2.sourceforge.net>

Bugs item #585792, was opened at 2002-07-24 04:52
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=585792&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: paul rubin (phr)
>Assigned to: Martin v. Löwis (loewis)
Summary: Invalid mmap crashes Python interpreter

Initial Comment:
This is under Red Hat 7.2, Linux kernel 2.4.7.   "x" is
an empty file, i.e. zero bytes long.

import mmap
f = open(x,"r+")m = mmap.mmap(f.fileno(), 10)
print m[1]

Crashes Python with a bus error.  Python should catch
the bus error signal
and raise an appropriate exception that the script can
catch.


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-12 11:47

Message:
Logged In: YES 
user_id=33168

I thought the st_size was updated by the code in
new_buffersize.  It was only the position, so the comment
should go.  ValueError is fine with me.  Should I add an
entry to NEWS?  New patch attached w/NEWS and test.

There is another issue--Windows.  I how Windows behaves and
I can't test it.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-12 10:45

Message:
Logged In: YES 
user_id=21627

I'd say it is a ValueError if the map size is larger than
the file size, instead of silently decreasing the size:
Errors should never pass silently, Unless explicitly silenced.

On the trick of new_buffersize: I'm not sure I understand
what you are referring to: we don't use stdio in mmap at all.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-12 09:30

Message:
Logged In: YES 
user_id=33168

I wasn't sure if I could change the size.  For Solaris at
least, it seems this is the right thing to do.  Is it likely
that other systems allow the file size to change?  I've
forced the size to be the max(size_arg, size_of_file).  This
has the added benefit of working for writing too.  Prior to
this patch, writing past the end crashed on Linux.

There are 2 comments in the patch:  one worrying about the
file changing, the other producing a warning message if the
size argument is larger than the file.  Do we have to worry
about the size changing?  Should we tell the user what they did?

Sorry about the old style diff.  I remembered to do the cvs
-f diff part, but forgot the -C5.  My defaults are unified.
New context patch attached.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-08-12 03:45

Message:
Logged In: NO 

Please don't even think of adding a stat call to every
access.  The whole idea of mmap is to speed up access by
eliminating system calls when you touch the file contents. 
Checking the file size at map creation is reasonable.  Some
note should also be added to the mmap doc about possible
crashes if the file size changes.

>From a Python script writer's viewpoint, the most convenient
fix is for Python to catch the bus error signal and inspect
the stack to figure out that the trap occurred in the mmap
routine, then generate and return an appropriate Python
exception.  However, doing that is pretty
platform-dependent, and attempting it in all the Python
ports that support mmap doesn't sound practical.  

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-12 03:15

Message:
Logged In: YES 
user_id=21627

Ah, an old-style diff. I assume that goes into mmap_item?

I'd rather avoid the stat call on every access, and check
the size on map creation.

The Solaris man page says this about changing files:

     If the size of the mapped file changes  after  the 
call  to
     mmap()  as  a  result  of some other operation on the
mapped
     file, the effect of references to  portions  of  the 
mapped
     region  that  correspond to added or removed portions
of the
     file is unspecified.

So it appears that this is a case of "don"t do this, then",
and that it atleast won't crash - but we might want to
perform a few experiments.



----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-11 11:05

Message:
Logged In: YES 
user_id=33168

Martin, could you please review the patch?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-07-28 11:00

Message:
Logged In: YES 
user_id=33168

Attached is a patch which fixes this problem.  I'm not sure
this patch it correct nor appropriate.  But it stops the
crash.  I'm hoping some mmap expert can shed some light on this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=585792&group_id=5470


From noreply@sourceforge.net  Mon Aug 12 16:49:15 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 12 Aug 2002 08:49:15 -0700
Subject: [Python-bugs-list] [ python-Bugs-585792 ] Invalid mmap crashes Python interpreter
Message-ID: <E17eHRT-0005Fr-00@usw-sf-web2.sourceforge.net>

Bugs item #585792, was opened at 2002-07-24 04:52
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=585792&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Martin v. Löwis (loewis)
Summary: Invalid mmap crashes Python interpreter

Initial Comment:
This is under Red Hat 7.2, Linux kernel 2.4.7.   "x" is
an empty file, i.e. zero bytes long.

import mmap
f = open(x,"r+")m = mmap.mmap(f.fileno(), 10)
print m[1]

Crashes Python with a bus error.  Python should catch
the bus error signal
and raise an appropriate exception that the script can
catch.


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-12 11:49

Message:
Logged In: YES 
user_id=33168

That last comment was supposed to be:  I don't know how
Windows behaves...

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-12 11:47

Message:
Logged In: YES 
user_id=33168

I thought the st_size was updated by the code in
new_buffersize.  It was only the position, so the comment
should go.  ValueError is fine with me.  Should I add an
entry to NEWS?  New patch attached w/NEWS and test.

There is another issue--Windows.  I how Windows behaves and
I can't test it.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-12 10:45

Message:
Logged In: YES 
user_id=21627

I'd say it is a ValueError if the map size is larger than
the file size, instead of silently decreasing the size:
Errors should never pass silently, Unless explicitly silenced.

On the trick of new_buffersize: I'm not sure I understand
what you are referring to: we don't use stdio in mmap at all.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-12 09:30

Message:
Logged In: YES 
user_id=33168

I wasn't sure if I could change the size.  For Solaris at
least, it seems this is the right thing to do.  Is it likely
that other systems allow the file size to change?  I've
forced the size to be the max(size_arg, size_of_file).  This
has the added benefit of working for writing too.  Prior to
this patch, writing past the end crashed on Linux.

There are 2 comments in the patch:  one worrying about the
file changing, the other producing a warning message if the
size argument is larger than the file.  Do we have to worry
about the size changing?  Should we tell the user what they did?

Sorry about the old style diff.  I remembered to do the cvs
-f diff part, but forgot the -C5.  My defaults are unified.
New context patch attached.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-08-12 03:45

Message:
Logged In: NO 

Please don't even think of adding a stat call to every
access.  The whole idea of mmap is to speed up access by
eliminating system calls when you touch the file contents. 
Checking the file size at map creation is reasonable.  Some
note should also be added to the mmap doc about possible
crashes if the file size changes.

>From a Python script writer's viewpoint, the most convenient
fix is for Python to catch the bus error signal and inspect
the stack to figure out that the trap occurred in the mmap
routine, then generate and return an appropriate Python
exception.  However, doing that is pretty
platform-dependent, and attempting it in all the Python
ports that support mmap doesn't sound practical.  

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-12 03:15

Message:
Logged In: YES 
user_id=21627

Ah, an old-style diff. I assume that goes into mmap_item?

I'd rather avoid the stat call on every access, and check
the size on map creation.

The Solaris man page says this about changing files:

     If the size of the mapped file changes  after  the 
call  to
     mmap()  as  a  result  of some other operation on the
mapped
     file, the effect of references to  portions  of  the 
mapped
     region  that  correspond to added or removed portions
of the
     file is unspecified.

So it appears that this is a case of "don"t do this, then",
and that it atleast won't crash - but we might want to
perform a few experiments.



----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-11 11:05

Message:
Logged In: YES 
user_id=33168

Martin, could you please review the patch?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-07-28 11:00

Message:
Logged In: YES 
user_id=33168

Attached is a patch which fixes this problem.  I'm not sure
this patch it correct nor appropriate.  But it stops the
crash.  I'm hoping some mmap expert can shed some light on this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=585792&group_id=5470


From noreply@sourceforge.net  Mon Aug 12 16:59:29 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 12 Aug 2002 08:59:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-585792 ] Invalid mmap crashes Python interpreter
Message-ID: <E17eHbN-0005Qa-00@usw-sf-web2.sourceforge.net>

Bugs item #585792, was opened at 2002-07-24 04:52
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=585792&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Martin v. Löwis (loewis)
Summary: Invalid mmap crashes Python interpreter

Initial Comment:
This is under Red Hat 7.2, Linux kernel 2.4.7.   "x" is
an empty file, i.e. zero bytes long.

import mmap
f = open(x,"r+")m = mmap.mmap(f.fileno(), 10)
print m[1]

Crashes Python with a bus error.  Python should catch
the bus error signal
and raise an appropriate exception that the script can
catch.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-08-12 11:59

Message:
Logged In: YES 
user_id=31435

mmap() on WIndows doesn't care if you map more bytes 
than exist in the file -- if you do, it grows the file to match.

"""
If an application specifies a size for the file mapping object 
that is larger than the size of the actual named file on disk, 
the file on disk is grown to match the specified size of the 
file mapping object. If the file cannot be grown, this results 
in a failure to create the file mapping object. GetLastError 
will return ERROR_DISK_FULL.
"""

Like so:

>>> import mmap
>>> import os
>>> os.path.getsize('abc.abc')
12L
>>> f = file('abc.abc', 'r+')
>>> m = mmap.mmap(f.fileno(), 10000)
>>> m.close()
>>> os.path.getsize('abc.abc')
10000L
>>>


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-12 11:49

Message:
Logged In: YES 
user_id=33168

That last comment was supposed to be:  I don't know how
Windows behaves...

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-12 11:47

Message:
Logged In: YES 
user_id=33168

I thought the st_size was updated by the code in
new_buffersize.  It was only the position, so the comment
should go.  ValueError is fine with me.  Should I add an
entry to NEWS?  New patch attached w/NEWS and test.

There is another issue--Windows.  I how Windows behaves and
I can't test it.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-12 10:45

Message:
Logged In: YES 
user_id=21627

I'd say it is a ValueError if the map size is larger than
the file size, instead of silently decreasing the size:
Errors should never pass silently, Unless explicitly silenced.

On the trick of new_buffersize: I'm not sure I understand
what you are referring to: we don't use stdio in mmap at all.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-12 09:30

Message:
Logged In: YES 
user_id=33168

I wasn't sure if I could change the size.  For Solaris at
least, it seems this is the right thing to do.  Is it likely
that other systems allow the file size to change?  I've
forced the size to be the max(size_arg, size_of_file).  This
has the added benefit of working for writing too.  Prior to
this patch, writing past the end crashed on Linux.

There are 2 comments in the patch:  one worrying about the
file changing, the other producing a warning message if the
size argument is larger than the file.  Do we have to worry
about the size changing?  Should we tell the user what they did?

Sorry about the old style diff.  I remembered to do the cvs
-f diff part, but forgot the -C5.  My defaults are unified.
New context patch attached.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-08-12 03:45

Message:
Logged In: NO 

Please don't even think of adding a stat call to every
access.  The whole idea of mmap is to speed up access by
eliminating system calls when you touch the file contents. 
Checking the file size at map creation is reasonable.  Some
note should also be added to the mmap doc about possible
crashes if the file size changes.

>From a Python script writer's viewpoint, the most convenient
fix is for Python to catch the bus error signal and inspect
the stack to figure out that the trap occurred in the mmap
routine, then generate and return an appropriate Python
exception.  However, doing that is pretty
platform-dependent, and attempting it in all the Python
ports that support mmap doesn't sound practical.  

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-12 03:15

Message:
Logged In: YES 
user_id=21627

Ah, an old-style diff. I assume that goes into mmap_item?

I'd rather avoid the stat call on every access, and check
the size on map creation.

The Solaris man page says this about changing files:

     If the size of the mapped file changes  after  the 
call  to
     mmap()  as  a  result  of some other operation on the
mapped
     file, the effect of references to  portions  of  the 
mapped
     region  that  correspond to added or removed portions
of the
     file is unspecified.

So it appears that this is a case of "don"t do this, then",
and that it atleast won't crash - but we might want to
perform a few experiments.



----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-11 11:05

Message:
Logged In: YES 
user_id=33168

Martin, could you please review the patch?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-07-28 11:00

Message:
Logged In: YES 
user_id=33168

Attached is a patch which fixes this problem.  I'm not sure
this patch it correct nor appropriate.  But it stops the
crash.  I'm hoping some mmap expert can shed some light on this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=585792&group_id=5470


From noreply@sourceforge.net  Mon Aug 12 17:04:42 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 12 Aug 2002 09:04:42 -0700
Subject: [Python-bugs-list] [ python-Bugs-594063 ] r'\' => Syntax error
Message-ID: <E17eHgQ-0006nA-00@usw-sf-web1.sourceforge.net>

Bugs item #594063, was opened at 2002-08-12 14:32
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594063&group_id=5470

Category: Parser/Compiler
Group: Not a Bug
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: a.hofkamp (axhlkhb)
Assigned to: Nobody/Anonymous (nobody)
Summary: r'\' => Syntax error

Initial Comment:
The raw string is supposed to treat \ as literal
characters. It does that with

>>> print r'\aslkjv'
\aslkjv

and

>>> print r'\'kdsr'
\'kdsr

but not with

>>> print r'\'
  File "<stdin>", line 1
    print r'\'
             ^
SyntaxError: invalid token

In the last case, I intend to have a string containing
a \ only.

This happens with Python 1.5.2 and 2.1.1
(on FreeBSD and/or Linux)


----------------------------------------------------------------------

>Comment By: a.hofkamp (axhlkhb)
Date: 2002-08-12 16:04

Message:
Logged In: YES 
user_id=438586

Hello Tim,

Hmm, the Python documentation is really good :-)

I used the Python pocket reference, and they say
'backslashed are retained literally'. From that statement
I deduced that r'\' should work. Apparently O'Reilly was
wrong in this case.

I find your argument of quoting string delimiters not really
convincing.
I can use either " or ' around the string, and I then have
the other quote character freely available.
The case that both quote characters are needed in the string
is extremely rare in my experience.

Therefore, it may be nicer for users to allow r'\' (i.e.
allow an odd number of back slashes), and only do trickery
like described in the FAQ (6.29) when both ' and " are
needed as quoting characters in the string.

Note that when one needs both ' and " as character, some
(advanced) trickery with back-slashes to escape either ' or
" is needed anyway in Python in that case. Not being able to
use raw strings then makes the problem not much
bigger/complexer.

Albert


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-08-12 15:26

Message:
Logged In: YES 
user_id=31435

Sorry, you're out of luck -- raw strings can't end with an odd 
number of backslashes, else there would be no way to write 
a raw string containing the quoting character.  See FAQ 
entry 6.29:

<http://www.python.org/cgi-bin/faqw.py?
req=show&file=faq06.029.htp>

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594063&group_id=5470


From noreply@sourceforge.net  Mon Aug 12 17:20:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 12 Aug 2002 09:20:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-594063 ] r'\' => Syntax error
Message-ID: <E17eHvf-0005pq-00@usw-sf-web2.sourceforge.net>

Bugs item #594063, was opened at 2002-08-12 10:32
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594063&group_id=5470

Category: Parser/Compiler
Group: Not a Bug
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: a.hofkamp (axhlkhb)
Assigned to: Nobody/Anonymous (nobody)
Summary: r'\' => Syntax error

Initial Comment:
The raw string is supposed to treat \ as literal
characters. It does that with

>>> print r'\aslkjv'
\aslkjv

and

>>> print r'\'kdsr'
\'kdsr

but not with

>>> print r'\'
  File "<stdin>", line 1
    print r'\'
             ^
SyntaxError: invalid token

In the last case, I intend to have a string containing
a \ only.

This happens with Python 1.5.2 and 2.1.1
(on FreeBSD and/or Linux)


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-08-12 12:20

Message:
Logged In: YES 
user_id=31435

Sorry, you're still out of luck.  This isn't going to change 
(you don't imagine it became a FAQ because you're the 
first person to argue about it <wink>?).

It's not uncommon to need both kinds of quotes in regexps, 
BTW, and that's the primary purpose of r-strings.

Backslashes are retained literally -- no exceptions.

It's not true that it requires "advanced trickery" to use both 
kinds of quotes in an r-string.  It's straightforward.

About docs, please read the section on string literals in the 
Python Reference Manual.  It's quite clear about the rules 
for r-strings.

----------------------------------------------------------------------

Comment By: a.hofkamp (axhlkhb)
Date: 2002-08-12 12:04

Message:
Logged In: YES 
user_id=438586

Hello Tim,

Hmm, the Python documentation is really good :-)

I used the Python pocket reference, and they say
'backslashed are retained literally'. From that statement
I deduced that r'\' should work. Apparently O'Reilly was
wrong in this case.

I find your argument of quoting string delimiters not really
convincing.
I can use either " or ' around the string, and I then have
the other quote character freely available.
The case that both quote characters are needed in the string
is extremely rare in my experience.

Therefore, it may be nicer for users to allow r'\' (i.e.
allow an odd number of back slashes), and only do trickery
like described in the FAQ (6.29) when both ' and " are
needed as quoting characters in the string.

Note that when one needs both ' and " as character, some
(advanced) trickery with back-slashes to escape either ' or
" is needed anyway in Python in that case. Not being able to
use raw strings then makes the problem not much
bigger/complexer.

Albert


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-08-12 11:26

Message:
Logged In: YES 
user_id=31435

Sorry, you're out of luck -- raw strings can't end with an odd 
number of backslashes, else there would be no way to write 
a raw string containing the quoting character.  See FAQ 
entry 6.29:

<http://www.python.org/cgi-bin/faqw.py?
req=show&file=faq06.029.htp>

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594063&group_id=5470


From noreply@sourceforge.net  Mon Aug 12 17:31:19 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 12 Aug 2002 09:31:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-585792 ] Invalid mmap crashes Python interpreter
Message-ID: <E17eI6B-00031W-00@usw-sf-web5.sourceforge.net>

Bugs item #585792, was opened at 2002-07-24 10:52
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=585792&group_id=5470

Category: None
Group: None
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: paul rubin (phr)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: Invalid mmap crashes Python interpreter

Initial Comment:
This is under Red Hat 7.2, Linux kernel 2.4.7.   "x" is
an empty file, i.e. zero bytes long.

import mmap
f = open(x,"r+")m = mmap.mmap(f.fileno(), 10)
print m[1]

Crashes Python with a bus error.  Python should catch
the bus error signal
and raise an appropriate exception that the script can
catch.


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-08-12 18:31

Message:
Logged In: YES 
user_id=21627

I think we should special-case Windows, then. For the
mmapmodule patch proper, nothing needs to be done; for the
testsuite test, pass and fail are exactly reversed on
Windows (but then, we'd test the implementation of Windows,
so skipping that test sounds reasonable as well).

With those changes, the patch is fine.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-08-12 17:59

Message:
Logged In: YES 
user_id=31435

mmap() on WIndows doesn't care if you map more bytes 
than exist in the file -- if you do, it grows the file to match.

"""
If an application specifies a size for the file mapping object 
that is larger than the size of the actual named file on disk, 
the file on disk is grown to match the specified size of the 
file mapping object. If the file cannot be grown, this results 
in a failure to create the file mapping object. GetLastError 
will return ERROR_DISK_FULL.
"""

Like so:

>>> import mmap
>>> import os
>>> os.path.getsize('abc.abc')
12L
>>> f = file('abc.abc', 'r+')
>>> m = mmap.mmap(f.fileno(), 10000)
>>> m.close()
>>> os.path.getsize('abc.abc')
10000L
>>>


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-12 17:49

Message:
Logged In: YES 
user_id=33168

That last comment was supposed to be:  I don't know how
Windows behaves...

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-12 17:47

Message:
Logged In: YES 
user_id=33168

I thought the st_size was updated by the code in
new_buffersize.  It was only the position, so the comment
should go.  ValueError is fine with me.  Should I add an
entry to NEWS?  New patch attached w/NEWS and test.

There is another issue--Windows.  I how Windows behaves and
I can't test it.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-12 16:45

Message:
Logged In: YES 
user_id=21627

I'd say it is a ValueError if the map size is larger than
the file size, instead of silently decreasing the size:
Errors should never pass silently, Unless explicitly silenced.

On the trick of new_buffersize: I'm not sure I understand
what you are referring to: we don't use stdio in mmap at all.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-12 15:30

Message:
Logged In: YES 
user_id=33168

I wasn't sure if I could change the size.  For Solaris at
least, it seems this is the right thing to do.  Is it likely
that other systems allow the file size to change?  I've
forced the size to be the max(size_arg, size_of_file).  This
has the added benefit of working for writing too.  Prior to
this patch, writing past the end crashed on Linux.

There are 2 comments in the patch:  one worrying about the
file changing, the other producing a warning message if the
size argument is larger than the file.  Do we have to worry
about the size changing?  Should we tell the user what they did?

Sorry about the old style diff.  I remembered to do the cvs
-f diff part, but forgot the -C5.  My defaults are unified.
New context patch attached.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-08-12 09:45

Message:
Logged In: NO 

Please don't even think of adding a stat call to every
access.  The whole idea of mmap is to speed up access by
eliminating system calls when you touch the file contents. 
Checking the file size at map creation is reasonable.  Some
note should also be added to the mmap doc about possible
crashes if the file size changes.

>From a Python script writer's viewpoint, the most convenient
fix is for Python to catch the bus error signal and inspect
the stack to figure out that the trap occurred in the mmap
routine, then generate and return an appropriate Python
exception.  However, doing that is pretty
platform-dependent, and attempting it in all the Python
ports that support mmap doesn't sound practical.  

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-12 09:15

Message:
Logged In: YES 
user_id=21627

Ah, an old-style diff. I assume that goes into mmap_item?

I'd rather avoid the stat call on every access, and check
the size on map creation.

The Solaris man page says this about changing files:

     If the size of the mapped file changes  after  the 
call  to
     mmap()  as  a  result  of some other operation on the
mapped
     file, the effect of references to  portions  of  the 
mapped
     region  that  correspond to added or removed portions
of the
     file is unspecified.

So it appears that this is a case of "don"t do this, then",
and that it atleast won't crash - but we might want to
perform a few experiments.



----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-11 17:05

Message:
Logged In: YES 
user_id=33168

Martin, could you please review the patch?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-07-28 17:00

Message:
Logged In: YES 
user_id=33168

Attached is a patch which fixes this problem.  I'm not sure
this patch it correct nor appropriate.  But it stops the
crash.  I'm hoping some mmap expert can shed some light on this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=585792&group_id=5470


From noreply@sourceforge.net  Mon Aug 12 20:06:58 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 12 Aug 2002 12:06:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-575229 ] multiple inheritance w/ slots dumps core
Message-ID: <E17eKWo-0000TW-00@usw-sf-web2.sourceforge.net>

Bugs item #575229, was opened at 2002-06-28 19:33
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575229&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Cesar Douady (douady)
Assigned to: Guido van Rossum (gvanrossum)
Summary: multiple inheritance w/ slots dumps core

Initial Comment:
The following script dumps a core (revision 2.2.1) :

class A(object): __slots__=()
class B(object): pass
class C(A,B) : __slots__=()
C().x=2

basic sizes for those classes are:
A => 8 (correct : no dict, no weakref)
B => 16 (correct : dict and weakref slots added)
C => 8 (incorrect : dict and weakref not inherited from
B)

in the last lines of type_new, variables add_dict and
add_weak
are exploited to add those slots, but only when
slots==NULL.
The best base selected for C is A, which is correct in
my opinion
since slots come from it, but dict and weak refs must
be treated
specially and can come from another base.

I have seen nothing in the cvs repository which may fix
this bug.

I did not submit a patch since this is a touchy part of
the interpreter,
but I may do it upon request.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-12 15:06

Message:
Logged In: YES 
user_id=6380

I've checked in a fix for 2.3 into current CVS.

I think I'll leave this broken for 2.2; the fix was *really*
hairy.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-11 22:30

Message:
Logged In: YES 
user_id=6380

Thanks! Definitely a bug, and your analysis hits the nail
right on the head. I'll come up with a fix shortly. I can
still reproduce this in a debug build of 2.3 (i.e. current CVS).

----------------------------------------------------------------------

Comment By: Greg Chapman (glchapman)
Date: 2002-07-07 13:25

Message:
Logged In: YES 
user_id=86307

FWIW, using the 2.2.1 windows binary release, I don't get an 
access violation.  However, under a debug build of 2.2.1, I do 
get an access violation.  Under the debug build (and using the 
original example), C's tp_dictoffset == tp_basicsize == 16 (all 
Python objects in a debug build have two extra pointers).  
Thus _PyObject_GetDictPtr (called when setting the 'x' 
attribute) returns a pointer which points beyond the allocated 
memory, and the access violation is generated (because 
MSVC fills the area after the allocated area with a garbage 
value).  This almost certainly means the regular build is also 
accessing memory beyond what it allocates, but it just 
happens to work in this case.  At any rate, there definitely 
appears to be a bug here.

----------------------------------------------------------------------

Comment By: Cesar Douady (douady)
Date: 2002-07-03 12:51

Message:
Logged In: YES 
user_id=428521

oops!
I meant C.__basicsize__ is now 12 (it has slot 'a'), but
this is still less than 16.

----------------------------------------------------------------------

Comment By: Cesar Douady (douady)
Date: 2002-07-03 12:47

Message:
Logged In: YES 
user_id=428521

I could not replicate the core dump with the latest 2.2 from
CVS,  but the problem still exist : C.__basicsize__ still is
8, which should not possible when
deriving from a class whose basic size is 16.
The following script show an abnormal behavior (actually the
one I had initially in my application):

class A(object): __slots__=('a')
class B(object): pass
class C(A,B) : __slots__=()
c=C()
c.x=2
c.a  ==> {'x':2}

In the original example, the B.__dictoffset__ would point
out of C objects, which may or may not create a core dump,
depending on a lot of factors.
In this script, B.__dictoffset__ points to slot 'a' of C,
hence 'c.x=2' creates the dictionary which is then seen as
the 'a' slot of c.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-07-02 15:13

Message:
Logged In: YES 
user_id=33168

I could not replicate this problem from current CVS
nor from 2.2.1+ (cvs).  Can you test with the CVS
versions to see if you still have a problem?

for 2.2.1+ the tag is release22-maint

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575229&group_id=5470


From noreply@sourceforge.net  Mon Aug 12 20:03:51 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 12 Aug 2002 12:03:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-592567 ] Bug with deepcopy and new style objects
Message-ID: <E17eKTn-0002ew-00@usw-sf-web1.sourceforge.net>

Bugs item #592567, was opened at 2002-08-08 12:42
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592567&group_id=5470

Category: Type/class unification
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Jiba (jiba)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Bug with deepcopy and new style objects

Initial Comment:
Deepcopying new style objects can bug if more than one
of such objects are deep copied at the same time (E.g.
you are deepcopying a list of two new style objects).

It seems that , in copy._reconstruct, the "state" 
variable should be "kept alive" (by passing it to the
"_keep_alive" function), since this state may be gc'ed,
and another state may be created later with the same
address memory / ID.

BTW, the same problem may arise with the "args"
variable, in the same function.

The included file demonstrates the bug.

----------------------------------------------------------------------

>Comment By: Jiba (jiba)
Date: 2002-08-12 19:03

Message:
Logged In: YES 
user_id=591223

I have just submitted a patch for fixing this bug -- the
patch uses an alternative solution to the one i explained
above; i would prefer the patch to the above solution.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-08-09 03:43

Message:
Logged In: YES 
user_id=80475

Confirmed on 2.2.1 and 2.3a:

Before deepcopying :
[11, 12, 13]
[21, 22, 23]
[31, 32, 33]

After deepcopying :
[11, 12, 13]
[11, 12, 13]
[11, 12, 13]


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592567&group_id=5470


From noreply@sourceforge.net  Mon Aug 12 20:58:50 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 12 Aug 2002 12:58:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-411881 ] Use of "except:" in modules
Message-ID: <E17eLL0-0003sz-00@usw-sf-web3.sourceforge.net>

Bugs item #411881, was opened at 2001-03-28 06:58
You can respond by visiting: 
https://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: Skip Montanaro (montanaro)
>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: 2002-08-12 14:58

Message:
Logged In: YES 
user_id=44345

Note that this particular item was expected to be an ongoing item, with 
no obvious closure.   Some of the bare excepts will have subtle 
ramifications, and it's not always obvious what specific exceptions 
should be caught.  I've made a few changes to my local source tree 
which I should check in.

Rather than opening new tracker items, I believe those with checkin 
privileges should correct those flaws they identify and attach a comment 
which will alert those monitoring the item.  Those people without checkin 
privileges should just attach a patch with a note.

Skip


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-12 02:22

Message:
Logged In: YES 
user_id=21627

My proposal would be to track this under a different issue:
Terry, if you volunteer, please produce a new list of
offenders (perhaps in an attachment to the report so it can
be updated), and attach any fixes that you have to that report.

People with CVS write access can then apply those patches
and delete them from the report.

If you do so, please post the new issue number in this
report, so we have a link.

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2002-08-11 13:16

Message:
Logged In: YES 
user_id=593130

Remove types.py from the list.  As distributed with 2.2.1, it 
has 5 'except xxxError:' statements but no offending bare 
except:'s.

Skip (or anyone else): if/when you pursue this, I volunteer 
to do occasional sleuthing and send reports with 
suggestions and/or questions.  Example: getpass.py has 
one 'offense':
   try:
        fd = sys.stdin.fileno()
    except:
        return default_getpass(prompt)
According to lib doc 2.2.8 File Objects (as I interpret) fileno
() should either work without exception or *not* be 
implemented. Suggestion: insert AttributeError .  Question: 
do we protect against pseudofile objects that ignore doc 
and have fake .fileno() that raises NotImplementedError or 
whatever?


----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-03-23 00:02

Message:
Logged In: YES 
user_id=44345

as partial fix, checked in changes for the following
modules:

  mimetools.py (1.24)
  popen2.py (1.23)
  quopripy (1.19)
  CGIHTTPServer.py (1.22)


----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-03-20 15:24

Message:
Logged In: YES 
user_id=44345

Here is a context diff with proposed changes for the
following modules: CGIHTTPServer, cgi, cmd, code, 
fileinput, httplib, inspect, locale, mimetools, popen2,
quopri


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-08-11 10:06

Message:
Logged In: YES 
user_id=21627

Fixed urllib in 1.131 and types in 1.19.


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-07-04 02:11

Message:
Logged In: YES 
user_id=3066

Fixed modules mhlib and rfc822 (SF is having a problem
generating the checkin emails, though).

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-05-11 14:40

Message:
Logged In: YES 
user_id=3066

OK, I've fixed up a few more modules:

anydbm
chunk
formatter
htmllib
mailcap
pre
pty

I made one change to asyncore as well, but other bare except
clauses remain there; I'm not sufficiently familiar with
that code to just go digging into those.

I also fixed an infraction in pstats, but left others for now.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-04-23 03: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 02: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 09: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 04: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 10: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 12: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 12: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 12: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 10: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 04: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-30 00: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: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=411881&group_id=5470


From noreply@sourceforge.net  Mon Aug 12 21:22:16 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 12 Aug 2002 13:22:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-592567 ] Bug with deepcopy and new style objects
Message-ID: <E17eLhg-0004e3-00@usw-sf-web1.sourceforge.net>

Bugs item #592567, was opened at 2002-08-08 08:42
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592567&group_id=5470

Category: Type/class unification
Group: Python 2.2.1
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jiba (jiba)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Bug with deepcopy and new style objects

Initial Comment:
Deepcopying new style objects can bug if more than one
of such objects are deep copied at the same time (E.g.
you are deepcopying a list of two new style objects).

It seems that , in copy._reconstruct, the "state" 
variable should be "kept alive" (by passing it to the
"_keep_alive" function), since this state may be gc'ed,
and another state may be created later with the same
address memory / ID.

BTW, the same problem may arise with the "args"
variable, in the same function.

The included file demonstrates the bug.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-12 16:22

Message:
Logged In: YES 
user_id=6380

Fixed in CVS, both for Python 2.3 and 2.2.2, using your
proposed patch (with a different comment). Thanks!

----------------------------------------------------------------------

Comment By: Jiba (jiba)
Date: 2002-08-12 15:03

Message:
Logged In: YES 
user_id=591223

I have just submitted a patch for fixing this bug -- the
patch uses an alternative solution to the one i explained
above; i would prefer the patch to the above solution.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-08-08 23:43

Message:
Logged In: YES 
user_id=80475

Confirmed on 2.2.1 and 2.3a:

Before deepcopying :
[11, 12, 13]
[21, 22, 23]
[31, 32, 33]

After deepcopying :
[11, 12, 13]
[11, 12, 13]
[11, 12, 13]


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592567&group_id=5470


From noreply@sourceforge.net  Mon Aug 12 22:06:40 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 12 Aug 2002 14:06:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-491888 ] whichdb lies about db type
Message-ID: <E17eMOe-0005UK-00@usw-sf-web1.sourceforge.net>

Bugs item #491888, was opened at 2001-12-11 21:22
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=491888&group_id=5470

Category: Python Library
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Jones (richard)
Assigned to: Martin v. Löwis (loewis)
Summary: whichdb lies about db type

Initial Comment:
>>> import dbm
>>> d = dbm.open('foo', 'n')
>>> d['a'] = 'b'
>>> d.close()
>>> import whichdb
>>> whichdb.whichdb('foo.db')
'dbhash'

I'm currently testing for the existence of "foo.db" 
instead of "foo" and hard-code my routines to use dbm 
if there is a "foo.db" file (since all other db 
modules that I've tested do no append ".db")

Might it also be possible to have anydbm perform a 
whichdb check in its open function, so that older 
databases are usable with newer, more feature-full 
installations that might include "better" dbm 
backends?



----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2002-08-12 16:06

Message:
Logged In: YES 
user_id=44345

If the user opened the file with

    db = anydbm.open("foo", "c")

*and* the dbm module happened to be selected by anydbm *and* 
dbmmodule.so happened to be linked with BerkDB, the file created will 
be named "foo.db" and will actually be a BerkDB hash file (whose 
version depends on the version of the library installed).  If the user later 
asks whichdb.whichdb what type of file "foo"  is, my latest change 
corrected responds "dbm".  If, on the other hand, the user asks 
whichdb.whichdb what type of file "foo.db" is, it should now respond 
"dbhash".   This is what my recent patch to the whichdb module fixed.  
It would be incorrect to try to open "foo.db" with the dbm module.

If a bsddb.error exception is raised, it's almost certainly because the user 
upgraded the BerkDB library, but didn't run the tools provided by 
Sleepycat to upgrade his or her preexisting files.  I don't see how there's 
a Python problem here that needs solving.  It's simply pilot error.  The 
best we can do I think is improve the message associated with the 
exception which the module raises.  (Something like "invalid file format" 
instead of simply "invalid argument.)

In my previous note I made a mistake.  Instead of

    He should have called
        dbhash.open('foo', 'r')
    as he later demonstrated.

The function call should have been "dbm.open".


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-11 16:13

Message:
Logged In: YES 
user_id=21627

Skip, I think you misunderstand the complaint. It's not
about the way in which an error message is given, but that
the error message is given at all.

The file is a dbm file, and the dbm module is capable of
opening it, so no error should be reported at all.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-07-25 10:03

Message:
Logged In: YES 
user_id=44345

Martin's comment in bug 584409 reminded me that I have a patched 
whichdb module which should cure this problem.  (At the moment my 
dbm module is linked with gdbm, not BerkDB, however, so while I've 
tested this in the past, I can't provide you with an interactive 
demonstration at the moment.)  Note that Richard was forced to do 
something for which whichdb was not designed. I believe with this 
patch he should be able to once again ask for simply "foo" and not 
wonder what extensions the underlying db package add to the files.

I still don't think version information would help here.  Richard's tests 
are flawed.  Berkeley DB only adds ".db" to the end of the file when 
using the dbm-compatibility API.  He should have called

    dbhash.open('foo', 'r')

as he later demonstrated.  While somewhat mystifying, the bsddb.error 
is more or less correct.  We should probably trap that and raise a "file 
not found" error or just try a stat() call if the db file is to be opened for 
reading.

Assigning to Martin for consideration.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-12-13 03:43

Message:
Logged In: YES 
user_id=21627

I see. The problem appears to be that your BSDDB
installation, which implements hash version 7, does not
simultaneously support hash version 5 anymore. This
primarily is a problem in the Sleepycat version shipped with
your system (for not supporting old databases), and in glibc
(for not incorporating a newer bsd db). Python can work
around this problem, at best - there might always be DBHASH
files that none of the DB implementations on a system can open.

bsddb should expose version information, like DB_HASHVERSION
and DB_HASHOLDVER (the current and the minimum hash
version). Unfortunately, db_185.h, as used by bsddb.c, do
not provide these constants, and db_185.h cannot be used
simultaneously with db.h. db_185.h exposes a HASHVERSION
constant, but that seems to stay at 2 regardless of the file
version that the compatibility API uses.

The right solution seems to drop support for the DB1 API,
and mandate a DB2-or-better db.h. I'd personally recommend
to integrate pybsddb.sf.net into Python 2.3, adding
portability to BSDDB 2 if necessary (it could be a
build-time decision to build either source module as bsddb).

For the moment, I cannot recommend a good work-around; I see
two options:
- find out magically (by looking at db.h) what hash versions
dbhash will support, then check the version of the hash
file, and refuse to use dbash if the version won't be
supported. Since this requires magic, such code should not
be added to Python, but left to the application.
- catch bsddb.error on dbhash.open, and retry with dbm.open.
 This is a heuristic which also shouldn't be added to
Python, but which may be acceptable to the application.

----------------------------------------------------------------------

Comment By: Richard Jones (richard)
Date: 2001-12-13 01:05

Message:
Logged In: YES 
user_id=6405

Sorry about the anydbm/whichdb confusion - reading the 
source a little closer would have avoided my confusion.

Regardless, there is still a problem that on my system, 
dbm files are reported as dbhash, and dbhash can't open 
the dbm files...

[richard@co3044991-a tmp]$ python
Python 2.1.1 (#1, Aug 30 2001, 17:36:05) 
[GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.61mdk)] on 
linux-i386
Type "copyright", "credits" or "license" for more 
information.
>>> import dbm
>>> dbm.open('foo','n')
<dbm object at 0x812a0f0>
>>> import dbhash
>>> dbhash.open('bar', 'n')
<bsddb object at 0x812b870>
>>> 
>>> import whichdb
>>> whichdb.whichdb('foo.db')
'dbhash'
>>> whichdb.whichdb('bar')
'dbhash'
>>> dbhash.open('foo.db', 'r')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.1/dbhash.py", line 16, in open
    return bsddb.hashopen(file, flag, mode)
bsddb.error: (-30990, 'Unknown error 4294936306')
>>> dbhash.open('bar', 'r')
<bsddb object at 0x812ef48>
>>> 
[richard@co3044991-a tmp]$ file foo.db
foo.db: Berkeley DB (Hash, version 5, native byte-order)
[richard@co3044991-a tmp]$ file bar
bar: Berkeley DB (Hash, version 7, native byte-order)



----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-12-12 17:28

Message:
Logged In: YES 
user_id=21627

I fail to see the problem altogether. What system are you
on? Why do you think dbm does not create dbhash files? It is
not just that the magic says they are BSDDB DB_HASH files,
they really are of that kind?

Also, which of the APIs (dbm, dbhash) do you consider
"better"? I'd say that dbhash is better, since it builds
upon bsddb. So whichdbm, and anydbm, do use the "better" dbm
backend already?

Where is the bug?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-11 22:28

Message:
Logged In: YES 
user_id=6380

Hm. anydmb *does* use whichdb. The problem seems to be that
the dbm file really *does* look like a BSD hash -- the Unix
file(1) command has the same problem.

But I'm not sure I understand your question. Do you have a
particular patch in mind?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=491888&group_id=5470


From noreply@sourceforge.net  Mon Aug 12 22:40:31 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 12 Aug 2002 14:40:31 -0700
Subject: [Python-bugs-list] [ python-Bugs-531205 ] Bugs in rfc822.parseaddr()
Message-ID: <E17eMvP-0003Bx-00@usw-sf-web4.sourceforge.net>

Bugs item #531205, was opened at 2002-03-17 21:13
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=531205&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Barry A. Warsaw (bwarsaw)
Assigned to: Ben Gertzfield (che_fox)
Summary: Bugs in rfc822.parseaddr()

Initial Comment:
This bug is in rfc822.parseaddr(), and thus inherited
into email.Utils.parseaddr() since the latter does a
straight include of the former.  It has a nasty bug
when the email address contains embedded spaces: it
collapses the spaces:

>>> from email.Utils import parseaddr
>>> parseaddr('foo bar@wooz.org')
('', 'foobar@wooz.org')
>>> parseaddr('<foo bar@wooz.org>')
('', 'foobar@wooz.org')

Boo, hiss.  Of course parseaddr() would be more
involved to implement in an RFC 2822 compliant way, but
it would be very cool.

Note that I'm reporting this bug here instead of the
mimelib project because it's actually in rfc822.py. 
Once solution might include fixing it in the email
package only.




----------------------------------------------------------------------

Comment By: Tim Roberts (timroberts)
Date: 2002-08-12 14:40

Message:
Logged In: YES 
user_id=265762

Interesting to note that RFC 822 (but not 2822) allows spaces 
around any periods in the address without quoting (2822 does 
allow spaces around the @), and those spaces are to be 
removed.  Section A.1.4 gives the example 
   Wilt  .  Chamberlain@NBA.US
and says it should be parsed as "Wilt.Chamberlain".

Given that, it's hard for me to see that the current behavior 
should be changed at all, since there is no correct way to 
parse this non-compliant address.

----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2002-04-15 10:18

Message:
Logged In: YES 
user_id=12800

Note further that "foo bar"@wooz.org is properly parsed. 
The question is, what should parseaddr() do in this
non-compliant situation?  I can think of a couple of things:

- it could raise an exception
- it could return ('', 'bar@wooz.org')
- it could return ('foo', 'bar@wooz.org')
- it could return ('' '"foo bar"@wooz.org')

I'm not sure what the right thing to do is.  I'm assigning
to Ben Gertzfield to get his opinion.  Ben, feel free to add
a comment and re-assign the bug to me.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=531205&group_id=5470


From noreply@sourceforge.net  Mon Aug 12 23:06:31 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 12 Aug 2002 15:06:31 -0700
Subject: [Python-bugs-list] [ python-Bugs-491888 ] whichdb lies about db type
Message-ID: <E17eNKZ-00041C-00@usw-sf-web5.sourceforge.net>

Bugs item #491888, was opened at 2001-12-12 14:22
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=491888&group_id=5470

Category: Python Library
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Jones (richard)
Assigned to: Martin v. Löwis (loewis)
Summary: whichdb lies about db type

Initial Comment:
>>> import dbm
>>> d = dbm.open('foo', 'n')
>>> d['a'] = 'b'
>>> d.close()
>>> import whichdb
>>> whichdb.whichdb('foo.db')
'dbhash'

I'm currently testing for the existence of "foo.db" 
instead of "foo" and hard-code my routines to use dbm 
if there is a "foo.db" file (since all other db 
modules that I've tested do no append ".db")

Might it also be possible to have anydbm perform a 
whichdb check in its open function, so that older 
databases are usable with newer, more feature-full 
installations that might include "better" dbm 
backends?



----------------------------------------------------------------------

>Comment By: Richard Jones (richard)
Date: 2002-08-13 08:06

Message:
Logged In: YES 
user_id=6405

I believe your patch has fixes the problem. There were no version      
changes, just the ".db" extension which was confusing anydbm. Your 
assertion that   
   dbhash.open('foo', 'r')  
should work doesn't fly here:  
Python 2.2.1 (#1, Apr  9 2002, 13:10:27)  
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2  
Type "help", "copyright", "credits" or "license" for more information.  
>>> import dbm, dbhash, whichdb  
>>> dbm.open('spam', 'n')  
<dbm.dbm object at 0x815a0f0>  
>>> _.close()  
>>> whichdb.whichdb('spam')  
>>> whichdb.whichdb('spam.db')  
'dbhash'  
>>> dbhash.open('spam', 'r')  
Traceback (most recent call last):  
  File "<stdin>", line 1, in ?  
  File "/usr/lib/python2.2/dbhash.py", line 16, in open  
    return bsddb.hashopen(file, flag, mode)  
bsddb.error: (2, 'No such file or directory')  
>>> dbhash.open('spam.db', 'r')  
Traceback (most recent call last):  
  File "<stdin>", line 1, in ?  
  File "/usr/lib/python2.2/dbhash.py", line 16, in open  
    return bsddb.hashopen(file, flag, mode)  
bsddb.error: (22, 'Invalid argument')  
>>> dbm.open('spam', 'r') 
<dbm.dbm object at 0x815a0f0> 
>>>  
 
I don't see how that's "pilot error". Your fixes will solve the problem 
though. anydbm will be able to reopen the dbm-created files it creates 
:) 
 

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-08-13 07:06

Message:
Logged In: YES 
user_id=44345

If the user opened the file with

    db = anydbm.open("foo", "c")

*and* the dbm module happened to be selected by anydbm *and* 
dbmmodule.so happened to be linked with BerkDB, the file created will 
be named "foo.db" and will actually be a BerkDB hash file (whose 
version depends on the version of the library installed).  If the user later 
asks whichdb.whichdb what type of file "foo"  is, my latest change 
corrected responds "dbm".  If, on the other hand, the user asks 
whichdb.whichdb what type of file "foo.db" is, it should now respond 
"dbhash".   This is what my recent patch to the whichdb module fixed.  
It would be incorrect to try to open "foo.db" with the dbm module.

If a bsddb.error exception is raised, it's almost certainly because the user 
upgraded the BerkDB library, but didn't run the tools provided by 
Sleepycat to upgrade his or her preexisting files.  I don't see how there's 
a Python problem here that needs solving.  It's simply pilot error.  The 
best we can do I think is improve the message associated with the 
exception which the module raises.  (Something like "invalid file format" 
instead of simply "invalid argument.)

In my previous note I made a mistake.  Instead of

    He should have called
        dbhash.open('foo', 'r')
    as he later demonstrated.

The function call should have been "dbm.open".


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-12 07:13

Message:
Logged In: YES 
user_id=21627

Skip, I think you misunderstand the complaint. It's not
about the way in which an error message is given, but that
the error message is given at all.

The file is a dbm file, and the dbm module is capable of
opening it, so no error should be reported at all.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-07-26 01:03

Message:
Logged In: YES 
user_id=44345

Martin's comment in bug 584409 reminded me that I have a patched 
whichdb module which should cure this problem.  (At the moment my 
dbm module is linked with gdbm, not BerkDB, however, so while I've 
tested this in the past, I can't provide you with an interactive 
demonstration at the moment.)  Note that Richard was forced to do 
something for which whichdb was not designed. I believe with this 
patch he should be able to once again ask for simply "foo" and not 
wonder what extensions the underlying db package add to the files.

I still don't think version information would help here.  Richard's tests 
are flawed.  Berkeley DB only adds ".db" to the end of the file when 
using the dbm-compatibility API.  He should have called

    dbhash.open('foo', 'r')

as he later demonstrated.  While somewhat mystifying, the bsddb.error 
is more or less correct.  We should probably trap that and raise a "file 
not found" error or just try a stat() call if the db file is to be opened for 
reading.

Assigning to Martin for consideration.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-12-13 20:43

Message:
Logged In: YES 
user_id=21627

I see. The problem appears to be that your BSDDB
installation, which implements hash version 7, does not
simultaneously support hash version 5 anymore. This
primarily is a problem in the Sleepycat version shipped with
your system (for not supporting old databases), and in glibc
(for not incorporating a newer bsd db). Python can work
around this problem, at best - there might always be DBHASH
files that none of the DB implementations on a system can open.

bsddb should expose version information, like DB_HASHVERSION
and DB_HASHOLDVER (the current and the minimum hash
version). Unfortunately, db_185.h, as used by bsddb.c, do
not provide these constants, and db_185.h cannot be used
simultaneously with db.h. db_185.h exposes a HASHVERSION
constant, but that seems to stay at 2 regardless of the file
version that the compatibility API uses.

The right solution seems to drop support for the DB1 API,
and mandate a DB2-or-better db.h. I'd personally recommend
to integrate pybsddb.sf.net into Python 2.3, adding
portability to BSDDB 2 if necessary (it could be a
build-time decision to build either source module as bsddb).

For the moment, I cannot recommend a good work-around; I see
two options:
- find out magically (by looking at db.h) what hash versions
dbhash will support, then check the version of the hash
file, and refuse to use dbash if the version won't be
supported. Since this requires magic, such code should not
be added to Python, but left to the application.
- catch bsddb.error on dbhash.open, and retry with dbm.open.
 This is a heuristic which also shouldn't be added to
Python, but which may be acceptable to the application.

----------------------------------------------------------------------

Comment By: Richard Jones (richard)
Date: 2001-12-13 18:05

Message:
Logged In: YES 
user_id=6405

Sorry about the anydbm/whichdb confusion - reading the 
source a little closer would have avoided my confusion.

Regardless, there is still a problem that on my system, 
dbm files are reported as dbhash, and dbhash can't open 
the dbm files...

[richard@co3044991-a tmp]$ python
Python 2.1.1 (#1, Aug 30 2001, 17:36:05) 
[GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.61mdk)] on 
linux-i386
Type "copyright", "credits" or "license" for more 
information.
>>> import dbm
>>> dbm.open('foo','n')
<dbm object at 0x812a0f0>
>>> import dbhash
>>> dbhash.open('bar', 'n')
<bsddb object at 0x812b870>
>>> 
>>> import whichdb
>>> whichdb.whichdb('foo.db')
'dbhash'
>>> whichdb.whichdb('bar')
'dbhash'
>>> dbhash.open('foo.db', 'r')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.1/dbhash.py", line 16, in open
    return bsddb.hashopen(file, flag, mode)
bsddb.error: (-30990, 'Unknown error 4294936306')
>>> dbhash.open('bar', 'r')
<bsddb object at 0x812ef48>
>>> 
[richard@co3044991-a tmp]$ file foo.db
foo.db: Berkeley DB (Hash, version 5, native byte-order)
[richard@co3044991-a tmp]$ file bar
bar: Berkeley DB (Hash, version 7, native byte-order)



----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-12-13 10:28

Message:
Logged In: YES 
user_id=21627

I fail to see the problem altogether. What system are you
on? Why do you think dbm does not create dbhash files? It is
not just that the magic says they are BSDDB DB_HASH files,
they really are of that kind?

Also, which of the APIs (dbm, dbhash) do you consider
"better"? I'd say that dbhash is better, since it builds
upon bsddb. So whichdbm, and anydbm, do use the "better" dbm
backend already?

Where is the bug?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-12 15:28

Message:
Logged In: YES 
user_id=6380

Hm. anydmb *does* use whichdb. The problem seems to be that
the dbm file really *does* look like a BSD hash -- the Unix
file(1) command has the same problem.

But I'm not sure I understand your question. Do you have a
particular patch in mind?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=491888&group_id=5470


From noreply@sourceforge.net  Mon Aug 12 22:13:00 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 12 Aug 2002 14:13:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-594255 ] email mishandles some multiparts
Message-ID: <E17eMUm-0002hG-00@usw-sf-web4.sourceforge.net>

Bugs item #594255, was opened at 2002-08-12 14:13
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594255&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Roberts (timroberts)
Assigned to: Nobody/Anonymous (nobody)
Summary: email mishandles some multiparts

Initial Comment:
Python 2.2 on Windows 2000; also occurs in Python 2.1.

email.Message.Message.is_multipart() returns true if 
and only if _payload is a list.  _payload becomes a list 
only if more than one subpart is added.  However, by 
RFC 1521, a multipart message is allowed to contain a 
single subpart.  (I received one today!)  In that case, 
Message.is_multipart() returns false, and Message.walk 
fails to enumerate the subpart.  There seems to be no 
way to discover that a parsable payload exists.

Suggested and tested fix is to modify the start of 
Message.add_payload from this:

        if self._payload is None:
            self._payload = payload

to this:

        if self._payload is None:
            if self.get_main_type() == 'multipart':
                self._payload = [payload]
            else:
                self._payload = payload


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594255&group_id=5470


From noreply@sourceforge.net  Tue Aug 13 00:42:17 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 12 Aug 2002 16:42:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-594255 ] email mishandles some multiparts
Message-ID: <E17eOpF-00059r-00@usw-sf-web4.sourceforge.net>

Bugs item #594255, was opened at 2002-08-12 17:13
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594255&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Tim Roberts (timroberts)
Assigned to: Nobody/Anonymous (nobody)
Summary: email mishandles some multiparts

Initial Comment:
Python 2.2 on Windows 2000; also occurs in Python 2.1.

email.Message.Message.is_multipart() returns true if 
and only if _payload is a list.  _payload becomes a list 
only if more than one subpart is added.  However, by 
RFC 1521, a multipart message is allowed to contain a 
single subpart.  (I received one today!)  In that case, 
Message.is_multipart() returns false, and Message.walk 
fails to enumerate the subpart.  There seems to be no 
way to discover that a parsable payload exists.

Suggested and tested fix is to modify the start of 
Message.add_payload from this:

        if self._payload is None:
            self._payload = payload

to this:

        if self._payload is None:
            if self.get_main_type() == 'multipart':
                self._payload = [payload]
            else:
                self._payload = payload


----------------------------------------------------------------------

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2002-08-12 19:42

Message:
Logged In: YES 
user_id=12800

This is fixed in Python 2.3cvs.  It's also fixed in the
standalone mimelib project, in email package version 2.2. 
It will be back ported to Python 2.2.2 at some point before
that release is made.

I suggest picking up the mimelib version and using that. 
It'll work with Python 2.1 and beyond.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594255&group_id=5470


From noreply@sourceforge.net  Tue Aug 13 03:11:23 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 12 Aug 2002 19:11:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-585792 ] Invalid mmap crashes Python interpreter
Message-ID: <E17eR9X-0002j6-00@usw-sf-web1.sourceforge.net>

Bugs item #585792, was opened at 2002-07-24 01:52
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=585792&group_id=5470

Category: None
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Invalid mmap crashes Python interpreter

Initial Comment:
This is under Red Hat 7.2, Linux kernel 2.4.7.   "x" is
an empty file, i.e. zero bytes long.

import mmap
f = open(x,"r+")m = mmap.mmap(f.fileno(), 10)
print m[1]

Crashes Python with a bus error.  Python should catch
the bus error signal
and raise an appropriate exception that the script can
catch.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-08-12 19:11

Message:
Logged In: NO 

I'd say the following is reasonable:

- on mmap object creation, stat the file and check its size
against the size arg passed to mmap.  Signal an error if the
file is smaller than the requested mmap size.  

- On access, compare the subscript to the mmap object size
and signal an error if out of bounds (presumably this is
done already)

- Figure out if another process can truncate the file while
the mmap is alive.  If yes, maybe add a method to the mmap
object that re-stats the file and makes sure it's still
larger than the mmap size.  

- Add warnings to the mmap documentation that weirdness can
result from the file size changing etc.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-12 09:31

Message:
Logged In: YES 
user_id=21627

I think we should special-case Windows, then. For the
mmapmodule patch proper, nothing needs to be done; for the
testsuite test, pass and fail are exactly reversed on
Windows (but then, we'd test the implementation of Windows,
so skipping that test sounds reasonable as well).

With those changes, the patch is fine.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-08-12 08:59

Message:
Logged In: YES 
user_id=31435

mmap() on WIndows doesn't care if you map more bytes 
than exist in the file -- if you do, it grows the file to match.

"""
If an application specifies a size for the file mapping object 
that is larger than the size of the actual named file on disk, 
the file on disk is grown to match the specified size of the 
file mapping object. If the file cannot be grown, this results 
in a failure to create the file mapping object. GetLastError 
will return ERROR_DISK_FULL.
"""

Like so:

>>> import mmap
>>> import os
>>> os.path.getsize('abc.abc')
12L
>>> f = file('abc.abc', 'r+')
>>> m = mmap.mmap(f.fileno(), 10000)
>>> m.close()
>>> os.path.getsize('abc.abc')
10000L
>>>


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-12 08:49

Message:
Logged In: YES 
user_id=33168

That last comment was supposed to be:  I don't know how
Windows behaves...

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-12 08:47

Message:
Logged In: YES 
user_id=33168

I thought the st_size was updated by the code in
new_buffersize.  It was only the position, so the comment
should go.  ValueError is fine with me.  Should I add an
entry to NEWS?  New patch attached w/NEWS and test.

There is another issue--Windows.  I how Windows behaves and
I can't test it.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-12 07:45

Message:
Logged In: YES 
user_id=21627

I'd say it is a ValueError if the map size is larger than
the file size, instead of silently decreasing the size:
Errors should never pass silently, Unless explicitly silenced.

On the trick of new_buffersize: I'm not sure I understand
what you are referring to: we don't use stdio in mmap at all.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-12 06:30

Message:
Logged In: YES 
user_id=33168

I wasn't sure if I could change the size.  For Solaris at
least, it seems this is the right thing to do.  Is it likely
that other systems allow the file size to change?  I've
forced the size to be the max(size_arg, size_of_file).  This
has the added benefit of working for writing too.  Prior to
this patch, writing past the end crashed on Linux.

There are 2 comments in the patch:  one worrying about the
file changing, the other producing a warning message if the
size argument is larger than the file.  Do we have to worry
about the size changing?  Should we tell the user what they did?

Sorry about the old style diff.  I remembered to do the cvs
-f diff part, but forgot the -C5.  My defaults are unified.
New context patch attached.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-08-12 00:45

Message:
Logged In: NO 

Please don't even think of adding a stat call to every
access.  The whole idea of mmap is to speed up access by
eliminating system calls when you touch the file contents. 
Checking the file size at map creation is reasonable.  Some
note should also be added to the mmap doc about possible
crashes if the file size changes.

>From a Python script writer's viewpoint, the most convenient
fix is for Python to catch the bus error signal and inspect
the stack to figure out that the trap occurred in the mmap
routine, then generate and return an appropriate Python
exception.  However, doing that is pretty
platform-dependent, and attempting it in all the Python
ports that support mmap doesn't sound practical.  

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-12 00:15

Message:
Logged In: YES 
user_id=21627

Ah, an old-style diff. I assume that goes into mmap_item?

I'd rather avoid the stat call on every access, and check
the size on map creation.

The Solaris man page says this about changing files:

     If the size of the mapped file changes  after  the 
call  to
     mmap()  as  a  result  of some other operation on the
mapped
     file, the effect of references to  portions  of  the 
mapped
     region  that  correspond to added or removed portions
of the
     file is unspecified.

So it appears that this is a case of "don"t do this, then",
and that it atleast won't crash - but we might want to
perform a few experiments.



----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-11 08:05

Message:
Logged In: YES 
user_id=33168

Martin, could you please review the patch?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-07-28 08:00

Message:
Logged In: YES 
user_id=33168

Attached is a patch which fixes this problem.  I'm not sure
this patch it correct nor appropriate.  But it stops the
crash.  I'm hoping some mmap expert can shed some light on this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=585792&group_id=5470


From noreply@sourceforge.net  Tue Aug 13 04:15:23 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 12 Aug 2002 20:15:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-592441 ] Webchecker error on http://www.naleo.org
Message-ID: <E17eS9T-0000vP-00@usw-sf-web5.sourceforge.net>

Bugs item #592441, was opened at 2002-08-08 00:40
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592441&group_id=5470

Category: Demos and Tools
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Carlos Conti (mcsolrac)
>Assigned to: Jeremy Hylton (jhylton)
Summary: Webchecker error on http://www.naleo.org

Initial Comment:
Webchecker version 1.25.6.1 on Windows 2000 
Professional. 

Run webchecker with this argument 
http://www.naleo.org/WSJArticle002.htm 
Webchecker will return this traceback: 

Traceback (most recent call last):
  File "C:\Python22\Tools\webchecker\webchecker.py", 
line 858, in ?
    main()
  File "C:\Python22\Tools\webchecker\webchecker.py", 
line 222, in main
    c.run()
  File "C:\Python22\Tools\webchecker\webchecker.py", 
line 349, in run
    self.dopage(url)
  File "C:\Python22\Tools\webchecker\webchecker.py", 
line 403, in dopage
    page = self.getpage(url_pair)
  File "C:\Python22\Tools\webchecker\webchecker.py", 
line 507, in getpage
    return Page(text, url, maxpage=self.maxpage, 
checker=self)
  File "C:\Python22\Tools\webchecker\webchecker.py", 
line 671, in __init__
    self.parser.feed(self.text)
  File "C:\Python22\lib\sgmllib.py", line 95, in feed
    self.goahead(0)
  File "C:\Python22\lib\sgmllib.py", line 161, in goahead
    k = self.parse_declaration(i)
  File "C:\Python22\lib\markupbase.py", line 66, in 
parse_declaration
    decltype, j = self._scan_name(j, i)
  File "C:\Python22\lib\markupbase.py", line 313, in 
_scan_name
    self.error("expected name token")
  File "C:\Python22\lib\sgmllib.py", line 102, in error
    raise SGMLParseError(message)
sgmllib.SGMLParseError: expected name token

I believe this is because of the xml in the source code 
(see WSJArticle002_source.txt attached to this bug 
report).

Even if the code in this page is poorly formatted, 
webchecker should be able continue checking other 
links in this domain (rather than stopping). For example 
webchecker could report “unable to check 
http://www.naleo.org/WSJArticle002.htm” and return 
traceback like the above, and then continue with the rest 
of the domain. 


----------------------------------------------------------------------

Comment By: Carlos Conti (mcsolrac)
Date: 2002-08-08 18:06

Message:
Logged In: YES 
user_id=591396

I'd love to submit a patch, but I am a newbie to both Python 
and programming. I apologize if this space is only intended 
for programmers; I am a QA engineer just getting acquainted 
to the wonderful world of Python. 

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-08-08 15:20

Message:
Logged In: YES 
user_id=31392

I've seen a variety of parsing problems kill webchecker.  I
agree that these exceptions should be caught somewhere so
that they are not fatal.  Care to submit a patch?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592441&group_id=5470


From noreply@sourceforge.net  Tue Aug 13 09:10:13 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 13 Aug 2002 01:10:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-491888 ] whichdb lies about db type
Message-ID: <E17eWkn-0001Il-00@usw-sf-web1.sourceforge.net>

Bugs item #491888, was opened at 2001-12-12 04:22
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=491888&group_id=5470

Category: Python Library
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Jones (richard)
Assigned to: Martin v. Löwis (loewis)
Summary: whichdb lies about db type

Initial Comment:
>>> import dbm
>>> d = dbm.open('foo', 'n')
>>> d['a'] = 'b'
>>> d.close()
>>> import whichdb
>>> whichdb.whichdb('foo.db')
'dbhash'

I'm currently testing for the existence of "foo.db" 
instead of "foo" and hard-code my routines to use dbm 
if there is a "foo.db" file (since all other db 
modules that I've tested do no append ".db")

Might it also be possible to have anydbm perform a 
whichdb check in its open function, so that older 
databases are usable with newer, more feature-full 
installations that might include "better" dbm 
backends?



----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-08-13 10:10

Message:
Logged In: YES 
user_id=21627

So can this report be closed then?

----------------------------------------------------------------------

Comment By: Richard Jones (richard)
Date: 2002-08-13 00:06

Message:
Logged In: YES 
user_id=6405

I believe your patch has fixes the problem. There were no version      
changes, just the ".db" extension which was confusing anydbm. Your 
assertion that   
   dbhash.open('foo', 'r')  
should work doesn't fly here:  
Python 2.2.1 (#1, Apr  9 2002, 13:10:27)  
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2  
Type "help", "copyright", "credits" or "license" for more information.  
>>> import dbm, dbhash, whichdb  
>>> dbm.open('spam', 'n')  
<dbm.dbm object at 0x815a0f0>  
>>> _.close()  
>>> whichdb.whichdb('spam')  
>>> whichdb.whichdb('spam.db')  
'dbhash'  
>>> dbhash.open('spam', 'r')  
Traceback (most recent call last):  
  File "<stdin>", line 1, in ?  
  File "/usr/lib/python2.2/dbhash.py", line 16, in open  
    return bsddb.hashopen(file, flag, mode)  
bsddb.error: (2, 'No such file or directory')  
>>> dbhash.open('spam.db', 'r')  
Traceback (most recent call last):  
  File "<stdin>", line 1, in ?  
  File "/usr/lib/python2.2/dbhash.py", line 16, in open  
    return bsddb.hashopen(file, flag, mode)  
bsddb.error: (22, 'Invalid argument')  
>>> dbm.open('spam', 'r') 
<dbm.dbm object at 0x815a0f0> 
>>>  
 
I don't see how that's "pilot error". Your fixes will solve the problem 
though. anydbm will be able to reopen the dbm-created files it creates 
:) 
 

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-08-12 23:06

Message:
Logged In: YES 
user_id=44345

If the user opened the file with

    db = anydbm.open("foo", "c")

*and* the dbm module happened to be selected by anydbm *and* 
dbmmodule.so happened to be linked with BerkDB, the file created will 
be named "foo.db" and will actually be a BerkDB hash file (whose 
version depends on the version of the library installed).  If the user later 
asks whichdb.whichdb what type of file "foo"  is, my latest change 
corrected responds "dbm".  If, on the other hand, the user asks 
whichdb.whichdb what type of file "foo.db" is, it should now respond 
"dbhash".   This is what my recent patch to the whichdb module fixed.  
It would be incorrect to try to open "foo.db" with the dbm module.

If a bsddb.error exception is raised, it's almost certainly because the user 
upgraded the BerkDB library, but didn't run the tools provided by 
Sleepycat to upgrade his or her preexisting files.  I don't see how there's 
a Python problem here that needs solving.  It's simply pilot error.  The 
best we can do I think is improve the message associated with the 
exception which the module raises.  (Something like "invalid file format" 
instead of simply "invalid argument.)

In my previous note I made a mistake.  Instead of

    He should have called
        dbhash.open('foo', 'r')
    as he later demonstrated.

The function call should have been "dbm.open".


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-11 23:13

Message:
Logged In: YES 
user_id=21627

Skip, I think you misunderstand the complaint. It's not
about the way in which an error message is given, but that
the error message is given at all.

The file is a dbm file, and the dbm module is capable of
opening it, so no error should be reported at all.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-07-25 17:03

Message:
Logged In: YES 
user_id=44345

Martin's comment in bug 584409 reminded me that I have a patched 
whichdb module which should cure this problem.  (At the moment my 
dbm module is linked with gdbm, not BerkDB, however, so while I've 
tested this in the past, I can't provide you with an interactive 
demonstration at the moment.)  Note that Richard was forced to do 
something for which whichdb was not designed. I believe with this 
patch he should be able to once again ask for simply "foo" and not 
wonder what extensions the underlying db package add to the files.

I still don't think version information would help here.  Richard's tests 
are flawed.  Berkeley DB only adds ".db" to the end of the file when 
using the dbm-compatibility API.  He should have called

    dbhash.open('foo', 'r')

as he later demonstrated.  While somewhat mystifying, the bsddb.error 
is more or less correct.  We should probably trap that and raise a "file 
not found" error or just try a stat() call if the db file is to be opened for 
reading.

Assigning to Martin for consideration.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-12-13 10:43

Message:
Logged In: YES 
user_id=21627

I see. The problem appears to be that your BSDDB
installation, which implements hash version 7, does not
simultaneously support hash version 5 anymore. This
primarily is a problem in the Sleepycat version shipped with
your system (for not supporting old databases), and in glibc
(for not incorporating a newer bsd db). Python can work
around this problem, at best - there might always be DBHASH
files that none of the DB implementations on a system can open.

bsddb should expose version information, like DB_HASHVERSION
and DB_HASHOLDVER (the current and the minimum hash
version). Unfortunately, db_185.h, as used by bsddb.c, do
not provide these constants, and db_185.h cannot be used
simultaneously with db.h. db_185.h exposes a HASHVERSION
constant, but that seems to stay at 2 regardless of the file
version that the compatibility API uses.

The right solution seems to drop support for the DB1 API,
and mandate a DB2-or-better db.h. I'd personally recommend
to integrate pybsddb.sf.net into Python 2.3, adding
portability to BSDDB 2 if necessary (it could be a
build-time decision to build either source module as bsddb).

For the moment, I cannot recommend a good work-around; I see
two options:
- find out magically (by looking at db.h) what hash versions
dbhash will support, then check the version of the hash
file, and refuse to use dbash if the version won't be
supported. Since this requires magic, such code should not
be added to Python, but left to the application.
- catch bsddb.error on dbhash.open, and retry with dbm.open.
 This is a heuristic which also shouldn't be added to
Python, but which may be acceptable to the application.

----------------------------------------------------------------------

Comment By: Richard Jones (richard)
Date: 2001-12-13 08:05

Message:
Logged In: YES 
user_id=6405

Sorry about the anydbm/whichdb confusion - reading the 
source a little closer would have avoided my confusion.

Regardless, there is still a problem that on my system, 
dbm files are reported as dbhash, and dbhash can't open 
the dbm files...

[richard@co3044991-a tmp]$ python
Python 2.1.1 (#1, Aug 30 2001, 17:36:05) 
[GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.61mdk)] on 
linux-i386
Type "copyright", "credits" or "license" for more 
information.
>>> import dbm
>>> dbm.open('foo','n')
<dbm object at 0x812a0f0>
>>> import dbhash
>>> dbhash.open('bar', 'n')
<bsddb object at 0x812b870>
>>> 
>>> import whichdb
>>> whichdb.whichdb('foo.db')
'dbhash'
>>> whichdb.whichdb('bar')
'dbhash'
>>> dbhash.open('foo.db', 'r')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.1/dbhash.py", line 16, in open
    return bsddb.hashopen(file, flag, mode)
bsddb.error: (-30990, 'Unknown error 4294936306')
>>> dbhash.open('bar', 'r')
<bsddb object at 0x812ef48>
>>> 
[richard@co3044991-a tmp]$ file foo.db
foo.db: Berkeley DB (Hash, version 5, native byte-order)
[richard@co3044991-a tmp]$ file bar
bar: Berkeley DB (Hash, version 7, native byte-order)



----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-12-13 00:28

Message:
Logged In: YES 
user_id=21627

I fail to see the problem altogether. What system are you
on? Why do you think dbm does not create dbhash files? It is
not just that the magic says they are BSDDB DB_HASH files,
they really are of that kind?

Also, which of the APIs (dbm, dbhash) do you consider
"better"? I'd say that dbhash is better, since it builds
upon bsddb. So whichdbm, and anydbm, do use the "better" dbm
backend already?

Where is the bug?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-12 05:28

Message:
Logged In: YES 
user_id=6380

Hm. anydmb *does* use whichdb. The problem seems to be that
the dbm file really *does* look like a BSD hash -- the Unix
file(1) command has the same problem.

But I'm not sure I understand your question. Do you have a
particular patch in mind?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=491888&group_id=5470


From noreply@sourceforge.net  Tue Aug 13 09:32:49 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 13 Aug 2002 01:32:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-491888 ] whichdb lies about db type
Message-ID: <E17eX6f-0005vV-00@usw-sf-web2.sourceforge.net>

Bugs item #491888, was opened at 2001-12-12 14:22
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=491888&group_id=5470

Category: Python Library
Group: Python 2.1.1
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Richard Jones (richard)
Assigned to: Martin v. Löwis (loewis)
Summary: whichdb lies about db type

Initial Comment:
>>> import dbm
>>> d = dbm.open('foo', 'n')
>>> d['a'] = 'b'
>>> d.close()
>>> import whichdb
>>> whichdb.whichdb('foo.db')
'dbhash'

I'm currently testing for the existence of "foo.db" 
instead of "foo" and hard-code my routines to use dbm 
if there is a "foo.db" file (since all other db 
modules that I've tested do no append ".db")

Might it also be possible to have anydbm perform a 
whichdb check in its open function, so that older 
databases are usable with newer, more feature-full 
installations that might include "better" dbm 
backends?



----------------------------------------------------------------------

>Comment By: Richard Jones (richard)
Date: 2002-08-13 18:32

Message:
Logged In: YES 
user_id=6405

Sorry, yes, I believe with Skip's fixes this can be closed. 

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-13 18:10

Message:
Logged In: YES 
user_id=21627

So can this report be closed then?

----------------------------------------------------------------------

Comment By: Richard Jones (richard)
Date: 2002-08-13 08:06

Message:
Logged In: YES 
user_id=6405

I believe your patch has fixes the problem. There were no version      
changes, just the ".db" extension which was confusing anydbm. Your 
assertion that   
   dbhash.open('foo', 'r')  
should work doesn't fly here:  
Python 2.2.1 (#1, Apr  9 2002, 13:10:27)  
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2  
Type "help", "copyright", "credits" or "license" for more information.  
>>> import dbm, dbhash, whichdb  
>>> dbm.open('spam', 'n')  
<dbm.dbm object at 0x815a0f0>  
>>> _.close()  
>>> whichdb.whichdb('spam')  
>>> whichdb.whichdb('spam.db')  
'dbhash'  
>>> dbhash.open('spam', 'r')  
Traceback (most recent call last):  
  File "<stdin>", line 1, in ?  
  File "/usr/lib/python2.2/dbhash.py", line 16, in open  
    return bsddb.hashopen(file, flag, mode)  
bsddb.error: (2, 'No such file or directory')  
>>> dbhash.open('spam.db', 'r')  
Traceback (most recent call last):  
  File "<stdin>", line 1, in ?  
  File "/usr/lib/python2.2/dbhash.py", line 16, in open  
    return bsddb.hashopen(file, flag, mode)  
bsddb.error: (22, 'Invalid argument')  
>>> dbm.open('spam', 'r') 
<dbm.dbm object at 0x815a0f0> 
>>>  
 
I don't see how that's "pilot error". Your fixes will solve the problem 
though. anydbm will be able to reopen the dbm-created files it creates 
:) 
 

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-08-13 07:06

Message:
Logged In: YES 
user_id=44345

If the user opened the file with

    db = anydbm.open("foo", "c")

*and* the dbm module happened to be selected by anydbm *and* 
dbmmodule.so happened to be linked with BerkDB, the file created will 
be named "foo.db" and will actually be a BerkDB hash file (whose 
version depends on the version of the library installed).  If the user later 
asks whichdb.whichdb what type of file "foo"  is, my latest change 
corrected responds "dbm".  If, on the other hand, the user asks 
whichdb.whichdb what type of file "foo.db" is, it should now respond 
"dbhash".   This is what my recent patch to the whichdb module fixed.  
It would be incorrect to try to open "foo.db" with the dbm module.

If a bsddb.error exception is raised, it's almost certainly because the user 
upgraded the BerkDB library, but didn't run the tools provided by 
Sleepycat to upgrade his or her preexisting files.  I don't see how there's 
a Python problem here that needs solving.  It's simply pilot error.  The 
best we can do I think is improve the message associated with the 
exception which the module raises.  (Something like "invalid file format" 
instead of simply "invalid argument.)

In my previous note I made a mistake.  Instead of

    He should have called
        dbhash.open('foo', 'r')
    as he later demonstrated.

The function call should have been "dbm.open".


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-12 07:13

Message:
Logged In: YES 
user_id=21627

Skip, I think you misunderstand the complaint. It's not
about the way in which an error message is given, but that
the error message is given at all.

The file is a dbm file, and the dbm module is capable of
opening it, so no error should be reported at all.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-07-26 01:03

Message:
Logged In: YES 
user_id=44345

Martin's comment in bug 584409 reminded me that I have a patched 
whichdb module which should cure this problem.  (At the moment my 
dbm module is linked with gdbm, not BerkDB, however, so while I've 
tested this in the past, I can't provide you with an interactive 
demonstration at the moment.)  Note that Richard was forced to do 
something for which whichdb was not designed. I believe with this 
patch he should be able to once again ask for simply "foo" and not 
wonder what extensions the underlying db package add to the files.

I still don't think version information would help here.  Richard's tests 
are flawed.  Berkeley DB only adds ".db" to the end of the file when 
using the dbm-compatibility API.  He should have called

    dbhash.open('foo', 'r')

as he later demonstrated.  While somewhat mystifying, the bsddb.error 
is more or less correct.  We should probably trap that and raise a "file 
not found" error or just try a stat() call if the db file is to be opened for 
reading.

Assigning to Martin for consideration.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-12-13 20:43

Message:
Logged In: YES 
user_id=21627

I see. The problem appears to be that your BSDDB
installation, which implements hash version 7, does not
simultaneously support hash version 5 anymore. This
primarily is a problem in the Sleepycat version shipped with
your system (for not supporting old databases), and in glibc
(for not incorporating a newer bsd db). Python can work
around this problem, at best - there might always be DBHASH
files that none of the DB implementations on a system can open.

bsddb should expose version information, like DB_HASHVERSION
and DB_HASHOLDVER (the current and the minimum hash
version). Unfortunately, db_185.h, as used by bsddb.c, do
not provide these constants, and db_185.h cannot be used
simultaneously with db.h. db_185.h exposes a HASHVERSION
constant, but that seems to stay at 2 regardless of the file
version that the compatibility API uses.

The right solution seems to drop support for the DB1 API,
and mandate a DB2-or-better db.h. I'd personally recommend
to integrate pybsddb.sf.net into Python 2.3, adding
portability to BSDDB 2 if necessary (it could be a
build-time decision to build either source module as bsddb).

For the moment, I cannot recommend a good work-around; I see
two options:
- find out magically (by looking at db.h) what hash versions
dbhash will support, then check the version of the hash
file, and refuse to use dbash if the version won't be
supported. Since this requires magic, such code should not
be added to Python, but left to the application.
- catch bsddb.error on dbhash.open, and retry with dbm.open.
 This is a heuristic which also shouldn't be added to
Python, but which may be acceptable to the application.

----------------------------------------------------------------------

Comment By: Richard Jones (richard)
Date: 2001-12-13 18:05

Message:
Logged In: YES 
user_id=6405

Sorry about the anydbm/whichdb confusion - reading the 
source a little closer would have avoided my confusion.

Regardless, there is still a problem that on my system, 
dbm files are reported as dbhash, and dbhash can't open 
the dbm files...

[richard@co3044991-a tmp]$ python
Python 2.1.1 (#1, Aug 30 2001, 17:36:05) 
[GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.61mdk)] on 
linux-i386
Type "copyright", "credits" or "license" for more 
information.
>>> import dbm
>>> dbm.open('foo','n')
<dbm object at 0x812a0f0>
>>> import dbhash
>>> dbhash.open('bar', 'n')
<bsddb object at 0x812b870>
>>> 
>>> import whichdb
>>> whichdb.whichdb('foo.db')
'dbhash'
>>> whichdb.whichdb('bar')
'dbhash'
>>> dbhash.open('foo.db', 'r')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.1/dbhash.py", line 16, in open
    return bsddb.hashopen(file, flag, mode)
bsddb.error: (-30990, 'Unknown error 4294936306')
>>> dbhash.open('bar', 'r')
<bsddb object at 0x812ef48>
>>> 
[richard@co3044991-a tmp]$ file foo.db
foo.db: Berkeley DB (Hash, version 5, native byte-order)
[richard@co3044991-a tmp]$ file bar
bar: Berkeley DB (Hash, version 7, native byte-order)



----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-12-13 10:28

Message:
Logged In: YES 
user_id=21627

I fail to see the problem altogether. What system are you
on? Why do you think dbm does not create dbhash files? It is
not just that the magic says they are BSDDB DB_HASH files,
they really are of that kind?

Also, which of the APIs (dbm, dbhash) do you consider
"better"? I'd say that dbhash is better, since it builds
upon bsddb. So whichdbm, and anydbm, do use the "better" dbm
backend already?

Where is the bug?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-12 15:28

Message:
Logged In: YES 
user_id=6380

Hm. anydmb *does* use whichdb. The problem seems to be that
the dbm file really *does* look like a BSD hash -- the Unix
file(1) command has the same problem.

But I'm not sure I understand your question. Do you have a
particular patch in mind?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=491888&group_id=5470


From noreply@sourceforge.net  Tue Aug 13 12:43:58 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 13 Aug 2002 04:43:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-556025 ] list(xrange(1e9))  -->  seg fault
Message-ID: <E17ea5e-0001EM-00@usw-sf-web2.sourceforge.net>

Bugs item #556025, was opened at 2002-05-14 08:41
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=556025&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Jason Tishler (jlt63)
Summary: list(xrange(1e9))  -->  seg fault

Initial Comment:
>From c.lang.py:

'''
 Python 2.2.1 (#2, Apr 21 2002, 22:22:55) 
[GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.62mdk)] 
on linux2
Type "help", "copyright", "credits" or "license" for 
more information.
>>> list(xrange(1e9))
Segmentation fault
'''

I've reproduced the same fault on Windows ME using 
Py2.2.0 and Py2.3a.

----------------------------------------------------------------------

>Comment By: Jason Tishler (jlt63)
Date: 2002-08-13 03:43

Message:
Logged In: YES 
user_id=86216

Committed as Lib/test/test_b1.py 1.51.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-12 05:38

Message:
Logged In: YES 
user_id=33168

You should probably add that it fails due to a bug in newlib
and not python.  Go ahead and check it in and close the bug
report.  Thanks.

----------------------------------------------------------------------

Comment By: Jason Tishler (jlt63)
Date: 2002-08-12 03:26

Message:
Logged In: YES 
user_id=86216

rhettinger wrote:
> My thought is to close the bug, but add a
> unittest that says in effect:  if os is cygwin
> and version(cygwin) >= 1.3.13 and the bug still
> exists, then fail with a message saying that SF
> 556025 was not successfully resolved.

Do we really want to add cruft that is not only
Cygwin specific but Cygwin version specific?

nnorwitz wrote:
> I'm not sure if the test should fail, be
> skipped, or not run for cygwin < 1.3.13.

Agreed.

> But let's at least put a comment in the test and
> close this bug report.  Jason, can you do that?

Yes, but I only have pre-approved commit access to
the CVS repository. Can you approve the attached
patch?

> Good persistence Jason!

Thanks.


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-10 06:27

Message:
Logged In: YES 
user_id=33168

I'm not sure if the test should fail, be skipped, or not run
for cygwin < 1.3.13.  But let's at least put a comment in
the test and close this bug report.  Jason, can you do that?

Good persistence Jason!

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-08-09 19:08

Message:
Logged In: YES 
user_id=80475

My thought is to close the bug, but add a unittest that 
says in effect:  if os is cygwin and version(cygwin) >= 
1.3.13 and the bug still exists, then fail with a message 
saying that SF 556025 was not successfully resolved.

This way, we can close the bug (since it is not a python 
bug) and still get a regression test to raise the concern if 
the expected solution either doesn't materialize or 
sometime later dematerializes.


----------------------------------------------------------------------

Comment By: Jason Tishler (jlt63)
Date: 2002-08-09 17:02

Message:
Logged In: YES 
user_id=86216

I guess that my perseverance paid off:

http://sources.redhat.com/ml/newlib/2002/msg00391.html

Hence, this bug will be fixed in Cygwin 1.3.13.

Can we close this bug now? Or, should we wait until
Cygwin 1.3.13 is released?

----------------------------------------------------------------------

Comment By: Jason Tishler (jlt63)
Date: 2002-08-09 10:09

Message:
Logged In: YES 
user_id=86216

Thanks for the sympathy.

I've tried, tried again:

http://sources.redhat.com/ml/newlib/2002/msg00390.html

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-08 16:56

Message:
Logged In: YES 
user_id=33168

I looked at the links.  I don't know what I can do to help.
 It seems like you proposed a reasonable solution and even
if it wasn't perfect, you still demonstrated a problem.  I
suppose I can only commiserate with you.

----------------------------------------------------------------------

Comment By: Jason Tishler (jlt63)
Date: 2002-08-08 04:11

Message:
Logged In: YES 
user_id=86216

> Jason, can you test/replicate this?

Yes, I've already been working on this one. See
the following mailing list threads for the details:

http://cygwin.com/ml/cygwin-developers/2002-07/msg00124.html
http://sources.redhat.com/ml/newlib/2002/msg00369.html

To summarize the above, the problem is actually
in newlib which provides Cygwin's libc (and
libm).  Unfortunately, Chris Falyor (the Cygwin
lead developer) has not been able to convince
the newlib maintainer to fix this problem.
Additionally, my first patch has been rejected.

I will continue my efforts to get this problem
resolved.  Any assistance will be greatly
appreciated.  I never expected to become an
expert in Doug Lea's malloc routines.  Sigh...

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-07 12:11

Message:
Logged In: YES 
user_id=33168

Actually, I think Jason may be more appropriate, since this
is a cygwin problem.  Jason, can you test/replicate this?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-07 10:20

Message:
Logged In: YES 
user_id=33168

Hmmm, Tim can you reproduce this?  I luckily don't have a
windows box. :-)

----------------------------------------------------------------------

Comment By: Steve Holden (holdenweb)
Date: 2002-08-07 09:28

Message:
Logged In: YES 
user_id=88157

I hope re-opening this is the right thing to do (I'm new here).

Current CVS fails under Win2000+Cygwin with a 
segmentation fault in the updated test_b1.py. Easily 
reproduced:

$ ./python.exe
Python 2.3a0 (#1, Aug  7 2002, 12:18:38)
[GCC 2.95.3-5 (cygwin special)] on cygwin
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import sys
>>> list(xrange(sys.maxint/4))
Segmentation fault (core dumped)

This does seem to be size-related, as:

>>> s = sys.maxint/8
>>> list(xrange(s))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
MemoryError

which is as expected in test_b1.py


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-22 15:20

Message:
Logged In: YES 
user_id=33168

Checked in as:
  listobject.c 2.106
  test_b1.py 1.46

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-21 04:59

Message:
Logged In: YES 
user_id=80475

Good plan!  Thx for squashing this bug. 

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-21 04:52

Message:
Logged In: YES 
user_id=33168

How about using sys.maxint / 4?  Does that make more sense
than 1e9?  This assumption is a little better, that the data
and address sizes are the same.  I can add a comment to this
effect.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-20 19:37

Message:
Logged In: YES 
user_id=80475

When you load the fix, please commit the regression test 
patch also.  Thx,  Raymond

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-05-20 18:51

Message:
Logged In: YES 
user_id=31435

Yup, lookin' better.  Python does assume 8-bit bytes in 
several places, and also 2's-complement integers.  Since 
size_t is guaranteed (by C) to be an unsigned type, the 
largest value of type size_t is more easily expressed as

(~(size_t)0)

The C part of the patch looks fine then.  The test is a 
little dubious:  who says the machine can't create a 
billion-integer list?  The idea that 1e9 necessarily 
overflows in this context is a 32-bit address-space 
assumption.  But I'm willing to delay fixing that until a 
machine with a usable larger address space appears <wink>.

So marked Accepted and assigned to you for checkin.  Thanks!

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-20 07:43

Message:
Logged In: YES 
user_id=33168

Ok, there were other problems, too:
  * Need to divide by the size of the type, 
    not >> 4 which was completely broken.
  * There was a missing PyErr_NoMemory().

I uploaded a new patch.

I'm not sure the size_t fix is correct.
I hope we can at least assume 8-bit machines: :-)

if (_new_size <= ((1 << (sizeof(size_t)*8 - 1)) / sizeof(type)))



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-05-19 20:48

Message:
Logged In: YES 
user_id=31435

The code patch has some problems:  you can't assume any 
relation between a size_t and an unsigned long; C simply 
doesn't define how big size_t is, and relative sizes do 
vary on 64-bit platforms.  However that gets fixed, if you 
decide it's "too big", var should be set to NULL (not 0 -- 
this is a "Guido thing" <wink>), and no exception should be 
set.  It's the caller's responsibility to check var for 
NULL after the macro is invoked, and set an appropriate 
exception.  listobject.c sometimes doesn't check the result 
for NULL, but that should only be when it knows it's 
*shrinking* a memory area, so that realloc can't fail.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-17 16:12

Message:
Logged In: YES 
user_id=80475

Added a patch to add this bug to the testbank.

Shallow code review:  Patch compiles okay (applied to 
Py2.3a0). Fixes the original problem.  Passes the smell 
test.  Macro style good (only the "var" operand is used 
more than once; no side-effects except setting "var" to 
zero upon a resize error).  Passes the standard regression 
tests.  Passes regression testing versus my personal (real 
code) testbank.

Will give it a deeper look this week-end.

One other thought: should the ValueError be replaced with a 
MemoryError to make the message consistent with PyList_New?



----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 13:03

Message:
Logged In: YES 
user_id=33168

Ok, this time I have a patch.  The patch only fixes listobject.

I looked over the other uses of PyMem_R{ESIZE,ALLOC}() and
they don't appear to be nearly as problematic as list.  For
example, if the grammar has 1e9 nodes, there are going to be
other problems well before then (ie, memory will probably be
gone).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 12:25

Message:
Logged In: YES 
user_id=33168

Oops, sorry about that last comment.  That was something I
was playing with.  The CVS version is fine for [x]range(float).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 12:22

Message:
Logged In: YES 
user_id=33168

Note, this problem is even more generic in CVS version:

>>> range(1.1)
Segmentation fault (core dumped)
>>> xrange(1.1)
Segmentation fault (core dumped)

[x]xrange(float) work fine in 2.2.1.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-14 16:44

Message:
Logged In: YES 
user_id=80475

Would there be some merit to converting PyMem_RESIZE to a 
function with an overflow check?  

I would guess that the time spent on a realloc dwarfs the 
overhead of a short wrapper function.

OTOH, I'll bet this core dump only occurs in toy examples 
and never in real code.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-05-14 14:15

Message:
Logged In: YES 
user_id=31435

Heh.  This is an instance of a general flaw:  the 
PyMem_RESIZE macro doesn't check for int overflow in its

    (n) * sizeof(type)

subexpression. The basic deal is that 1000000000 fits in an 
int, but 4 times that (silently) overflows.  In more 
detail, for this specific test case, listobject.c'.s 
roundupsize rounds 1e9 up to 0x40000000, which silently 
underflows to 0!() when PyMem_RESIZE multiplies it by 4.

Hard to know how to fix this in general; PyMem_RESIZE 
callers don't generally worry about overflow now.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=556025&group_id=5470


From noreply@sourceforge.net  Tue Aug 13 14:36:55 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 13 Aug 2002 06:36:55 -0700
Subject: [Python-bugs-list] [ python-Bugs-592441 ] Webchecker error on http://www.naleo.org
Message-ID: <E17ebqx-0003YT-00@usw-sf-web2.sourceforge.net>

Bugs item #592441, was opened at 2002-08-08 04:40
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592441&group_id=5470

Category: Demos and Tools
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Carlos Conti (mcsolrac)
Assigned to: Jeremy Hylton (jhylton)
Summary: Webchecker error on http://www.naleo.org

Initial Comment:
Webchecker version 1.25.6.1 on Windows 2000 
Professional. 

Run webchecker with this argument 
http://www.naleo.org/WSJArticle002.htm 
Webchecker will return this traceback: 

Traceback (most recent call last):
  File "C:\Python22\Tools\webchecker\webchecker.py", 
line 858, in ?
    main()
  File "C:\Python22\Tools\webchecker\webchecker.py", 
line 222, in main
    c.run()
  File "C:\Python22\Tools\webchecker\webchecker.py", 
line 349, in run
    self.dopage(url)
  File "C:\Python22\Tools\webchecker\webchecker.py", 
line 403, in dopage
    page = self.getpage(url_pair)
  File "C:\Python22\Tools\webchecker\webchecker.py", 
line 507, in getpage
    return Page(text, url, maxpage=self.maxpage, 
checker=self)
  File "C:\Python22\Tools\webchecker\webchecker.py", 
line 671, in __init__
    self.parser.feed(self.text)
  File "C:\Python22\lib\sgmllib.py", line 95, in feed
    self.goahead(0)
  File "C:\Python22\lib\sgmllib.py", line 161, in goahead
    k = self.parse_declaration(i)
  File "C:\Python22\lib\markupbase.py", line 66, in 
parse_declaration
    decltype, j = self._scan_name(j, i)
  File "C:\Python22\lib\markupbase.py", line 313, in 
_scan_name
    self.error("expected name token")
  File "C:\Python22\lib\sgmllib.py", line 102, in error
    raise SGMLParseError(message)
sgmllib.SGMLParseError: expected name token

I believe this is because of the xml in the source code 
(see WSJArticle002_source.txt attached to this bug 
report).

Even if the code in this page is poorly formatted, 
webchecker should be able continue checking other 
links in this domain (rather than stopping). For example 
webchecker could report “unable to check 
http://www.naleo.org/WSJArticle002.htm” and return 
traceback like the above, and then continue with the rest 
of the domain. 


----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-08-13 13:36

Message:
Logged In: YES 
user_id=31392

No need to apologize.  Everyone is welcome to submit bug
reports here.  There are, however, lots of programmers who
submit bugs, so I find it helpful to ask :-).  I'll look
into this, but it's not the highest priority.


----------------------------------------------------------------------

Comment By: Carlos Conti (mcsolrac)
Date: 2002-08-08 22:06

Message:
Logged In: YES 
user_id=591396

I'd love to submit a patch, but I am a newbie to both Python 
and programming. I apologize if this space is only intended 
for programmers; I am a QA engineer just getting acquainted 
to the wonderful world of Python. 

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-08-08 19:20

Message:
Logged In: YES 
user_id=31392

I've seen a variety of parsing problems kill webchecker.  I
agree that these exceptions should be caught somewhere so
that they are not fatal.  Care to submit a patch?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592441&group_id=5470


From noreply@sourceforge.net  Tue Aug 13 16:42:51 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 13 Aug 2002 08:42:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-581529 ] bug in splituser(host) in urllib
Message-ID: <E17edop-0003RW-00@usw-sf-web1.sourceforge.net>

Bugs item #581529, was opened at 2002-07-15 04:36
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=581529&group_id=5470

Category: Python Library
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Chetan Sarva (csarva)
Assigned to: Jeremy Hylton (jhylton)
Summary: bug in splituser(host) in urllib

Initial Comment:
The splituser() method splits on the very first "@" it encounters 
which can lead to inaccurate results in certain cases (i.e. if the 
username portion contains an e-mail address). Splitting on the last 
"@" in the string will give the desired results every time.

 I'm 
not very good with regex's so I've given my simple solution as a 
sample below:

_userprog = None
def 
splituser(host):
    """splituser('user[:passwd]@host[:port]') --> 
'user[:passwd]', 'host[:port]'."""
    global _userprog
    if 
_userprog is None:
        x = host.rfind('@')
        if x != -1:
            return 
host[:x], host[x+1:]
        else:
            return None, host
            
        
#import re
        #_userprog = re.compile('^([^@]*)@(.*)$')

    
#match = _userprog.match(host)
    #if match: return 
map(unquote, match.group(1, 2))
    return None, host

----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-08-13 15:42

Message:
Logged In: YES 
user_id=31392

The '@' in the userinfo is not legal according to RFC 2396.
 It must be escaped.

But I suppose other tools handle this without the escaping,
so we ought to also.  '@' isn't legal in the host part
either, but it's much less likely to occur there.



----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-11 15:30

Message:
Logged In: YES 
user_id=33168

Jeremy, how should this be fixed?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=581529&group_id=5470


From noreply@sourceforge.net  Tue Aug 13 18:39:37 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 13 Aug 2002 10:39:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-585792 ] Invalid mmap crashes Python interpreter
Message-ID: <E17efdp-0006SJ-00@usw-sf-web3.sourceforge.net>

Bugs item #585792, was opened at 2002-07-24 04:52
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=585792&group_id=5470

Category: None
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: paul rubin (phr)
>Assigned to: Tim Peters (tim_one)
Summary: Invalid mmap crashes Python interpreter

Initial Comment:
This is under Red Hat 7.2, Linux kernel 2.4.7.   "x" is
an empty file, i.e. zero bytes long.

import mmap
f = open(x,"r+")m = mmap.mmap(f.fileno(), 10)
print m[1]

Crashes Python with a bus error.  Python should catch
the bus error signal
and raise an appropriate exception that the script can
catch.


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-13 13:39

Message:
Logged In: YES 
user_id=33168

I can't test windows.  I've attached a patch which tries to
test windows doesn't raise an exception.
I also modified the NEWS to state this change affects
non-Windows platforms.

Tim/Martin, can you test (or at least review the test code)
that this works on Windows before I check it in?  Or let me
know if you want me to check it in.  It should be easy to
fix if it doesn't work on Windows.

Thanks.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-08-12 22:11

Message:
Logged In: NO 

I'd say the following is reasonable:

- on mmap object creation, stat the file and check its size
against the size arg passed to mmap.  Signal an error if the
file is smaller than the requested mmap size.  

- On access, compare the subscript to the mmap object size
and signal an error if out of bounds (presumably this is
done already)

- Figure out if another process can truncate the file while
the mmap is alive.  If yes, maybe add a method to the mmap
object that re-stats the file and makes sure it's still
larger than the mmap size.  

- Add warnings to the mmap documentation that weirdness can
result from the file size changing etc.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-12 12:31

Message:
Logged In: YES 
user_id=21627

I think we should special-case Windows, then. For the
mmapmodule patch proper, nothing needs to be done; for the
testsuite test, pass and fail are exactly reversed on
Windows (but then, we'd test the implementation of Windows,
so skipping that test sounds reasonable as well).

With those changes, the patch is fine.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-08-12 11:59

Message:
Logged In: YES 
user_id=31435

mmap() on WIndows doesn't care if you map more bytes 
than exist in the file -- if you do, it grows the file to match.

"""
If an application specifies a size for the file mapping object 
that is larger than the size of the actual named file on disk, 
the file on disk is grown to match the specified size of the 
file mapping object. If the file cannot be grown, this results 
in a failure to create the file mapping object. GetLastError 
will return ERROR_DISK_FULL.
"""

Like so:

>>> import mmap
>>> import os
>>> os.path.getsize('abc.abc')
12L
>>> f = file('abc.abc', 'r+')
>>> m = mmap.mmap(f.fileno(), 10000)
>>> m.close()
>>> os.path.getsize('abc.abc')
10000L
>>>


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-12 11:49

Message:
Logged In: YES 
user_id=33168

That last comment was supposed to be:  I don't know how
Windows behaves...

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-12 11:47

Message:
Logged In: YES 
user_id=33168

I thought the st_size was updated by the code in
new_buffersize.  It was only the position, so the comment
should go.  ValueError is fine with me.  Should I add an
entry to NEWS?  New patch attached w/NEWS and test.

There is another issue--Windows.  I how Windows behaves and
I can't test it.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-12 10:45

Message:
Logged In: YES 
user_id=21627

I'd say it is a ValueError if the map size is larger than
the file size, instead of silently decreasing the size:
Errors should never pass silently, Unless explicitly silenced.

On the trick of new_buffersize: I'm not sure I understand
what you are referring to: we don't use stdio in mmap at all.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-12 09:30

Message:
Logged In: YES 
user_id=33168

I wasn't sure if I could change the size.  For Solaris at
least, it seems this is the right thing to do.  Is it likely
that other systems allow the file size to change?  I've
forced the size to be the max(size_arg, size_of_file).  This
has the added benefit of working for writing too.  Prior to
this patch, writing past the end crashed on Linux.

There are 2 comments in the patch:  one worrying about the
file changing, the other producing a warning message if the
size argument is larger than the file.  Do we have to worry
about the size changing?  Should we tell the user what they did?

Sorry about the old style diff.  I remembered to do the cvs
-f diff part, but forgot the -C5.  My defaults are unified.
New context patch attached.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-08-12 03:45

Message:
Logged In: NO 

Please don't even think of adding a stat call to every
access.  The whole idea of mmap is to speed up access by
eliminating system calls when you touch the file contents. 
Checking the file size at map creation is reasonable.  Some
note should also be added to the mmap doc about possible
crashes if the file size changes.

>From a Python script writer's viewpoint, the most convenient
fix is for Python to catch the bus error signal and inspect
the stack to figure out that the trap occurred in the mmap
routine, then generate and return an appropriate Python
exception.  However, doing that is pretty
platform-dependent, and attempting it in all the Python
ports that support mmap doesn't sound practical.  

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-12 03:15

Message:
Logged In: YES 
user_id=21627

Ah, an old-style diff. I assume that goes into mmap_item?

I'd rather avoid the stat call on every access, and check
the size on map creation.

The Solaris man page says this about changing files:

     If the size of the mapped file changes  after  the 
call  to
     mmap()  as  a  result  of some other operation on the
mapped
     file, the effect of references to  portions  of  the 
mapped
     region  that  correspond to added or removed portions
of the
     file is unspecified.

So it appears that this is a case of "don"t do this, then",
and that it atleast won't crash - but we might want to
perform a few experiments.



----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-11 11:05

Message:
Logged In: YES 
user_id=33168

Martin, could you please review the patch?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-07-28 11:00

Message:
Logged In: YES 
user_id=33168

Attached is a patch which fixes this problem.  I'm not sure
this patch it correct nor appropriate.  But it stops the
crash.  I'm hoping some mmap expert can shed some light on this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=585792&group_id=5470


From noreply@sourceforge.net  Tue Aug 13 18:50:08 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 13 Aug 2002 10:50:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-574235 ] convert_path fails with empty pathname
Message-ID: <E17efo0-0006lM-00@usw-sf-web3.sourceforge.net>

Bugs item #574235, was opened at 2002-06-26 15:48
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574235&group_id=5470

Category: Distutils
Group: Python 2.1.2
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Aneesh Dalvi (adalvi)
Assigned to: Neal Norwitz (nnorwitz)
Summary: convert_path fails with empty pathname

Initial Comment:
In distutils/util.py, in the function convert_path, I find I 
have to add the following two lines:

def convert_path (pathname):
    ...
    if os.sep == '/':
        return pathname
>>    if pathname=='':
>>        return pathname

This is required when installing piddle-1.0.15 on a Win32 
platform.  It is required under Python 2.1.2 as well as 
2.2.1.

I don't know if it is something specific to piddle, Win32, 
or something else.


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-13 13:50

Message:
Logged In: YES 
user_id=33168

Checked in as distutils/util.py 1.70 and 1.65.6.1.
Thanks!

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-11 17:07

Message:
Logged In: YES 
user_id=21627

I've checked piddle, and the traceback is

Traceback (most recent call last):
  File "setup.py", line 28, in ?
    packages = ['piddle', 'piddle.piddleGTK',
'piddle.piddleSVG', 'piddle.piddleTK2'] )
  File "/usr/local/lib/python2.3/distutils/core.py", line
140, in setup
    dist.run_commands()
  File "/usr/local/lib/python2.3/distutils/dist.py", line
886, in run_commands
    self.run_command(cmd)
  File "/usr/local/lib/python2.3/distutils/dist.py", line
906, in run_command
    cmd_obj.run()
  File
"/usr/local/lib/python2.3/distutils/command/install.py",
line 504, in run
    self.run_command(cmd_name)
  File "/usr/local/lib/python2.3/distutils/cmd.py", line
334, in run_command
    self.distribution.run_command(command)
  File "/usr/local/lib/python2.3/distutils/dist.py", line
906, in run_command
    cmd_obj.run()
  File
"/usr/local/lib/python2.3/distutils/command/install_data.py",
line 61, in run
    dir = convert_path(f[0])
  File "/usr/local/lib/python2.3/distutils/util.py", line
85, in convert_path
    assert pathname
AssertionError

(the assertion is a local change). This in turn results from

      data_files = [ ('piddle/pilfonts', pilfontsList),
                     ('piddle', ['src/piddle/python.gif']),
                     ('', ['src/piddle.pth']) ],

i.e. it tries to install piddle.pth into install_dir.

So the change is ok, although I'm not sure whether
install_data's usage of convert_path is correct. E.g. it
tries to support absolute paths, which are rejected in
convert_path.


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-11 11:33

Message:
Logged In: YES 
user_id=33168

Martin, could you please review this patch?  Should this be
implemented?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-26 22:02

Message:
Logged In: YES 
user_id=33168

This approach seems reasonable.
I've attached a patch.
I'm not sure why an empty path would
be passed, but I suppose it can't hurt to check.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574235&group_id=5470


From noreply@sourceforge.net  Tue Aug 13 23:21:26 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 13 Aug 2002 15:21:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-545600 ] IDLE doesn't save 8bit files
Message-ID: <E17ek2Y-0003WT-00@usw-sf-web4.sourceforge.net>

Bugs item #545600, was opened at 2002-04-18 04:28
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=545600&group_id=5470

Category: IDLE
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexandre Fayolle (afayolle)
Assigned to: Nobody/Anonymous (nobody)
Summary: IDLE doesn't save 8bit files

Initial Comment:
This bug seems to be related to #527022. 

Short version is: IDLE won't save files containing 8bit
characters (for instance in comments or in litteral
strings). No error dialog is displayed, only a
traceback on stderr or in the interactive window if
it's available:

Exception in Tkinter callback
Traceback (most recent call last):
  File "/usr/lib/python2.1/lib-tk/Tkinter.py", line
1285, in __call__
    return apply(self.func, args)
  File "/usr/lib/idle-python2.1/IOBinding.py", line
126, in save
    self.save_as(event)
  File "/usr/lib/idle-python2.1/IOBinding.py", line
136, in save_as
    if self.writefile(filename):
  File "/usr/lib/idle-python2.1/IOBinding.py", line
154, in writefile
    f.write(chars)
UnicodeError: ASCII encoding error: ordinal not in
range(128)

Possible solution:

 * at least warn the user that the file could not be
saved with an error dialog
 * try using the locale to guess the encoding and do
appropriate conversions
 * ask the user wich encoding should be used to save
the file

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-08-13 15:21

Message:
Logged In: NO 

Also, the file gets destroyed - truncated to 0 bytes, after 
such unsucessful save.

----------------------------------------------------------------------

Comment By: Alexandre Fayolle (afayolle)
Date: 2002-04-19 02:30

Message:
Logged In: YES 
user_id=116727

I like the solution proposed in the reference.

However, having just a traceback printed on the console
looks like a bug to me. I expect IDLE to complain loudly in
case it cannot save my file. If it could give me a hint as
to what to add to the file to be able to save it, that'd be
even better. 

Cheers 

Alexandre 

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-04-19 01:23

Message:
Logged In: YES 
user_id=21627

In this form, this is not a bug. IDLE cannot know what
encoding you want to use the file.

Under PEP 263, you will need to declare the encoding inside
the file; then IDLE will use the declared encoding. See

http://sourceforge.net/tracker/index.php?func=detail&aid=508973&group_id=9579&atid=309579

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=545600&group_id=5470


From noreply@sourceforge.net  Wed Aug 14 01:30:15 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 13 Aug 2002 17:30:15 -0700
Subject: [Python-bugs-list] [ python-Bugs-594833 ] python-mode.el disables raw_input()
Message-ID: <E17em3D-0005uK-00@usw-sf-web3.sourceforge.net>

Bugs item #594833, was opened at 2002-08-13 17:30
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594833&group_id=5470

Category: Demos and Tools
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Kow Kuroda (kowk)
Assigned to: Nobody/Anonymous (nobody)
Summary: python-mode.el disables raw_input()

Initial Comment:
Hi,

I'm not sure if this is a bug. I just wanted to report a problem 
with my emacs environment using python-mode. With the 
current version of python-mode.el with Python 2.1, 2.2, 2.2.1, 
I always get

	EOFError: EOF when reading a line

at the line I call raw_input() function. How to get this work in 
emacs?
By the way, the same code doesn't raise this error with vim.

Thanks in advance.
Kow

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594833&group_id=5470


From noreply@sourceforge.net  Wed Aug 14 03:29:50 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 13 Aug 2002 19:29:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-589427 ] standard include paths on command line
Message-ID: <E17enuw-0004Zz-00@usw-sf-web5.sourceforge.net>

Bugs item #589427, was opened at 2002-07-31 19:13
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=589427&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: Remind
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Skip Montanaro (montanaro)
Summary: standard include paths on command line

Initial Comment:
when compiling shared modules (using gcc-3.1.1), 
standard include paths are included (by setup.py?) in 
the include path, which can change the search order. 
gcc-3.1 warns about:

building 'xreadlines' extension
gcc-3.1 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -
fPIC -I. -I/home/packages/pyt
hon2.3/python2.3-2.2.90/./Include -I/usr/include -
I/usr/local/include -I/home/pa
ckages/python2.3/python2.3-2.2.90/Include -
I/home/packages/python2.3/python2.3-2
.2.90/build-static -
c /home/packages/python2.3/python2.3-
2.2.90/Modules/xreadlin
esmodule.c -o build/temp.linux-i686-
2.3/xreadlinesmodule.o
gcc -shared build/temp.linux-i686-
2.3/xreadlinesmodule.o -L/usr/lib -L/usr/local
/lib -o build/lib.linux-i686-2.3/xreadlines.so
building 'array' extension
gcc-3.1 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -
fPIC -I. -I/hocc1: warning: c
hanging search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory

In this case, /usr/include and /usr/local/include should 
not be included on the command line.


----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2002-08-13 21:29

Message:
Logged In: YES 
user_id=44345

Doko, are you still having problems?  I really have nothing to go on here.  I 
don't see /usr/include turning up on the command line and don't have a 
Debian system to try things out on. (Does the SF compile farm?)

Skip


----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-08-05 10:25

Message:
Logged In: YES 
user_id=44345

Sorry guys, I'm coming in on this late.  

I'm done with the bsddb trickery.  In any case /usr/include is not added 
as a -I argument under any circumstances in the bsddb build section of 
setup.py.  Various Linux vendors allow you to install multiple versions of 
Berkeley DB simultaneously.  The only way you can guarantee that a 
particular version is compiled against and linked with is to add the 
appropriate -I and -L flags to the command line.  On RedHat-derived 
systems the include files are in /usr/include/db{1,2,3,4} if installed as part 
of a system install, while if you install from Sleepycat source I believe it's 
/usr/local/BerkeleyDB<version>/include.   I can't really get rid of the 
RH-related include directories. 

Wait a minute.  I take some of that back.  *If* you are foolish enough to 
uncomment the section of code which enables compilation and linkage 
with Berkeley DB 1.85, you might wind up with -I/usr/include on the 
command line to build the bsddb module.  I will correct that (make it so 
/usr/include isn't added to the -I flag) and also reorder the directory 
search so system include directories are scanned after non-system 
directories.

How's this going to help the OP?  I thought the problem he saw was 
more pervasive (xreadlines, _ssl, etc).



----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-08-05 09:51

Message:
Logged In: YES 
user_id=6656

Skip, are you still working on the bsddb related bits of
setup.py?  Can you look into how /usr/include is getting
onto the commandline?


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-04 07:47

Message:
Logged In: YES 
user_id=21627

I can't reproduce this. With the current CVS, on Debian,
with --prefix=/usr, I get

gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC
-DWITH_APPINIT=1 -I/usr/include/tcl8.3 -I/usr/X11R6/include
-I. -I/vol/marvin-vol8/loewis/python/dist/src/./Include
-I/usr/local/include
-I/vol/marvin-vol8/loewis/python/dist/src/Include
-I/vol/marvin-vol8/loewis/python/dist/src -c
/vol/marvin-vol8/loewis/python/dist/src/Modules/_tkinter.c
-o build/temp.linux-i686-2.3/_tkinter.o

So it won't add -I/usr/include to the command line options.

----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2002-08-03 11:30

Message:
Logged In: YES 
user_id=60903

No. It's:

 - bsddb
 - dbm
 - _tkinter

all modules, which are installed in /usr at least on Debian
GNU/Linux (but maybe on other distros as well).

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-08-03 11:19

Message:
Logged In: YES 
user_id=6656

It's only the _ssl module, right?  I've fixed that.

The -R/usr/lib and -L/usr/lib's come from various database
modules, the configuration of which is under review anyway.
 I hope those doing the reviewing have seen this bug traffic...

----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2002-08-03 10:56

Message:
Logged In: YES 
user_id=60903

build log attached. please tell me if you need an account on
a Debian machine (doko   debian org).
configure \
        --with-gcc=gcc-3.1 \
        --with-cxx=g++-3.1 \
        --prefix=/usr \
        --with-fpectl \
        --enable-ipv6


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-08-03 10:12

Message:
Logged In: YES 
user_id=6656

Really?  Nuts.  They're not on my machine.

What arguments are you passing to configure?

----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2002-08-02 16:48

Message:
Logged In: YES 
user_id=60903

Thanks for the fix, however when building shared modules,
-I/usr/include and -L/usr/lib are still passed to the compiler.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-02 09:05

Message:
Logged In: YES 
user_id=21627

And indeed, we should not remove /usr/local/include, since
the system compiler may not be gcc.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-08-02 08:56

Message:
Logged In: YES 
user_id=6656

OK, done, in

setup.py revision 1.100

I don't see us removing /usr/local/include from the command
line.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-02 08:49

Message:
Logged In: YES 
user_id=21627

The patch looks fine to me, please apply it.

I still think that the bogus warning should be removed from
gcc entirely.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-08-02 07:54

Message:
Logged In: YES 
user_id=6656

OK, can you try the attached patch?

Martin, does this look OK to you?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-08-02 03:53

Message:
Logged In: YES 
user_id=6656

Ah, sorry!

Hmm.  Now I don't see the problem, i.e. for me
-I/usr/include is not part of the command line passed to the
compiler.

Are you building from up-to-date CVS?  Though I don't recall
any recent changes in this area.  Ahh, you're running
".../configure --prefix=/usr", right?

I'll dig.

----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2002-08-01 15:23

Message:
Logged In: YES 
user_id=60903

I disagree. The discussion is on /usr/local/include. We are 
talking about /usr/include, which is a system include dir on 
almost all systems.

See the thread "gcc 3.2's cpp breaks configure scripts" at 
http://gcc.gnu.org/ml/gcc/2002-07/, i.e.:

http://gcc.gnu.org/ml/gcc/2002-07/msg01527.html

Inclusion of /usr/include can lead to errors, as explained in:
http://gcc.gnu.org/ml/gcc/2002-07/msg01541.html

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-08-01 04:08

Message:
Logged In: YES 
user_id=6656

This has been deemed a bug in gcc, see this thread:

http://mail.python.org/pipermail/python-dev/2002-June/025990.html

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=589427&group_id=5470


From noreply@sourceforge.net  Wed Aug 14 04:15:35 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 13 Aug 2002 20:15:35 -0700
Subject: [Python-bugs-list] [ python-Bugs-411881 ] Use of "except:" in modules
Message-ID: <E17eodD-0000QV-00@usw-sf-web1.sourceforge.net>

Bugs item #411881, was opened at 2001-03-28 06:58
You can respond by visiting: 
https://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: Skip Montanaro (montanaro)
>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: 2002-08-13 22:15

Message:
Logged In: YES 
user_id=44345

checked in fileinput.py (v 1.15) with three except:'s tightened up.  The 
comment in the code about IOError notwithstanding, I don't see how any 
of the three situations would have caught anything other than OSError.


----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-08-12 14:58

Message:
Logged In: YES 
user_id=44345

Note that this particular item was expected to be an ongoing item, with 
no obvious closure.   Some of the bare excepts will have subtle 
ramifications, and it's not always obvious what specific exceptions 
should be caught.  I've made a few changes to my local source tree 
which I should check in.

Rather than opening new tracker items, I believe those with checkin 
privileges should correct those flaws they identify and attach a comment 
which will alert those monitoring the item.  Those people without checkin 
privileges should just attach a patch with a note.

Skip


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-12 02:22

Message:
Logged In: YES 
user_id=21627

My proposal would be to track this under a different issue:
Terry, if you volunteer, please produce a new list of
offenders (perhaps in an attachment to the report so it can
be updated), and attach any fixes that you have to that report.

People with CVS write access can then apply those patches
and delete them from the report.

If you do so, please post the new issue number in this
report, so we have a link.

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2002-08-11 13:16

Message:
Logged In: YES 
user_id=593130

Remove types.py from the list.  As distributed with 2.2.1, it 
has 5 'except xxxError:' statements but no offending bare 
except:'s.

Skip (or anyone else): if/when you pursue this, I volunteer 
to do occasional sleuthing and send reports with 
suggestions and/or questions.  Example: getpass.py has 
one 'offense':
   try:
        fd = sys.stdin.fileno()
    except:
        return default_getpass(prompt)
According to lib doc 2.2.8 File Objects (as I interpret) fileno
() should either work without exception or *not* be 
implemented. Suggestion: insert AttributeError .  Question: 
do we protect against pseudofile objects that ignore doc 
and have fake .fileno() that raises NotImplementedError or 
whatever?


----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-03-23 00:02

Message:
Logged In: YES 
user_id=44345

as partial fix, checked in changes for the following
modules:

  mimetools.py (1.24)
  popen2.py (1.23)
  quopripy (1.19)
  CGIHTTPServer.py (1.22)


----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-03-20 15:24

Message:
Logged In: YES 
user_id=44345

Here is a context diff with proposed changes for the
following modules: CGIHTTPServer, cgi, cmd, code, 
fileinput, httplib, inspect, locale, mimetools, popen2,
quopri


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-08-11 10:06

Message:
Logged In: YES 
user_id=21627

Fixed urllib in 1.131 and types in 1.19.


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-07-04 02:11

Message:
Logged In: YES 
user_id=3066

Fixed modules mhlib and rfc822 (SF is having a problem
generating the checkin emails, though).

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-05-11 14:40

Message:
Logged In: YES 
user_id=3066

OK, I've fixed up a few more modules:

anydbm
chunk
formatter
htmllib
mailcap
pre
pty

I made one change to asyncore as well, but other bare except
clauses remain there; I'm not sufficiently familiar with
that code to just go digging into those.

I also fixed an infraction in pstats, but left others for now.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-04-23 03: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 02: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 09: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 04: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 10: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 12: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 12: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 12: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 10: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 04: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-30 00: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: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=411881&group_id=5470


From noreply@sourceforge.net  Wed Aug 14 05:59:58 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 13 Aug 2002 21:59:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-594893 ] printing email object deletes whitespace
Message-ID: <E17eqGE-0001xP-00@usw-sf-web1.sourceforge.net>

Bugs item #594893, was opened at 2002-08-13 23:59
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594893&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: printing email object deletes whitespace

Initial Comment:
I certain situations when printing email Message objects (I think), 
whitespace in headers disappears.  The attached zip file 
demonstrates this problem.  In email.orig, there is a line break 
followed by a TAB in the X-Vm-v5-Data header at the end of the 
first continuation line.  In email.new, which was generated by 
printing an email.Message object, the line break and TAB are gone, 
but no SPACE was inserted in their place.

This example is from a larger program which reads in a Unix 
mailbox like so:

    msgdict = {}
    i = 0
    for msg in mailbox.PortableUnixMailbox(f,
                                 email.Parser.Parser().parse):
        subj = msg["subject"]
        item = msgdict.get(subj) or []
        item.append((i, msg))
        msgdict[subj] = item
        i += 1

runs through msgdict and deletes a bunch of messages matching 
various criteria, then prints out those which remain retaining the 
relative order they had in the original mailbox:

    msglist = []
    for val in msgdict.values():
        msglist.extend(val)
    msglist.sort()
    for i,msg in msglist:
        print msg

email.orig was plucked from the input mailbox and email.new from 
the output mailbox.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594893&group_id=5470


From noreply@sourceforge.net  Wed Aug 14 07:56:17 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 13 Aug 2002 23:56:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-545600 ] IDLE doesn't save 8bit files
Message-ID: <E17es4n-0005m2-00@usw-sf-web2.sourceforge.net>

Bugs item #545600, was opened at 2002-04-18 13:28
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=545600&group_id=5470

Category: IDLE
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexandre Fayolle (afayolle)
Assigned to: Nobody/Anonymous (nobody)
Summary: IDLE doesn't save 8bit files

Initial Comment:
This bug seems to be related to #527022. 

Short version is: IDLE won't save files containing 8bit
characters (for instance in comments or in litteral
strings). No error dialog is displayed, only a
traceback on stderr or in the interactive window if
it's available:

Exception in Tkinter callback
Traceback (most recent call last):
  File "/usr/lib/python2.1/lib-tk/Tkinter.py", line
1285, in __call__
    return apply(self.func, args)
  File "/usr/lib/idle-python2.1/IOBinding.py", line
126, in save
    self.save_as(event)
  File "/usr/lib/idle-python2.1/IOBinding.py", line
136, in save_as
    if self.writefile(filename):
  File "/usr/lib/idle-python2.1/IOBinding.py", line
154, in writefile
    f.write(chars)
UnicodeError: ASCII encoding error: ordinal not in
range(128)

Possible solution:

 * at least warn the user that the file could not be
saved with an error dialog
 * try using the locale to guess the encoding and do
appropriate conversions
 * ask the user wich encoding should be used to save
the file

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-08-14 08:56

Message:
Logged In: YES 
user_id=21627

Please try CVS IDLE. It corrects these problems.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-08-14 00:21

Message:
Logged In: NO 

Also, the file gets destroyed - truncated to 0 bytes, after 
such unsucessful save.

----------------------------------------------------------------------

Comment By: Alexandre Fayolle (afayolle)
Date: 2002-04-19 11:30

Message:
Logged In: YES 
user_id=116727

I like the solution proposed in the reference.

However, having just a traceback printed on the console
looks like a bug to me. I expect IDLE to complain loudly in
case it cannot save my file. If it could give me a hint as
to what to add to the file to be able to save it, that'd be
even better. 

Cheers 

Alexandre 

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-04-19 10:23

Message:
Logged In: YES 
user_id=21627

In this form, this is not a bug. IDLE cannot know what
encoding you want to use the file.

Under PEP 263, you will need to declare the encoding inside
the file; then IDLE will use the declared encoding. See

http://sourceforge.net/tracker/index.php?func=detail&aid=508973&group_id=9579&atid=309579

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=545600&group_id=5470


From noreply@sourceforge.net  Wed Aug 14 07:57:33 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 13 Aug 2002 23:57:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-545600 ] IDLE doesn't save 8bit files
Message-ID: <E17es61-0005n0-00@usw-sf-web2.sourceforge.net>

Bugs item #545600, was opened at 2002-04-18 13:28
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=545600&group_id=5470

Category: IDLE
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexandre Fayolle (afayolle)
>Assigned to: Martin v. Löwis (loewis)
Summary: IDLE doesn't save 8bit files

Initial Comment:
This bug seems to be related to #527022. 

Short version is: IDLE won't save files containing 8bit
characters (for instance in comments or in litteral
strings). No error dialog is displayed, only a
traceback on stderr or in the interactive window if
it's available:

Exception in Tkinter callback
Traceback (most recent call last):
  File "/usr/lib/python2.1/lib-tk/Tkinter.py", line
1285, in __call__
    return apply(self.func, args)
  File "/usr/lib/idle-python2.1/IOBinding.py", line
126, in save
    self.save_as(event)
  File "/usr/lib/idle-python2.1/IOBinding.py", line
136, in save_as
    if self.writefile(filename):
  File "/usr/lib/idle-python2.1/IOBinding.py", line
154, in writefile
    f.write(chars)
UnicodeError: ASCII encoding error: ordinal not in
range(128)

Possible solution:

 * at least warn the user that the file could not be
saved with an error dialog
 * try using the locale to guess the encoding and do
appropriate conversions
 * ask the user wich encoding should be used to save
the file

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-14 08:56

Message:
Logged In: YES 
user_id=21627

Please try CVS IDLE. It corrects these problems.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-08-14 00:21

Message:
Logged In: NO 

Also, the file gets destroyed - truncated to 0 bytes, after 
such unsucessful save.

----------------------------------------------------------------------

Comment By: Alexandre Fayolle (afayolle)
Date: 2002-04-19 11:30

Message:
Logged In: YES 
user_id=116727

I like the solution proposed in the reference.

However, having just a traceback printed on the console
looks like a bug to me. I expect IDLE to complain loudly in
case it cannot save my file. If it could give me a hint as
to what to add to the file to be able to save it, that'd be
even better. 

Cheers 

Alexandre 

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-04-19 10:23

Message:
Logged In: YES 
user_id=21627

In this form, this is not a bug. IDLE cannot know what
encoding you want to use the file.

Under PEP 263, you will need to declare the encoding inside
the file; then IDLE will use the declared encoding. See

http://sourceforge.net/tracker/index.php?func=detail&aid=508973&group_id=9579&atid=309579

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=545600&group_id=5470


From noreply@sourceforge.net  Wed Aug 14 09:00:05 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 14 Aug 2002 01:00:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-502503 ] pickle interns strings
Message-ID: <E17et4X-0005QD-00@usw-sf-web1.sourceforge.net>

Bugs item #502503, was opened at 2002-01-11 22:21
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=502503&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Brian Kelley (wc2so1)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: pickle interns strings

Initial Comment:
Pickle (and cPickle) use eval to reconstruct string
variables from the stored format.  Eval is used because
it correctly reconstructs the repr of a string back
into the original string object by translating all the
appropriately escape characters like "\m" and "\n"

There is an side effect in that eval interns string
variables for faster lookup.

This causes the following sample code to unexpectedly
grow in memory consumption:

import pickle
import random
import string

def genstring(length=100):
    s = [random.choice(string.letters) for x in
range(length)]
    return "".join(s)

def test():
    while 1:
        s = genstring()
        dump = pickle.dumps(s)
        s2 = pickle.loads(dump)
        assert s == s2

test()

Note that all strings are not interned, just ones that,
as Tim Peters once said, "look like", variable names. 
The above example is contrived to generate a lot of
different names that "look like" variables names but
since this has happened in practice it probably should
documented.

Interestingly, by inserting
 s.append(" ")
before
 return "".join(s)

The memory consumption is not seen because the names no
longer "look like" variable names.


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-08-14 10:00

Message:
Logged In: YES 
user_id=21627

This is fixed with patch 505705.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-24 03:03

Message:
Logged In: YES 
user_id=35752

See patch 505705 for a slightly different solution.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-23 22:21

Message:
Logged In: YES 
user_id=35752

Attached is a first stab at documentation.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 21:27

Message:
Logged In: YES 
user_id=35752

Okay, I moved unquote to a method of str.  I also fixed
pickle.py and the tests (no need to test for insecure
strings).

Fred, do you have to time to write documentation for 
_PyString_Unquote and str.unquote?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-22 20:12

Message:
Logged In: YES 
user_id=31435

I haven't tried the patch, but yes, it looks sane to me.  A 
deprecated module is definitely a poor place to add a new 
feature <wink>; it makes as much sense as a string method 
as, say, .upper(), right?  That is, why not?  String in, 
string out.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 19:35

Message:
Logged In: YES 
user_id=35752

Attached is a patch that implements _PyString_Unquote
and strop.unquote.  strop is probably the wrong place since
it's deprecated but I'm not sure if unquote as a string method
is right either.  cPickle.c is changed to use
_PyString_Unquote instead of calling eval.  pickle.py
still needs to be fixed, documentation added, tests fixed.
Before all that, does this patch look sane?

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2002-02-16 02:26

Message:
Logged In: YES 
user_id=72053

I agree about eval being dangerous.  Also, the memory leak
is itself a security concern: if an attacker can stuff
enough strings into the unpickler to exhaust memory, that's
a denial of service attack.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-01-11 22:36

Message:
Logged In: YES 
user_id=31435

Noting that Security Geeks are uncomfortable with using eval
() for this purpose regardless.  Would be good if Python 
got refactored so that pickle and cPickle and the front end 
all called a new routine that simply parsed the escape 
sequences in a character buffer, returning a Python string 
object.

Don't ask me about Unicode <wink>.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=502503&group_id=5470


From noreply@sourceforge.net  Wed Aug 14 09:23:23 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 14 Aug 2002 01:23:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-593656 ] pickle/cPickle incompatibility
Message-ID: <E17etR5-0004jU-00@usw-sf-web3.sourceforge.net>

Bugs item #593656, was opened at 2002-08-11 15:50
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=593656&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: atsuo ishimoto (ishimoto)
Assigned to: Nobody/Anonymous (nobody)
Summary: pickle/cPickle incompatibility

Initial Comment:
In the following case, I found pickle doesn't detect 
insecure string
whereas cPickle does.

>>> import pickle, cPickle
>>> pickle.loads("S'\x5c'\np0\n.")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.1/pickle.py", line 
951, in loads
    return Unpickler(file).load()
  File "/usr/local/lib/python2.1/pickle.py", line 
567, in load
    dispatch[key](self)
  File "/usr/local/lib/python2.1/pickle.py", line 
635, in load_string
    {'__builtins__': {}})) # Let's be careful
  File "<string>", line 1
    '\'
     ^
SyntaxError: invalid token
>>> cPickle.loads("S'\x5c'\np0\n.")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ValueError: insecure string pickle
>>>


This is because pickle.Unpickler._is_string_secure() 
return 1 if string
contains one or more quote characters, whether 
they are escaped or not.


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-08-14 10:23

Message:
Logged In: YES 
user_id=21627

This is fixed with

stringobject.c 2.178;
pickletester.py 1.19;

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-11 16:10

Message:
Logged In: YES 
user_id=6380

I assume patch #505705 will fix this too.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=593656&group_id=5470


From noreply@sourceforge.net  Wed Aug 14 09:32:45 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 14 Aug 2002 01:32:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-594959 ] Reference count error (new class object)
Message-ID: <E17eta9-0007ZK-00@usw-sf-web2.sourceforge.net>

Bugs item #594959, was opened at 2002-08-14 08:32
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594959&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Henric Ericsson (henric_ericsson)
Assigned to: Nobody/Anonymous (nobody)
Summary: Reference count error (new class object)

Initial Comment:
When sorting a list of new class objects
that has a __cmp__() method the reference counters
are incremented.

Example code:
--------------------------
import sys

class Test2(object):
    def __init__(self, nr):
        self.nr = nr

    def __cmp__(self, other):
        return self.nr - other.nr

l = map(Test2, range(10))
print map(sys.getrefcount, l)
l.sort()
print map(sys.getrefcount, l)
--------------------------
Output:
--------------------------
[2, 2, 2, 2, 2, 2, 2, 2, 2, 2]
[2, 3, 3, 3, 3, 3, 3, 3, 3, 3]
--------------------------

I'm attaching another test prgram.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594959&group_id=5470


From noreply@sourceforge.net  Wed Aug 14 10:18:14 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 14 Aug 2002 02:18:14 -0700
Subject: [Python-bugs-list] [ python-Bugs-594959 ] Reference count error (new class object)
Message-ID: <E17euIA-0008VH-00@usw-sf-web2.sourceforge.net>

Bugs item #594959, was opened at 2002-08-14 08:32
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594959&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Henric Ericsson (henric_ericsson)
>Assigned to: Michael Hudson (mwh)
Summary: Reference count error (new class object)

Initial Comment:
When sorting a list of new class objects
that has a __cmp__() method the reference counters
are incremented.

Example code:
--------------------------
import sys

class Test2(object):
    def __init__(self, nr):
        self.nr = nr

    def __cmp__(self, other):
        return self.nr - other.nr

l = map(Test2, range(10))
print map(sys.getrefcount, l)
l.sort()
print map(sys.getrefcount, l)
--------------------------
Output:
--------------------------
[2, 2, 2, 2, 2, 2, 2, 2, 2, 2]
[2, 3, 3, 3, 3, 3, 3, 3, 3, 3]
--------------------------

I'm attaching another test prgram.


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-08-14 09:18

Message:
Logged In: YES 
user_id=6656

This seems to have been fixed, both on the trunk and the
22-maint branch.

No idea which checkin fixed it, I'd have to admit...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594959&group_id=5470


From noreply@sourceforge.net  Wed Aug 14 11:46:56 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 14 Aug 2002 03:46:56 -0700
Subject: [Python-bugs-list] [ python-Bugs-594996 ] OverflowError in random.randrange
Message-ID: <E17evg0-0007AK-00@usw-sf-web4.sourceforge.net>

Bugs item #594996, was opened at 2002-08-14 05:46
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594996&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Shannon Jones (sjones)
Assigned to: Nobody/Anonymous (nobody)
Summary: OverflowError in random.randrange

Initial Comment:
The following code can produce an OverflowError in
random.randrange.

import random
from sys import maxint
minint = -maxint - 1

random.randrange(minint, maxint)

You may need to execute the last line a few times to
get the error because it depends on the random number
generated. The traceback is on line 315 of random.py
and is OverflowError: float too large to convert.

Changing line 315 from:
return istart + int(self.random() * (istop - istart))
to:
return int(istart + self.random() * (istop - istart))

seems to fix the problem.

-----
I'm using Python 2.3 from CVS on RH 7.3


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594996&group_id=5470


From noreply@sourceforge.net  Wed Aug 14 11:53:49 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 14 Aug 2002 03:53:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-594998 ] test_nis test fails on TRU64 5.1
Message-ID: <E17evmf-00024A-00@usw-sf-web2.sourceforge.net>

Bugs item #594998, was opened at 2002-08-14 10:53
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594998&group_id=5470

Category: Build
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Patrick Finnerty (finnertyp)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_nis test fails on TRU64 5.1

Initial Comment:
Platform: TRU64 v5.1a

Ran configure with --with-dec-threads options. 
Also used --without-gcc although this has no impact on
test failure.

The ouput from ./python ./Lib/test/test_nis.py is large
so I've included it in an attached file rather than
pasted here.

The machine that Python is being built on is a NIS
server as well as client.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594998&group_id=5470


From noreply@sourceforge.net  Wed Aug 14 12:41:26 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 14 Aug 2002 04:41:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-595018 ] inspect.getsource shows incorrect output
Message-ID: <E17ewWk-0001fU-00@usw-sf-web1.sourceforge.net>

Bugs item #595018, was opened at 2002-08-14 13:41
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595018&group_id=5470

Category: Python Library
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregor Lingl (glingl)
Assigned to: Nobody/Anonymous (nobody)
Summary: inspect.getsource shows incorrect output

Initial Comment:
example:
>>> from turtle import *
>>> from inspect import *
>>> print getsource(up)
def up(): _getpen().up()
def down(): _getpen().down()
def width(width): _getpen().width(width)
def color(*args): apply(_getpen().color, args)
def write(arg, move=0): _getpen().write(arg, move)
def fill(flag): _getpen().fill(flag)
def circle(radius, extent=None):
_getpen().circle(radius, extent)
def goto(*args): apply(_getpen().goto, args)

def demo():
    reset()
    tracer(1)
# etc ...

changing the form of the definition of up in turtle to:

def up(): 
     _getpen().up()

results in:

>>> print getsource(up)
def up():
     _getpen().up()

>>> 

So the error probably occurs when parsing the
sourcefile if functiondefinition is a oneliner ...

Regards
Gregor Lingl


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595018&group_id=5470


From noreply@sourceforge.net  Wed Aug 14 13:26:55 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 14 Aug 2002 05:26:55 -0700
Subject: [Python-bugs-list] [ python-Bugs-595026 ] Support for masks in getargs.c
Message-ID: <E17exEl-0000h6-00@usw-sf-web4.sourceforge.net>

Bugs item #595026, was opened at 2002-08-14 08:26
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595026&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Support for masks in getargs.c

Initial Comment:
We need this implemented:

> How about the following counterproposal.  This also
changes some of
> the other format codes to be a little more regular.
>
> Code    C type          	Range check
>
> b	unsigned char		0..UCHAR_MAX
> B	unsigned char		none **
> h	unsigned short		0..USHRT_MAX
> H	unsigned short		none **
> i	int
		INT_MIN..INT_MAX
> I *	unsigned int		0..UINT_MAX
> l	long
		LONG_MIN..LONG_MAX
> k *	unsigned long		none
> L	long long		LLONG_MIN..LLONG_MAX
> K *	unsigned long long	none
>
> Notes:
>
> * New format codes.
>
> ** Changed from previous "range-and-a-half" to
"none"; the
>    range-and-a-half checking wasn't particularly useful.

Plus a C API or two, e.g. PyInt_AsLongMask() ->
unsigned long and PyInt_AsLongLongMask() -> unsigned
long long (if that exists).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595026&group_id=5470


From noreply@sourceforge.net  Wed Aug 14 13:43:51 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 14 Aug 2002 05:43:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-595032 ] Tutorial: Section 9.6 - error in example
Message-ID: <E17exV9-00047h-00@usw-sf-web2.sourceforge.net>

Bugs item #595032, was opened at 2002-08-14 13:43
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595032&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nathan Dimmock (ned21)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Tutorial: Section 9.6 - error in example

Initial Comment:
I couldn't get the following code from the tutorial
(section 9.6) to work. My local guru says the problem
is in the third line and probably used to work in a
previous version of python. (I'm using 2.2.1 on
RH-Linux 2.4.18)

# example code
class VirtualAttributes:
    __vdict = None
    __vdict_name = locals().keys()[0] # BROKEN
     
    def __init__(self):
        self.__dict__[self.__vdict_name] = {}
    
    def __getattr__(self, name):
        return self.__vdict[name]
    
    def __setattr__(self, name, value):
        self.__vdict[name] = value

# test code (added by user)
db = VirtualAttributes() # create an empty database
db.x = 1
print db.x

Trace:
Traceback (most recent call last):
  File "./classTest.py", line 19, in ?
    db.x = 1
  File "./classTest.py", line 16, in __setattr__
    self.__vdict[name] = value
TypeError: object does not support item assignment


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595032&group_id=5470


From noreply@sourceforge.net  Wed Aug 14 16:28:38 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 14 Aug 2002 08:28:38 -0700
Subject: [Python-bugs-list] [ python-Bugs-595032 ] Tutorial: Section 9.6 - error in example
Message-ID: <E17f04c-0004Di-00@usw-sf-web5.sourceforge.net>

Bugs item #595032, was opened at 2002-08-14 08:43
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595032&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nathan Dimmock (ned21)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Tutorial: Section 9.6 - error in example

Initial Comment:
I couldn't get the following code from the tutorial
(section 9.6) to work. My local guru says the problem
is in the third line and probably used to work in a
previous version of python. (I'm using 2.2.1 on
RH-Linux 2.4.18)

# example code
class VirtualAttributes:
    __vdict = None
    __vdict_name = locals().keys()[0] # BROKEN
     
    def __init__(self):
        self.__dict__[self.__vdict_name] = {}
    
    def __getattr__(self, name):
        return self.__vdict[name]
    
    def __setattr__(self, name, value):
        self.__vdict[name] = value

# test code (added by user)
db = VirtualAttributes() # create an empty database
db.x = 1
print db.x

Trace:
Traceback (most recent call last):
  File "./classTest.py", line 19, in ?
    db.x = 1
  File "./classTest.py", line 16, in __setattr__
    self.__vdict[name] = value
TypeError: object does not support item assignment


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-08-14 11:28

Message:
Logged In: YES 
user_id=3066

I've removed the obsolete example from Doc/tut/tut.tex 1.169
and 1.156.4.1.2.9.

The rules for private names were introduced well before
Python 2.0, and it is not reasonable for the tutorial to
cater to versions that old.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595032&group_id=5470


From noreply@sourceforge.net  Wed Aug 14 17:02:39 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 14 Aug 2002 09:02:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-595105 ] AESend on Jaguar
Message-ID: <E17f0bX-0007Gz-00@usw-sf-web1.sourceforge.net>

Bugs item #595105, was opened at 2002-08-14 09:02
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595105&group_id=5470

Category: Macintosh
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexandre Parenteau (aubonbeurre)
Assigned to: Jack Jansen (jackjansen)
Summary: AESend on Jaguar

Initial Comment:
I wonder how many of you guys played with Jaguar 
(OSX 10.2). It is also my
first glance at gcc 3.1 that comes with 10.2. Everything 
was fine for
building Python, except for waste which has an 
obsolete libWaste.a (even in
August 1st Waste 2.1b1) which won't compile with 
gcc3.1. After I recompiled
waste with CodeWarrior 8.2 (MPTP: early access), it 
came OK.

I then run into some problems of checked out files 
because I'm using MacCvs
(see earlier message). I used the 'make 
frameworkinstall' scheme.

Now I'm experiencing the nice new architecture. I 
mostly use python from the
command line to invoke CodeWarrior thru AppleScripts, 
so I almost immeditly
run into a hanging problems of python :

        _err = AESend(&_self->ob_itself,
                      &reply,
                      sendMode,
                      sendPriority,
                      timeOutInTicks,
                      0L/*upp_AEIdleProc*/,
                      (AEFilterUPP)0);

I had to comment out upp_AEIdleProc (I tried several 
things, but that is the
only thing which helped). Jack, you might want to 
remember this one if the
problem is still in Jaguar. It hangs and finally times out. 
I've looked
inside this function and I can see the signal handling, 
but I'm not sure
what it is for.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595105&group_id=5470


From noreply@sourceforge.net  Wed Aug 14 17:59:14 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 14 Aug 2002 09:59:14 -0700
Subject: [Python-bugs-list] [ python-Bugs-594996 ] OverflowError in random.randrange
Message-ID: <E17f1UI-00065C-00@usw-sf-web4.sourceforge.net>

Bugs item #594996, was opened at 2002-08-14 06:46
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594996&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Shannon Jones (sjones)
>Assigned to: Tim Peters (tim_one)
Summary: OverflowError in random.randrange

Initial Comment:
The following code can produce an OverflowError in
random.randrange.

import random
from sys import maxint
minint = -maxint - 1

random.randrange(minint, maxint)

You may need to execute the last line a few times to
get the error because it depends on the random number
generated. The traceback is on line 315 of random.py
and is OverflowError: float too large to convert.

Changing line 315 from:
return istart + int(self.random() * (istop - istart))
to:
return int(istart + self.random() * (istop - istart))

seems to fix the problem.

-----
I'm using Python 2.3 from CVS on RH 7.3


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-08-14 12:59

Message:
Logged In: YES 
user_id=31435

The suggested change stops OverflowError but delivers 
incorrect results; for example, try randrange(-2, 0) repeatedly, 
and you'll find it delivers one of {-2, -1} before the change, but 
one of {-1, 0} after the change.  Using int(math.floor(...)) 
instead would restore correct behavior, but I'm loathe to slow 
this high-usage function.  In the absence of an idea that's 
both correct and fast, I'll close this as WontFix -- speed is 
more important here than pushing the limit on the overall 
range by 1 bit.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594996&group_id=5470


From noreply@sourceforge.net  Wed Aug 14 18:15:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 14 Aug 2002 10:15:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-586926 ] Empty genindex.html pages
Message-ID: <E17f1jz-00073y-00@usw-sf-web5.sourceforge.net>

Bugs item #586926, was opened at 2002-07-26 06:25
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=586926&group_id=5470

Category: Documentation
Group: Python 2.3
>Status: Pending
Resolution: Invalid
Priority: 6
Submitted By: Matthias Klose (doko)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Empty genindex.html pages

Initial Comment:
When building the html docs, empty index pages are 
generated.

$ ls -l html/*/genindex.html
-rw-r--r--    1 doko     doko         3341 Jul 26 11:53 
html/api/genindex.html
-rw-r--r--    1 doko     doko         3433 Jul 26 11:59 
html/lib/genindex.html
-rw-r--r--    1 doko     doko         3436 Jul 26 12:00 
html/mac/genindex.html
-rw-r--r--    1 doko     doko         3322 Jul 26 12:00 
html/ref/genindex.html

compared to 2.1.3, built with texinfo-4.1:

$ ls -l html/*/genindex.html
-rw-r--r--    1 doko     doko        51726 Jul 26 11:42 
html/api/genindex.html
-rw-r--r--    1 doko     doko       310251 Jul 26 11:47 
html/lib/genindex.html
-rw-r--r--    1 doko     doko        28449 Jul 26 11:48 
html/mac/genindex.html
-rw-r--r--    1 doko     doko        73766 Jul 26 11:48 
html/ref/genindex.html

building the 2.1.3 docs with texinfo-4.2 fails as well. For 
2.2.1 and current CVS the empty files are generated 
independent of the texinfo version.

An account on a build environment can be provided 
(Debian 3.0).

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-08-14 13:15

Message:
Logged In: YES 
user_id=3066

Please provide a detailed list of steps you took from a
clean checkout.  If you can provide a typescript (using the
"script" command at your shell), I'd appreciate it.  Version
numbers for LaTeX2HTML, the installed version of Python, and
Perl would be helpful.

----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2002-08-10 02:12

Message:
Logged In: YES 
user_id=60903

Just rechecked. The problem is still there (trying to
generate the documentation for today's CVS).


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-08-09 17:28

Message:
Logged In: YES 
user_id=3066

This problem appears to have disappeared in the development
versions of the documentation at some point since the report
was filed.

If you see this only on documentation you generate rather
than the standarad documentation from python.org, please let
me know.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=586926&group_id=5470


From noreply@sourceforge.net  Wed Aug 14 20:34:06 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 14 Aug 2002 12:34:06 -0700
Subject: [Python-bugs-list] [ python-Bugs-595217 ] asynchat problems multi-threaded
Message-ID: <E17f3uA-0001sh-00@usw-sf-web5.sourceforge.net>

Bugs item #595217, was opened at 2002-08-14 19:34
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595217&group_id=5470

Category: Python Library
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Dieter Maurer (dmaurer)
Assigned to: Nobody/Anonymous (nobody)
Summary: asynchat problems multi-threaded

Initial Comment:
asynchat.async_chat.push has two problems when
used in an application where the pusher and the
main loop are run by different threads.

1.  A "push" does not wake up the main loop. This may 
result in long delays (the loop, by default, uses a timeout 
of 30 s). The work around is an explicit wakeup on the 
loop. I do not have a solution for Windows (more 
generally an OS where select does not work for pipes).
When select does work for pipes, a simple "wakeup"
can be implemented by writing to a pipe the main loop
is waiting for.

2. The "self.initiate_send" can lead to two identical
sends (which should be only one!) under the condition
above. Workaround is to remove the call. 


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595217&group_id=5470


From noreply@sourceforge.net  Thu Aug 15 01:01:34 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 14 Aug 2002 17:01:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-216289 ] Programs using Tkinter sometimes can't shut down (Windows)
Message-ID: <E17f850-0007i5-00@usw-sf-web3.sourceforge.net>

Bugs item #216289, was opened at 2000-10-06 19:25
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=216289&group_id=5470

Category: Windows
Group: Python 2.3
Status: Open
Resolution: Later
Priority: 3
Submitted By: Tim Peters (tim_one)
Assigned to: Fredrik Lundh (effbot)
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: David Gravereaux (davygrvy)
Date: 2002-08-14 17:01

Message:
Logged In: YES 
user_id=7549

To johnnypops,

Where in Tcl_FinalizeNotifier() is the dead-lock occuring and 
is this with a threaded build of Tcl?


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-07-02 12:39

Message:
Logged In: YES 
user_id=31435

Jeff, a long time ago Fredrik Lundh said he was able to 
reproduce this with a short wish script (no Python, no Tkinter, 
just Tcl/Tk + wish).  I'm reassigning this to /F in the hopes 
he'll remember how.

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-07-02 11:55

Message:
Logged In: YES 
user_id=72656

I appreciate that many others see this is a problem in 
embedding Tcl, but without any clear way to reproduce this in 
Tcl/Tk itself, it's very hard for me to fix it.  I don't think that 
there is anything done in 8.4 to fix this that I recall, but if 
someone finds that the problem "goes away" with 8.4, please 
report that.

For those of course that experience this with python, the 
simple and "correct" work-around is to launch with 
pythonw.exe instead of python.exe.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-06-26 10:40

Message:
Logged In: NO 

According to http://tcl.activestate.com ActiveTcl 8.4.0 is now 
available for download.  It is new as of June 24.  I don't know 
whether this will solve our problems or not, but it's worth 
looking into.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-06-19 06:36

Message:
Logged In: NO 

I just downloaded Ruby 1.6.6 for Windows, which also uses 
Tcl/Tk 8.3 and I experience exactly the same problem there. 
So this is definitely a Tcl problem (but we know that already).

----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-06-07 12:01

Message:
Logged In: YES 
user_id=143340

Hmmm. 
I run a Python Tcl/Tk application several times every day - 
the very application that prompted my bug-hunt.

I do use "pythonw.exe" to launch it, but it used to hang 
almost as badly as "python.exe".

Whilst developing this app I used "python.exe" and 
experienced no hang-ups.

The Tcl guys point out that this bug is only one of several 
possible causes of the hang-up, maybe you are just out of 
luck.

The patch has fixed the problem on three Win98 machines, 
all of which exhibited the problem before updating the DLLs.

One thought - are you sure there weren't multiple copies of 
the tcl83.dll and tk83.dll files? My (only) copies were 
in "D:\python20\DLLs"

good luck,
John.


----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-06-03 11:55

Message:
Logged In: YES 
user_id=72656

providing Tim with a fixed DLL exactly according to John 
Popplewell's patch did not fix the problem for him.  That 
makes it seem fishy that John really didn't see the problem 
any more.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-03 09:59

Message:
Logged In: YES 
user_id=31435

I tried replacing Python 2.2.1's tk83.dll and tcl83.dll (from 
Tcl/Tk 8.3.2) with newer matched sets from

A) PythonWare's py21 distribution (Tcl/Tk 8.3.3).

and again from

B) ActiveState's Tcl/Tk 8.3.4.

All the symptoms originally reported here persisted on 
Win98SE despite that.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-05-22 06:57

Message:
Logged In: NO 

I am new to Python and encountered this bug on my very first 
Tkinter application.  It persists in Python 2.2.1 under 
Windows Me. Needless to say, it makes a bad first 
impression.  Basically, this thread says that Tkinter has been 
broken for a year and a half on a popular platform at a time 
when Python is trying to expand its user base.  Hopefully, this 
bug will be corrected soon.

If Tcl/Tk 8.4 is not released shortly you might try repackaging 
Tkinter for Win32 with an earlier version of Tcl/Tk, such as 
8.0, that doesn't encounter this problem.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 19:36

Message:
Logged In: YES 
user_id=6380

The proper action is to wait until Tcl 8.3.5 is released,
and then shaming someone else in providing you with a set of
Windowsbinaries for Tcl. You may also ask Hobbs if there's a
Windows project file to build Tcl/Tk for Windows.

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-03-11 18:31

Message:
Logged In: YES 
user_id=72656

I did end up back-porting this to the 8.3.4+ Tcl CVS on 
2002-02-25, which means it will be in an eventual 8.3.5.  
It is already in the release 8.4 alpha series.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-09 17:50

Message:
Logged In: YES 
user_id=31435

Back to Guido:  Do you think you know what the proper 
action is?  (You said that's why you reopened it, and 
there's been no new info here since then.)

----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-02-25 16:55

Message:
Logged In: YES 
user_id=143340

I knew I wasn't getting to the heart of it ....

Almost a one-liner!

It has been seriously spoiling my (otherwise crash free) 
Python experience on Win9x - hope it gets fixed soon.

cheers,
John.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-02-25 15:39

Message:
Logged In: YES 
user_id=6380

Reopened until we know what the proper action is.

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-02-25 15:32

Message:
Logged In: YES 
user_id=72656

This is mostly correct, and is fixed in the 8.4 Tcl sources 
already (I guess we can backport this).  This was mentioned 
in SF Tcl bug (account for chopped URL):

https://sourceforge.net/tracker/?
func=detail&aid=217982&group_id=10894&atid=110894

and the code comment is:

    /*
     * Only finalize the notifier if a notifier was 
installed in the
     * current thread; there is a route in which this is not
     * guaranteed to be true (when tclWin32Dll.c:DllMain() 
is called
     * with the flag DLL_PROCESS_DETACH by the OS, which 
could be
     * doing so from a thread that's never previously been 
involved
     * with Tcl, e.g. the task manager) so this check is 
important.
     *
     * Fixes Bug #217982 reported by Hugh Vu and Gene 
Leache.
     */
    if (tsdPtr == NULL) {
	return;
    }


----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-02-25 14:41

Message:
Logged In: YES 
user_id=143340

This one has been torturing me for a while.

Managed to track it down to a problem inside Tcl.
For the Tcl8.3.4 source distribution the problem is in
the file win/tclWinNotify.c 

void Tcl_FinalizeNotifier(ClientData clientData)
{
    ThreadSpecificData *tsdPtr = 
                         (ThreadSpecificData *) clientData;

    /* sometimes called with tsdPtr == NULL */
    if ( tsdPtr != NULL )
    {
        DeleteCriticalSection(&tsdPtr->crit);
        CloseHandle(tsdPtr->event);

        /*
         * Clean up the timer and messaging 
         * window for this thread.
         */

        if (tsdPtr->hwnd) {
	    KillTimer(tsdPtr->hwnd, INTERVAL_TIMER);
            DestroyWindow(tsdPtr->hwnd);
        }
    }

    /*
     * If this is the last thread to use the notifier, 
     * unregister the notifier window class.
     */

    Tcl_MutexLock(&notifierMutex);
    if ( notifierCount && !--notifierCount ) {
	UnregisterClassA( "TclNotifier", 
                          TclWinGetTclInstance());
    }
    Tcl_MutexUnlock(&notifierMutex);
}

This bodge doesn't address the underlying problem but has 
stopped me from tearing all my hair out,

cheers,
John Popplewell.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-10-24 15:27

Message:
Logged In: YES 
user_id=31435

FYI, you don't need an IDE to do this -- in Win9x, hit 
Ctrl+Alt+Del and kill the process directly.

A saner <wink> solution is to develop under Win2K, which 
doesn't appear to suffer this problem (the only reports 
I've seen, and experienced myself, came from Win9x boxes).

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-10-24 01:52

Message:
Logged In: NO 

For those who are still trapped in this bug's hell, I will 
gladly share the one thing that saved my sanity:  
WingIDE's 'Kill' command will shut down the program with 
apparent 100% certainty and no fear of lockups.  WingIDE 
has its own issues, so its not a perfect solution, but if 
you are like me and Joe (above) who test in small 
iterations, then using 'Kill' to quit out of your app while 
testing is a workaround that may preserve your sanity.

Perhaps the python gods and the Wing guys can get together 
and tell us how to replicate 'kill' into our code.  For 
now, I'll use WingIDE to edit, and pythonw.exe for my final 
client's delivery.

----------------------------------------------------------------------

Comment By: Howard Lightstone (hlightstone)
Date: 2001-09-05 10:43

Message:
Logged In: YES 
user_id=66570

I sometimes get bunches of these....

A tool I use (Taskinfo2000) reports that (after killing 
winoldap):

python.exe is blocked on a mutex named OLESCELOCKMUTEX.
The reported state is "Console Terminating".  There appears 
to be only one (os) thread running.


----------------------------------------------------------------------

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: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=216289&group_id=5470


From noreply@sourceforge.net  Thu Aug 15 02:00:20 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 14 Aug 2002 18:00:20 -0700
Subject: [Python-bugs-list] [ python-Bugs-216289 ] Programs using Tkinter sometimes can't shut down (Windows)
Message-ID: <E17f8zs-0000Ww-00@usw-sf-web1.sourceforge.net>

Bugs item #216289, was opened at 2000-10-06 22:25
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=216289&group_id=5470

Category: Windows
Group: Python 2.3
Status: Open
Resolution: Later
Priority: 3
Submitted By: Tim Peters (tim_one)
Assigned to: Fredrik Lundh (effbot)
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: Guido van Rossum (gvanrossum)
Date: 2002-08-14 21:00

Message:
Logged In: YES 
user_id=6380

AFAIK we never distributed a threaded build.

----------------------------------------------------------------------

Comment By: David Gravereaux (davygrvy)
Date: 2002-08-14 20:01

Message:
Logged In: YES 
user_id=7549

To johnnypops,

Where in Tcl_FinalizeNotifier() is the dead-lock occuring and 
is this with a threaded build of Tcl?


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-07-02 15:39

Message:
Logged In: YES 
user_id=31435

Jeff, a long time ago Fredrik Lundh said he was able to 
reproduce this with a short wish script (no Python, no Tkinter, 
just Tcl/Tk + wish).  I'm reassigning this to /F in the hopes 
he'll remember how.

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-07-02 14:55

Message:
Logged In: YES 
user_id=72656

I appreciate that many others see this is a problem in 
embedding Tcl, but without any clear way to reproduce this in 
Tcl/Tk itself, it's very hard for me to fix it.  I don't think that 
there is anything done in 8.4 to fix this that I recall, but if 
someone finds that the problem "goes away" with 8.4, please 
report that.

For those of course that experience this with python, the 
simple and "correct" work-around is to launch with 
pythonw.exe instead of python.exe.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-06-26 13:40

Message:
Logged In: NO 

According to http://tcl.activestate.com ActiveTcl 8.4.0 is now 
available for download.  It is new as of June 24.  I don't know 
whether this will solve our problems or not, but it's worth 
looking into.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-06-19 09:36

Message:
Logged In: NO 

I just downloaded Ruby 1.6.6 for Windows, which also uses 
Tcl/Tk 8.3 and I experience exactly the same problem there. 
So this is definitely a Tcl problem (but we know that already).

----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-06-07 15:01

Message:
Logged In: YES 
user_id=143340

Hmmm. 
I run a Python Tcl/Tk application several times every day - 
the very application that prompted my bug-hunt.

I do use "pythonw.exe" to launch it, but it used to hang 
almost as badly as "python.exe".

Whilst developing this app I used "python.exe" and 
experienced no hang-ups.

The Tcl guys point out that this bug is only one of several 
possible causes of the hang-up, maybe you are just out of 
luck.

The patch has fixed the problem on three Win98 machines, 
all of which exhibited the problem before updating the DLLs.

One thought - are you sure there weren't multiple copies of 
the tcl83.dll and tk83.dll files? My (only) copies were 
in "D:\python20\DLLs"

good luck,
John.


----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-06-03 14:55

Message:
Logged In: YES 
user_id=72656

providing Tim with a fixed DLL exactly according to John 
Popplewell's patch did not fix the problem for him.  That 
makes it seem fishy that John really didn't see the problem 
any more.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-03 12:59

Message:
Logged In: YES 
user_id=31435

I tried replacing Python 2.2.1's tk83.dll and tcl83.dll (from 
Tcl/Tk 8.3.2) with newer matched sets from

A) PythonWare's py21 distribution (Tcl/Tk 8.3.3).

and again from

B) ActiveState's Tcl/Tk 8.3.4.

All the symptoms originally reported here persisted on 
Win98SE despite that.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-05-22 09:57

Message:
Logged In: NO 

I am new to Python and encountered this bug on my very first 
Tkinter application.  It persists in Python 2.2.1 under 
Windows Me. Needless to say, it makes a bad first 
impression.  Basically, this thread says that Tkinter has been 
broken for a year and a half on a popular platform at a time 
when Python is trying to expand its user base.  Hopefully, this 
bug will be corrected soon.

If Tcl/Tk 8.4 is not released shortly you might try repackaging 
Tkinter for Win32 with an earlier version of Tcl/Tk, such as 
8.0, that doesn't encounter this problem.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 22:36

Message:
Logged In: YES 
user_id=6380

The proper action is to wait until Tcl 8.3.5 is released,
and then shaming someone else in providing you with a set of
Windowsbinaries for Tcl. You may also ask Hobbs if there's a
Windows project file to build Tcl/Tk for Windows.

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-03-11 21:31

Message:
Logged In: YES 
user_id=72656

I did end up back-porting this to the 8.3.4+ Tcl CVS on 
2002-02-25, which means it will be in an eventual 8.3.5.  
It is already in the release 8.4 alpha series.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-09 20:50

Message:
Logged In: YES 
user_id=31435

Back to Guido:  Do you think you know what the proper 
action is?  (You said that's why you reopened it, and 
there's been no new info here since then.)

----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-02-25 19:55

Message:
Logged In: YES 
user_id=143340

I knew I wasn't getting to the heart of it ....

Almost a one-liner!

It has been seriously spoiling my (otherwise crash free) 
Python experience on Win9x - hope it gets fixed soon.

cheers,
John.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-02-25 18:39

Message:
Logged In: YES 
user_id=6380

Reopened until we know what the proper action is.

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-02-25 18:32

Message:
Logged In: YES 
user_id=72656

This is mostly correct, and is fixed in the 8.4 Tcl sources 
already (I guess we can backport this).  This was mentioned 
in SF Tcl bug (account for chopped URL):

https://sourceforge.net/tracker/?
func=detail&aid=217982&group_id=10894&atid=110894

and the code comment is:

    /*
     * Only finalize the notifier if a notifier was 
installed in the
     * current thread; there is a route in which this is not
     * guaranteed to be true (when tclWin32Dll.c:DllMain() 
is called
     * with the flag DLL_PROCESS_DETACH by the OS, which 
could be
     * doing so from a thread that's never previously been 
involved
     * with Tcl, e.g. the task manager) so this check is 
important.
     *
     * Fixes Bug #217982 reported by Hugh Vu and Gene 
Leache.
     */
    if (tsdPtr == NULL) {
	return;
    }


----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-02-25 17:41

Message:
Logged In: YES 
user_id=143340

This one has been torturing me for a while.

Managed to track it down to a problem inside Tcl.
For the Tcl8.3.4 source distribution the problem is in
the file win/tclWinNotify.c 

void Tcl_FinalizeNotifier(ClientData clientData)
{
    ThreadSpecificData *tsdPtr = 
                         (ThreadSpecificData *) clientData;

    /* sometimes called with tsdPtr == NULL */
    if ( tsdPtr != NULL )
    {
        DeleteCriticalSection(&tsdPtr->crit);
        CloseHandle(tsdPtr->event);

        /*
         * Clean up the timer and messaging 
         * window for this thread.
         */

        if (tsdPtr->hwnd) {
	    KillTimer(tsdPtr->hwnd, INTERVAL_TIMER);
            DestroyWindow(tsdPtr->hwnd);
        }
    }

    /*
     * If this is the last thread to use the notifier, 
     * unregister the notifier window class.
     */

    Tcl_MutexLock(&notifierMutex);
    if ( notifierCount && !--notifierCount ) {
	UnregisterClassA( "TclNotifier", 
                          TclWinGetTclInstance());
    }
    Tcl_MutexUnlock(&notifierMutex);
}

This bodge doesn't address the underlying problem but has 
stopped me from tearing all my hair out,

cheers,
John Popplewell.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-10-24 18:27

Message:
Logged In: YES 
user_id=31435

FYI, you don't need an IDE to do this -- in Win9x, hit 
Ctrl+Alt+Del and kill the process directly.

A saner <wink> solution is to develop under Win2K, which 
doesn't appear to suffer this problem (the only reports 
I've seen, and experienced myself, came from Win9x boxes).

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-10-24 04:52

Message:
Logged In: NO 

For those who are still trapped in this bug's hell, I will 
gladly share the one thing that saved my sanity:  
WingIDE's 'Kill' command will shut down the program with 
apparent 100% certainty and no fear of lockups.  WingIDE 
has its own issues, so its not a perfect solution, but if 
you are like me and Joe (above) who test in small 
iterations, then using 'Kill' to quit out of your app while 
testing is a workaround that may preserve your sanity.

Perhaps the python gods and the Wing guys can get together 
and tell us how to replicate 'kill' into our code.  For 
now, I'll use WingIDE to edit, and pythonw.exe for my final 
client's delivery.

----------------------------------------------------------------------

Comment By: Howard Lightstone (hlightstone)
Date: 2001-09-05 13:43

Message:
Logged In: YES 
user_id=66570

I sometimes get bunches of these....

A tool I use (Taskinfo2000) reports that (after killing 
winoldap):

python.exe is blocked on a mutex named OLESCELOCKMUTEX.
The reported state is "Console Terminating".  There appears 
to be only one (os) thread running.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-04-02 16: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-06 00: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 21: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 15: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 12: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 10:40

Message:
Back to Tim since I have no clue what to do here.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-12 13: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 03: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: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=216289&group_id=5470


From noreply@sourceforge.net  Thu Aug 15 02:56:24 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 14 Aug 2002 18:56:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-595350 ] string method bugs w/ 8bit, unicode args
Message-ID: <E17f9s8-0004CZ-00@usw-sf-web2.sourceforge.net>

Bugs item #595350, was opened at 2002-08-15 01:56
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595350&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Inyeol Lee (inyeol)
Assigned to: Nobody/Anonymous (nobody)
Summary: string method bugs w/ 8bit, unicode args

Initial Comment:
Python 2.2.1 (#1, Apr 10 2002, 18:25:16) 
[GCC 2.95.3 20010315 (release)] on sunos5

1. "abc".endswith("c") ->1
   "abc".endswith(u"c") -> 0 # bug.
   u"abc".endswith("c") -> 1
   u"abc".endswith(u"c") -> 1

2. "aaa".rfind("a") -> 2
   "aaa".rfind(u"a") -> 0 # bug.
   u"aaa".rfind("a") -> 2
   u"aaa".rfind(u"a") -> 2

   .rindex() has the same bug.

3. "abc".rfind("") -> 3
   "abc".rfind(u"") -> 0 # bug.
   u"abc".rfind("") -> 0 # bug.
   u"abc".rfind(u"") -> 0 # bug.

   .rindex() has the same bug.

4. "abc".replace("", "x") -> ValueError
   "abc".replace(u"", "x") -> u'abcxxxx' # bug.
   u"abc".replace("", "x") -> u'abcxxxx' # bug.
   u"abc".replace(u"", "x") -> u'abcxxxx' # bug.

   They should raise ValueError, or return u'xaxbxcx'.
   BTW, how about changing s.replace("") behavior to
return
   "xaxbxcx" (or u"xaxbxcx") for all 4 cases? It is
consistent
   with other string methods and re.sub() method.
   It seems that Guido doesn't mind changing this.

[Guido]
> If someone really wants 'abc'.replace('', '-') to
return '-a-b-c-',
> please submit patches for both 8-bit and Unicode
strings to
> SourceForge and assign to me.  I looked into this and
it's
> non-trivial: the implementation used for 8-bit
strings goes into an
> infinite loop when the pattern is empty, and the
Unicode
> implementation tacks '----' onto the end.  Please
supply doc and
> unittest patches too.  At least re does the right
thing already:

5. (it's not a bug)
   Except for .replace() above, s.split() is the only
string method
   which raises exception. How about changing this to
return
   unmodified string when empty string  is given as a
separator?
   This is consistent with re.split() behavior.

- Inyeol Lee

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595350&group_id=5470


From noreply@sourceforge.net  Thu Aug 15 08:17:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Aug 2002 00:17:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-594996 ] OverflowError in random.randrange
Message-ID: <E17fEsu-0001mm-00@usw-sf-web4.sourceforge.net>

Bugs item #594996, was opened at 2002-08-14 05:46
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594996&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Shannon Jones (sjones)
Assigned to: Tim Peters (tim_one)
Summary: OverflowError in random.randrange

Initial Comment:
The following code can produce an OverflowError in
random.randrange.

import random
from sys import maxint
minint = -maxint - 1

random.randrange(minint, maxint)

You may need to execute the last line a few times to
get the error because it depends on the random number
generated. The traceback is on line 315 of random.py
and is OverflowError: float too large to convert.

Changing line 315 from:
return istart + int(self.random() * (istop - istart))
to:
return int(istart + self.random() * (istop - istart))

seems to fix the problem.

-----
I'm using Python 2.3 from CVS on RH 7.3


----------------------------------------------------------------------

>Comment By: Shannon Jones (sjones)
Date: 2002-08-15 02:17

Message:
Logged In: YES 
user_id=589306

I'm attaching a patch that I *hope* generates correct output
for all inputs :-)

Just for kicks, I tried running random.randrange(-10, 10)
fifty million times with the regular code and with these
changes. The regular version ran in 543.04 seconds. The
changed code took 559.21 seconds. The difference is 2.98%.

To put that in perspective: if you had a simulation that did
nothing but generate random numbers and throw them away for
10 hours, it would now take 10 hours and 18 minutes to run.

If the range between numbers is bigger than sys.maxint,
things slow down by roughly a factor of 5 on my computer. I
guess because Python switches to long ints?


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-08-14 11:59

Message:
Logged In: YES 
user_id=31435

The suggested change stops OverflowError but delivers 
incorrect results; for example, try randrange(-2, 0) repeatedly, 
and you'll find it delivers one of {-2, -1} before the change, but 
one of {-1, 0} after the change.  Using int(math.floor(...)) 
instead would restore correct behavior, but I'm loathe to slow 
this high-usage function.  In the absence of an idea that's 
both correct and fast, I'll close this as WontFix -- speed is 
more important here than pushing the limit on the overall 
range by 1 bit.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594996&group_id=5470


From noreply@sourceforge.net  Thu Aug 15 10:01:26 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Aug 2002 02:01:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-594998 ] test_nis test fails on TRU64 5.1
Message-ID: <E17fGVS-0001Er-00@usw-sf-web2.sourceforge.net>

Bugs item #594998, was opened at 2002-08-14 12:53
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594998&group_id=5470

Category: Build
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Patrick Finnerty (finnertyp)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_nis test fails on TRU64 5.1

Initial Comment:
Platform: TRU64 v5.1a

Ran configure with --with-dec-threads options. 
Also used --without-gcc although this has no impact on
test failure.

The ouput from ./python ./Lib/test/test_nis.py is large
so I've included it in an attached file rather than
pasted here.

The machine that Python is being built on is a NIS
server as well as client.



----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-15 11:01

Message:
Logged In: YES 
user_id=21627

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594998&group_id=5470


From noreply@sourceforge.net  Thu Aug 15 11:02:11 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Aug 2002 03:02:11 -0700
Subject: [Python-bugs-list] [ python-Bugs-594998 ] test_nis test fails on TRU64 5.1
Message-ID: <E17fHSF-00026a-00@usw-sf-web1.sourceforge.net>

Bugs item #594998, was opened at 2002-08-14 10:53
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594998&group_id=5470

Category: Build
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Patrick Finnerty (finnertyp)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_nis test fails on TRU64 5.1

Initial Comment:
Platform: TRU64 v5.1a

Ran configure with --with-dec-threads options. 
Also used --without-gcc although this has no impact on
test failure.

The ouput from ./python ./Lib/test/test_nis.py is large
so I've included it in an attached file rather than
pasted here.

The machine that Python is being built on is a NIS
server as well as client.



----------------------------------------------------------------------

>Comment By: Patrick Finnerty (finnertyp)
Date: 2002-08-15 10:02

Message:
Logged In: YES 
user_id=594846

Uploading the output file from ./python ./Lib/test/test_nis.py.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-15 09:01

Message:
Logged In: YES 
user_id=21627

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594998&group_id=5470


From noreply@sourceforge.net  Thu Aug 15 12:05:34 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Aug 2002 04:05:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-594998 ] test_nis test fails on TRU64 5.1
Message-ID: <E17fIRa-0003cG-00@usw-sf-web2.sourceforge.net>

Bugs item #594998, was opened at 2002-08-14 12:53
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594998&group_id=5470

Category: Build
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Patrick Finnerty (finnertyp)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_nis test fails on TRU64 5.1

Initial Comment:
Platform: TRU64 v5.1a

Ran configure with --with-dec-threads options. 
Also used --without-gcc although this has no impact on
test failure.

The ouput from ./python ./Lib/test/test_nis.py is large
so I've included it in an attached file rather than
pasted here.

The machine that Python is being built on is a NIS
server as well as client.



----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-08-15 13:05

Message:
Logged In: YES 
user_id=21627

This sounds like some serious memory corruption is going on.
Unfortunately, I can't spot a problem, so somebody with
access to such a system would need to debug it.

My first guess is that the type of the callback function is
incorrect. Can you please find out what signatures are
involved in yp_all(3)? On Solaris, the callback signature is
not declared in a header, but only documented in
yp_clnt(3NSL), as

                foreach(int instatus, char *inkey,
                int inkeylen, char *inval,
                int invallen, char *indata);


----------------------------------------------------------------------

Comment By: Patrick Finnerty (finnertyp)
Date: 2002-08-15 12:02

Message:
Logged In: YES 
user_id=594846

Uploading the output file from ./python ./Lib/test/test_nis.py.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-15 11:01

Message:
Logged In: YES 
user_id=21627

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594998&group_id=5470


From noreply@sourceforge.net  Thu Aug 15 13:15:48 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Aug 2002 05:15:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-216289 ] Programs using Tkinter sometimes can't shut down (Windows)
Message-ID: <E17fJXY-00021S-00@usw-sf-web3.sourceforge.net>

Bugs item #216289, was opened at 2000-10-07 02:25
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=216289&group_id=5470

Category: Windows
Group: Python 2.3
Status: Open
Resolution: Later
Priority: 3
Submitted By: Tim Peters (tim_one)
Assigned to: Fredrik Lundh (effbot)
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: John Popplewell (johnnypops)
Date: 2002-08-15 12:15

Message:
Logged In: YES 
user_id=143340

Hi to davygrvy,

my fix isn't for a thread related (deadlock) type problem - it 
is a fix for a double free type problem which is presumably 
screwing up the heap and causing the C runtime to hang.

It *is* with a threaded build (THREADDEFINES = -
DTCL_THREADS=1) which I think I enabled because I was 
using  'after' and it didn't work unless threading was 
enabled - but I may be mis-remembering here!

Also, I ended up doing all this with the debug build and 
found the -GZ flag useful - in fact it pointed out the fact that 
there was a problem with the heap.

It is worth noting that I have only seen this on Win98 and 
that using 'pythonw.exe' did *not* prevent this from 
happening,

regards John.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-15 01:00

Message:
Logged In: YES 
user_id=6380

AFAIK we never distributed a threaded build.

----------------------------------------------------------------------

Comment By: David Gravereaux (davygrvy)
Date: 2002-08-15 00:01

Message:
Logged In: YES 
user_id=7549

To johnnypops,

Where in Tcl_FinalizeNotifier() is the dead-lock occuring and 
is this with a threaded build of Tcl?


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-07-02 19:39

Message:
Logged In: YES 
user_id=31435

Jeff, a long time ago Fredrik Lundh said he was able to 
reproduce this with a short wish script (no Python, no Tkinter, 
just Tcl/Tk + wish).  I'm reassigning this to /F in the hopes 
he'll remember how.

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-07-02 18:55

Message:
Logged In: YES 
user_id=72656

I appreciate that many others see this is a problem in 
embedding Tcl, but without any clear way to reproduce this in 
Tcl/Tk itself, it's very hard for me to fix it.  I don't think that 
there is anything done in 8.4 to fix this that I recall, but if 
someone finds that the problem "goes away" with 8.4, please 
report that.

For those of course that experience this with python, the 
simple and "correct" work-around is to launch with 
pythonw.exe instead of python.exe.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-06-26 17:40

Message:
Logged In: NO 

According to http://tcl.activestate.com ActiveTcl 8.4.0 is now 
available for download.  It is new as of June 24.  I don't know 
whether this will solve our problems or not, but it's worth 
looking into.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-06-19 13:36

Message:
Logged In: NO 

I just downloaded Ruby 1.6.6 for Windows, which also uses 
Tcl/Tk 8.3 and I experience exactly the same problem there. 
So this is definitely a Tcl problem (but we know that already).

----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-06-07 19:01

Message:
Logged In: YES 
user_id=143340

Hmmm. 
I run a Python Tcl/Tk application several times every day - 
the very application that prompted my bug-hunt.

I do use "pythonw.exe" to launch it, but it used to hang 
almost as badly as "python.exe".

Whilst developing this app I used "python.exe" and 
experienced no hang-ups.

The Tcl guys point out that this bug is only one of several 
possible causes of the hang-up, maybe you are just out of 
luck.

The patch has fixed the problem on three Win98 machines, 
all of which exhibited the problem before updating the DLLs.

One thought - are you sure there weren't multiple copies of 
the tcl83.dll and tk83.dll files? My (only) copies were 
in "D:\python20\DLLs"

good luck,
John.


----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-06-03 18:55

Message:
Logged In: YES 
user_id=72656

providing Tim with a fixed DLL exactly according to John 
Popplewell's patch did not fix the problem for him.  That 
makes it seem fishy that John really didn't see the problem 
any more.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-03 16:59

Message:
Logged In: YES 
user_id=31435

I tried replacing Python 2.2.1's tk83.dll and tcl83.dll (from 
Tcl/Tk 8.3.2) with newer matched sets from

A) PythonWare's py21 distribution (Tcl/Tk 8.3.3).

and again from

B) ActiveState's Tcl/Tk 8.3.4.

All the symptoms originally reported here persisted on 
Win98SE despite that.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-05-22 13:57

Message:
Logged In: NO 

I am new to Python and encountered this bug on my very first 
Tkinter application.  It persists in Python 2.2.1 under 
Windows Me. Needless to say, it makes a bad first 
impression.  Basically, this thread says that Tkinter has been 
broken for a year and a half on a popular platform at a time 
when Python is trying to expand its user base.  Hopefully, this 
bug will be corrected soon.

If Tcl/Tk 8.4 is not released shortly you might try repackaging 
Tkinter for Win32 with an earlier version of Tcl/Tk, such as 
8.0, that doesn't encounter this problem.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-23 03:36

Message:
Logged In: YES 
user_id=6380

The proper action is to wait until Tcl 8.3.5 is released,
and then shaming someone else in providing you with a set of
Windowsbinaries for Tcl. You may also ask Hobbs if there's a
Windows project file to build Tcl/Tk for Windows.

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-03-12 02:31

Message:
Logged In: YES 
user_id=72656

I did end up back-porting this to the 8.3.4+ Tcl CVS on 
2002-02-25, which means it will be in an eventual 8.3.5.  
It is already in the release 8.4 alpha series.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-10 01:50

Message:
Logged In: YES 
user_id=31435

Back to Guido:  Do you think you know what the proper 
action is?  (You said that's why you reopened it, and 
there's been no new info here since then.)

----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-02-26 00:55

Message:
Logged In: YES 
user_id=143340

I knew I wasn't getting to the heart of it ....

Almost a one-liner!

It has been seriously spoiling my (otherwise crash free) 
Python experience on Win9x - hope it gets fixed soon.

cheers,
John.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-02-25 23:39

Message:
Logged In: YES 
user_id=6380

Reopened until we know what the proper action is.

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-02-25 23:32

Message:
Logged In: YES 
user_id=72656

This is mostly correct, and is fixed in the 8.4 Tcl sources 
already (I guess we can backport this).  This was mentioned 
in SF Tcl bug (account for chopped URL):

https://sourceforge.net/tracker/?
func=detail&aid=217982&group_id=10894&atid=110894

and the code comment is:

    /*
     * Only finalize the notifier if a notifier was 
installed in the
     * current thread; there is a route in which this is not
     * guaranteed to be true (when tclWin32Dll.c:DllMain() 
is called
     * with the flag DLL_PROCESS_DETACH by the OS, which 
could be
     * doing so from a thread that's never previously been 
involved
     * with Tcl, e.g. the task manager) so this check is 
important.
     *
     * Fixes Bug #217982 reported by Hugh Vu and Gene 
Leache.
     */
    if (tsdPtr == NULL) {
	return;
    }


----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-02-25 22:41

Message:
Logged In: YES 
user_id=143340

This one has been torturing me for a while.

Managed to track it down to a problem inside Tcl.
For the Tcl8.3.4 source distribution the problem is in
the file win/tclWinNotify.c 

void Tcl_FinalizeNotifier(ClientData clientData)
{
    ThreadSpecificData *tsdPtr = 
                         (ThreadSpecificData *) clientData;

    /* sometimes called with tsdPtr == NULL */
    if ( tsdPtr != NULL )
    {
        DeleteCriticalSection(&tsdPtr->crit);
        CloseHandle(tsdPtr->event);

        /*
         * Clean up the timer and messaging 
         * window for this thread.
         */

        if (tsdPtr->hwnd) {
	    KillTimer(tsdPtr->hwnd, INTERVAL_TIMER);
            DestroyWindow(tsdPtr->hwnd);
        }
    }

    /*
     * If this is the last thread to use the notifier, 
     * unregister the notifier window class.
     */

    Tcl_MutexLock(&notifierMutex);
    if ( notifierCount && !--notifierCount ) {
	UnregisterClassA( "TclNotifier", 
                          TclWinGetTclInstance());
    }
    Tcl_MutexUnlock(&notifierMutex);
}

This bodge doesn't address the underlying problem but has 
stopped me from tearing all my hair out,

cheers,
John Popplewell.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-10-24 22:27

Message:
Logged In: YES 
user_id=31435

FYI, you don't need an IDE to do this -- in Win9x, hit 
Ctrl+Alt+Del and kill the process directly.

A saner <wink> solution is to develop under Win2K, which 
doesn't appear to suffer this problem (the only reports 
I've seen, and experienced myself, came from Win9x boxes).

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-10-24 08:52

Message:
Logged In: NO 

For those who are still trapped in this bug's hell, I will 
gladly share the one thing that saved my sanity:  
WingIDE's 'Kill' command will shut down the program with 
apparent 100% certainty and no fear of lockups.  WingIDE 
has its own issues, so its not a perfect solution, but if 
you are like me and Joe (above) who test in small 
iterations, then using 'Kill' to quit out of your app while 
testing is a workaround that may preserve your sanity.

Perhaps the python gods and the Wing guys can get together 
and tell us how to replicate 'kill' into our code.  For 
now, I'll use WingIDE to edit, and pythonw.exe for my final 
client's delivery.

----------------------------------------------------------------------

Comment By: Howard Lightstone (hlightstone)
Date: 2001-09-05 17:43

Message:
Logged In: YES 
user_id=66570

I sometimes get bunches of these....

A tool I use (Taskinfo2000) reports that (after killing 
winoldap):

python.exe is blocked on a mutex named OLESCELOCKMUTEX.
The reported state is "Console Terminating".  There appears 
to be only one (os) thread running.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-04-02 20: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-06 05: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-13 02: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 20: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 16: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 14:40

Message:
Back to Tim since I have no clue what to do here.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-12 17: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 07: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: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=216289&group_id=5470


From noreply@sourceforge.net  Thu Aug 15 14:09:06 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Aug 2002 06:09:06 -0700
Subject: [Python-bugs-list] [ python-Bugs-216289 ] Programs using Tkinter sometimes can't shut down (Windows)
Message-ID: <E17fKN8-0006H0-00@usw-sf-web2.sourceforge.net>

Bugs item #216289, was opened at 2000-10-07 03:25
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=216289&group_id=5470

Category: Windows
Group: Python 2.3
Status: Open
Resolution: Later
Priority: 3
Submitted By: Tim Peters (tim_one)
Assigned to: Fredrik Lundh (effbot)
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: Donal K. Fellows (dkf)
Date: 2002-08-15 14:09

Message:
Logged In: YES 
user_id=79902

Firstly, on the matter of threads.  Tcl/Tk on Windows uses
threads internally even in non-threaded builds.  That's
Windows for you (in particular, you can get calls parachuted
in from completely separate threads with relatively little
warning.  Also, you need threaded helpers to handle
non-blocking waiting on some kinds of objects.)

It's a bit hard to work out if the problem's been fixed
without a stack-trace (preferably with debugging symbols
enabled so that we can see what the function names and
arguments to those functions are.)  I have no  chance of
replicating this bug here (I'm currently running IRIX, but
also have some access to Solaris and Linux...)

----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-08-15 13:15

Message:
Logged In: YES 
user_id=143340

Hi to davygrvy,

my fix isn't for a thread related (deadlock) type problem - it 
is a fix for a double free type problem which is presumably 
screwing up the heap and causing the C runtime to hang.

It *is* with a threaded build (THREADDEFINES = -
DTCL_THREADS=1) which I think I enabled because I was 
using  'after' and it didn't work unless threading was 
enabled - but I may be mis-remembering here!

Also, I ended up doing all this with the debug build and 
found the -GZ flag useful - in fact it pointed out the fact that 
there was a problem with the heap.

It is worth noting that I have only seen this on Win98 and 
that using 'pythonw.exe' did *not* prevent this from 
happening,

regards John.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-15 02:00

Message:
Logged In: YES 
user_id=6380

AFAIK we never distributed a threaded build.

----------------------------------------------------------------------

Comment By: David Gravereaux (davygrvy)
Date: 2002-08-15 01:01

Message:
Logged In: YES 
user_id=7549

To johnnypops,

Where in Tcl_FinalizeNotifier() is the dead-lock occuring and 
is this with a threaded build of Tcl?


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-07-02 20:39

Message:
Logged In: YES 
user_id=31435

Jeff, a long time ago Fredrik Lundh said he was able to 
reproduce this with a short wish script (no Python, no Tkinter, 
just Tcl/Tk + wish).  I'm reassigning this to /F in the hopes 
he'll remember how.

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-07-02 19:55

Message:
Logged In: YES 
user_id=72656

I appreciate that many others see this is a problem in 
embedding Tcl, but without any clear way to reproduce this in 
Tcl/Tk itself, it's very hard for me to fix it.  I don't think that 
there is anything done in 8.4 to fix this that I recall, but if 
someone finds that the problem "goes away" with 8.4, please 
report that.

For those of course that experience this with python, the 
simple and "correct" work-around is to launch with 
pythonw.exe instead of python.exe.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-06-26 18:40

Message:
Logged In: NO 

According to http://tcl.activestate.com ActiveTcl 8.4.0 is now 
available for download.  It is new as of June 24.  I don't know 
whether this will solve our problems or not, but it's worth 
looking into.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-06-19 14:36

Message:
Logged In: NO 

I just downloaded Ruby 1.6.6 for Windows, which also uses 
Tcl/Tk 8.3 and I experience exactly the same problem there. 
So this is definitely a Tcl problem (but we know that already).

----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-06-07 20:01

Message:
Logged In: YES 
user_id=143340

Hmmm. 
I run a Python Tcl/Tk application several times every day - 
the very application that prompted my bug-hunt.

I do use "pythonw.exe" to launch it, but it used to hang 
almost as badly as "python.exe".

Whilst developing this app I used "python.exe" and 
experienced no hang-ups.

The Tcl guys point out that this bug is only one of several 
possible causes of the hang-up, maybe you are just out of 
luck.

The patch has fixed the problem on three Win98 machines, 
all of which exhibited the problem before updating the DLLs.

One thought - are you sure there weren't multiple copies of 
the tcl83.dll and tk83.dll files? My (only) copies were 
in "D:\python20\DLLs"

good luck,
John.


----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-06-03 19:55

Message:
Logged In: YES 
user_id=72656

providing Tim with a fixed DLL exactly according to John 
Popplewell's patch did not fix the problem for him.  That 
makes it seem fishy that John really didn't see the problem 
any more.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-03 17:59

Message:
Logged In: YES 
user_id=31435

I tried replacing Python 2.2.1's tk83.dll and tcl83.dll (from 
Tcl/Tk 8.3.2) with newer matched sets from

A) PythonWare's py21 distribution (Tcl/Tk 8.3.3).

and again from

B) ActiveState's Tcl/Tk 8.3.4.

All the symptoms originally reported here persisted on 
Win98SE despite that.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-05-22 14:57

Message:
Logged In: NO 

I am new to Python and encountered this bug on my very first 
Tkinter application.  It persists in Python 2.2.1 under 
Windows Me. Needless to say, it makes a bad first 
impression.  Basically, this thread says that Tkinter has been 
broken for a year and a half on a popular platform at a time 
when Python is trying to expand its user base.  Hopefully, this 
bug will be corrected soon.

If Tcl/Tk 8.4 is not released shortly you might try repackaging 
Tkinter for Win32 with an earlier version of Tcl/Tk, such as 
8.0, that doesn't encounter this problem.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-23 03:36

Message:
Logged In: YES 
user_id=6380

The proper action is to wait until Tcl 8.3.5 is released,
and then shaming someone else in providing you with a set of
Windowsbinaries for Tcl. You may also ask Hobbs if there's a
Windows project file to build Tcl/Tk for Windows.

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-03-12 02:31

Message:
Logged In: YES 
user_id=72656

I did end up back-porting this to the 8.3.4+ Tcl CVS on 
2002-02-25, which means it will be in an eventual 8.3.5.  
It is already in the release 8.4 alpha series.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-10 01:50

Message:
Logged In: YES 
user_id=31435

Back to Guido:  Do you think you know what the proper 
action is?  (You said that's why you reopened it, and 
there's been no new info here since then.)

----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-02-26 00:55

Message:
Logged In: YES 
user_id=143340

I knew I wasn't getting to the heart of it ....

Almost a one-liner!

It has been seriously spoiling my (otherwise crash free) 
Python experience on Win9x - hope it gets fixed soon.

cheers,
John.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-02-25 23:39

Message:
Logged In: YES 
user_id=6380

Reopened until we know what the proper action is.

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-02-25 23:32

Message:
Logged In: YES 
user_id=72656

This is mostly correct, and is fixed in the 8.4 Tcl sources 
already (I guess we can backport this).  This was mentioned 
in SF Tcl bug (account for chopped URL):

https://sourceforge.net/tracker/?
func=detail&aid=217982&group_id=10894&atid=110894

and the code comment is:

    /*
     * Only finalize the notifier if a notifier was 
installed in the
     * current thread; there is a route in which this is not
     * guaranteed to be true (when tclWin32Dll.c:DllMain() 
is called
     * with the flag DLL_PROCESS_DETACH by the OS, which 
could be
     * doing so from a thread that's never previously been 
involved
     * with Tcl, e.g. the task manager) so this check is 
important.
     *
     * Fixes Bug #217982 reported by Hugh Vu and Gene 
Leache.
     */
    if (tsdPtr == NULL) {
	return;
    }


----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-02-25 22:41

Message:
Logged In: YES 
user_id=143340

This one has been torturing me for a while.

Managed to track it down to a problem inside Tcl.
For the Tcl8.3.4 source distribution the problem is in
the file win/tclWinNotify.c 

void Tcl_FinalizeNotifier(ClientData clientData)
{
    ThreadSpecificData *tsdPtr = 
                         (ThreadSpecificData *) clientData;

    /* sometimes called with tsdPtr == NULL */
    if ( tsdPtr != NULL )
    {
        DeleteCriticalSection(&tsdPtr->crit);
        CloseHandle(tsdPtr->event);

        /*
         * Clean up the timer and messaging 
         * window for this thread.
         */

        if (tsdPtr->hwnd) {
	    KillTimer(tsdPtr->hwnd, INTERVAL_TIMER);
            DestroyWindow(tsdPtr->hwnd);
        }
    }

    /*
     * If this is the last thread to use the notifier, 
     * unregister the notifier window class.
     */

    Tcl_MutexLock(&notifierMutex);
    if ( notifierCount && !--notifierCount ) {
	UnregisterClassA( "TclNotifier", 
                          TclWinGetTclInstance());
    }
    Tcl_MutexUnlock(&notifierMutex);
}

This bodge doesn't address the underlying problem but has 
stopped me from tearing all my hair out,

cheers,
John Popplewell.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-10-24 23:27

Message:
Logged In: YES 
user_id=31435

FYI, you don't need an IDE to do this -- in Win9x, hit 
Ctrl+Alt+Del and kill the process directly.

A saner <wink> solution is to develop under Win2K, which 
doesn't appear to suffer this problem (the only reports 
I've seen, and experienced myself, came from Win9x boxes).

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-10-24 09:52

Message:
Logged In: NO 

For those who are still trapped in this bug's hell, I will 
gladly share the one thing that saved my sanity:  
WingIDE's 'Kill' command will shut down the program with 
apparent 100% certainty and no fear of lockups.  WingIDE 
has its own issues, so its not a perfect solution, but if 
you are like me and Joe (above) who test in small 
iterations, then using 'Kill' to quit out of your app while 
testing is a workaround that may preserve your sanity.

Perhaps the python gods and the Wing guys can get together 
and tell us how to replicate 'kill' into our code.  For 
now, I'll use WingIDE to edit, and pythonw.exe for my final 
client's delivery.

----------------------------------------------------------------------

Comment By: Howard Lightstone (hlightstone)
Date: 2001-09-05 18:43

Message:
Logged In: YES 
user_id=66570

I sometimes get bunches of these....

A tool I use (Taskinfo2000) reports that (after killing 
winoldap):

python.exe is blocked on a mutex named OLESCELOCKMUTEX.
The reported state is "Console Terminating".  There appears 
to be only one (os) thread running.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-04-02 21: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-06 05: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-13 02: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 20: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 17: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 15:40

Message:
Back to Tim since I have no clue what to do here.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-12 18: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 08: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: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=216289&group_id=5470


From noreply@sourceforge.net  Thu Aug 15 14:06:42 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Aug 2002 06:06:42 -0700
Subject: [Python-bugs-list] [ python-Bugs-594998 ] test_nis test fails on TRU64 5.1
Message-ID: <E17fKKo-0008R5-00@usw-sf-web4.sourceforge.net>

Bugs item #594998, was opened at 2002-08-14 10:53
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594998&group_id=5470

Category: Build
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Patrick Finnerty (finnertyp)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_nis test fails on TRU64 5.1

Initial Comment:
Platform: TRU64 v5.1a

Ran configure with --with-dec-threads options. 
Also used --without-gcc although this has no impact on
test failure.

The ouput from ./python ./Lib/test/test_nis.py is large
so I've included it in an attached file rather than
pasted here.

The machine that Python is being built on is a NIS
server as well as client.



----------------------------------------------------------------------

>Comment By: Patrick Finnerty (finnertyp)
Date: 2002-08-15 13:06

Message:
Logged In: YES 
user_id=594846

On TRU64 this is doucmented as


       foreach(instatus, inkey, inkeylen, inval, invallen,
indata);
       int instatus;
       char *inkey;
       int inkeylen;
       char *inval;
       int invallen;
       char *indata;


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-15 11:05

Message:
Logged In: YES 
user_id=21627

This sounds like some serious memory corruption is going on.
Unfortunately, I can't spot a problem, so somebody with
access to such a system would need to debug it.

My first guess is that the type of the callback function is
incorrect. Can you please find out what signatures are
involved in yp_all(3)? On Solaris, the callback signature is
not declared in a header, but only documented in
yp_clnt(3NSL), as

                foreach(int instatus, char *inkey,
                int inkeylen, char *inval,
                int invallen, char *indata);


----------------------------------------------------------------------

Comment By: Patrick Finnerty (finnertyp)
Date: 2002-08-15 10:02

Message:
Logged In: YES 
user_id=594846

Uploading the output file from ./python ./Lib/test/test_nis.py.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-15 09:01

Message:
Logged In: YES 
user_id=21627

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594998&group_id=5470


From noreply@sourceforge.net  Thu Aug 15 14:23:42 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Aug 2002 06:23:42 -0700
Subject: [Python-bugs-list] [ python-Bugs-216289 ] Programs using Tkinter sometimes can't shut down (Windows)
Message-ID: <E17fKbG-0000SF-00@usw-sf-web4.sourceforge.net>

Bugs item #216289, was opened at 2000-10-06 19:25
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=216289&group_id=5470

Category: Windows
Group: Python 2.3
Status: Open
Resolution: Later
Priority: 3
Submitted By: Tim Peters (tim_one)
Assigned to: Fredrik Lundh (effbot)
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: David Gravereaux (davygrvy)
Date: 2002-08-15 06:23

Message:
Logged In: YES 
user_id=7549

Hi John,

I have seen Tcl extension DLLs that set exit handlers get 
called by Tcl after they were torn-down.  NT and Win9x seem 
to be a bit different in the order of what DLLs get torn-down.  
here's a note from some old code of mine:

#ifdef __WIN32__
    // It can happen that the HEAP could have already been 
unloaded
    // from an awkward teardown caused by a Ctrl+C or other.  
Win32
    // seems to do a teardown in reverse order and by the time 
Tcl
    // knows what's going on and Tcl_Finalize calls the exit
    // handlers, this extension's data (heap?) has already been
    // unloaded by the OS.  Do a quick legal check on the 
pointer
    // first.
    //
    if (IsBadReadPtr(adapt, sizeof(T *))) return;
#endif

what's the back/stacktrace?  who is calling 
Tcl_FinalizeNotifier?  And had anyone called it before during 
the shutdown phase? I can't say with much confidence that 
this is happening here, too.  Maybe..  Could Tk be telling Tcl 
shutdown?  That's sort of backwards, if so.

I run w2k here, so I can't help in debugging from a test case.  
tclsh with a threaded build doesn't even call Tcl_Finalize to 
avoid all this!

----------------------------------------------------------------------

Comment By: Donal K. Fellows (dkf)
Date: 2002-08-15 06:09

Message:
Logged In: YES 
user_id=79902

Firstly, on the matter of threads.  Tcl/Tk on Windows uses
threads internally even in non-threaded builds.  That's
Windows for you (in particular, you can get calls parachuted
in from completely separate threads with relatively little
warning.  Also, you need threaded helpers to handle
non-blocking waiting on some kinds of objects.)

It's a bit hard to work out if the problem's been fixed
without a stack-trace (preferably with debugging symbols
enabled so that we can see what the function names and
arguments to those functions are.)  I have no  chance of
replicating this bug here (I'm currently running IRIX, but
also have some access to Solaris and Linux...)

----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-08-15 05:15

Message:
Logged In: YES 
user_id=143340

Hi to davygrvy,

my fix isn't for a thread related (deadlock) type problem - it 
is a fix for a double free type problem which is presumably 
screwing up the heap and causing the C runtime to hang.

It *is* with a threaded build (THREADDEFINES = -
DTCL_THREADS=1) which I think I enabled because I was 
using  'after' and it didn't work unless threading was 
enabled - but I may be mis-remembering here!

Also, I ended up doing all this with the debug build and 
found the -GZ flag useful - in fact it pointed out the fact that 
there was a problem with the heap.

It is worth noting that I have only seen this on Win98 and 
that using 'pythonw.exe' did *not* prevent this from 
happening,

regards John.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-14 18:00

Message:
Logged In: YES 
user_id=6380

AFAIK we never distributed a threaded build.

----------------------------------------------------------------------

Comment By: David Gravereaux (davygrvy)
Date: 2002-08-14 17:01

Message:
Logged In: YES 
user_id=7549

To johnnypops,

Where in Tcl_FinalizeNotifier() is the dead-lock occuring and 
is this with a threaded build of Tcl?


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-07-02 12:39

Message:
Logged In: YES 
user_id=31435

Jeff, a long time ago Fredrik Lundh said he was able to 
reproduce this with a short wish script (no Python, no Tkinter, 
just Tcl/Tk + wish).  I'm reassigning this to /F in the hopes 
he'll remember how.

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-07-02 11:55

Message:
Logged In: YES 
user_id=72656

I appreciate that many others see this is a problem in 
embedding Tcl, but without any clear way to reproduce this in 
Tcl/Tk itself, it's very hard for me to fix it.  I don't think that 
there is anything done in 8.4 to fix this that I recall, but if 
someone finds that the problem "goes away" with 8.4, please 
report that.

For those of course that experience this with python, the 
simple and "correct" work-around is to launch with 
pythonw.exe instead of python.exe.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-06-26 10:40

Message:
Logged In: NO 

According to http://tcl.activestate.com ActiveTcl 8.4.0 is now 
available for download.  It is new as of June 24.  I don't know 
whether this will solve our problems or not, but it's worth 
looking into.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-06-19 06:36

Message:
Logged In: NO 

I just downloaded Ruby 1.6.6 for Windows, which also uses 
Tcl/Tk 8.3 and I experience exactly the same problem there. 
So this is definitely a Tcl problem (but we know that already).

----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-06-07 12:01

Message:
Logged In: YES 
user_id=143340

Hmmm. 
I run a Python Tcl/Tk application several times every day - 
the very application that prompted my bug-hunt.

I do use "pythonw.exe" to launch it, but it used to hang 
almost as badly as "python.exe".

Whilst developing this app I used "python.exe" and 
experienced no hang-ups.

The Tcl guys point out that this bug is only one of several 
possible causes of the hang-up, maybe you are just out of 
luck.

The patch has fixed the problem on three Win98 machines, 
all of which exhibited the problem before updating the DLLs.

One thought - are you sure there weren't multiple copies of 
the tcl83.dll and tk83.dll files? My (only) copies were 
in "D:\python20\DLLs"

good luck,
John.


----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-06-03 11:55

Message:
Logged In: YES 
user_id=72656

providing Tim with a fixed DLL exactly according to John 
Popplewell's patch did not fix the problem for him.  That 
makes it seem fishy that John really didn't see the problem 
any more.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-03 09:59

Message:
Logged In: YES 
user_id=31435

I tried replacing Python 2.2.1's tk83.dll and tcl83.dll (from 
Tcl/Tk 8.3.2) with newer matched sets from

A) PythonWare's py21 distribution (Tcl/Tk 8.3.3).

and again from

B) ActiveState's Tcl/Tk 8.3.4.

All the symptoms originally reported here persisted on 
Win98SE despite that.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-05-22 06:57

Message:
Logged In: NO 

I am new to Python and encountered this bug on my very first 
Tkinter application.  It persists in Python 2.2.1 under 
Windows Me. Needless to say, it makes a bad first 
impression.  Basically, this thread says that Tkinter has been 
broken for a year and a half on a popular platform at a time 
when Python is trying to expand its user base.  Hopefully, this 
bug will be corrected soon.

If Tcl/Tk 8.4 is not released shortly you might try repackaging 
Tkinter for Win32 with an earlier version of Tcl/Tk, such as 
8.0, that doesn't encounter this problem.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 19:36

Message:
Logged In: YES 
user_id=6380

The proper action is to wait until Tcl 8.3.5 is released,
and then shaming someone else in providing you with a set of
Windowsbinaries for Tcl. You may also ask Hobbs if there's a
Windows project file to build Tcl/Tk for Windows.

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-03-11 18:31

Message:
Logged In: YES 
user_id=72656

I did end up back-porting this to the 8.3.4+ Tcl CVS on 
2002-02-25, which means it will be in an eventual 8.3.5.  
It is already in the release 8.4 alpha series.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-09 17:50

Message:
Logged In: YES 
user_id=31435

Back to Guido:  Do you think you know what the proper 
action is?  (You said that's why you reopened it, and 
there's been no new info here since then.)

----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-02-25 16:55

Message:
Logged In: YES 
user_id=143340

I knew I wasn't getting to the heart of it ....

Almost a one-liner!

It has been seriously spoiling my (otherwise crash free) 
Python experience on Win9x - hope it gets fixed soon.

cheers,
John.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-02-25 15:39

Message:
Logged In: YES 
user_id=6380

Reopened until we know what the proper action is.

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-02-25 15:32

Message:
Logged In: YES 
user_id=72656

This is mostly correct, and is fixed in the 8.4 Tcl sources 
already (I guess we can backport this).  This was mentioned 
in SF Tcl bug (account for chopped URL):

https://sourceforge.net/tracker/?
func=detail&aid=217982&group_id=10894&atid=110894

and the code comment is:

    /*
     * Only finalize the notifier if a notifier was 
installed in the
     * current thread; there is a route in which this is not
     * guaranteed to be true (when tclWin32Dll.c:DllMain() 
is called
     * with the flag DLL_PROCESS_DETACH by the OS, which 
could be
     * doing so from a thread that's never previously been 
involved
     * with Tcl, e.g. the task manager) so this check is 
important.
     *
     * Fixes Bug #217982 reported by Hugh Vu and Gene 
Leache.
     */
    if (tsdPtr == NULL) {
	return;
    }


----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-02-25 14:41

Message:
Logged In: YES 
user_id=143340

This one has been torturing me for a while.

Managed to track it down to a problem inside Tcl.
For the Tcl8.3.4 source distribution the problem is in
the file win/tclWinNotify.c 

void Tcl_FinalizeNotifier(ClientData clientData)
{
    ThreadSpecificData *tsdPtr = 
                         (ThreadSpecificData *) clientData;

    /* sometimes called with tsdPtr == NULL */
    if ( tsdPtr != NULL )
    {
        DeleteCriticalSection(&tsdPtr->crit);
        CloseHandle(tsdPtr->event);

        /*
         * Clean up the timer and messaging 
         * window for this thread.
         */

        if (tsdPtr->hwnd) {
	    KillTimer(tsdPtr->hwnd, INTERVAL_TIMER);
            DestroyWindow(tsdPtr->hwnd);
        }
    }

    /*
     * If this is the last thread to use the notifier, 
     * unregister the notifier window class.
     */

    Tcl_MutexLock(&notifierMutex);
    if ( notifierCount && !--notifierCount ) {
	UnregisterClassA( "TclNotifier", 
                          TclWinGetTclInstance());
    }
    Tcl_MutexUnlock(&notifierMutex);
}

This bodge doesn't address the underlying problem but has 
stopped me from tearing all my hair out,

cheers,
John Popplewell.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-10-24 15:27

Message:
Logged In: YES 
user_id=31435

FYI, you don't need an IDE to do this -- in Win9x, hit 
Ctrl+Alt+Del and kill the process directly.

A saner <wink> solution is to develop under Win2K, which 
doesn't appear to suffer this problem (the only reports 
I've seen, and experienced myself, came from Win9x boxes).

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-10-24 01:52

Message:
Logged In: NO 

For those who are still trapped in this bug's hell, I will 
gladly share the one thing that saved my sanity:  
WingIDE's 'Kill' command will shut down the program with 
apparent 100% certainty and no fear of lockups.  WingIDE 
has its own issues, so its not a perfect solution, but if 
you are like me and Joe (above) who test in small 
iterations, then using 'Kill' to quit out of your app while 
testing is a workaround that may preserve your sanity.

Perhaps the python gods and the Wing guys can get together 
and tell us how to replicate 'kill' into our code.  For 
now, I'll use WingIDE to edit, and pythonw.exe for my final 
client's delivery.

----------------------------------------------------------------------

Comment By: Howard Lightstone (hlightstone)
Date: 2001-09-05 10:43

Message:
Logged In: YES 
user_id=66570

I sometimes get bunches of these....

A tool I use (Taskinfo2000) reports that (after killing 
winoldap):

python.exe is blocked on a mutex named OLESCELOCKMUTEX.
The reported state is "Console Terminating".  There appears 
to be only one (os) thread running.


----------------------------------------------------------------------

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: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=216289&group_id=5470


From noreply@sourceforge.net  Thu Aug 15 15:19:54 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Aug 2002 07:19:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-216289 ] Programs using Tkinter sometimes can't shut down (Windows)
Message-ID: <E17fLTe-0004Yn-00@usw-sf-web5.sourceforge.net>

Bugs item #216289, was opened at 2000-10-06 22:25
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=216289&group_id=5470

Category: Windows
Group: Python 2.3
Status: Open
Resolution: Later
Priority: 3
Submitted By: Tim Peters (tim_one)
Assigned to: Fredrik Lundh (effbot)
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: Guido van Rossum (gvanrossum)
Date: 2002-08-15 10:19

Message:
Logged In: YES 
user_id=6380

Just a note so I won't forget this: Jeff Hobbs once said the
code to look at is

tk/generic/tkConsole.c:Tk_InitConsoleChannels

----------------------------------------------------------------------

Comment By: David Gravereaux (davygrvy)
Date: 2002-08-15 09:23

Message:
Logged In: YES 
user_id=7549

Hi John,

I have seen Tcl extension DLLs that set exit handlers get 
called by Tcl after they were torn-down.  NT and Win9x seem 
to be a bit different in the order of what DLLs get torn-down.  
here's a note from some old code of mine:

#ifdef __WIN32__
    // It can happen that the HEAP could have already been 
unloaded
    // from an awkward teardown caused by a Ctrl+C or other.  
Win32
    // seems to do a teardown in reverse order and by the time 
Tcl
    // knows what's going on and Tcl_Finalize calls the exit
    // handlers, this extension's data (heap?) has already been
    // unloaded by the OS.  Do a quick legal check on the 
pointer
    // first.
    //
    if (IsBadReadPtr(adapt, sizeof(T *))) return;
#endif

what's the back/stacktrace?  who is calling 
Tcl_FinalizeNotifier?  And had anyone called it before during 
the shutdown phase? I can't say with much confidence that 
this is happening here, too.  Maybe..  Could Tk be telling Tcl 
shutdown?  That's sort of backwards, if so.

I run w2k here, so I can't help in debugging from a test case.  
tclsh with a threaded build doesn't even call Tcl_Finalize to 
avoid all this!

----------------------------------------------------------------------

Comment By: Donal K. Fellows (dkf)
Date: 2002-08-15 09:09

Message:
Logged In: YES 
user_id=79902

Firstly, on the matter of threads.  Tcl/Tk on Windows uses
threads internally even in non-threaded builds.  That's
Windows for you (in particular, you can get calls parachuted
in from completely separate threads with relatively little
warning.  Also, you need threaded helpers to handle
non-blocking waiting on some kinds of objects.)

It's a bit hard to work out if the problem's been fixed
without a stack-trace (preferably with debugging symbols
enabled so that we can see what the function names and
arguments to those functions are.)  I have no  chance of
replicating this bug here (I'm currently running IRIX, but
also have some access to Solaris and Linux...)

----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-08-15 08:15

Message:
Logged In: YES 
user_id=143340

Hi to davygrvy,

my fix isn't for a thread related (deadlock) type problem - it 
is a fix for a double free type problem which is presumably 
screwing up the heap and causing the C runtime to hang.

It *is* with a threaded build (THREADDEFINES = -
DTCL_THREADS=1) which I think I enabled because I was 
using  'after' and it didn't work unless threading was 
enabled - but I may be mis-remembering here!

Also, I ended up doing all this with the debug build and 
found the -GZ flag useful - in fact it pointed out the fact that 
there was a problem with the heap.

It is worth noting that I have only seen this on Win98 and 
that using 'pythonw.exe' did *not* prevent this from 
happening,

regards John.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-14 21:00

Message:
Logged In: YES 
user_id=6380

AFAIK we never distributed a threaded build.

----------------------------------------------------------------------

Comment By: David Gravereaux (davygrvy)
Date: 2002-08-14 20:01

Message:
Logged In: YES 
user_id=7549

To johnnypops,

Where in Tcl_FinalizeNotifier() is the dead-lock occuring and 
is this with a threaded build of Tcl?


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-07-02 15:39

Message:
Logged In: YES 
user_id=31435

Jeff, a long time ago Fredrik Lundh said he was able to 
reproduce this with a short wish script (no Python, no Tkinter, 
just Tcl/Tk + wish).  I'm reassigning this to /F in the hopes 
he'll remember how.

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-07-02 14:55

Message:
Logged In: YES 
user_id=72656

I appreciate that many others see this is a problem in 
embedding Tcl, but without any clear way to reproduce this in 
Tcl/Tk itself, it's very hard for me to fix it.  I don't think that 
there is anything done in 8.4 to fix this that I recall, but if 
someone finds that the problem "goes away" with 8.4, please 
report that.

For those of course that experience this with python, the 
simple and "correct" work-around is to launch with 
pythonw.exe instead of python.exe.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-06-26 13:40

Message:
Logged In: NO 

According to http://tcl.activestate.com ActiveTcl 8.4.0 is now 
available for download.  It is new as of June 24.  I don't know 
whether this will solve our problems or not, but it's worth 
looking into.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-06-19 09:36

Message:
Logged In: NO 

I just downloaded Ruby 1.6.6 for Windows, which also uses 
Tcl/Tk 8.3 and I experience exactly the same problem there. 
So this is definitely a Tcl problem (but we know that already).

----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-06-07 15:01

Message:
Logged In: YES 
user_id=143340

Hmmm. 
I run a Python Tcl/Tk application several times every day - 
the very application that prompted my bug-hunt.

I do use "pythonw.exe" to launch it, but it used to hang 
almost as badly as "python.exe".

Whilst developing this app I used "python.exe" and 
experienced no hang-ups.

The Tcl guys point out that this bug is only one of several 
possible causes of the hang-up, maybe you are just out of 
luck.

The patch has fixed the problem on three Win98 machines, 
all of which exhibited the problem before updating the DLLs.

One thought - are you sure there weren't multiple copies of 
the tcl83.dll and tk83.dll files? My (only) copies were 
in "D:\python20\DLLs"

good luck,
John.


----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-06-03 14:55

Message:
Logged In: YES 
user_id=72656

providing Tim with a fixed DLL exactly according to John 
Popplewell's patch did not fix the problem for him.  That 
makes it seem fishy that John really didn't see the problem 
any more.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-03 12:59

Message:
Logged In: YES 
user_id=31435

I tried replacing Python 2.2.1's tk83.dll and tcl83.dll (from 
Tcl/Tk 8.3.2) with newer matched sets from

A) PythonWare's py21 distribution (Tcl/Tk 8.3.3).

and again from

B) ActiveState's Tcl/Tk 8.3.4.

All the symptoms originally reported here persisted on 
Win98SE despite that.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-05-22 09:57

Message:
Logged In: NO 

I am new to Python and encountered this bug on my very first 
Tkinter application.  It persists in Python 2.2.1 under 
Windows Me. Needless to say, it makes a bad first 
impression.  Basically, this thread says that Tkinter has been 
broken for a year and a half on a popular platform at a time 
when Python is trying to expand its user base.  Hopefully, this 
bug will be corrected soon.

If Tcl/Tk 8.4 is not released shortly you might try repackaging 
Tkinter for Win32 with an earlier version of Tcl/Tk, such as 
8.0, that doesn't encounter this problem.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 22:36

Message:
Logged In: YES 
user_id=6380

The proper action is to wait until Tcl 8.3.5 is released,
and then shaming someone else in providing you with a set of
Windowsbinaries for Tcl. You may also ask Hobbs if there's a
Windows project file to build Tcl/Tk for Windows.

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-03-11 21:31

Message:
Logged In: YES 
user_id=72656

I did end up back-porting this to the 8.3.4+ Tcl CVS on 
2002-02-25, which means it will be in an eventual 8.3.5.  
It is already in the release 8.4 alpha series.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-09 20:50

Message:
Logged In: YES 
user_id=31435

Back to Guido:  Do you think you know what the proper 
action is?  (You said that's why you reopened it, and 
there's been no new info here since then.)

----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-02-25 19:55

Message:
Logged In: YES 
user_id=143340

I knew I wasn't getting to the heart of it ....

Almost a one-liner!

It has been seriously spoiling my (otherwise crash free) 
Python experience on Win9x - hope it gets fixed soon.

cheers,
John.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-02-25 18:39

Message:
Logged In: YES 
user_id=6380

Reopened until we know what the proper action is.

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-02-25 18:32

Message:
Logged In: YES 
user_id=72656

This is mostly correct, and is fixed in the 8.4 Tcl sources 
already (I guess we can backport this).  This was mentioned 
in SF Tcl bug (account for chopped URL):

https://sourceforge.net/tracker/?
func=detail&aid=217982&group_id=10894&atid=110894

and the code comment is:

    /*
     * Only finalize the notifier if a notifier was 
installed in the
     * current thread; there is a route in which this is not
     * guaranteed to be true (when tclWin32Dll.c:DllMain() 
is called
     * with the flag DLL_PROCESS_DETACH by the OS, which 
could be
     * doing so from a thread that's never previously been 
involved
     * with Tcl, e.g. the task manager) so this check is 
important.
     *
     * Fixes Bug #217982 reported by Hugh Vu and Gene 
Leache.
     */
    if (tsdPtr == NULL) {
	return;
    }


----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-02-25 17:41

Message:
Logged In: YES 
user_id=143340

This one has been torturing me for a while.

Managed to track it down to a problem inside Tcl.
For the Tcl8.3.4 source distribution the problem is in
the file win/tclWinNotify.c 

void Tcl_FinalizeNotifier(ClientData clientData)
{
    ThreadSpecificData *tsdPtr = 
                         (ThreadSpecificData *) clientData;

    /* sometimes called with tsdPtr == NULL */
    if ( tsdPtr != NULL )
    {
        DeleteCriticalSection(&tsdPtr->crit);
        CloseHandle(tsdPtr->event);

        /*
         * Clean up the timer and messaging 
         * window for this thread.
         */

        if (tsdPtr->hwnd) {
	    KillTimer(tsdPtr->hwnd, INTERVAL_TIMER);
            DestroyWindow(tsdPtr->hwnd);
        }
    }

    /*
     * If this is the last thread to use the notifier, 
     * unregister the notifier window class.
     */

    Tcl_MutexLock(&notifierMutex);
    if ( notifierCount && !--notifierCount ) {
	UnregisterClassA( "TclNotifier", 
                          TclWinGetTclInstance());
    }
    Tcl_MutexUnlock(&notifierMutex);
}

This bodge doesn't address the underlying problem but has 
stopped me from tearing all my hair out,

cheers,
John Popplewell.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-10-24 18:27

Message:
Logged In: YES 
user_id=31435

FYI, you don't need an IDE to do this -- in Win9x, hit 
Ctrl+Alt+Del and kill the process directly.

A saner <wink> solution is to develop under Win2K, which 
doesn't appear to suffer this problem (the only reports 
I've seen, and experienced myself, came from Win9x boxes).

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-10-24 04:52

Message:
Logged In: NO 

For those who are still trapped in this bug's hell, I will 
gladly share the one thing that saved my sanity:  
WingIDE's 'Kill' command will shut down the program with 
apparent 100% certainty and no fear of lockups.  WingIDE 
has its own issues, so its not a perfect solution, but if 
you are like me and Joe (above) who test in small 
iterations, then using 'Kill' to quit out of your app while 
testing is a workaround that may preserve your sanity.

Perhaps the python gods and the Wing guys can get together 
and tell us how to replicate 'kill' into our code.  For 
now, I'll use WingIDE to edit, and pythonw.exe for my final 
client's delivery.

----------------------------------------------------------------------

Comment By: Howard Lightstone (hlightstone)
Date: 2001-09-05 13:43

Message:
Logged In: YES 
user_id=66570

I sometimes get bunches of these....

A tool I use (Taskinfo2000) reports that (after killing 
winoldap):

python.exe is blocked on a mutex named OLESCELOCKMUTEX.
The reported state is "Console Terminating".  There appears 
to be only one (os) thread running.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-04-02 16: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-06 00: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 21: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 15: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 12: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 10:40

Message:
Back to Tim since I have no clue what to do here.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-12 13: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 03: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: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=216289&group_id=5470


From noreply@sourceforge.net  Thu Aug 15 15:34:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Aug 2002 07:34:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-595537 ] pythonw has a console on Win98
Message-ID: <E17fLhL-0001bX-00@usw-sf-web4.sourceforge.net>

Bugs item #595537, was opened at 2002-08-15 14:34
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595537&group_id=5470

Category: Windows
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Paul Spencer (pgs)
Assigned to: Tim Peters (tim_one)
Summary: pythonw has a console on Win98

Initial Comment:
executing a script with pythonw (2.2.1) on win98
results in a console window being visible.  I reverted
my application to Python 2.1.1 and it works fine. 

pythonw works okay on WinXP with 2.2.1 though.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595537&group_id=5470


From noreply@sourceforge.net  Thu Aug 15 15:49:01 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Aug 2002 07:49:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-595545 ] gcc warning about __builtin_fabsf
Message-ID: <E17fLvp-0008UJ-00@usw-sf-web1.sourceforge.net>

Bugs item #595545, was opened at 2002-08-15 09:49
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595545&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Tim Peters (tim_one)
Summary: gcc warning about __builtin_fabsf

Initial Comment:
While compiling a third-party extension (see readyexec.sf.net), I 
got this output running setup.py:

gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC 
-I/usr/local/include/python2.3 -c fdpass.c -o 
build/temp.linux-i686-2.3/fdpass.o -Wall -Wpointer-arith 
-Wcast-qual -Wcast-align -Wconversion -Waggregate-return 
-Wstrict-prototypes -Wmissing-prototypes 
-Wmissing-declarations -Wnested-externs
In file included from /usr/include/math.h:350,
                 from /usr/local/include/python2.3/pyport.h:92,
                 from /usr/local/include/python2.3/Python.h:48,
                 from fdpass.c:11:
/usr/include/bits/mathinline.h: In function `fabsf':
/usr/include/bits/mathinline.h:446: warning: passing arg 1 of 
`__builtin_fabsf' as `float' rather than `double' due to prototype
gcc -shared build/temp.linux-i686-2.3/fdpass.o -o 
build/lib.linux-i686-2.3/fdpass.so

The extension wasn't using fabs, though I notice the addition of 
-Wstrict-prototypes to the gcc command, so maybe this is a "not 
to worry" sort of thing.

Relevant (I think) information about the system is:

    glibc 2.2.4 (the source of /usr/include/bits/mathinline.h)
    gcc 2.96

The chunk of code in mathinline.h involving __builtin_fabsf is

#if __GNUC_PREREQ (2, 8)
__inline_mathcodeNP_ (double, fabs, __x, return __builtin_fabs 
(__x))
__inline_mathcodeNP_ (float, fabsf, __x, return __builtin_fabsf 
(__x))
__inline_mathcodeNP_ (long double, fabsl, __x, return 
__builtin_fabsl (__x))
__inline_mathcodeNP_ (long double, __fabsl, __x, return 
__builtin_fabsl (__x))
#else
__inline_mathop (fabs, "fabs")
__inline_mathop_ (long double, __fabsl, "fabs")
#endif


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595545&group_id=5470


From noreply@sourceforge.net  Thu Aug 15 16:52:41 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Aug 2002 08:52:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-595545 ] gcc warning about __builtin_fabsf
Message-ID: <E17fMvR-0006v5-00@usw-sf-web5.sourceforge.net>

Bugs item #595545, was opened at 2002-08-15 10:49
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595545&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
>Assigned to: Martin v. Löwis (loewis)
Summary: gcc warning about __builtin_fabsf

Initial Comment:
While compiling a third-party extension (see readyexec.sf.net), I 
got this output running setup.py:

gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC 
-I/usr/local/include/python2.3 -c fdpass.c -o 
build/temp.linux-i686-2.3/fdpass.o -Wall -Wpointer-arith 
-Wcast-qual -Wcast-align -Wconversion -Waggregate-return 
-Wstrict-prototypes -Wmissing-prototypes 
-Wmissing-declarations -Wnested-externs
In file included from /usr/include/math.h:350,
                 from /usr/local/include/python2.3/pyport.h:92,
                 from /usr/local/include/python2.3/Python.h:48,
                 from fdpass.c:11:
/usr/include/bits/mathinline.h: In function `fabsf':
/usr/include/bits/mathinline.h:446: warning: passing arg 1 of 
`__builtin_fabsf' as `float' rather than `double' due to prototype
gcc -shared build/temp.linux-i686-2.3/fdpass.o -o 
build/lib.linux-i686-2.3/fdpass.so

The extension wasn't using fabs, though I notice the addition of 
-Wstrict-prototypes to the gcc command, so maybe this is a "not 
to worry" sort of thing.

Relevant (I think) information about the system is:

    glibc 2.2.4 (the source of /usr/include/bits/mathinline.h)
    gcc 2.96

The chunk of code in mathinline.h involving __builtin_fabsf is

#if __GNUC_PREREQ (2, 8)
__inline_mathcodeNP_ (double, fabs, __x, return __builtin_fabs 
(__x))
__inline_mathcodeNP_ (float, fabsf, __x, return __builtin_fabsf 
(__x))
__inline_mathcodeNP_ (long double, fabsl, __x, return 
__builtin_fabsl (__x))
__inline_mathcodeNP_ (long double, __fabsl, __x, return 
__builtin_fabsl (__x))
#else
__inline_mathop (fabs, "fabs")
__inline_mathop_ (long double, __fabsl, "fabs")
#endif


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-08-15 11:52

Message:
Logged In: YES 
user_id=31435

Maybe Martin has a clue. so assigned to him.  Line 92 of 
pyport.h is simply

#include <math.h>

There's not enough info here to guess what line 446 of 
mathinline.h may be, but it's not in Python code regardless.  
Note that Python never calls fabsf either.

Offhand it looks like you should file this report against gcc.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595545&group_id=5470


From noreply@sourceforge.net  Thu Aug 15 17:34:16 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Aug 2002 09:34:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-595601 ] file (& socket) I/O are not thread safe
Message-ID: <E17fNZg-0002xw-00@usw-sf-web2.sourceforge.net>

Bugs item #595601, was opened at 2002-08-15 16:34
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595601&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Nobody/Anonymous (nobody)
Summary: file (& socket) I/O are not thread safe

Initial Comment:
We recently found an assertion failure in the universal
newline support when running a multithreaded program
where two threads used the same Python file object. 
The assert(stream != NULL) test in 
Py_UniversalNewlineFread() fails once in a blue moon,
where stream is the stdio FILE * that the fileobject
wraps.  Further analysis suggests that there is a race
condition between checking FILE * and using FILE * that
exists in at least Python 2.1 and up.

I'll actually describe the problem as it exists in
Python 2.2, because it is simpler to avoid the
universal newline code.  That code isn't the source of
the problem, although it's assert() uncovers it in a
clear way.

In file_read() (rev 2.141.6.5), the first thing it does
is check if f_fp (the FILE *) is NULL.  If so it raises
an IOError -- operation on closed file object.  Later,
file_read() enters a for loop that calls fread() until
enough bytes have been read.

	for (;;) {
		Py_BEGIN_ALLOW_THREADS
		errno = 0;
		chunksize = fread(BUF(v) + bytesread, 1,
				  buffersize - bytesread, f->f_fp);
		Py_END_ALLOW_THREADS
		if (chunksize == 0) {
			if (!ferror(f->f_fp))
				break;
			PyErr_SetFromErrno(PyExc_IOError);
			clearerr(f->f_fp);
			Py_DECREF(v);
			return NULL;
		}

The problem is that fread() is called after the global
interpreter lock is released.  Since the lock is
released, another Python thread could run and modify
the file object, changing the value of f->f_fp.  Under
the current interpreter lock scheme, it isn't safe to
use f->f_fp without holding the interpreter lock.

The current file_read() code can fail in a variety of
ways.  It's possible for a second thread to close the
file, which will set f->f_fp to NULL.  Who knows what
fread() will do when NULL is passed.

The universal newline code is squirrels the FILE * in a
local variable, which is worse.  If it happens that
another thread closes the file, at best the local
points to a closed FILE *.  But that memory could get
recycled and then there's no way to know what it points to.

socket I/O has a similar problem with unsafe sharing of
the file descriptor.  However, this problem seems less
severe in general, because we'd just be passing a bogus
file descriptor to a system call.  We don't have to
worry about whether stdio will dump core when passed a
bogus pointer.  There is a chance the a socket will be
closed and its file descriptor used for a different
socket.  So a call to recv() with one socket ends up
using a different socket.  That will be a nightmare to
debug, but it won't cause a segfault.  (And, in
general, files and sockets shouldn't be shared between
application threads unless the application is going to
make sure its safe.)

The solution to this problem is to use a
per-file-object lock to guard access to f->f_fp.  No
thread should read or right f->f_fp without holding the
lock.  To make sure that other threads get a chance to
run when there is contention for the file, the
file-object lock should never be held when the GIL is held.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595601&group_id=5470


From noreply@sourceforge.net  Thu Aug 15 17:31:33 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Aug 2002 09:31:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-558072 ] faqwiz.py could do email obfuscation
Message-ID: <E17fNX3-0003HW-00@usw-sf-web4.sourceforge.net>

Bugs item #558072, was opened at 2002-05-19 16:50
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=558072&group_id=5470

Category: Demos and Tools
Group: Feature Request
>Status: Closed
>Resolution: Rejected
Priority: 3
Submitted By: Christian Reis (kiko_async)
Assigned to: Guido van Rossum (gvanrossum)
Summary: faqwiz.py could do email obfuscation

Initial Comment:
Faqwiz.py could obfuscate emails very easily, simply by
replacing @ by some other symbol in it's output. I've
homecooked a solution that basically involves:

adding to faqconf.py:

 # Obfuscate @ symbol as

 OBFUSCATE="-at-"

and changing interpolate() in faqwiz.py:

 def _interpolate(format, args, kw):
    try:
        quote = kw['_quote']
    except KeyError:
        quote = 1 
    d = (kw,) + args + (faqconf.__dict__,)
    m = MagicDict(d, quote)
    return string.replace(format % m, '@', OBFUSCATE)

This isn't my favourite solution, though, but since I
find the code a bit hard to follow, it suffices for
now. I'm willing to work a bit more on this if it
interests people.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-15 12:31

Message:
Logged In: YES 
user_id=6380

I'm rejecting this, not because i think it's a bad idea, but
because I have no time to maintain the faq wizard any more.

Christian Reis (the poster of this bug) has offered to take
over maintenance, but he won't use SourceForge. Christian,
if you ever get to this, would you mind at least adding a
URL to this SF bug report?

----------------------------------------------------------------------

Comment By: Christian Reis (kiko_async)
Date: 2002-06-13 07:22

Message:
Logged In: YES 
user_id=222305

You're right, I did. The patch attached does it in a less
broken way, though I don't like the way I have to
permanently change last_changed_email - I just wanted to
obfuscate on the printing.

Anyway, since the link can't be a mailto anymore (which may
be considered a regression) I've removed the relevant link
from faqconf.py.

I've kept the faqconf.py OBFUSCATE symbol but am unsure as
to where it should go.

I've also rolled in two changes I did locally to my faqwiz.
The first one is a simple CSS mod that avoids the need for
an external image and makes the PRE sections highlight.

The second one is adding LABEL to the radiobuttons on the
front page and removing the "/"s and <BR> between the first
"query argument" options. It was confusing users at the
office. The LABEL tag allows you to click on the label and
have the radiobutton select, and is supported on superior
browsers (cough mozilla cough).

I'd appreciate comments, thanks.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-10 16:45

Message:
Logged In: YES 
user_id=6380

Clearly this does too much -- interpolate is used in a
number of contexts where a @ shouldn't be obfuscated, e.g.
commands to be executed by the shell.

I'm unclear on *where* you'd like to obfuscate email
addresses. Do you only want to obfuscate the email address
of the person who modified the entry, or do you want to
obfuscate all @ signs anywhere in the text? The latter seems
overkill, and can cause breakage in code samples that happen
to use @ signs.

BTW, you're right that this code is hard to follow! It could
benefit from a few comments here or there... :-(

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-05 14:46

Message:
Logged In: YES 
user_id=6380

Good idea.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=558072&group_id=5470


From noreply@sourceforge.net  Thu Aug 15 18:24:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Aug 2002 10:24:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-595545 ] gcc warning about __builtin_fabsf
Message-ID: <E17fOLq-0000Sr-00@usw-sf-web5.sourceforge.net>

Bugs item #595545, was opened at 2002-08-15 16:49
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595545&group_id=5470

Category: Extension Modules
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Martin v. Löwis (loewis)
Summary: gcc warning about __builtin_fabsf

Initial Comment:
While compiling a third-party extension (see readyexec.sf.net), I 
got this output running setup.py:

gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC 
-I/usr/local/include/python2.3 -c fdpass.c -o 
build/temp.linux-i686-2.3/fdpass.o -Wall -Wpointer-arith 
-Wcast-qual -Wcast-align -Wconversion -Waggregate-return 
-Wstrict-prototypes -Wmissing-prototypes 
-Wmissing-declarations -Wnested-externs
In file included from /usr/include/math.h:350,
                 from /usr/local/include/python2.3/pyport.h:92,
                 from /usr/local/include/python2.3/Python.h:48,
                 from fdpass.c:11:
/usr/include/bits/mathinline.h: In function `fabsf':
/usr/include/bits/mathinline.h:446: warning: passing arg 1 of 
`__builtin_fabsf' as `float' rather than `double' due to prototype
gcc -shared build/temp.linux-i686-2.3/fdpass.o -o 
build/lib.linux-i686-2.3/fdpass.so

The extension wasn't using fabs, though I notice the addition of 
-Wstrict-prototypes to the gcc command, so maybe this is a "not 
to worry" sort of thing.

Relevant (I think) information about the system is:

    glibc 2.2.4 (the source of /usr/include/bits/mathinline.h)
    gcc 2.96

The chunk of code in mathinline.h involving __builtin_fabsf is

#if __GNUC_PREREQ (2, 8)
__inline_mathcodeNP_ (double, fabs, __x, return __builtin_fabs 
(__x))
__inline_mathcodeNP_ (float, fabsf, __x, return __builtin_fabsf 
(__x))
__inline_mathcodeNP_ (long double, fabsl, __x, return 
__builtin_fabsl (__x))
__inline_mathcodeNP_ (long double, __fabsl, __x, return 
__builtin_fabsl (__x))
#else
__inline_mathop (fabs, "fabs")
__inline_mathop_ (long double, __fabsl, "fabs")
#endif


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-08-15 19:24

Message:
Logged In: YES 
user_id=21627

This problem is caused by -Wconversion; the compiler warns
that it will call __builtin_fabsf with a float argument -
even though C would default to double in absence of prototypes.

The prototype for __builtin_fabsf is built into gcc. The
call to __builtin_fabsf originates from the inline function
fabsf defined by the inline_mathcode macro.

This warning occurs every time you include math.h, and
compile with both -O and -Wconversions. You may want to
report this as a glibc bug, for not supressing the warning.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-08-15 17:52

Message:
Logged In: YES 
user_id=31435

Maybe Martin has a clue. so assigned to him.  Line 92 of 
pyport.h is simply

#include <math.h>

There's not enough info here to guess what line 446 of 
mathinline.h may be, but it's not in Python code regardless.  
Note that Python never calls fabsf either.

Offhand it looks like you should file this report against gcc.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595545&group_id=5470


From noreply@sourceforge.net  Thu Aug 15 19:27:35 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Aug 2002 11:27:35 -0700
Subject: [Python-bugs-list] [ python-Bugs-595671 ] base64.decodestring raises error on ""
Message-ID: <E17fPLL-0004yK-00@usw-sf-web1.sourceforge.net>

Bugs item #595671, was opened at 2002-08-15 18:27
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595671&group_id=5470

Category: Python Library
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Danny Yoo (dyoo)
Assigned to: Nobody/Anonymous (nobody)
Summary: base64.decodestring raises error on ""

Initial Comment:
The SOAPpy project uses base64.decodestring() to decode
base64-encoded strings.  One issue that's been brought
up is the exception-raising behavior of decodestring()
if given the empty string in Python 2.2:

### In Python 2.2.1
>>> base64.decodestring("")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/opt/Python-2.2/lib/python2.2/base64.py", line
44, in decodestring
    return binascii.a2b_base64(s)
binascii.Error: Cannot decode empty input
###

This is a behavioral change from Python 2.1.1, where it
had previously returned the empty string:

### Python 2.1.1
>>> base64.decodestring("")
""
###

This change seems to have been introduced in -r2.29 of
binascii.c.  Is this the expected behavior of
decodestring() now?

For more information about our discussion on this,
please see the thread started here:

http://www.geocrawler.com/lists/3/SourceForge/12392/0/9289852/

Thanks again!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595671&group_id=5470


From noreply@sourceforge.net  Thu Aug 15 20:26:40 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Aug 2002 12:26:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-595671 ] base64.decodestring raises error on ""
Message-ID: <E17fQGW-0002Uj-00@usw-sf-web3.sourceforge.net>

Bugs item #595671, was opened at 2002-08-15 14:27
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595671&group_id=5470

Category: Python Library
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Danny Yoo (dyoo)
>Assigned to: Barry A. Warsaw (bwarsaw)
>Summary: base64.decodestring raises error on ""

Initial Comment:
The SOAPpy project uses base64.decodestring() to decode
base64-encoded strings.  One issue that's been brought
up is the exception-raising behavior of decodestring()
if given the empty string in Python 2.2:

### In Python 2.2.1
>>> base64.decodestring("")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/opt/Python-2.2/lib/python2.2/base64.py", line
44, in decodestring
    return binascii.a2b_base64(s)
binascii.Error: Cannot decode empty input
###

This is a behavioral change from Python 2.1.1, where it
had previously returned the empty string:

### Python 2.1.1
>>> base64.decodestring("")
""
###

This change seems to have been introduced in -r2.29 of
binascii.c.  Is this the expected behavior of
decodestring() now?

For more information about our discussion on this,
please see the thread started here:

http://www.geocrawler.com/lists/3/SourceForge/12392/0/9289852/

Thanks again!

----------------------------------------------------------------------

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2002-08-15 15:26

Message:
Logged In: YES 
user_id=12800

Note that Python 2.1.3 has the same behavior as Python 2.2.
 This behavior was introduced to fix SF bug #430849, but
that fix was actually incorrect.  The SystemError (bad
internal call) was caused by trying to resize the empty
string, which is shared, and thus has a refcount != 1. 
_PyString_Resize() requires the refcount of the string you
pass in to be == 1.

The proper fix should be to not resize the empty string in
binascii_a2b_base64() and to remove the exception raised in
the patch for #430849.  I'll work out a patch for that and
upload it here.  It will be a Python 2.2 bug fix candiate as
well.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595671&group_id=5470


From noreply@sourceforge.net  Thu Aug 15 20:34:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Aug 2002 12:34:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-595601 ] file (& socket) I/O are not thread safe
Message-ID: <E17fQNe-0002hD-00@usw-sf-web3.sourceforge.net>

Bugs item #595601, was opened at 2002-08-15 16:34
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595601&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Hylton (jhylton)
>Assigned to: Jeremy Hylton (jhylton)
Summary: file (& socket) I/O are not thread safe

Initial Comment:
We recently found an assertion failure in the universal
newline support when running a multithreaded program
where two threads used the same Python file object. 
The assert(stream != NULL) test in 
Py_UniversalNewlineFread() fails once in a blue moon,
where stream is the stdio FILE * that the fileobject
wraps.  Further analysis suggests that there is a race
condition between checking FILE * and using FILE * that
exists in at least Python 2.1 and up.

I'll actually describe the problem as it exists in
Python 2.2, because it is simpler to avoid the
universal newline code.  That code isn't the source of
the problem, although it's assert() uncovers it in a
clear way.

In file_read() (rev 2.141.6.5), the first thing it does
is check if f_fp (the FILE *) is NULL.  If so it raises
an IOError -- operation on closed file object.  Later,
file_read() enters a for loop that calls fread() until
enough bytes have been read.

	for (;;) {
		Py_BEGIN_ALLOW_THREADS
		errno = 0;
		chunksize = fread(BUF(v) + bytesread, 1,
				  buffersize - bytesread, f->f_fp);
		Py_END_ALLOW_THREADS
		if (chunksize == 0) {
			if (!ferror(f->f_fp))
				break;
			PyErr_SetFromErrno(PyExc_IOError);
			clearerr(f->f_fp);
			Py_DECREF(v);
			return NULL;
		}

The problem is that fread() is called after the global
interpreter lock is released.  Since the lock is
released, another Python thread could run and modify
the file object, changing the value of f->f_fp.  Under
the current interpreter lock scheme, it isn't safe to
use f->f_fp without holding the interpreter lock.

The current file_read() code can fail in a variety of
ways.  It's possible for a second thread to close the
file, which will set f->f_fp to NULL.  Who knows what
fread() will do when NULL is passed.

The universal newline code is squirrels the FILE * in a
local variable, which is worse.  If it happens that
another thread closes the file, at best the local
points to a closed FILE *.  But that memory could get
recycled and then there's no way to know what it points to.

socket I/O has a similar problem with unsafe sharing of
the file descriptor.  However, this problem seems less
severe in general, because we'd just be passing a bogus
file descriptor to a system call.  We don't have to
worry about whether stdio will dump core when passed a
bogus pointer.  There is a chance the a socket will be
closed and its file descriptor used for a different
socket.  So a call to recv() with one socket ends up
using a different socket.  That will be a nightmare to
debug, but it won't cause a segfault.  (And, in
general, files and sockets shouldn't be shared between
application threads unless the application is going to
make sure its safe.)

The solution to this problem is to use a
per-file-object lock to guard access to f->f_fp.  No
thread should read or right f->f_fp without holding the
lock.  To make sure that other threads get a chance to
run when there is contention for the file, the
file-object lock should never be held when the GIL is held.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595601&group_id=5470


From noreply@sourceforge.net  Thu Aug 15 20:39:24 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Aug 2002 12:39:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-582297 ] pickle error message unhelpful
Message-ID: <E17fQSq-0002os-00@usw-sf-web3.sourceforge.net>

Bugs item #582297, was opened at 2002-07-16 15:22
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=582297&group_id=5470

Category: Python Library
Group: Python 2.2
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Dave Aitel (wabe0x90)
Assigned to: Nobody/Anonymous (nobody)
Summary: pickle error message unhelpful

Initial Comment:
Version: Python 2.2 (#1, Feb 24 2002, 16:21:58) 
I was trying to pickle a class which had an open
socket, the exception  I got was:
File "/usr/lib/python2.2/pickle.py", line 969, in dump
    Pickler(file, bin).dump(object)
  File "/usr/lib/python2.2/pickle.py", line 115, in dump
    self.save(object)
  File "/usr/lib/python2.2/pickle.py", line 221, in save
    f(self, object)
  File "/usr/lib/python2.2/pickle.py", line 494, in
save_inst
    save(stuff)
  File "/usr/lib/python2.2/pickle.py", line 221, in save
    f(self, object)
  File "/usr/lib/python2.2/pickle.py", line 443, in
save_dict
    save(value)
  File "/usr/lib/python2.2/pickle.py", line 221, in save
    f(self, object)
  File "/usr/lib/python2.2/pickle.py", line 494, in
save_inst
    save(stuff)
  File "/usr/lib/python2.2/pickle.py", line 221, in save
    f(self, object)
  File "/usr/lib/python2.2/pickle.py", line 443, in
save_dict
    save(value)
  File "/usr/lib/python2.2/pickle.py", line 185, in save
    tup = reduce()
  File "/usr/lib/python2.2/copy_reg.py", line 57, in
_reduce
    state = base(self)
TypeError: an integer is required

Only by adding this to copy_reg.py was I able to figure
out what was really going on:
def _reduce(self):
    for base in self.__class__.__mro__:
        if hasattr(base, '__flags__') and not
base.__flags__ & _HEAPTYPE:
            break
    else:
        base = object # not really reachable
    if base is object:
        state = None
    else:
################I added the next line
        print "dave: type of self="+str(self)
        state = base(self)
    args = (self.__class__, base, state)


It would be REALLY nice if pickle returned some sort of
better error message so I didn't have to do that,
especially for beginers like myself. :>



----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-08-15 19:39

Message:
Logged In: YES 
user_id=31392

Closed for lack of response.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-07-16 16:50

Message:
Logged In: YES 
user_id=31392

Can you provide some sample code that cause the obscure
error message?  When I tried to reproduce this problem, I
create an instance with a socket attribute.  When I pickled
it, I get a clear error message:

>>> import socket
>>> class Foo(object):
...     def __init__(self):
...             self.sock = socket.socket(socket.AF_INET,
socket.SOCK_STREAM)
... 
>>> f = Foo()
>>> pickle.dumps(f)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.3/pickle.py", line 1055, in dumps
    Pickler(file, bin).dump(object)
  File "/usr/local/lib/python2.3/pickle.py", line 165, in dump
    self.save(object)
  File "/usr/local/lib/python2.3/pickle.py", line 275, in save
    f(self, object)
  File "/usr/local/lib/python2.3/pickle.py", line 555, in
save_inst
    save(stuff)
  File "/usr/local/lib/python2.3/pickle.py", line 275, in save
    f(self, object)
  File "/usr/local/lib/python2.3/pickle.py", line 504, in
save_dict
    save(value)
  File "/usr/local/lib/python2.3/pickle.py", line 239, in save
    tup = reduce()
  File "/usr/local/lib/python2.3/copy_reg.py", line 57, in
_reduce
    raise TypeError, "can't pickle %s objects" % base.__name__
TypeError: can't pickle socket objects

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=582297&group_id=5470


From noreply@sourceforge.net  Thu Aug 15 20:54:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Aug 2002 12:54:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-595671 ] base64.decodestring raises error on ""
Message-ID: <E17fQhU-00038J-00@usw-sf-web3.sourceforge.net>

Bugs item #595671, was opened at 2002-08-15 14:27
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595671&group_id=5470

Category: Python Library
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Danny Yoo (dyoo)
Assigned to: Barry A. Warsaw (bwarsaw)
>Summary: base64.decodestring raises error on ""

Initial Comment:
The SOAPpy project uses base64.decodestring() to decode
base64-encoded strings.  One issue that's been brought
up is the exception-raising behavior of decodestring()
if given the empty string in Python 2.2:

### In Python 2.2.1
>>> base64.decodestring("")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/opt/Python-2.2/lib/python2.2/base64.py", line
44, in decodestring
    return binascii.a2b_base64(s)
binascii.Error: Cannot decode empty input
###

This is a behavioral change from Python 2.1.1, where it
had previously returned the empty string:

### Python 2.1.1
>>> base64.decodestring("")
""
###

This change seems to have been introduced in -r2.29 of
binascii.c.  Is this the expected behavior of
decodestring() now?

For more information about our discussion on this,
please see the thread started here:

http://www.geocrawler.com/lists/3/SourceForge/12392/0/9289852/

Thanks again!

----------------------------------------------------------------------

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2002-08-15 15:54

Message:
Logged In: YES 
user_id=12800

Attached is a patch candidate for Python 2.3cvs.  I haven't
checked the backport to 2.2.2 yet, but its probably not much
different.

----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2002-08-15 15:26

Message:
Logged In: YES 
user_id=12800

Note that Python 2.1.3 has the same behavior as Python 2.2.
 This behavior was introduced to fix SF bug #430849, but
that fix was actually incorrect.  The SystemError (bad
internal call) was caused by trying to resize the empty
string, which is shared, and thus has a refcount != 1. 
_PyString_Resize() requires the refcount of the string you
pass in to be == 1.

The proper fix should be to not resize the empty string in
binascii_a2b_base64() and to remove the exception raised in
the patch for #430849.  I'll work out a patch for that and
upload it here.  It will be a Python 2.2 bug fix candiate as
well.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595671&group_id=5470


From noreply@sourceforge.net  Thu Aug 15 21:49:29 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Aug 2002 13:49:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-595601 ] file (& socket) I/O are not thread safe
Message-ID: <E17fRYf-0007lW-00@usw-sf-web2.sourceforge.net>

Bugs item #595601, was opened at 2002-08-15 18:34
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595601&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Jeremy Hylton (jhylton)
Summary: file (& socket) I/O are not thread safe

Initial Comment:
We recently found an assertion failure in the universal
newline support when running a multithreaded program
where two threads used the same Python file object. 
The assert(stream != NULL) test in 
Py_UniversalNewlineFread() fails once in a blue moon,
where stream is the stdio FILE * that the fileobject
wraps.  Further analysis suggests that there is a race
condition between checking FILE * and using FILE * that
exists in at least Python 2.1 and up.

I'll actually describe the problem as it exists in
Python 2.2, because it is simpler to avoid the
universal newline code.  That code isn't the source of
the problem, although it's assert() uncovers it in a
clear way.

In file_read() (rev 2.141.6.5), the first thing it does
is check if f_fp (the FILE *) is NULL.  If so it raises
an IOError -- operation on closed file object.  Later,
file_read() enters a for loop that calls fread() until
enough bytes have been read.

	for (;;) {
		Py_BEGIN_ALLOW_THREADS
		errno = 0;
		chunksize = fread(BUF(v) + bytesread, 1,
				  buffersize - bytesread, f->f_fp);
		Py_END_ALLOW_THREADS
		if (chunksize == 0) {
			if (!ferror(f->f_fp))
				break;
			PyErr_SetFromErrno(PyExc_IOError);
			clearerr(f->f_fp);
			Py_DECREF(v);
			return NULL;
		}

The problem is that fread() is called after the global
interpreter lock is released.  Since the lock is
released, another Python thread could run and modify
the file object, changing the value of f->f_fp.  Under
the current interpreter lock scheme, it isn't safe to
use f->f_fp without holding the interpreter lock.

The current file_read() code can fail in a variety of
ways.  It's possible for a second thread to close the
file, which will set f->f_fp to NULL.  Who knows what
fread() will do when NULL is passed.

The universal newline code is squirrels the FILE * in a
local variable, which is worse.  If it happens that
another thread closes the file, at best the local
points to a closed FILE *.  But that memory could get
recycled and then there's no way to know what it points to.

socket I/O has a similar problem with unsafe sharing of
the file descriptor.  However, this problem seems less
severe in general, because we'd just be passing a bogus
file descriptor to a system call.  We don't have to
worry about whether stdio will dump core when passed a
bogus pointer.  There is a chance the a socket will be
closed and its file descriptor used for a different
socket.  So a call to recv() with one socket ends up
using a different socket.  That will be a nightmare to
debug, but it won't cause a segfault.  (And, in
general, files and sockets shouldn't be shared between
application threads unless the application is going to
make sure its safe.)

The solution to this problem is to use a
per-file-object lock to guard access to f->f_fp.  No
thread should read or right f->f_fp without holding the
lock.  To make sure that other threads get a chance to
run when there is contention for the file, the
file-object lock should never be held when the GIL is held.


----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2002-08-15 22:49

Message:
Logged In: YES 
user_id=45365

I'm not sure your solution of locking in the file object is feasible. Every call of PyFile_AsFile() is dangerous, if the  code proceeds to release the GIL before using the FILE* it's in danger. And this code could be in extension modules too (I know there's quite a few in my own img package).

When I did the universal newlines patch I basically ignored the problem (thinking that no-one in their right mind would close a file in one thread while it's still in use in another: how wrong can one be:-).

The only real solution may be to get rid of PyFile_AsFile altogether, and replace it with PyFile_AsFileLocked() and PyFile_Unlock() and make these calls somehow work even when the GIL is held (possibly by temporarily releasing the GIL while acquiring the file lock).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595601&group_id=5470


From noreply@sourceforge.net  Thu Aug 15 21:54:11 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Aug 2002 13:54:11 -0700
Subject: [Python-bugs-list] [ python-Bugs-487703 ] Replace strcat, strcpy
Message-ID: <E17fRdD-0008I4-00@usw-sf-web1.sourceforge.net>

Bugs item #487703, was opened at 2001-11-30 23:39
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=487703&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Tim Peters (tim_one)
Summary: Replace strcat, strcpy

Initial Comment:
Alex Martelli sent this URL for a paper describing the 
safer strlcat and strlcpy functions:

>http://www.usenix.org/events/usenix99/full_papers/mill
ert/millert_html/>

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-08-15 22:54

Message:
Logged In: YES 
user_id=21627

I'm opposed to strlcat/strlcpy in the first place. It
usually starts long debates, and opponents usually argue
that it serves no real purpose, and gives a shallow feeling
of safety when there really is none. Proponents of strlcpy
are quite religious about spreading it quickly. For example,
there was a heated discussion about adding strlcpy to GNU
libc, after which glibc maintainers to ignore them.

I propose to do the same thing in Python.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 17:56

Message:
Logged In: YES 
user_id=35752


If they want people to use their code why do they put that
stupid clause in the license?  How annoying.  Attached is
a strlcpy function that I wrote based on the man page:

http://www.tac.eu.org/cgi-bin/man-cgi?strlcpy+3

Do whatever you like with it. :-)  I would appreciate it if
someone would review the code however.  There are a number
of corner cases that are easy to screw up.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-11 23:51

Message:
Logged In: YES 
user_id=6380

Strictly speaking, binary Python distributions would be
required to contain a copy of the entire license for that
file. I don't like that.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-12-03 19:59

Message:
Logged In: YES 
user_id=31435

I'm attaching a patch from Alex Martelli; haven't reviewed 
it, and don't expect to before 2.2 final is released.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-12-03 11:47

Message:
Logged In: YES 
user_id=38388

Time for PyOS_strlcat() and PyOS_strlcpy() ? Looking at the web-site it seems that we could simply copy the 
code into the Python distro. I'd then suggest to bundle all the string helpers into a new file: e.g. mystrapis.c.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=487703&group_id=5470


From noreply@sourceforge.net  Thu Aug 15 22:18:57 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Aug 2002 14:18:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-595671 ] base64.decodestring raises error on ""
Message-ID: <E17fS1B-0004bo-00@usw-sf-web5.sourceforge.net>

Bugs item #595671, was opened at 2002-08-15 14:27
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595671&group_id=5470

Category: Python Library
Group: Python 2.2.1
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Danny Yoo (dyoo)
Assigned to: Barry A. Warsaw (bwarsaw)
>Summary: base64.decodestring raises error on ""

Initial Comment:
The SOAPpy project uses base64.decodestring() to decode
base64-encoded strings.  One issue that's been brought
up is the exception-raising behavior of decodestring()
if given the empty string in Python 2.2:

### In Python 2.2.1
>>> base64.decodestring("")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/opt/Python-2.2/lib/python2.2/base64.py", line
44, in decodestring
    return binascii.a2b_base64(s)
binascii.Error: Cannot decode empty input
###

This is a behavioral change from Python 2.1.1, where it
had previously returned the empty string:

### Python 2.1.1
>>> base64.decodestring("")
""
###

This change seems to have been introduced in -r2.29 of
binascii.c.  Is this the expected behavior of
decodestring() now?

For more information about our discussion on this,
please see the thread started here:

http://www.geocrawler.com/lists/3/SourceForge/12392/0/9289852/

Thanks again!

----------------------------------------------------------------------

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2002-08-15 17:18

Message:
Logged In: YES 
user_id=12800

Patch to binascii.c applies to Python 2.2 maint, but there's
no Lib/test/test_base64.py.  I'm going to copy those over
from Python 2.3 (with the addition of
Lib/test/output/test_base64) and check all this stuff in.

----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2002-08-15 15:54

Message:
Logged In: YES 
user_id=12800

Attached is a patch candidate for Python 2.3cvs.  I haven't
checked the backport to 2.2.2 yet, but its probably not much
different.

----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2002-08-15 15:26

Message:
Logged In: YES 
user_id=12800

Note that Python 2.1.3 has the same behavior as Python 2.2.
 This behavior was introduced to fix SF bug #430849, but
that fix was actually incorrect.  The SystemError (bad
internal call) was caused by trying to resize the empty
string, which is shared, and thus has a refcount != 1. 
_PyString_Resize() requires the refcount of the string you
pass in to be == 1.

The proper fix should be to not resize the empty string in
binascii_a2b_base64() and to remove the exception raised in
the patch for #430849.  I'll work out a patch for that and
upload it here.  It will be a Python 2.2 bug fix candiate as
well.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595671&group_id=5470


From noreply@sourceforge.net  Thu Aug 15 22:33:24 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Aug 2002 14:33:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-487703 ] Replace strcat, strcpy
Message-ID: <E17fSFA-0005J5-00@usw-sf-web3.sourceforge.net>

Bugs item #487703, was opened at 2001-11-30 22:39
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=487703&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Tim Peters (tim_one)
>Assigned to: Nobody/Anonymous (nobody)
Summary: Replace strcat, strcpy

Initial Comment:
Alex Martelli sent this URL for a paper describing the 
safer strlcat and strlcpy functions:

>http://www.usenix.org/events/usenix99/full_papers/mill
ert/millert_html/>

----------------------------------------------------------------------

>Comment By: Neil Schemenauer (nascheme)
Date: 2002-08-15 21:33

Message:
Logged In: YES 
user_id=35752

Duplicate, see www.python.org/sf/595703 .

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-15 20:54

Message:
Logged In: YES 
user_id=21627

I'm opposed to strlcat/strlcpy in the first place. It
usually starts long debates, and opponents usually argue
that it serves no real purpose, and gives a shallow feeling
of safety when there really is none. Proponents of strlcpy
are quite religious about spreading it quickly. For example,
there was a heated discussion about adding strlcpy to GNU
libc, after which glibc maintainers to ignore them.

I propose to do the same thing in Python.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 16:56

Message:
Logged In: YES 
user_id=35752


If they want people to use their code why do they put that
stupid clause in the license?  How annoying.  Attached is
a strlcpy function that I wrote based on the man page:

http://www.tac.eu.org/cgi-bin/man-cgi?strlcpy+3

Do whatever you like with it. :-)  I would appreciate it if
someone would review the code however.  There are a number
of corner cases that are easy to screw up.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-11 22:51

Message:
Logged In: YES 
user_id=6380

Strictly speaking, binary Python distributions would be
required to contain a copy of the entire license for that
file. I don't like that.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-12-03 18:59

Message:
Logged In: YES 
user_id=31435

I'm attaching a patch from Alex Martelli; haven't reviewed 
it, and don't expect to before 2.2 final is released.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-12-03 10:47

Message:
Logged In: YES 
user_id=38388

Time for PyOS_strlcat() and PyOS_strlcpy() ? Looking at the web-site it seems that we could simply copy the 
code into the Python distro. I'd then suggest to bundle all the string helpers into a new file: e.g. mystrapis.c.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=487703&group_id=5470


From noreply@sourceforge.net  Thu Aug 15 23:08:44 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Aug 2002 15:08:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-595763 ] Get rid of FutureWarnings in Carbon
Message-ID: <E17fSnM-0002BM-00@usw-sf-web4.sourceforge.net>

Bugs item #595763, was opened at 2002-08-16 00:08
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595763&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Get rid of FutureWarnings in Carbon

Initial Comment:
I should get rid of the FutureWarnings in the Carbon constant definition files (as soon as a way is devised to actually get the right bit patterns in 2.3 without getting the warnings).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595763&group_id=5470


From noreply@sourceforge.net  Thu Aug 15 23:21:30 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Aug 2002 15:21:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-595766 ] timemodule doesn't build on solaris 8
Message-ID: <E17fSzi-00064G-00@usw-sf-web3.sourceforge.net>

Bugs item #595766, was opened at 2002-08-15 18:21
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595766&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Martin v. Löwis (loewis)
Summary: timemodule doesn't build on solaris 8

Initial Comment:
altzone is only defined if _XOPEN_SOURCE is *not*
defined (for STDC) in <time.h>.  The autoconf test for
altzone, doesn't use _XOPEN_SOURCE, so HAVE_ALTZONE is
defined.  But timemodule can't build because
_XOPEN_SOURCE is always defined in pyconfig.h before
including /usr/include/time.h.

I'm not sure how this should be fixed.  Martin, I think
you were involved with the _XOPEN_SOURCE thread.  Does
this work for you on Solaris8?  Are there OS patches
which are necessary (ie, bug in the header files)?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595766&group_id=5470


From noreply@sourceforge.net  Fri Aug 16 00:18:16 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Aug 2002 16:18:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-595537 ] pythonw has a console on Win98
Message-ID: <E17fTse-0006W9-00@usw-sf-web5.sourceforge.net>

Bugs item #595537, was opened at 2002-08-15 10:34
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595537&group_id=5470

Category: Windows
Group: Python 2.2.1
Status: Open
>Resolution: Works For Me
Priority: 5
Submitted By: Paul Spencer (pgs)
Assigned to: Tim Peters (tim_one)
Summary: pythonw has a console on Win98

Initial Comment:
executing a script with pythonw (2.2.1) on win98
results in a console window being visible.  I reverted
my application to Python 2.1.1 and it works fine. 

pythonw works okay on WinXP with 2.2.1 though.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-08-15 19:18

Message:
Logged In: YES 
user_id=31435

Please give a specific, short example.  For example, if I 
double-click on this file from Explorer under Win98, using 
2.2.1, it plays the sound but no console window opens:

C:\Python22>type example.pyw
import winsound
winsound.Beep(3000, 1000)

C:\Python22>

What happens when you try that?  If a console window does 
pop up, check the your .pyw file assocation -- you may have 
damaged it.  .pyw (Python File (no console))'s Open action 
should be associated to

C:\PYTHON22\pythonw.exe "%1" %*

or to wherever you installed Python 2.2.1.

    



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595537&group_id=5470


From noreply@sourceforge.net  Fri Aug 16 01:01:17 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Aug 2002 17:01:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-595791 ] IDLE/Command Line Output Differ
Message-ID: <E17fUYH-0007CJ-00@usw-sf-web5.sourceforge.net>

Bugs item #595791, was opened at 2002-08-15 17:01
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595791&group_id=5470

Category: IDLE
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: James Pomeroy (moody834)
Assigned to: Nobody/Anonymous (nobody)
Summary: IDLE/Command Line Output Differ

Initial Comment:
Platform: OS X 10.1.5
XDarwin: 1.1 (XFree86 4.2)
IDLE: 0.8
Python: 2.2.1

Code (from Python Tutorial sec. 4.4) [I don't know if my 
indentation will be preserved here, but the code was indented per 
Python convention]:

>>> for n in range(2, 10):
...     for x in range(2, n):
...         if n % x == 0:
...            print n, 'equals', x, '*', n/x
...            break
...     else:
...          # loop fell through without finding a factor
...          print n, 'is a prime number'

Result in IDLE:

3 is a prime number
4 equals 2 * 2
5 is a prime number
5 is a prime number
5 is a prime number
6 equals 2 * 3
7 is a prime number
7 is a prime number
7 is a prime number
7 is a prime number
7 is a prime number
8 equals 2 * 4
9 is a prime number
9 equals 3 * 3

Result using (xterm) command line matched example given in 
Python Tutorial:

2 is a prime number
3 is a prime number
4 equals 2 * 2
5 is a prime number
6 equals 2 * 3
7 is a prime number
8 equals 2 * 4
9 equals 3 * 3

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595791&group_id=5470


From noreply@sourceforge.net  Fri Aug 16 01:47:11 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Aug 2002 17:47:11 -0700
Subject: [Python-bugs-list] [ python-Bugs-233084 ] nis.match('username', 'aliases') does not work under Linux
Message-ID: <E17fVGh-0004pc-00@usw-sf-web1.sourceforge.net>

Bugs item #233084, was opened at 2001-02-19 07:17
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=233084&group_id=5470

Category: Python Library
Group: None
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: nis.match('username', 'aliases') does not work under Linux

Initial Comment:
The exception 'nis.error: No such key in map' is thrown
when issuing

>>> nis.match('username', 'aliases')

under SuSE-Linux 6.4 and 7.0 with both Python 2.0 and 
Python 2.1a2, even if 'username' is valid and 

$ ypmatch username aliases

works.

Fix: Apply the following patch to Modules/nismodule.c

--- nismodule.c.sv      Mon Feb 19 16:12:10 2001
+++ nismodule.c Mon Feb 19 16:15:28 2001
@@ -43,7 +43,7 @@
        {"hosts",       "hosts.byname",         0},
        {"protocols",   "protocols.bynumber",   0},
        {"services",    "services.byname",      0},
-       {"aliases",     "mail.aliases",         1}, /* created with 'makedbm -a' */
+       {"aliases",     "mail.aliases",         0}, /* created with 'makedbm -a' */
        {"ethers",      "ethers.byname",        0},
        {0L,            0L,                     0}
 };


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-08-15 17:47

Message:
Logged In: NO 

Actually I think the right fix is to remove the bogus 'fix'
code from nismodule.c.  It seems to do the wrong thing in
several places.  It's broken under MacOS X and Solaris, at
least with Python 2.2.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-07-19 07:22

Message:
Logged In: YES 
user_id=3066

After soliciting information from python-dev, it appears
that there's no clear fix -- fixing this properly may not be
possible, as it has a lot to do with the server
configuration.  See the "NIS on Linux, others?" thread that
starts at:

http://mail.python.org/pipermail/python-dev/2001-June/015633.html

Closing this as "Won't Fix".  If there is a portable and
reliable way to fix this, please submit a patch.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-06-29 05:39

Message:
Logged In: NO 

The fix (or the Python 1.5.2 behavior) is correct for such
platforms as RedHat Linux 6.2 (NIS server BSDI 2.1) and an
unknown FreeBSD version.

The need for the "fix" flag is likely dependent on the
server, not the client, and may very well need to be guessed
at runtime.

A related bug causes a segmentation violation in memcpy()
for 'nis.cat("aliases")' when a zero-length key or value
appears in the map, because (unsigned)-1 is passed as the
length argument.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-02-23 11:52

Message:
You are all going down on this one

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-02-19 13:33

Message:
Can anyone confirm this bug for other platforms?  How about the fix?  I don't have any access a network that uses NIS these days.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=233084&group_id=5470


From noreply@sourceforge.net  Fri Aug 16 03:25:50 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Aug 2002 19:25:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-430160 ] CGIHTTPServer.py POST bug using IE
Message-ID: <E17fWoA-000596-00@usw-sf-web4.sourceforge.net>

Bugs item #430160, was opened at 2001-06-04 20:09
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=430160&group_id=5470

Category: Windows
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Kevin Altis (kasplat)
Assigned to: Steve Holden (holdenweb)
Summary: CGIHTTPServer.py POST bug using IE

Initial Comment:
>From the readme included in the zip:
This set of files shows a bug that occurs when doing 
POST requests via the CGIHTTPServer.py module in 
Python 2.1 The testpost.html file when accessed via 
Internet Explorer 5.5 from webserver.py should show 
this bug. On short POST requests IE will end up doing 
a second POST and then displaying an error message 
while longer POSTs will be followed by a second POST 
and then a GET.

The problem appears to be specific to the interaction 
of IE and the handling of windows sockets in Python in 
the CGIHTTPServer.py module which relies on 
BaseHTTPServer.py, SocketServer.py...

posttestwebserver.py is currently setup to use 
C:\tmp\testpost as the document root, so either move 
the "testpost" folder to C:\tmp or change the 
directory to wherever the testpost folder is located. 
Start the server using the .bat file and bring 
up .html page with something like:
  http://localhost/testpost.html

The bug should occur when you try:
  Test short CGI response with POST
or
  Test long CGI response with POST

The other requests should work fine. The bug will 
occur regardless of whether IE is set to use HTTP/1.0 
or HTTP/1.1. The bug doesn't appear to occur when 
going through a simple proxy. You can also get the bug 
to occur using a remote IE client (either on a LAN or 
over the Net). In addition, it doesn't appear to 
matter whether running with unbuffered binary pipes 
(python -u) or not. I also tested against my modified 
CGIHTTPServer.py See the bug I posted at:
http://sourceforge.net/tracker/?
func=detail&atid=105470&aid=427345&group_id=5470

My configuration:
Windows 2000 Pro, SP2
AMD 1.2GHz
256MB RAM
ActiveStatet Python 2.1 (build 210)
Internet Explorer 5.5 (5.50.4522.1800)

ka
---
Mark Lutz said:
"FWIW, I noticed today (in between lecturing a class) 
that on Windows, Python actually uses a special Python-
coded socket.py library module, not the standard C-
coded socket extension module.  socket.py lives in the 
library directory; it does unique things for closes 
and deletes that may not make sense in all cases 
(e.g., the makefile call generates a class instance, 
not a true file object).  It may also be trying to 
close the underlying socket twice.  I don't have"


----------------------------------------------------------------------

>Comment By: Steve Holden (holdenweb)
Date: 2002-08-15 22:25

Message:
Logged In: YES 
user_id=88157

This patch appears to fix the basic CGIHTTPServer behavior, 
at least for Unix and Wiondows platforms, but I'm not yet 
confident of its robustness in the face of Forking or threading 
mixin code. More later ...

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-05 10:57

Message:
Logged In: YES 
user_id=6380

Steve, I'm assigning this bug to you. Feel free to check in
a fix if you think one exists (as long as it doesn't break
on Unix).

----------------------------------------------------------------------

Comment By: Matthew King (kyrrigle)
Date: 2002-03-28 15:49

Message:
Logged In: YES 
user_id=247536

it appears that IE is sending 2 extra bytes ('\r\n') after 
the request data.  and if you don't read those two extra 
bytes off, the window's socket handling gets messed up.

the result is that a partial response is returned and the 
socket closed.  IE tries to recover by re-POST'ing (which 
is behavior specified in the HTTP/1.1 RFC)... only they 
seem to add an embedded NULL the second time through, and 
the original socket problem happens again anyway.

Try reading an extra 2 bytes from the rfile before sending 
your response and the problem should go away.

not sure what the real fix for this should be?


----------------------------------------------------------------------

Comment By: Steve Holden (holdenweb)
Date: 2001-07-17 07:28

Message:
Logged In: YES 
user_id=88157

Please note that I have observed this behavior on Windows
98 using Python 2.0 (#8, Mar  7 2001, 16:04:37) [MSC 32 bit 
(Intel)] using the same build of IE, so it is not a Win2k-
specific problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=430160&group_id=5470


From noreply@sourceforge.net  Fri Aug 16 03:44:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Aug 2002 19:44:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-487703 ] Replace strcat, strcpy
Message-ID: <E17fX5m-0005bL-00@usw-sf-web2.sourceforge.net>

Bugs item #487703, was opened at 2001-11-30 17:39
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=487703&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Closed
Resolution: Duplicate
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Nobody/Anonymous (nobody)
Summary: Replace strcat, strcpy

Initial Comment:
Alex Martelli sent this URL for a paper describing the 
safer strlcat and strlcpy functions:

>http://www.usenix.org/events/usenix99/full_papers/mill
ert/millert_html/>

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-08-15 22:44

Message:
Logged In: YES 
user_id=31435

Noting that Guido rejected the patch.  It must suck if even 
glibc didn't toss it into the kitchen sink <wink>.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-08-15 17:33

Message:
Logged In: YES 
user_id=35752

Duplicate, see www.python.org/sf/595703 .

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-15 16:54

Message:
Logged In: YES 
user_id=21627

I'm opposed to strlcat/strlcpy in the first place. It
usually starts long debates, and opponents usually argue
that it serves no real purpose, and gives a shallow feeling
of safety when there really is none. Proponents of strlcpy
are quite religious about spreading it quickly. For example,
there was a heated discussion about adding strlcpy to GNU
libc, after which glibc maintainers to ignore them.

I propose to do the same thing in Python.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 11:56

Message:
Logged In: YES 
user_id=35752


If they want people to use their code why do they put that
stupid clause in the license?  How annoying.  Attached is
a strlcpy function that I wrote based on the man page:

http://www.tac.eu.org/cgi-bin/man-cgi?strlcpy+3

Do whatever you like with it. :-)  I would appreciate it if
someone would review the code however.  There are a number
of corner cases that are easy to screw up.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-11 17:51

Message:
Logged In: YES 
user_id=6380

Strictly speaking, binary Python distributions would be
required to contain a copy of the entire license for that
file. I don't like that.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-12-03 13:59

Message:
Logged In: YES 
user_id=31435

I'm attaching a patch from Alex Martelli; haven't reviewed 
it, and don't expect to before 2.2 final is released.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-12-03 05:47

Message:
Logged In: YES 
user_id=38388

Time for PyOS_strlcat() and PyOS_strlcpy() ? Looking at the web-site it seems that we could simply copy the 
code into the Python distro. I'd then suggest to bundle all the string helpers into a new file: e.g. mystrapis.c.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=487703&group_id=5470


From noreply@sourceforge.net  Fri Aug 16 04:28:45 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Aug 2002 20:28:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-595837 ] pickle_complex in copy_reg.py
Message-ID: <E17fXn3-0007dp-00@usw-sf-web1.sourceforge.net>

Bugs item #595837, was opened at 2002-08-15 23:28
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595837&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Guido van Rossum (gvanrossum)
Summary: pickle_complex in copy_reg.py

Initial Comment:
This code is in copy_reg.py from 1997:

def pickle_complex(c):
    return complex, (c.real, c.imag)

pickle(type(1j), pickle_complex, complex)

I'm not sure if the function pickle_complex() is
necessary, but it definitely seems that the line after
should be commented out or removed.  pickle_complex()
is not in the doc either.

(I was building WITHOUT_COMPLEX and found this problem.)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595837&group_id=5470


From noreply@sourceforge.net  Fri Aug 16 04:32:11 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Aug 2002 20:32:11 -0700
Subject: [Python-bugs-list] [ python-Bugs-595838 ] unnecessary static variable
Message-ID: <E17fXqN-0007hr-00@usw-sf-web1.sourceforge.net>

Bugs item #595838, was opened at 2002-08-15 23:32
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595838&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Guido van Rossum (gvanrossum)
Summary: unnecessary static variable

Initial Comment:
In typeobject.c:1011 (in type_new), buffer is static. 
It doesn't seem to need to be static as it's only
passed to Py_Mangle().

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595838&group_id=5470


From noreply@sourceforge.net  Fri Aug 16 04:42:30 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Aug 2002 20:42:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-594996 ] OverflowError in random.randrange
Message-ID: <E17fY0M-0005zC-00@usw-sf-web4.sourceforge.net>

Bugs item #594996, was opened at 2002-08-14 06:46
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594996&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Shannon Jones (sjones)
Assigned to: Tim Peters (tim_one)
Summary: OverflowError in random.randrange

Initial Comment:
The following code can produce an OverflowError in
random.randrange.

import random
from sys import maxint
minint = -maxint - 1

random.randrange(minint, maxint)

You may need to execute the last line a few times to
get the error because it depends on the random number
generated. The traceback is on line 315 of random.py
and is OverflowError: float too large to convert.

Changing line 315 from:
return istart + int(self.random() * (istop - istart))
to:
return int(istart + self.random() * (istop - istart))

seems to fix the problem.

-----
I'm using Python 2.3 from CVS on RH 7.3


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-08-15 23:42

Message:
Logged In: YES 
user_id=31435

3% is unacceptable, but I agree it would be nice to extend 
this, and found a more efficient way to do it.  That's 
checked in, and thanks for the nag!

random.py, rev 1.34.

Long ints account for part of the slowdown you saw, so 
does looking up globals instead of locals, and so does 
simply calling an external libm function (C's floor()).  Step 
though it in a debugger and your "single-step" finger will 
grow numb <wink>.

----------------------------------------------------------------------

Comment By: Shannon Jones (sjones)
Date: 2002-08-15 03:17

Message:
Logged In: YES 
user_id=589306

I'm attaching a patch that I *hope* generates correct output
for all inputs :-)

Just for kicks, I tried running random.randrange(-10, 10)
fifty million times with the regular code and with these
changes. The regular version ran in 543.04 seconds. The
changed code took 559.21 seconds. The difference is 2.98%.

To put that in perspective: if you had a simulation that did
nothing but generate random numbers and throw them away for
10 hours, it would now take 10 hours and 18 minutes to run.

If the range between numbers is bigger than sys.maxint,
things slow down by roughly a factor of 5 on my computer. I
guess because Python switches to long ints?


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-08-14 12:59

Message:
Logged In: YES 
user_id=31435

The suggested change stops OverflowError but delivers 
incorrect results; for example, try randrange(-2, 0) repeatedly, 
and you'll find it delivers one of {-2, -1} before the change, but 
one of {-1, 0} after the change.  Using int(math.floor(...)) 
instead would restore correct behavior, but I'm loathe to slow 
this high-usage function.  In the absence of an idea that's 
both correct and fast, I'll close this as WontFix -- speed is 
more important here than pushing the limit on the overall 
range by 1 bit.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594996&group_id=5470


From noreply@sourceforge.net  Fri Aug 16 04:48:20 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Aug 2002 20:48:20 -0700
Subject: [Python-bugs-list] [ python-Bugs-595838 ] unnecessary static variable
Message-ID: <E17fY60-0002ad-00@usw-sf-web5.sourceforge.net>

Bugs item #595838, was opened at 2002-08-15 23:32
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595838&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Guido van Rossum (gvanrossum)
Summary: unnecessary static variable

Initial Comment:
In typeobject.c:1011 (in type_new), buffer is static. 
It doesn't seem to need to be static as it's only
passed to Py_Mangle().

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-15 23:48

Message:
Logged In: YES 
user_id=6380

Oops, thanks, fxed! I don't know what I was thinking.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595838&group_id=5470


From noreply@sourceforge.net  Fri Aug 16 04:49:36 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Aug 2002 20:49:36 -0700
Subject: [Python-bugs-list] [ python-Bugs-595837 ] pickle_complex in copy_reg.py
Message-ID: <E17fY7E-0002bb-00@usw-sf-web5.sourceforge.net>

Bugs item #595837, was opened at 2002-08-15 23:28
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595837&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: pickle_complex in copy_reg.py

Initial Comment:
This code is in copy_reg.py from 1997:

def pickle_complex(c):
    return complex, (c.real, c.imag)

pickle(type(1j), pickle_complex, complex)

I'm not sure if the function pickle_complex() is
necessary, but it definitely seems that the line after
should be commented out or removed.  pickle_complex()
is not in the doc either.

(I was building WITHOUT_COMPLEX and found this problem.)

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-15 23:49

Message:
Logged In: YES 
user_id=6380

Without that line you can't pickle complex numbers. Maybe it
should fail gracefully if complex doesn't exist. Feel free
to check in a fix for that.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595837&group_id=5470


From noreply@sourceforge.net  Fri Aug 16 07:14:31 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Aug 2002 23:14:31 -0700
Subject: [Python-bugs-list] [ python-Bugs-595766 ] timemodule doesn't build on solaris 8
Message-ID: <E17faNT-0007pS-00@usw-sf-web4.sourceforge.net>

Bugs item #595766, was opened at 2002-08-16 00:21
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595766&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Martin v. Löwis (loewis)
Summary: timemodule doesn't build on solaris 8

Initial Comment:
altzone is only defined if _XOPEN_SOURCE is *not*
defined (for STDC) in <time.h>.  The autoconf test for
altzone, doesn't use _XOPEN_SOURCE, so HAVE_ALTZONE is
defined.  But timemodule can't build because
_XOPEN_SOURCE is always defined in pyconfig.h before
including /usr/include/time.h.

I'm not sure how this should be fixed.  Martin, I think
you were involved with the _XOPEN_SOURCE thread.  Does
this work for you on Solaris8?  Are there OS patches
which are necessary (ie, bug in the header files)?

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-08-16 08:14

Message:
Logged In: YES 
user_id=21627

It works fine for me. Why do you say that the test for
altzone doesn't use _XOPEN_SOURCE? It certainly does, by
means of

AC_DEFINE(_XOPEN_SOURCE, 500)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595766&group_id=5470


From noreply@sourceforge.net  Fri Aug 16 07:17:49 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Aug 2002 23:17:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-595766 ] timemodule doesn't build on solaris 8
Message-ID: <E17faQf-0007rJ-00@usw-sf-web4.sourceforge.net>

Bugs item #595766, was opened at 2002-08-16 00:21
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595766&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: timemodule doesn't build on solaris 8

Initial Comment:
altzone is only defined if _XOPEN_SOURCE is *not*
defined (for STDC) in <time.h>.  The autoconf test for
altzone, doesn't use _XOPEN_SOURCE, so HAVE_ALTZONE is
defined.  But timemodule can't build because
_XOPEN_SOURCE is always defined in pyconfig.h before
including /usr/include/time.h.

I'm not sure how this should be fixed.  Martin, I think
you were involved with the _XOPEN_SOURCE thread.  Does
this work for you on Solaris8?  Are there OS patches
which are necessary (ie, bug in the header files)?

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-16 08:14

Message:
Logged In: YES 
user_id=21627

It works fine for me. Why do you say that the test for
altzone doesn't use _XOPEN_SOURCE? It certainly does, by
means of

AC_DEFINE(_XOPEN_SOURCE, 500)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595766&group_id=5470


From noreply@sourceforge.net  Fri Aug 16 10:25:39 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Aug 2002 02:25:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-595919 ] popenN return only text mode pipes
Message-ID: <E17fdMR-0003Fe-00@usw-sf-web2.sourceforge.net>

Bugs item #595919, was opened at 2002-08-16 09:25
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595919&group_id=5470

Category: Python Library
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Boyan Boyadjiev (bbboyadjiev)
Assigned to: Nobody/Anonymous (nobody)
Summary: popenN return only text mode pipes

Initial Comment:
The functions popen2, popen3 & popen 4 (module 
win32pipe) will return only text mode pipes even 
if the parameter mode is 'b'.

In the file win32popen.cpp on lines 363 
(popen2&popen4) and 398 (popen3) can be found 
the following code:
if (mode && _O_TEXT)
    {
      m1="r";
      m2="w";
    }
      else
    {
      m1="rb";
      m2="wb";
    }
The following change solves the problem :
if (mode & _O_TEXT)
    { ....



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595919&group_id=5470


From noreply@sourceforge.net  Fri Aug 16 12:03:10 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Aug 2002 04:03:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-595919 ] popenN return only text mode pipes
Message-ID: <E17feso-0007fL-00@usw-sf-web1.sourceforge.net>

Bugs item #595919, was opened at 2002-08-16 09:25
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595919&group_id=5470

Category: Python Library
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Boyan Boyadjiev (bbboyadjiev)
Assigned to: Nobody/Anonymous (nobody)
Summary: popenN return only text mode pipes

Initial Comment:
The functions popen2, popen3 & popen 4 (module 
win32pipe) will return only text mode pipes even 
if the parameter mode is 'b'.

In the file win32popen.cpp on lines 363 
(popen2&popen4) and 398 (popen3) can be found 
the following code:
if (mode && _O_TEXT)
    {
      m1="r";
      m2="w";
    }
      else
    {
      m1="rb";
      m2="wb";
    }
The following change solves the problem :
if (mode & _O_TEXT)
    { ....



----------------------------------------------------------------------

>Comment By: Boyan Boyadjiev (bbboyadjiev)
Date: 2002-08-16 11:03

Message:
Logged In: YES 
user_id=595971

The same code (if (mode && _O_TEXT) ...) is used also in the function _PyPopen of the posix module 
(posixmodule.c).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595919&group_id=5470


From noreply@sourceforge.net  Fri Aug 16 13:00:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Aug 2002 05:00:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-595791 ] IDLE/Command Line Output Differ
Message-ID: <E17ffmY-0003Or-00@usw-sf-web3.sourceforge.net>

Bugs item #595791, was opened at 2002-08-16 02:01
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595791&group_id=5470

Category: IDLE
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: James Pomeroy (moody834)
Assigned to: Nobody/Anonymous (nobody)
Summary: IDLE/Command Line Output Differ

Initial Comment:
Platform: OS X 10.1.5
XDarwin: 1.1 (XFree86 4.2)
IDLE: 0.8
Python: 2.2.1

Code (from Python Tutorial sec. 4.4) [I don't know if my 
indentation will be preserved here, but the code was indented per 
Python convention]:

>>> for n in range(2, 10):
...     for x in range(2, n):
...         if n % x == 0:
...            print n, 'equals', x, '*', n/x
...            break
...     else:
...          # loop fell through without finding a factor
...          print n, 'is a prime number'

Result in IDLE:

3 is a prime number
4 equals 2 * 2
5 is a prime number
5 is a prime number
5 is a prime number
6 equals 2 * 3
7 is a prime number
7 is a prime number
7 is a prime number
7 is a prime number
7 is a prime number
8 equals 2 * 4
9 is a prime number
9 equals 3 * 3

Result using (xterm) command line matched example given in 
Python Tutorial:

2 is a prime number
3 is a prime number
4 equals 2 * 2
5 is a prime number
6 equals 2 * 3
7 is a prime number
8 equals 2 * 4
9 equals 3 * 3

----------------------------------------------------------------------

Comment By: Gregor Lingl (glingl)
Date: 2002-08-16 14:00

Message:
Logged In: YES 
user_id=505031

Apparently this is a bug in the INPUT to IDLE,
as the incorrect output is produced, if the else-part in 
the statement is incorrectly idented as part of the if-statement
instead as a part of the for-statement


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595791&group_id=5470


From noreply@sourceforge.net  Fri Aug 16 13:20:13 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Aug 2002 05:20:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-595018 ] inspect.getsource shows incorrect output
Message-ID: <E17fg5N-0006wE-00@usw-sf-web2.sourceforge.net>

Bugs item #595018, was opened at 2002-08-14 13:41
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595018&group_id=5470

Category: Python Library
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregor Lingl (glingl)
>Assigned to: Ka-Ping Yee (ping)
Summary: inspect.getsource shows incorrect output

Initial Comment:
example:
>>> from turtle import *
>>> from inspect import *
>>> print getsource(up)
def up(): _getpen().up()
def down(): _getpen().down()
def width(width): _getpen().width(width)
def color(*args): apply(_getpen().color, args)
def write(arg, move=0): _getpen().write(arg, move)
def fill(flag): _getpen().fill(flag)
def circle(radius, extent=None):
_getpen().circle(radius, extent)
def goto(*args): apply(_getpen().goto, args)

def demo():
    reset()
    tracer(1)
# etc ...

changing the form of the definition of up in turtle to:

def up(): 
     _getpen().up()

results in:

>>> print getsource(up)
def up():
     _getpen().up()

>>> 

So the error probably occurs when parsing the
sourcefile if functiondefinition is a oneliner ...

Regards
Gregor Lingl


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595018&group_id=5470


From noreply@sourceforge.net  Fri Aug 16 15:17:00 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Aug 2002 07:17:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-216289 ] Programs using Tkinter sometimes can't shut down (Windows)
Message-ID: <E17fhuO-0000Vj-00@usw-sf-web2.sourceforge.net>

Bugs item #216289, was opened at 2000-10-07 02:25
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=216289&group_id=5470

Category: Windows
Group: Python 2.3
Status: Open
Resolution: Later
Priority: 3
Submitted By: Tim Peters (tim_one)
Assigned to: Fredrik Lundh (effbot)
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: John Popplewell (johnnypops)
Date: 2002-08-16 14:16

Message:
Logged In: YES 
user_id=143340

I have dug out the setup I used previously and, apart from 
using Python 2.2 instead of 2.0.1, have had a go at 
reproducing my previous results.

With a debug build of Tcl/Tk and threads disabled I have 
managed to get this stack trace when it locks on exit (after 
doing a break):

ConsoleCloseProc(int * 0x006a0ae4, Tcl_Interp * 
0x00000000) line 527 + 17 bytes
TclFinalizeIOSubsystem() line 241 + 20 bytes
Tcl_FinalizeThread() line 911
Tcl_Finalize() line 812
DllMain(HINSTANCE__ * 0x00970000, unsigned long 
0x00000000, void * 0x00000001) line 197
TCL83! _DllMainCRTStartup@12 + 80 bytes
KERNEL32! bff7ddd6()
KERNEL32! bff8d123()
8176b5fc()

It is hanging up in ConsoleCloseProc() in 'tclWinConsole.c'
at about line 527:
WaitForSingleObject(consolePtr->writeThread, INFINITE);

I tried changing the timeout from INFINITE to 100ms and 
testing the return value for WAIT_TIMEOUT. Sure enough it 
occasionaly printed a message (and didn't lock-up).

Don't know if this helps. Will try to reproduce the double 
free problem in the threaded build later,

cheers,
John.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-15 14:19

Message:
Logged In: YES 
user_id=6380

Just a note so I won't forget this: Jeff Hobbs once said the
code to look at is

tk/generic/tkConsole.c:Tk_InitConsoleChannels

----------------------------------------------------------------------

Comment By: David Gravereaux (davygrvy)
Date: 2002-08-15 13:23

Message:
Logged In: YES 
user_id=7549

Hi John,

I have seen Tcl extension DLLs that set exit handlers get 
called by Tcl after they were torn-down.  NT and Win9x seem 
to be a bit different in the order of what DLLs get torn-down.  
here's a note from some old code of mine:

#ifdef __WIN32__
    // It can happen that the HEAP could have already been 
unloaded
    // from an awkward teardown caused by a Ctrl+C or other.  
Win32
    // seems to do a teardown in reverse order and by the time 
Tcl
    // knows what's going on and Tcl_Finalize calls the exit
    // handlers, this extension's data (heap?) has already been
    // unloaded by the OS.  Do a quick legal check on the 
pointer
    // first.
    //
    if (IsBadReadPtr(adapt, sizeof(T *))) return;
#endif

what's the back/stacktrace?  who is calling 
Tcl_FinalizeNotifier?  And had anyone called it before during 
the shutdown phase? I can't say with much confidence that 
this is happening here, too.  Maybe..  Could Tk be telling Tcl 
shutdown?  That's sort of backwards, if so.

I run w2k here, so I can't help in debugging from a test case.  
tclsh with a threaded build doesn't even call Tcl_Finalize to 
avoid all this!

----------------------------------------------------------------------

Comment By: Donal K. Fellows (dkf)
Date: 2002-08-15 13:09

Message:
Logged In: YES 
user_id=79902

Firstly, on the matter of threads.  Tcl/Tk on Windows uses
threads internally even in non-threaded builds.  That's
Windows for you (in particular, you can get calls parachuted
in from completely separate threads with relatively little
warning.  Also, you need threaded helpers to handle
non-blocking waiting on some kinds of objects.)

It's a bit hard to work out if the problem's been fixed
without a stack-trace (preferably with debugging symbols
enabled so that we can see what the function names and
arguments to those functions are.)  I have no  chance of
replicating this bug here (I'm currently running IRIX, but
also have some access to Solaris and Linux...)

----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-08-15 12:15

Message:
Logged In: YES 
user_id=143340

Hi to davygrvy,

my fix isn't for a thread related (deadlock) type problem - it 
is a fix for a double free type problem which is presumably 
screwing up the heap and causing the C runtime to hang.

It *is* with a threaded build (THREADDEFINES = -
DTCL_THREADS=1) which I think I enabled because I was 
using  'after' and it didn't work unless threading was 
enabled - but I may be mis-remembering here!

Also, I ended up doing all this with the debug build and 
found the -GZ flag useful - in fact it pointed out the fact that 
there was a problem with the heap.

It is worth noting that I have only seen this on Win98 and 
that using 'pythonw.exe' did *not* prevent this from 
happening,

regards John.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-15 01:00

Message:
Logged In: YES 
user_id=6380

AFAIK we never distributed a threaded build.

----------------------------------------------------------------------

Comment By: David Gravereaux (davygrvy)
Date: 2002-08-15 00:01

Message:
Logged In: YES 
user_id=7549

To johnnypops,

Where in Tcl_FinalizeNotifier() is the dead-lock occuring and 
is this with a threaded build of Tcl?


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-07-02 19:39

Message:
Logged In: YES 
user_id=31435

Jeff, a long time ago Fredrik Lundh said he was able to 
reproduce this with a short wish script (no Python, no Tkinter, 
just Tcl/Tk + wish).  I'm reassigning this to /F in the hopes 
he'll remember how.

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-07-02 18:55

Message:
Logged In: YES 
user_id=72656

I appreciate that many others see this is a problem in 
embedding Tcl, but without any clear way to reproduce this in 
Tcl/Tk itself, it's very hard for me to fix it.  I don't think that 
there is anything done in 8.4 to fix this that I recall, but if 
someone finds that the problem "goes away" with 8.4, please 
report that.

For those of course that experience this with python, the 
simple and "correct" work-around is to launch with 
pythonw.exe instead of python.exe.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-06-26 17:40

Message:
Logged In: NO 

According to http://tcl.activestate.com ActiveTcl 8.4.0 is now 
available for download.  It is new as of June 24.  I don't know 
whether this will solve our problems or not, but it's worth 
looking into.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-06-19 13:36

Message:
Logged In: NO 

I just downloaded Ruby 1.6.6 for Windows, which also uses 
Tcl/Tk 8.3 and I experience exactly the same problem there. 
So this is definitely a Tcl problem (but we know that already).

----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-06-07 19:01

Message:
Logged In: YES 
user_id=143340

Hmmm. 
I run a Python Tcl/Tk application several times every day - 
the very application that prompted my bug-hunt.

I do use "pythonw.exe" to launch it, but it used to hang 
almost as badly as "python.exe".

Whilst developing this app I used "python.exe" and 
experienced no hang-ups.

The Tcl guys point out that this bug is only one of several 
possible causes of the hang-up, maybe you are just out of 
luck.

The patch has fixed the problem on three Win98 machines, 
all of which exhibited the problem before updating the DLLs.

One thought - are you sure there weren't multiple copies of 
the tcl83.dll and tk83.dll files? My (only) copies were 
in "D:\python20\DLLs"

good luck,
John.


----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-06-03 18:55

Message:
Logged In: YES 
user_id=72656

providing Tim with a fixed DLL exactly according to John 
Popplewell's patch did not fix the problem for him.  That 
makes it seem fishy that John really didn't see the problem 
any more.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-03 16:59

Message:
Logged In: YES 
user_id=31435

I tried replacing Python 2.2.1's tk83.dll and tcl83.dll (from 
Tcl/Tk 8.3.2) with newer matched sets from

A) PythonWare's py21 distribution (Tcl/Tk 8.3.3).

and again from

B) ActiveState's Tcl/Tk 8.3.4.

All the symptoms originally reported here persisted on 
Win98SE despite that.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-05-22 13:57

Message:
Logged In: NO 

I am new to Python and encountered this bug on my very first 
Tkinter application.  It persists in Python 2.2.1 under 
Windows Me. Needless to say, it makes a bad first 
impression.  Basically, this thread says that Tkinter has been 
broken for a year and a half on a popular platform at a time 
when Python is trying to expand its user base.  Hopefully, this 
bug will be corrected soon.

If Tcl/Tk 8.4 is not released shortly you might try repackaging 
Tkinter for Win32 with an earlier version of Tcl/Tk, such as 
8.0, that doesn't encounter this problem.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-23 03:36

Message:
Logged In: YES 
user_id=6380

The proper action is to wait until Tcl 8.3.5 is released,
and then shaming someone else in providing you with a set of
Windowsbinaries for Tcl. You may also ask Hobbs if there's a
Windows project file to build Tcl/Tk for Windows.

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-03-12 02:31

Message:
Logged In: YES 
user_id=72656

I did end up back-porting this to the 8.3.4+ Tcl CVS on 
2002-02-25, which means it will be in an eventual 8.3.5.  
It is already in the release 8.4 alpha series.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-10 01:50

Message:
Logged In: YES 
user_id=31435

Back to Guido:  Do you think you know what the proper 
action is?  (You said that's why you reopened it, and 
there's been no new info here since then.)

----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-02-26 00:55

Message:
Logged In: YES 
user_id=143340

I knew I wasn't getting to the heart of it ....

Almost a one-liner!

It has been seriously spoiling my (otherwise crash free) 
Python experience on Win9x - hope it gets fixed soon.

cheers,
John.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-02-25 23:39

Message:
Logged In: YES 
user_id=6380

Reopened until we know what the proper action is.

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-02-25 23:32

Message:
Logged In: YES 
user_id=72656

This is mostly correct, and is fixed in the 8.4 Tcl sources 
already (I guess we can backport this).  This was mentioned 
in SF Tcl bug (account for chopped URL):

https://sourceforge.net/tracker/?
func=detail&aid=217982&group_id=10894&atid=110894

and the code comment is:

    /*
     * Only finalize the notifier if a notifier was 
installed in the
     * current thread; there is a route in which this is not
     * guaranteed to be true (when tclWin32Dll.c:DllMain() 
is called
     * with the flag DLL_PROCESS_DETACH by the OS, which 
could be
     * doing so from a thread that's never previously been 
involved
     * with Tcl, e.g. the task manager) so this check is 
important.
     *
     * Fixes Bug #217982 reported by Hugh Vu and Gene 
Leache.
     */
    if (tsdPtr == NULL) {
	return;
    }


----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-02-25 22:41

Message:
Logged In: YES 
user_id=143340

This one has been torturing me for a while.

Managed to track it down to a problem inside Tcl.
For the Tcl8.3.4 source distribution the problem is in
the file win/tclWinNotify.c 

void Tcl_FinalizeNotifier(ClientData clientData)
{
    ThreadSpecificData *tsdPtr = 
                         (ThreadSpecificData *) clientData;

    /* sometimes called with tsdPtr == NULL */
    if ( tsdPtr != NULL )
    {
        DeleteCriticalSection(&tsdPtr->crit);
        CloseHandle(tsdPtr->event);

        /*
         * Clean up the timer and messaging 
         * window for this thread.
         */

        if (tsdPtr->hwnd) {
	    KillTimer(tsdPtr->hwnd, INTERVAL_TIMER);
            DestroyWindow(tsdPtr->hwnd);
        }
    }

    /*
     * If this is the last thread to use the notifier, 
     * unregister the notifier window class.
     */

    Tcl_MutexLock(&notifierMutex);
    if ( notifierCount && !--notifierCount ) {
	UnregisterClassA( "TclNotifier", 
                          TclWinGetTclInstance());
    }
    Tcl_MutexUnlock(&notifierMutex);
}

This bodge doesn't address the underlying problem but has 
stopped me from tearing all my hair out,

cheers,
John Popplewell.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-10-24 22:27

Message:
Logged In: YES 
user_id=31435

FYI, you don't need an IDE to do this -- in Win9x, hit 
Ctrl+Alt+Del and kill the process directly.

A saner <wink> solution is to develop under Win2K, which 
doesn't appear to suffer this problem (the only reports 
I've seen, and experienced myself, came from Win9x boxes).

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-10-24 08:52

Message:
Logged In: NO 

For those who are still trapped in this bug's hell, I will 
gladly share the one thing that saved my sanity:  
WingIDE's 'Kill' command will shut down the program with 
apparent 100% certainty and no fear of lockups.  WingIDE 
has its own issues, so its not a perfect solution, but if 
you are like me and Joe (above) who test in small 
iterations, then using 'Kill' to quit out of your app while 
testing is a workaround that may preserve your sanity.

Perhaps the python gods and the Wing guys can get together 
and tell us how to replicate 'kill' into our code.  For 
now, I'll use WingIDE to edit, and pythonw.exe for my final 
client's delivery.

----------------------------------------------------------------------

Comment By: Howard Lightstone (hlightstone)
Date: 2001-09-05 17:43

Message:
Logged In: YES 
user_id=66570

I sometimes get bunches of these....

A tool I use (Taskinfo2000) reports that (after killing 
winoldap):

python.exe is blocked on a mutex named OLESCELOCKMUTEX.
The reported state is "Console Terminating".  There appears 
to be only one (os) thread running.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-04-02 20: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-06 05: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-13 02: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 20: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 16: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 14:40

Message:
Back to Tim since I have no clue what to do here.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-12 17: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 07: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: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=216289&group_id=5470


From noreply@sourceforge.net  Fri Aug 16 16:04:13 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Aug 2002 08:04:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-595601 ] file (& socket) I/O are not thread safe
Message-ID: <E17fie5-0004NG-00@usw-sf-web1.sourceforge.net>

Bugs item #595601, was opened at 2002-08-15 16:34
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595601&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Jeremy Hylton (jhylton)
Summary: file (& socket) I/O are not thread safe

Initial Comment:
We recently found an assertion failure in the universal
newline support when running a multithreaded program
where two threads used the same Python file object. 
The assert(stream != NULL) test in 
Py_UniversalNewlineFread() fails once in a blue moon,
where stream is the stdio FILE * that the fileobject
wraps.  Further analysis suggests that there is a race
condition between checking FILE * and using FILE * that
exists in at least Python 2.1 and up.

I'll actually describe the problem as it exists in
Python 2.2, because it is simpler to avoid the
universal newline code.  That code isn't the source of
the problem, although it's assert() uncovers it in a
clear way.

In file_read() (rev 2.141.6.5), the first thing it does
is check if f_fp (the FILE *) is NULL.  If so it raises
an IOError -- operation on closed file object.  Later,
file_read() enters a for loop that calls fread() until
enough bytes have been read.

	for (;;) {
		Py_BEGIN_ALLOW_THREADS
		errno = 0;
		chunksize = fread(BUF(v) + bytesread, 1,
				  buffersize - bytesread, f->f_fp);
		Py_END_ALLOW_THREADS
		if (chunksize == 0) {
			if (!ferror(f->f_fp))
				break;
			PyErr_SetFromErrno(PyExc_IOError);
			clearerr(f->f_fp);
			Py_DECREF(v);
			return NULL;
		}

The problem is that fread() is called after the global
interpreter lock is released.  Since the lock is
released, another Python thread could run and modify
the file object, changing the value of f->f_fp.  Under
the current interpreter lock scheme, it isn't safe to
use f->f_fp without holding the interpreter lock.

The current file_read() code can fail in a variety of
ways.  It's possible for a second thread to close the
file, which will set f->f_fp to NULL.  Who knows what
fread() will do when NULL is passed.

The universal newline code is squirrels the FILE * in a
local variable, which is worse.  If it happens that
another thread closes the file, at best the local
points to a closed FILE *.  But that memory could get
recycled and then there's no way to know what it points to.

socket I/O has a similar problem with unsafe sharing of
the file descriptor.  However, this problem seems less
severe in general, because we'd just be passing a bogus
file descriptor to a system call.  We don't have to
worry about whether stdio will dump core when passed a
bogus pointer.  There is a chance the a socket will be
closed and its file descriptor used for a different
socket.  So a call to recv() with one socket ends up
using a different socket.  That will be a nightmare to
debug, but it won't cause a segfault.  (And, in
general, files and sockets shouldn't be shared between
application threads unless the application is going to
make sure its safe.)

The solution to this problem is to use a
per-file-object lock to guard access to f->f_fp.  No
thread should read or right f->f_fp without holding the
lock.  To make sure that other threads get a chance to
run when there is contention for the file, the
file-object lock should never be held when the GIL is held.


----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-08-16 15:04

Message:
Logged In: YES 
user_id=31392

I think I'm less worried about PyFile_AsFile() than I am
about PyFile_WriteObject().  The latter is invoked by the
print statement.  It extracts the FILE* using
PyFile_AsFile() and proceeds to pass it to PyObject_Print().
 PyObject_Print() MUST hold the GIL, but since it has the
raw FILE* it MUST hold the file lock.  But you can't hold
both locks :-(.


----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-08-15 20:49

Message:
Logged In: YES 
user_id=45365

I'm not sure your solution of locking in the file object is feasible. Every call of PyFile_AsFile() is dangerous, if the  code proceeds to release the GIL before using the FILE* it's in danger. And this code could be in extension modules too (I know there's quite a few in my own img package).

When I did the universal newlines patch I basically ignored the problem (thinking that no-one in their right mind would close a file in one thread while it's still in use in another: how wrong can one be:-).

The only real solution may be to get rid of PyFile_AsFile altogether, and replace it with PyFile_AsFileLocked() and PyFile_Unlock() and make these calls somehow work even when the GIL is held (possibly by temporarily releasing the GIL while acquiring the file lock).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595601&group_id=5470


From noreply@sourceforge.net  Fri Aug 16 16:22:08 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Aug 2002 08:22:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-595791 ] IDLE/Command Line Output Differ
Message-ID: <E17fivQ-0007vb-00@usw-sf-web3.sourceforge.net>

Bugs item #595791, was opened at 2002-08-15 17:01
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595791&group_id=5470

Category: IDLE
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: James Pomeroy (moody834)
Assigned to: Nobody/Anonymous (nobody)
Summary: IDLE/Command Line Output Differ

Initial Comment:
Platform: OS X 10.1.5
XDarwin: 1.1 (XFree86 4.2)
IDLE: 0.8
Python: 2.2.1

Code (from Python Tutorial sec. 4.4) [I don't know if my 
indentation will be preserved here, but the code was indented per 
Python convention]:

>>> for n in range(2, 10):
...     for x in range(2, n):
...         if n % x == 0:
...            print n, 'equals', x, '*', n/x
...            break
...     else:
...          # loop fell through without finding a factor
...          print n, 'is a prime number'

Result in IDLE:

3 is a prime number
4 equals 2 * 2
5 is a prime number
5 is a prime number
5 is a prime number
6 equals 2 * 3
7 is a prime number
7 is a prime number
7 is a prime number
7 is a prime number
7 is a prime number
8 equals 2 * 4
9 is a prime number
9 equals 3 * 3

Result using (xterm) command line matched example given in 
Python Tutorial:

2 is a prime number
3 is a prime number
4 equals 2 * 2
5 is a prime number
6 equals 2 * 3
7 is a prime number
8 equals 2 * 4
9 equals 3 * 3

----------------------------------------------------------------------

>Comment By: James Pomeroy (moody834)
Date: 2002-08-16 08:22

Message:
Logged In: YES 
user_id=448016

UPDATE:

This issue all appears if I use OS X's default terminal. Same output as 
with IDLE. So, only xterm produces the result expected.

----------------------------------------------------------------------

Comment By: Gregor Lingl (glingl)
Date: 2002-08-16 05:00

Message:
Logged In: YES 
user_id=505031

Apparently this is a bug in the INPUT to IDLE,
as the incorrect output is produced, if the else-part in 
the statement is incorrectly idented as part of the if-statement
instead as a part of the for-statement


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595791&group_id=5470


From noreply@sourceforge.net  Fri Aug 16 16:26:56 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Aug 2002 08:26:56 -0700
Subject: [Python-bugs-list] [ python-Bugs-595601 ] file (& socket) I/O are not thread safe
Message-ID: <E17fj04-0000pU-00@usw-sf-web5.sourceforge.net>

Bugs item #595601, was opened at 2002-08-15 12:34
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595601&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Jeremy Hylton (jhylton)
Summary: file (& socket) I/O are not thread safe

Initial Comment:
We recently found an assertion failure in the universal
newline support when running a multithreaded program
where two threads used the same Python file object. 
The assert(stream != NULL) test in 
Py_UniversalNewlineFread() fails once in a blue moon,
where stream is the stdio FILE * that the fileobject
wraps.  Further analysis suggests that there is a race
condition between checking FILE * and using FILE * that
exists in at least Python 2.1 and up.

I'll actually describe the problem as it exists in
Python 2.2, because it is simpler to avoid the
universal newline code.  That code isn't the source of
the problem, although it's assert() uncovers it in a
clear way.

In file_read() (rev 2.141.6.5), the first thing it does
is check if f_fp (the FILE *) is NULL.  If so it raises
an IOError -- operation on closed file object.  Later,
file_read() enters a for loop that calls fread() until
enough bytes have been read.

	for (;;) {
		Py_BEGIN_ALLOW_THREADS
		errno = 0;
		chunksize = fread(BUF(v) + bytesread, 1,
				  buffersize - bytesread, f->f_fp);
		Py_END_ALLOW_THREADS
		if (chunksize == 0) {
			if (!ferror(f->f_fp))
				break;
			PyErr_SetFromErrno(PyExc_IOError);
			clearerr(f->f_fp);
			Py_DECREF(v);
			return NULL;
		}

The problem is that fread() is called after the global
interpreter lock is released.  Since the lock is
released, another Python thread could run and modify
the file object, changing the value of f->f_fp.  Under
the current interpreter lock scheme, it isn't safe to
use f->f_fp without holding the interpreter lock.

The current file_read() code can fail in a variety of
ways.  It's possible for a second thread to close the
file, which will set f->f_fp to NULL.  Who knows what
fread() will do when NULL is passed.

The universal newline code is squirrels the FILE * in a
local variable, which is worse.  If it happens that
another thread closes the file, at best the local
points to a closed FILE *.  But that memory could get
recycled and then there's no way to know what it points to.

socket I/O has a similar problem with unsafe sharing of
the file descriptor.  However, this problem seems less
severe in general, because we'd just be passing a bogus
file descriptor to a system call.  We don't have to
worry about whether stdio will dump core when passed a
bogus pointer.  There is a chance the a socket will be
closed and its file descriptor used for a different
socket.  So a call to recv() with one socket ends up
using a different socket.  That will be a nightmare to
debug, but it won't cause a segfault.  (And, in
general, files and sockets shouldn't be shared between
application threads unless the application is going to
make sure its safe.)

The solution to this problem is to use a
per-file-object lock to guard access to f->f_fp.  No
thread should read or right f->f_fp without holding the
lock.  To make sure that other threads get a chance to
run when there is contention for the file, the
file-object lock should never be held when the GIL is held.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-08-16 11:26

Message:
Logged In: YES 
user_id=31435

To cheer you up, it's probably worse than that <wink>.  
While you're holding a file lock, in theory you dare not 
execute any code that may call back into Python, because 
the called code may try to do an operation on the file 
you've got locked, and then the whole system freezes. That 
is, independent of the GIL, it's not thoroughly safe to call 
PyObject_Print with a file lock held, because an object's 
__str__ may try to "do something" with the Python-level file 
object too.  The more depressing news is that a reentrant 
file lock would solve that one.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-08-16 11:04

Message:
Logged In: YES 
user_id=31392

I think I'm less worried about PyFile_AsFile() than I am
about PyFile_WriteObject().  The latter is invoked by the
print statement.  It extracts the FILE* using
PyFile_AsFile() and proceeds to pass it to PyObject_Print().
 PyObject_Print() MUST hold the GIL, but since it has the
raw FILE* it MUST hold the file lock.  But you can't hold
both locks :-(.


----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-08-15 16:49

Message:
Logged In: YES 
user_id=45365

I'm not sure your solution of locking in the file object is feasible. Every call of PyFile_AsFile() is dangerous, if the  code proceeds to release the GIL before using the FILE* it's in danger. And this code could be in extension modules too (I know there's quite a few in my own img package).

When I did the universal newlines patch I basically ignored the problem (thinking that no-one in their right mind would close a file in one thread while it's still in use in another: how wrong can one be:-).

The only real solution may be to get rid of PyFile_AsFile altogether, and replace it with PyFile_AsFileLocked() and PyFile_Unlock() and make these calls somehow work even when the GIL is held (possibly by temporarily releasing the GIL while acquiring the file lock).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595601&group_id=5470


From noreply@sourceforge.net  Fri Aug 16 18:45:41 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Aug 2002 10:45:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-595350 ] string method bugs w/ 8bit, unicode args
Message-ID: <E17flAL-00007G-00@usw-sf-web1.sourceforge.net>

Bugs item #595350, was opened at 2002-08-15 01:56
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595350&group_id=5470

>Category: Unicode
>Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Inyeol Lee (inyeol)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: string method bugs w/ 8bit, unicode args

Initial Comment:
Python 2.2.1 (#1, Apr 10 2002, 18:25:16) 
[GCC 2.95.3 20010315 (release)] on sunos5

1. "abc".endswith("c") ->1
   "abc".endswith(u"c") -> 0 # bug.
   u"abc".endswith("c") -> 1
   u"abc".endswith(u"c") -> 1

2. "aaa".rfind("a") -> 2
   "aaa".rfind(u"a") -> 0 # bug.
   u"aaa".rfind("a") -> 2
   u"aaa".rfind(u"a") -> 2

   .rindex() has the same bug.

3. "abc".rfind("") -> 3
   "abc".rfind(u"") -> 0 # bug.
   u"abc".rfind("") -> 0 # bug.
   u"abc".rfind(u"") -> 0 # bug.

   .rindex() has the same bug.

4. "abc".replace("", "x") -> ValueError
   "abc".replace(u"", "x") -> u'abcxxxx' # bug.
   u"abc".replace("", "x") -> u'abcxxxx' # bug.
   u"abc".replace(u"", "x") -> u'abcxxxx' # bug.

   They should raise ValueError, or return u'xaxbxcx'.
   BTW, how about changing s.replace("") behavior to
return
   "xaxbxcx" (or u"xaxbxcx") for all 4 cases? It is
consistent
   with other string methods and re.sub() method.
   It seems that Guido doesn't mind changing this.

[Guido]
> If someone really wants 'abc'.replace('', '-') to
return '-a-b-c-',
> please submit patches for both 8-bit and Unicode
strings to
> SourceForge and assign to me.  I looked into this and
it's
> non-trivial: the implementation used for 8-bit
strings goes into an
> infinite loop when the pattern is empty, and the
Unicode
> implementation tacks '----' onto the end.  Please
supply doc and
> unittest patches too.  At least re does the right
thing already:

5. (it's not a bug)
   Except for .replace() above, s.split() is the only
string method
   which raises exception. How about changing this to
return
   unmodified string when empty string  is given as a
separator?
   This is consistent with re.split() behavior.

- Inyeol Lee

----------------------------------------------------------------------

>Comment By: Inyeol Lee (inyeol)
Date: 2002-08-16 17:45

Message:
Logged In: YES 
user_id=595280

uploaded patch for these bugs.  -Inyeol Lee

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595350&group_id=5470


From noreply@sourceforge.net  Fri Aug 16 18:50:21 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Aug 2002 10:50:21 -0700
Subject: [Python-bugs-list] [ python-Bugs-216289 ] Programs using Tkinter sometimes can't shut down (Windows)
Message-ID: <E17flEr-0000EY-00@usw-sf-web1.sourceforge.net>

Bugs item #216289, was opened at 2000-10-06 19:25
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=216289&group_id=5470

Category: Windows
Group: Python 2.3
Status: Open
Resolution: Later
Priority: 3
Submitted By: Tim Peters (tim_one)
Assigned to: Fredrik Lundh (effbot)
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: Jeffrey Hobbs (hobbs)
Date: 2002-08-16 10:50

Message:
Logged In: YES 
user_id=72656

johnny - That actually helps a lot and fairly clearly indicates 
the source of this hanging problem.  To give more context to 
that area, this is in the final shutdown code where it is 
(obviously) shutting down the console I/O.  The reader is 
shutdown without a check for more input (why, we are 
exiting?), so there is no issue there.

The writer however wants to make sure that the console 
output channel is drained before exit.  A blocking channel 
that is not being flushed will cause a hang.

So the question is, what is the stdio setup for Tcl in 
Py/Tkinter?  That should be examined to see whether stdio is 
clear to flush on exit.

Perhaps you can also help with more debugging.  Could you 
wrap the problematic WaitForSingleObject call with
if (consolePtr->toWrite) { ...
and perhaps also print out what to write.  It may be that 
blocking output isn't the problem at all, but rather that we are 
never receiving the signal on consolePtr->writable (usually 
done in the writer thread).  The consolePtr->toWrite check 
will at least ensure flushed channels do not enter this 
potential hanging state.

----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-08-16 07:16

Message:
Logged In: YES 
user_id=143340

I have dug out the setup I used previously and, apart from 
using Python 2.2 instead of 2.0.1, have had a go at 
reproducing my previous results.

With a debug build of Tcl/Tk and threads disabled I have 
managed to get this stack trace when it locks on exit (after 
doing a break):

ConsoleCloseProc(int * 0x006a0ae4, Tcl_Interp * 
0x00000000) line 527 + 17 bytes
TclFinalizeIOSubsystem() line 241 + 20 bytes
Tcl_FinalizeThread() line 911
Tcl_Finalize() line 812
DllMain(HINSTANCE__ * 0x00970000, unsigned long 
0x00000000, void * 0x00000001) line 197
TCL83! _DllMainCRTStartup@12 + 80 bytes
KERNEL32! bff7ddd6()
KERNEL32! bff8d123()
8176b5fc()

It is hanging up in ConsoleCloseProc() in 'tclWinConsole.c'
at about line 527:
WaitForSingleObject(consolePtr->writeThread, INFINITE);

I tried changing the timeout from INFINITE to 100ms and 
testing the return value for WAIT_TIMEOUT. Sure enough it 
occasionaly printed a message (and didn't lock-up).

Don't know if this helps. Will try to reproduce the double 
free problem in the threaded build later,

cheers,
John.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-15 07:19

Message:
Logged In: YES 
user_id=6380

Just a note so I won't forget this: Jeff Hobbs once said the
code to look at is

tk/generic/tkConsole.c:Tk_InitConsoleChannels

----------------------------------------------------------------------

Comment By: David Gravereaux (davygrvy)
Date: 2002-08-15 06:23

Message:
Logged In: YES 
user_id=7549

Hi John,

I have seen Tcl extension DLLs that set exit handlers get 
called by Tcl after they were torn-down.  NT and Win9x seem 
to be a bit different in the order of what DLLs get torn-down.  
here's a note from some old code of mine:

#ifdef __WIN32__
    // It can happen that the HEAP could have already been 
unloaded
    // from an awkward teardown caused by a Ctrl+C or other.  
Win32
    // seems to do a teardown in reverse order and by the time 
Tcl
    // knows what's going on and Tcl_Finalize calls the exit
    // handlers, this extension's data (heap?) has already been
    // unloaded by the OS.  Do a quick legal check on the 
pointer
    // first.
    //
    if (IsBadReadPtr(adapt, sizeof(T *))) return;
#endif

what's the back/stacktrace?  who is calling 
Tcl_FinalizeNotifier?  And had anyone called it before during 
the shutdown phase? I can't say with much confidence that 
this is happening here, too.  Maybe..  Could Tk be telling Tcl 
shutdown?  That's sort of backwards, if so.

I run w2k here, so I can't help in debugging from a test case.  
tclsh with a threaded build doesn't even call Tcl_Finalize to 
avoid all this!

----------------------------------------------------------------------

Comment By: Donal K. Fellows (dkf)
Date: 2002-08-15 06:09

Message:
Logged In: YES 
user_id=79902

Firstly, on the matter of threads.  Tcl/Tk on Windows uses
threads internally even in non-threaded builds.  That's
Windows for you (in particular, you can get calls parachuted
in from completely separate threads with relatively little
warning.  Also, you need threaded helpers to handle
non-blocking waiting on some kinds of objects.)

It's a bit hard to work out if the problem's been fixed
without a stack-trace (preferably with debugging symbols
enabled so that we can see what the function names and
arguments to those functions are.)  I have no  chance of
replicating this bug here (I'm currently running IRIX, but
also have some access to Solaris and Linux...)

----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-08-15 05:15

Message:
Logged In: YES 
user_id=143340

Hi to davygrvy,

my fix isn't for a thread related (deadlock) type problem - it 
is a fix for a double free type problem which is presumably 
screwing up the heap and causing the C runtime to hang.

It *is* with a threaded build (THREADDEFINES = -
DTCL_THREADS=1) which I think I enabled because I was 
using  'after' and it didn't work unless threading was 
enabled - but I may be mis-remembering here!

Also, I ended up doing all this with the debug build and 
found the -GZ flag useful - in fact it pointed out the fact that 
there was a problem with the heap.

It is worth noting that I have only seen this on Win98 and 
that using 'pythonw.exe' did *not* prevent this from 
happening,

regards John.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-14 18:00

Message:
Logged In: YES 
user_id=6380

AFAIK we never distributed a threaded build.

----------------------------------------------------------------------

Comment By: David Gravereaux (davygrvy)
Date: 2002-08-14 17:01

Message:
Logged In: YES 
user_id=7549

To johnnypops,

Where in Tcl_FinalizeNotifier() is the dead-lock occuring and 
is this with a threaded build of Tcl?


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-07-02 12:39

Message:
Logged In: YES 
user_id=31435

Jeff, a long time ago Fredrik Lundh said he was able to 
reproduce this with a short wish script (no Python, no Tkinter, 
just Tcl/Tk + wish).  I'm reassigning this to /F in the hopes 
he'll remember how.

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-07-02 11:55

Message:
Logged In: YES 
user_id=72656

I appreciate that many others see this is a problem in 
embedding Tcl, but without any clear way to reproduce this in 
Tcl/Tk itself, it's very hard for me to fix it.  I don't think that 
there is anything done in 8.4 to fix this that I recall, but if 
someone finds that the problem "goes away" with 8.4, please 
report that.

For those of course that experience this with python, the 
simple and "correct" work-around is to launch with 
pythonw.exe instead of python.exe.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-06-26 10:40

Message:
Logged In: NO 

According to http://tcl.activestate.com ActiveTcl 8.4.0 is now 
available for download.  It is new as of June 24.  I don't know 
whether this will solve our problems or not, but it's worth 
looking into.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-06-19 06:36

Message:
Logged In: NO 

I just downloaded Ruby 1.6.6 for Windows, which also uses 
Tcl/Tk 8.3 and I experience exactly the same problem there. 
So this is definitely a Tcl problem (but we know that already).

----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-06-07 12:01

Message:
Logged In: YES 
user_id=143340

Hmmm. 
I run a Python Tcl/Tk application several times every day - 
the very application that prompted my bug-hunt.

I do use "pythonw.exe" to launch it, but it used to hang 
almost as badly as "python.exe".

Whilst developing this app I used "python.exe" and 
experienced no hang-ups.

The Tcl guys point out that this bug is only one of several 
possible causes of the hang-up, maybe you are just out of 
luck.

The patch has fixed the problem on three Win98 machines, 
all of which exhibited the problem before updating the DLLs.

One thought - are you sure there weren't multiple copies of 
the tcl83.dll and tk83.dll files? My (only) copies were 
in "D:\python20\DLLs"

good luck,
John.


----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-06-03 11:55

Message:
Logged In: YES 
user_id=72656

providing Tim with a fixed DLL exactly according to John 
Popplewell's patch did not fix the problem for him.  That 
makes it seem fishy that John really didn't see the problem 
any more.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-03 09:59

Message:
Logged In: YES 
user_id=31435

I tried replacing Python 2.2.1's tk83.dll and tcl83.dll (from 
Tcl/Tk 8.3.2) with newer matched sets from

A) PythonWare's py21 distribution (Tcl/Tk 8.3.3).

and again from

B) ActiveState's Tcl/Tk 8.3.4.

All the symptoms originally reported here persisted on 
Win98SE despite that.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-05-22 06:57

Message:
Logged In: NO 

I am new to Python and encountered this bug on my very first 
Tkinter application.  It persists in Python 2.2.1 under 
Windows Me. Needless to say, it makes a bad first 
impression.  Basically, this thread says that Tkinter has been 
broken for a year and a half on a popular platform at a time 
when Python is trying to expand its user base.  Hopefully, this 
bug will be corrected soon.

If Tcl/Tk 8.4 is not released shortly you might try repackaging 
Tkinter for Win32 with an earlier version of Tcl/Tk, such as 
8.0, that doesn't encounter this problem.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 19:36

Message:
Logged In: YES 
user_id=6380

The proper action is to wait until Tcl 8.3.5 is released,
and then shaming someone else in providing you with a set of
Windowsbinaries for Tcl. You may also ask Hobbs if there's a
Windows project file to build Tcl/Tk for Windows.

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-03-11 18:31

Message:
Logged In: YES 
user_id=72656

I did end up back-porting this to the 8.3.4+ Tcl CVS on 
2002-02-25, which means it will be in an eventual 8.3.5.  
It is already in the release 8.4 alpha series.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-09 17:50

Message:
Logged In: YES 
user_id=31435

Back to Guido:  Do you think you know what the proper 
action is?  (You said that's why you reopened it, and 
there's been no new info here since then.)

----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-02-25 16:55

Message:
Logged In: YES 
user_id=143340

I knew I wasn't getting to the heart of it ....

Almost a one-liner!

It has been seriously spoiling my (otherwise crash free) 
Python experience on Win9x - hope it gets fixed soon.

cheers,
John.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-02-25 15:39

Message:
Logged In: YES 
user_id=6380

Reopened until we know what the proper action is.

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-02-25 15:32

Message:
Logged In: YES 
user_id=72656

This is mostly correct, and is fixed in the 8.4 Tcl sources 
already (I guess we can backport this).  This was mentioned 
in SF Tcl bug (account for chopped URL):

https://sourceforge.net/tracker/?
func=detail&aid=217982&group_id=10894&atid=110894

and the code comment is:

    /*
     * Only finalize the notifier if a notifier was 
installed in the
     * current thread; there is a route in which this is not
     * guaranteed to be true (when tclWin32Dll.c:DllMain() 
is called
     * with the flag DLL_PROCESS_DETACH by the OS, which 
could be
     * doing so from a thread that's never previously been 
involved
     * with Tcl, e.g. the task manager) so this check is 
important.
     *
     * Fixes Bug #217982 reported by Hugh Vu and Gene 
Leache.
     */
    if (tsdPtr == NULL) {
	return;
    }


----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-02-25 14:41

Message:
Logged In: YES 
user_id=143340

This one has been torturing me for a while.

Managed to track it down to a problem inside Tcl.
For the Tcl8.3.4 source distribution the problem is in
the file win/tclWinNotify.c 

void Tcl_FinalizeNotifier(ClientData clientData)
{
    ThreadSpecificData *tsdPtr = 
                         (ThreadSpecificData *) clientData;

    /* sometimes called with tsdPtr == NULL */
    if ( tsdPtr != NULL )
    {
        DeleteCriticalSection(&tsdPtr->crit);
        CloseHandle(tsdPtr->event);

        /*
         * Clean up the timer and messaging 
         * window for this thread.
         */

        if (tsdPtr->hwnd) {
	    KillTimer(tsdPtr->hwnd, INTERVAL_TIMER);
            DestroyWindow(tsdPtr->hwnd);
        }
    }

    /*
     * If this is the last thread to use the notifier, 
     * unregister the notifier window class.
     */

    Tcl_MutexLock(&notifierMutex);
    if ( notifierCount && !--notifierCount ) {
	UnregisterClassA( "TclNotifier", 
                          TclWinGetTclInstance());
    }
    Tcl_MutexUnlock(&notifierMutex);
}

This bodge doesn't address the underlying problem but has 
stopped me from tearing all my hair out,

cheers,
John Popplewell.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-10-24 15:27

Message:
Logged In: YES 
user_id=31435

FYI, you don't need an IDE to do this -- in Win9x, hit 
Ctrl+Alt+Del and kill the process directly.

A saner <wink> solution is to develop under Win2K, which 
doesn't appear to suffer this problem (the only reports 
I've seen, and experienced myself, came from Win9x boxes).

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-10-24 01:52

Message:
Logged In: NO 

For those who are still trapped in this bug's hell, I will 
gladly share the one thing that saved my sanity:  
WingIDE's 'Kill' command will shut down the program with 
apparent 100% certainty and no fear of lockups.  WingIDE 
has its own issues, so its not a perfect solution, but if 
you are like me and Joe (above) who test in small 
iterations, then using 'Kill' to quit out of your app while 
testing is a workaround that may preserve your sanity.

Perhaps the python gods and the Wing guys can get together 
and tell us how to replicate 'kill' into our code.  For 
now, I'll use WingIDE to edit, and pythonw.exe for my final 
client's delivery.

----------------------------------------------------------------------

Comment By: Howard Lightstone (hlightstone)
Date: 2001-09-05 10:43

Message:
Logged In: YES 
user_id=66570

I sometimes get bunches of these....

A tool I use (Taskinfo2000) reports that (after killing 
winoldap):

python.exe is blocked on a mutex named OLESCELOCKMUTEX.
The reported state is "Console Terminating".  There appears 
to be only one (os) thread running.


----------------------------------------------------------------------

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: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=216289&group_id=5470


From noreply@sourceforge.net  Fri Aug 16 19:15:33 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Aug 2002 11:15:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-595766 ] timemodule doesn't build on solaris 8
Message-ID: <E17fldF-0000nk-00@usw-sf-web1.sourceforge.net>

Bugs item #595766, was opened at 2002-08-15 18:21
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595766&group_id=5470

Category: Build
Group: Python 2.3
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Neal Norwitz (nnorwitz)
Summary: timemodule doesn't build on solaris 8

Initial Comment:
altzone is only defined if _XOPEN_SOURCE is *not*
defined (for STDC) in <time.h>.  The autoconf test for
altzone, doesn't use _XOPEN_SOURCE, so HAVE_ALTZONE is
defined.  But timemodule can't build because
_XOPEN_SOURCE is always defined in pyconfig.h before
including /usr/include/time.h.

I'm not sure how this should be fixed.  Martin, I think
you were involved with the _XOPEN_SOURCE thread.  Does
this work for you on Solaris8?  Are there OS patches
which are necessary (ie, bug in the header files)?

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-16 14:15

Message:
Logged In: YES 
user_id=33168

The problem was an old cache value.  Closing as invalid. 
Thanks Martin.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-16 02:14

Message:
Logged In: YES 
user_id=21627

It works fine for me. Why do you say that the test for
altzone doesn't use _XOPEN_SOURCE? It certainly does, by
means of

AC_DEFINE(_XOPEN_SOURCE, 500)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595766&group_id=5470


From noreply@sourceforge.net  Fri Aug 16 19:56:16 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Aug 2002 11:56:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-216289 ] Programs using Tkinter sometimes can't shut down (Windows)
Message-ID: <E17fmGe-0001fZ-00@usw-sf-web1.sourceforge.net>

Bugs item #216289, was opened at 2000-10-06 19:25
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=216289&group_id=5470

Category: Windows
Group: Python 2.3
Status: Open
Resolution: Later
Priority: 3
Submitted By: Tim Peters (tim_one)
Assigned to: Fredrik Lundh (effbot)
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: Jeffrey Hobbs (hobbs)
Date: 2002-08-16 11:56

Message:
Logged In: YES 
user_id=72656

I'm finding it a bit hard to reproduce, and now not at all.  
Could people please try replacing their current tcl83.dll with 
the one at http://www.tcl.tk/tcl83.dll.  The sig on it is:
634880 Aug 16 10:53 tcl83.dll
(md5) b35628568ddc4afed4f675d2d9a50faf  tcl83.dll

I can't hang anymore with python 2.2.1 at the Win98 
command prompt with:
   python \Python22\Tools\idle\idle.pyw

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-08-16 10:50

Message:
Logged In: YES 
user_id=72656

johnny - That actually helps a lot and fairly clearly indicates 
the source of this hanging problem.  To give more context to 
that area, this is in the final shutdown code where it is 
(obviously) shutting down the console I/O.  The reader is 
shutdown without a check for more input (why, we are 
exiting?), so there is no issue there.

The writer however wants to make sure that the console 
output channel is drained before exit.  A blocking channel 
that is not being flushed will cause a hang.

So the question is, what is the stdio setup for Tcl in 
Py/Tkinter?  That should be examined to see whether stdio is 
clear to flush on exit.

Perhaps you can also help with more debugging.  Could you 
wrap the problematic WaitForSingleObject call with
if (consolePtr->toWrite) { ...
and perhaps also print out what to write.  It may be that 
blocking output isn't the problem at all, but rather that we are 
never receiving the signal on consolePtr->writable (usually 
done in the writer thread).  The consolePtr->toWrite check 
will at least ensure flushed channels do not enter this 
potential hanging state.

----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-08-16 07:16

Message:
Logged In: YES 
user_id=143340

I have dug out the setup I used previously and, apart from 
using Python 2.2 instead of 2.0.1, have had a go at 
reproducing my previous results.

With a debug build of Tcl/Tk and threads disabled I have 
managed to get this stack trace when it locks on exit (after 
doing a break):

ConsoleCloseProc(int * 0x006a0ae4, Tcl_Interp * 
0x00000000) line 527 + 17 bytes
TclFinalizeIOSubsystem() line 241 + 20 bytes
Tcl_FinalizeThread() line 911
Tcl_Finalize() line 812
DllMain(HINSTANCE__ * 0x00970000, unsigned long 
0x00000000, void * 0x00000001) line 197
TCL83! _DllMainCRTStartup@12 + 80 bytes
KERNEL32! bff7ddd6()
KERNEL32! bff8d123()
8176b5fc()

It is hanging up in ConsoleCloseProc() in 'tclWinConsole.c'
at about line 527:
WaitForSingleObject(consolePtr->writeThread, INFINITE);

I tried changing the timeout from INFINITE to 100ms and 
testing the return value for WAIT_TIMEOUT. Sure enough it 
occasionaly printed a message (and didn't lock-up).

Don't know if this helps. Will try to reproduce the double 
free problem in the threaded build later,

cheers,
John.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-15 07:19

Message:
Logged In: YES 
user_id=6380

Just a note so I won't forget this: Jeff Hobbs once said the
code to look at is

tk/generic/tkConsole.c:Tk_InitConsoleChannels

----------------------------------------------------------------------

Comment By: David Gravereaux (davygrvy)
Date: 2002-08-15 06:23

Message:
Logged In: YES 
user_id=7549

Hi John,

I have seen Tcl extension DLLs that set exit handlers get 
called by Tcl after they were torn-down.  NT and Win9x seem 
to be a bit different in the order of what DLLs get torn-down.  
here's a note from some old code of mine:

#ifdef __WIN32__
    // It can happen that the HEAP could have already been 
unloaded
    // from an awkward teardown caused by a Ctrl+C or other.  
Win32
    // seems to do a teardown in reverse order and by the time 
Tcl
    // knows what's going on and Tcl_Finalize calls the exit
    // handlers, this extension's data (heap?) has already been
    // unloaded by the OS.  Do a quick legal check on the 
pointer
    // first.
    //
    if (IsBadReadPtr(adapt, sizeof(T *))) return;
#endif

what's the back/stacktrace?  who is calling 
Tcl_FinalizeNotifier?  And had anyone called it before during 
the shutdown phase? I can't say with much confidence that 
this is happening here, too.  Maybe..  Could Tk be telling Tcl 
shutdown?  That's sort of backwards, if so.

I run w2k here, so I can't help in debugging from a test case.  
tclsh with a threaded build doesn't even call Tcl_Finalize to 
avoid all this!

----------------------------------------------------------------------

Comment By: Donal K. Fellows (dkf)
Date: 2002-08-15 06:09

Message:
Logged In: YES 
user_id=79902

Firstly, on the matter of threads.  Tcl/Tk on Windows uses
threads internally even in non-threaded builds.  That's
Windows for you (in particular, you can get calls parachuted
in from completely separate threads with relatively little
warning.  Also, you need threaded helpers to handle
non-blocking waiting on some kinds of objects.)

It's a bit hard to work out if the problem's been fixed
without a stack-trace (preferably with debugging symbols
enabled so that we can see what the function names and
arguments to those functions are.)  I have no  chance of
replicating this bug here (I'm currently running IRIX, but
also have some access to Solaris and Linux...)

----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-08-15 05:15

Message:
Logged In: YES 
user_id=143340

Hi to davygrvy,

my fix isn't for a thread related (deadlock) type problem - it 
is a fix for a double free type problem which is presumably 
screwing up the heap and causing the C runtime to hang.

It *is* with a threaded build (THREADDEFINES = -
DTCL_THREADS=1) which I think I enabled because I was 
using  'after' and it didn't work unless threading was 
enabled - but I may be mis-remembering here!

Also, I ended up doing all this with the debug build and 
found the -GZ flag useful - in fact it pointed out the fact that 
there was a problem with the heap.

It is worth noting that I have only seen this on Win98 and 
that using 'pythonw.exe' did *not* prevent this from 
happening,

regards John.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-14 18:00

Message:
Logged In: YES 
user_id=6380

AFAIK we never distributed a threaded build.

----------------------------------------------------------------------

Comment By: David Gravereaux (davygrvy)
Date: 2002-08-14 17:01

Message:
Logged In: YES 
user_id=7549

To johnnypops,

Where in Tcl_FinalizeNotifier() is the dead-lock occuring and 
is this with a threaded build of Tcl?


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-07-02 12:39

Message:
Logged In: YES 
user_id=31435

Jeff, a long time ago Fredrik Lundh said he was able to 
reproduce this with a short wish script (no Python, no Tkinter, 
just Tcl/Tk + wish).  I'm reassigning this to /F in the hopes 
he'll remember how.

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-07-02 11:55

Message:
Logged In: YES 
user_id=72656

I appreciate that many others see this is a problem in 
embedding Tcl, but without any clear way to reproduce this in 
Tcl/Tk itself, it's very hard for me to fix it.  I don't think that 
there is anything done in 8.4 to fix this that I recall, but if 
someone finds that the problem "goes away" with 8.4, please 
report that.

For those of course that experience this with python, the 
simple and "correct" work-around is to launch with 
pythonw.exe instead of python.exe.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-06-26 10:40

Message:
Logged In: NO 

According to http://tcl.activestate.com ActiveTcl 8.4.0 is now 
available for download.  It is new as of June 24.  I don't know 
whether this will solve our problems or not, but it's worth 
looking into.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-06-19 06:36

Message:
Logged In: NO 

I just downloaded Ruby 1.6.6 for Windows, which also uses 
Tcl/Tk 8.3 and I experience exactly the same problem there. 
So this is definitely a Tcl problem (but we know that already).

----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-06-07 12:01

Message:
Logged In: YES 
user_id=143340

Hmmm. 
I run a Python Tcl/Tk application several times every day - 
the very application that prompted my bug-hunt.

I do use "pythonw.exe" to launch it, but it used to hang 
almost as badly as "python.exe".

Whilst developing this app I used "python.exe" and 
experienced no hang-ups.

The Tcl guys point out that this bug is only one of several 
possible causes of the hang-up, maybe you are just out of 
luck.

The patch has fixed the problem on three Win98 machines, 
all of which exhibited the problem before updating the DLLs.

One thought - are you sure there weren't multiple copies of 
the tcl83.dll and tk83.dll files? My (only) copies were 
in "D:\python20\DLLs"

good luck,
John.


----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-06-03 11:55

Message:
Logged In: YES 
user_id=72656

providing Tim with a fixed DLL exactly according to John 
Popplewell's patch did not fix the problem for him.  That 
makes it seem fishy that John really didn't see the problem 
any more.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-03 09:59

Message:
Logged In: YES 
user_id=31435

I tried replacing Python 2.2.1's tk83.dll and tcl83.dll (from 
Tcl/Tk 8.3.2) with newer matched sets from

A) PythonWare's py21 distribution (Tcl/Tk 8.3.3).

and again from

B) ActiveState's Tcl/Tk 8.3.4.

All the symptoms originally reported here persisted on 
Win98SE despite that.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-05-22 06:57

Message:
Logged In: NO 

I am new to Python and encountered this bug on my very first 
Tkinter application.  It persists in Python 2.2.1 under 
Windows Me. Needless to say, it makes a bad first 
impression.  Basically, this thread says that Tkinter has been 
broken for a year and a half on a popular platform at a time 
when Python is trying to expand its user base.  Hopefully, this 
bug will be corrected soon.

If Tcl/Tk 8.4 is not released shortly you might try repackaging 
Tkinter for Win32 with an earlier version of Tcl/Tk, such as 
8.0, that doesn't encounter this problem.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 19:36

Message:
Logged In: YES 
user_id=6380

The proper action is to wait until Tcl 8.3.5 is released,
and then shaming someone else in providing you with a set of
Windowsbinaries for Tcl. You may also ask Hobbs if there's a
Windows project file to build Tcl/Tk for Windows.

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-03-11 18:31

Message:
Logged In: YES 
user_id=72656

I did end up back-porting this to the 8.3.4+ Tcl CVS on 
2002-02-25, which means it will be in an eventual 8.3.5.  
It is already in the release 8.4 alpha series.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-09 17:50

Message:
Logged In: YES 
user_id=31435

Back to Guido:  Do you think you know what the proper 
action is?  (You said that's why you reopened it, and 
there's been no new info here since then.)

----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-02-25 16:55

Message:
Logged In: YES 
user_id=143340

I knew I wasn't getting to the heart of it ....

Almost a one-liner!

It has been seriously spoiling my (otherwise crash free) 
Python experience on Win9x - hope it gets fixed soon.

cheers,
John.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-02-25 15:39

Message:
Logged In: YES 
user_id=6380

Reopened until we know what the proper action is.

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-02-25 15:32

Message:
Logged In: YES 
user_id=72656

This is mostly correct, and is fixed in the 8.4 Tcl sources 
already (I guess we can backport this).  This was mentioned 
in SF Tcl bug (account for chopped URL):

https://sourceforge.net/tracker/?
func=detail&aid=217982&group_id=10894&atid=110894

and the code comment is:

    /*
     * Only finalize the notifier if a notifier was 
installed in the
     * current thread; there is a route in which this is not
     * guaranteed to be true (when tclWin32Dll.c:DllMain() 
is called
     * with the flag DLL_PROCESS_DETACH by the OS, which 
could be
     * doing so from a thread that's never previously been 
involved
     * with Tcl, e.g. the task manager) so this check is 
important.
     *
     * Fixes Bug #217982 reported by Hugh Vu and Gene 
Leache.
     */
    if (tsdPtr == NULL) {
	return;
    }


----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-02-25 14:41

Message:
Logged In: YES 
user_id=143340

This one has been torturing me for a while.

Managed to track it down to a problem inside Tcl.
For the Tcl8.3.4 source distribution the problem is in
the file win/tclWinNotify.c 

void Tcl_FinalizeNotifier(ClientData clientData)
{
    ThreadSpecificData *tsdPtr = 
                         (ThreadSpecificData *) clientData;

    /* sometimes called with tsdPtr == NULL */
    if ( tsdPtr != NULL )
    {
        DeleteCriticalSection(&tsdPtr->crit);
        CloseHandle(tsdPtr->event);

        /*
         * Clean up the timer and messaging 
         * window for this thread.
         */

        if (tsdPtr->hwnd) {
	    KillTimer(tsdPtr->hwnd, INTERVAL_TIMER);
            DestroyWindow(tsdPtr->hwnd);
        }
    }

    /*
     * If this is the last thread to use the notifier, 
     * unregister the notifier window class.
     */

    Tcl_MutexLock(&notifierMutex);
    if ( notifierCount && !--notifierCount ) {
	UnregisterClassA( "TclNotifier", 
                          TclWinGetTclInstance());
    }
    Tcl_MutexUnlock(&notifierMutex);
}

This bodge doesn't address the underlying problem but has 
stopped me from tearing all my hair out,

cheers,
John Popplewell.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-10-24 15:27

Message:
Logged In: YES 
user_id=31435

FYI, you don't need an IDE to do this -- in Win9x, hit 
Ctrl+Alt+Del and kill the process directly.

A saner <wink> solution is to develop under Win2K, which 
doesn't appear to suffer this problem (the only reports 
I've seen, and experienced myself, came from Win9x boxes).

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-10-24 01:52

Message:
Logged In: NO 

For those who are still trapped in this bug's hell, I will 
gladly share the one thing that saved my sanity:  
WingIDE's 'Kill' command will shut down the program with 
apparent 100% certainty and no fear of lockups.  WingIDE 
has its own issues, so its not a perfect solution, but if 
you are like me and Joe (above) who test in small 
iterations, then using 'Kill' to quit out of your app while 
testing is a workaround that may preserve your sanity.

Perhaps the python gods and the Wing guys can get together 
and tell us how to replicate 'kill' into our code.  For 
now, I'll use WingIDE to edit, and pythonw.exe for my final 
client's delivery.

----------------------------------------------------------------------

Comment By: Howard Lightstone (hlightstone)
Date: 2001-09-05 10:43

Message:
Logged In: YES 
user_id=66570

I sometimes get bunches of these....

A tool I use (Taskinfo2000) reports that (after killing 
winoldap):

python.exe is blocked on a mutex named OLESCELOCKMUTEX.
The reported state is "Console Terminating".  There appears 
to be only one (os) thread running.


----------------------------------------------------------------------

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: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=216289&group_id=5470


From noreply@sourceforge.net  Fri Aug 16 22:41:58 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Aug 2002 14:41:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-216289 ] Programs using Tkinter sometimes can't shut down (Windows)
Message-ID: <E17for0-0000GL-00@usw-sf-web5.sourceforge.net>

Bugs item #216289, was opened at 2000-10-06 19:25
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=216289&group_id=5470

Category: Windows
Group: Python 2.3
Status: Open
Resolution: Later
Priority: 3
Submitted By: Tim Peters (tim_one)
Assigned to: Fredrik Lundh (effbot)
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: David Gravereaux (davygrvy)
Date: 2002-08-16 14:41

Message:
Logged In: YES 
user_id=7549

>It is hanging up in ConsoleCloseProc() in 'tclWinConsole.c'
>at about line 527:
>WaitForSingleObject(consolePtr->writeThread, INFINITE);

Jeff, this might need the same attention the pipe reader 
thread got for that [exec] memory leak bug.  I think 
ConsoleWriterThread() should use WaitForMultipleObjects 
instead of WaitForSingleObject with a second event handle 
used to single a fall-out like the pipe reader thread does.  It 
appears that ConsoleCloseProc() has no way to signal the 
writer thread to close at all.

This doesn't address the blocking WriteFile() in 
ConsoleWriterThread(), though.  Is it blocking there, too?
Sorry for the large post.  I'm given the option to attach a file.

Index: tclWinConsole.c
=============================================
======================
RCS file: /cvsroot/tcl/tcl/win/tclWinConsole.c,v
retrieving revision 1.7
diff -c -r1.7 tclWinConsole.c
*** tclWinConsole.c	15 Jan 2002 17:55:30 -0000	1.7
--- tclWinConsole.c	16 Aug 2002 21:31:56 -0000
***************
*** 79,84 ****
--- 79,87 ----
      HANDLE startWriter;		/* Auto-reset 
event used by the main thread to
  				 * signal when 
the writer thread should attempt
  				 * to write to the 
console. */
+     HANDLE stopWriter;		/* Auto-reset 
event used by the main thread to
+ 				 * signal when 
the writer thread should
+ 				 * terminate. */
      HANDLE startReader;		/* Auto-reset 
event used by the main thread to
  				 * signal when 
the reader thread should attempt
  				 * to read from 
the console. */
***************
*** 516,522 ****
  	 */
  
  	Tcl_MutexLock(&consoleMutex);
! 	TerminateThread(consolePtr->writeThread, 0);
  
  	/*
  	 * Wait for the thread to terminate.  This ensures 
that we are
--- 519,525 ----
  	 */
  
  	Tcl_MutexLock(&consoleMutex);
! 	SetEvent(consolePtr->stopWriter);
  
  	/*
  	 * Wait for the thread to terminate.  This ensures 
that we are
***************
*** 1134,1149 ****
  {
  
      ConsoleInfo *infoPtr = (ConsoleInfo *)arg;
      HANDLE *handle = infoPtr->handle;
      DWORD count, toWrite;
      char *buf;
  
      for (;;) {
  	/*
  	 * Wait for the main thread to signal before 
attempting to write.
  	 */
  
! 	WaitForSingleObject(infoPtr->startWriter, 
INFINITE);
  
  	buf = infoPtr->writeBuf;
  	toWrite = infoPtr->toWrite;
--- 1137,1163 ----
  {
  
      ConsoleInfo *infoPtr = (ConsoleInfo *)arg;
+     HANDLE events[2];
      HANDLE *handle = infoPtr->handle;
      DWORD count, toWrite;
      char *buf;
  
+     events[0] = infoPtr->stopWriter;
+     events[1] = infoPtr->startWriter;
+ 
      for (;;) {
+ 	DWORD dwWait;
+ 
  	/*
  	 * Wait for the main thread to signal before 
attempting to write.
  	 */
  
! 	dwWait = WaitForMultipleObjects(events, 2, 
FALSE, INFINITE);
! 
! 	if (dwWait != (WAIT_OBJECT_0 + 1)) {
! 	    /* either the stop event or some other error, so 
exit */
! 	    return 0;
! 	}
  
  	buf = infoPtr->writeBuf;
  	toWrite = infoPtr->toWrite;
***************
*** 1251,1256 ****
--- 1265,1271 ----
      if (permissions & TCL_WRITABLE) {
  	infoPtr->writable = CreateEvent(NULL, TRUE, 
TRUE, NULL);
  	infoPtr->startWriter = CreateEvent(NULL, FALSE, 
FALSE, NULL);
+ 	infoPtr->stopWriter = CreateEvent(NULL, FALSE, 
FALSE, NULL);
  	infoPtr->writeThread = CreateThread(NULL, 8000, 
ConsoleWriterThread,
  	        infoPtr, 0, &id);
      }


----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-08-16 11:56

Message:
Logged In: YES 
user_id=72656

I'm finding it a bit hard to reproduce, and now not at all.  
Could people please try replacing their current tcl83.dll with 
the one at http://www.tcl.tk/tcl83.dll.  The sig on it is:
634880 Aug 16 10:53 tcl83.dll
(md5) b35628568ddc4afed4f675d2d9a50faf  tcl83.dll

I can't hang anymore with python 2.2.1 at the Win98 
command prompt with:
   python \Python22\Tools\idle\idle.pyw

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-08-16 10:50

Message:
Logged In: YES 
user_id=72656

johnny - That actually helps a lot and fairly clearly indicates 
the source of this hanging problem.  To give more context to 
that area, this is in the final shutdown code where it is 
(obviously) shutting down the console I/O.  The reader is 
shutdown without a check for more input (why, we are 
exiting?), so there is no issue there.

The writer however wants to make sure that the console 
output channel is drained before exit.  A blocking channel 
that is not being flushed will cause a hang.

So the question is, what is the stdio setup for Tcl in 
Py/Tkinter?  That should be examined to see whether stdio is 
clear to flush on exit.

Perhaps you can also help with more debugging.  Could you 
wrap the problematic WaitForSingleObject call with
if (consolePtr->toWrite) { ...
and perhaps also print out what to write.  It may be that 
blocking output isn't the problem at all, but rather that we are 
never receiving the signal on consolePtr->writable (usually 
done in the writer thread).  The consolePtr->toWrite check 
will at least ensure flushed channels do not enter this 
potential hanging state.

----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-08-16 07:16

Message:
Logged In: YES 
user_id=143340

I have dug out the setup I used previously and, apart from 
using Python 2.2 instead of 2.0.1, have had a go at 
reproducing my previous results.

With a debug build of Tcl/Tk and threads disabled I have 
managed to get this stack trace when it locks on exit (after 
doing a break):

ConsoleCloseProc(int * 0x006a0ae4, Tcl_Interp * 
0x00000000) line 527 + 17 bytes
TclFinalizeIOSubsystem() line 241 + 20 bytes
Tcl_FinalizeThread() line 911
Tcl_Finalize() line 812
DllMain(HINSTANCE__ * 0x00970000, unsigned long 
0x00000000, void * 0x00000001) line 197
TCL83! _DllMainCRTStartup@12 + 80 bytes
KERNEL32! bff7ddd6()
KERNEL32! bff8d123()
8176b5fc()

It is hanging up in ConsoleCloseProc() in 'tclWinConsole.c'
at about line 527:
WaitForSingleObject(consolePtr->writeThread, INFINITE);

I tried changing the timeout from INFINITE to 100ms and 
testing the return value for WAIT_TIMEOUT. Sure enough it 
occasionaly printed a message (and didn't lock-up).

Don't know if this helps. Will try to reproduce the double 
free problem in the threaded build later,

cheers,
John.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-15 07:19

Message:
Logged In: YES 
user_id=6380

Just a note so I won't forget this: Jeff Hobbs once said the
code to look at is

tk/generic/tkConsole.c:Tk_InitConsoleChannels

----------------------------------------------------------------------

Comment By: David Gravereaux (davygrvy)
Date: 2002-08-15 06:23

Message:
Logged In: YES 
user_id=7549

Hi John,

I have seen Tcl extension DLLs that set exit handlers get 
called by Tcl after they were torn-down.  NT and Win9x seem 
to be a bit different in the order of what DLLs get torn-down.  
here's a note from some old code of mine:

#ifdef __WIN32__
    // It can happen that the HEAP could have already been 
unloaded
    // from an awkward teardown caused by a Ctrl+C or other.  
Win32
    // seems to do a teardown in reverse order and by the time 
Tcl
    // knows what's going on and Tcl_Finalize calls the exit
    // handlers, this extension's data (heap?) has already been
    // unloaded by the OS.  Do a quick legal check on the 
pointer
    // first.
    //
    if (IsBadReadPtr(adapt, sizeof(T *))) return;
#endif

what's the back/stacktrace?  who is calling 
Tcl_FinalizeNotifier?  And had anyone called it before during 
the shutdown phase? I can't say with much confidence that 
this is happening here, too.  Maybe..  Could Tk be telling Tcl 
shutdown?  That's sort of backwards, if so.

I run w2k here, so I can't help in debugging from a test case.  
tclsh with a threaded build doesn't even call Tcl_Finalize to 
avoid all this!

----------------------------------------------------------------------

Comment By: Donal K. Fellows (dkf)
Date: 2002-08-15 06:09

Message:
Logged In: YES 
user_id=79902

Firstly, on the matter of threads.  Tcl/Tk on Windows uses
threads internally even in non-threaded builds.  That's
Windows for you (in particular, you can get calls parachuted
in from completely separate threads with relatively little
warning.  Also, you need threaded helpers to handle
non-blocking waiting on some kinds of objects.)

It's a bit hard to work out if the problem's been fixed
without a stack-trace (preferably with debugging symbols
enabled so that we can see what the function names and
arguments to those functions are.)  I have no  chance of
replicating this bug here (I'm currently running IRIX, but
also have some access to Solaris and Linux...)

----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-08-15 05:15

Message:
Logged In: YES 
user_id=143340

Hi to davygrvy,

my fix isn't for a thread related (deadlock) type problem - it 
is a fix for a double free type problem which is presumably 
screwing up the heap and causing the C runtime to hang.

It *is* with a threaded build (THREADDEFINES = -
DTCL_THREADS=1) which I think I enabled because I was 
using  'after' and it didn't work unless threading was 
enabled - but I may be mis-remembering here!

Also, I ended up doing all this with the debug build and 
found the -GZ flag useful - in fact it pointed out the fact that 
there was a problem with the heap.

It is worth noting that I have only seen this on Win98 and 
that using 'pythonw.exe' did *not* prevent this from 
happening,

regards John.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-14 18:00

Message:
Logged In: YES 
user_id=6380

AFAIK we never distributed a threaded build.

----------------------------------------------------------------------

Comment By: David Gravereaux (davygrvy)
Date: 2002-08-14 17:01

Message:
Logged In: YES 
user_id=7549

To johnnypops,

Where in Tcl_FinalizeNotifier() is the dead-lock occuring and 
is this with a threaded build of Tcl?


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-07-02 12:39

Message:
Logged In: YES 
user_id=31435

Jeff, a long time ago Fredrik Lundh said he was able to 
reproduce this with a short wish script (no Python, no Tkinter, 
just Tcl/Tk + wish).  I'm reassigning this to /F in the hopes 
he'll remember how.

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-07-02 11:55

Message:
Logged In: YES 
user_id=72656

I appreciate that many others see this is a problem in 
embedding Tcl, but without any clear way to reproduce this in 
Tcl/Tk itself, it's very hard for me to fix it.  I don't think that 
there is anything done in 8.4 to fix this that I recall, but if 
someone finds that the problem "goes away" with 8.4, please 
report that.

For those of course that experience this with python, the 
simple and "correct" work-around is to launch with 
pythonw.exe instead of python.exe.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-06-26 10:40

Message:
Logged In: NO 

According to http://tcl.activestate.com ActiveTcl 8.4.0 is now 
available for download.  It is new as of June 24.  I don't know 
whether this will solve our problems or not, but it's worth 
looking into.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-06-19 06:36

Message:
Logged In: NO 

I just downloaded Ruby 1.6.6 for Windows, which also uses 
Tcl/Tk 8.3 and I experience exactly the same problem there. 
So this is definitely a Tcl problem (but we know that already).

----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-06-07 12:01

Message:
Logged In: YES 
user_id=143340

Hmmm. 
I run a Python Tcl/Tk application several times every day - 
the very application that prompted my bug-hunt.

I do use "pythonw.exe" to launch it, but it used to hang 
almost as badly as "python.exe".

Whilst developing this app I used "python.exe" and 
experienced no hang-ups.

The Tcl guys point out that this bug is only one of several 
possible causes of the hang-up, maybe you are just out of 
luck.

The patch has fixed the problem on three Win98 machines, 
all of which exhibited the problem before updating the DLLs.

One thought - are you sure there weren't multiple copies of 
the tcl83.dll and tk83.dll files? My (only) copies were 
in "D:\python20\DLLs"

good luck,
John.


----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-06-03 11:55

Message:
Logged In: YES 
user_id=72656

providing Tim with a fixed DLL exactly according to John 
Popplewell's patch did not fix the problem for him.  That 
makes it seem fishy that John really didn't see the problem 
any more.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-03 09:59

Message:
Logged In: YES 
user_id=31435

I tried replacing Python 2.2.1's tk83.dll and tcl83.dll (from 
Tcl/Tk 8.3.2) with newer matched sets from

A) PythonWare's py21 distribution (Tcl/Tk 8.3.3).

and again from

B) ActiveState's Tcl/Tk 8.3.4.

All the symptoms originally reported here persisted on 
Win98SE despite that.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-05-22 06:57

Message:
Logged In: NO 

I am new to Python and encountered this bug on my very first 
Tkinter application.  It persists in Python 2.2.1 under 
Windows Me. Needless to say, it makes a bad first 
impression.  Basically, this thread says that Tkinter has been 
broken for a year and a half on a popular platform at a time 
when Python is trying to expand its user base.  Hopefully, this 
bug will be corrected soon.

If Tcl/Tk 8.4 is not released shortly you might try repackaging 
Tkinter for Win32 with an earlier version of Tcl/Tk, such as 
8.0, that doesn't encounter this problem.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 19:36

Message:
Logged In: YES 
user_id=6380

The proper action is to wait until Tcl 8.3.5 is released,
and then shaming someone else in providing you with a set of
Windowsbinaries for Tcl. You may also ask Hobbs if there's a
Windows project file to build Tcl/Tk for Windows.

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-03-11 18:31

Message:
Logged In: YES 
user_id=72656

I did end up back-porting this to the 8.3.4+ Tcl CVS on 
2002-02-25, which means it will be in an eventual 8.3.5.  
It is already in the release 8.4 alpha series.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-09 17:50

Message:
Logged In: YES 
user_id=31435

Back to Guido:  Do you think you know what the proper 
action is?  (You said that's why you reopened it, and 
there's been no new info here since then.)

----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-02-25 16:55

Message:
Logged In: YES 
user_id=143340

I knew I wasn't getting to the heart of it ....

Almost a one-liner!

It has been seriously spoiling my (otherwise crash free) 
Python experience on Win9x - hope it gets fixed soon.

cheers,
John.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-02-25 15:39

Message:
Logged In: YES 
user_id=6380

Reopened until we know what the proper action is.

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-02-25 15:32

Message:
Logged In: YES 
user_id=72656

This is mostly correct, and is fixed in the 8.4 Tcl sources 
already (I guess we can backport this).  This was mentioned 
in SF Tcl bug (account for chopped URL):

https://sourceforge.net/tracker/?
func=detail&aid=217982&group_id=10894&atid=110894

and the code comment is:

    /*
     * Only finalize the notifier if a notifier was 
installed in the
     * current thread; there is a route in which this is not
     * guaranteed to be true (when tclWin32Dll.c:DllMain() 
is called
     * with the flag DLL_PROCESS_DETACH by the OS, which 
could be
     * doing so from a thread that's never previously been 
involved
     * with Tcl, e.g. the task manager) so this check is 
important.
     *
     * Fixes Bug #217982 reported by Hugh Vu and Gene 
Leache.
     */
    if (tsdPtr == NULL) {
	return;
    }


----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-02-25 14:41

Message:
Logged In: YES 
user_id=143340

This one has been torturing me for a while.

Managed to track it down to a problem inside Tcl.
For the Tcl8.3.4 source distribution the problem is in
the file win/tclWinNotify.c 

void Tcl_FinalizeNotifier(ClientData clientData)
{
    ThreadSpecificData *tsdPtr = 
                         (ThreadSpecificData *) clientData;

    /* sometimes called with tsdPtr == NULL */
    if ( tsdPtr != NULL )
    {
        DeleteCriticalSection(&tsdPtr->crit);
        CloseHandle(tsdPtr->event);

        /*
         * Clean up the timer and messaging 
         * window for this thread.
         */

        if (tsdPtr->hwnd) {
	    KillTimer(tsdPtr->hwnd, INTERVAL_TIMER);
            DestroyWindow(tsdPtr->hwnd);
        }
    }

    /*
     * If this is the last thread to use the notifier, 
     * unregister the notifier window class.
     */

    Tcl_MutexLock(&notifierMutex);
    if ( notifierCount && !--notifierCount ) {
	UnregisterClassA( "TclNotifier", 
                          TclWinGetTclInstance());
    }
    Tcl_MutexUnlock(&notifierMutex);
}

This bodge doesn't address the underlying problem but has 
stopped me from tearing all my hair out,

cheers,
John Popplewell.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-10-24 15:27

Message:
Logged In: YES 
user_id=31435

FYI, you don't need an IDE to do this -- in Win9x, hit 
Ctrl+Alt+Del and kill the process directly.

A saner <wink> solution is to develop under Win2K, which 
doesn't appear to suffer this problem (the only reports 
I've seen, and experienced myself, came from Win9x boxes).

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-10-24 01:52

Message:
Logged In: NO 

For those who are still trapped in this bug's hell, I will 
gladly share the one thing that saved my sanity:  
WingIDE's 'Kill' command will shut down the program with 
apparent 100% certainty and no fear of lockups.  WingIDE 
has its own issues, so its not a perfect solution, but if 
you are like me and Joe (above) who test in small 
iterations, then using 'Kill' to quit out of your app while 
testing is a workaround that may preserve your sanity.

Perhaps the python gods and the Wing guys can get together 
and tell us how to replicate 'kill' into our code.  For 
now, I'll use WingIDE to edit, and pythonw.exe for my final 
client's delivery.

----------------------------------------------------------------------

Comment By: Howard Lightstone (hlightstone)
Date: 2001-09-05 10:43

Message:
Logged In: YES 
user_id=66570

I sometimes get bunches of these....

A tool I use (Taskinfo2000) reports that (after killing 
winoldap):

python.exe is blocked on a mutex named OLESCELOCKMUTEX.
The reported state is "Console Terminating".  There appears 
to be only one (os) thread running.


----------------------------------------------------------------------

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: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=216289&group_id=5470


From noreply@sourceforge.net  Fri Aug 16 22:53:05 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Aug 2002 14:53:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-216289 ] Programs using Tkinter sometimes can't shut down (Windows)
Message-ID: <E17fp1l-0000AM-00@usw-sf-web2.sourceforge.net>

Bugs item #216289, was opened at 2000-10-06 19:25
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=216289&group_id=5470

Category: Windows
Group: Python 2.3
Status: Open
Resolution: Later
Priority: 3
Submitted By: Tim Peters (tim_one)
Assigned to: Fredrik Lundh (effbot)
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: David Gravereaux (davygrvy)
Date: 2002-08-16 14:53

Message:
Logged In: YES 
user_id=7549

Whoop, error in the patch..  consoleMutex might not need to 
be locked.  It could cause a new dead-lock.

----------------------------------------------------------------------

Comment By: David Gravereaux (davygrvy)
Date: 2002-08-16 14:41

Message:
Logged In: YES 
user_id=7549

>It is hanging up in ConsoleCloseProc() in 'tclWinConsole.c'
>at about line 527:
>WaitForSingleObject(consolePtr->writeThread, INFINITE);

Jeff, this might need the same attention the pipe reader 
thread got for that [exec] memory leak bug.  I think 
ConsoleWriterThread() should use WaitForMultipleObjects 
instead of WaitForSingleObject with a second event handle 
used to single a fall-out like the pipe reader thread does.  It 
appears that ConsoleCloseProc() has no way to signal the 
writer thread to close at all.

This doesn't address the blocking WriteFile() in 
ConsoleWriterThread(), though.  Is it blocking there, too?
Sorry for the large post.  I'm given the option to attach a file.

Index: tclWinConsole.c
=============================================
======================
RCS file: /cvsroot/tcl/tcl/win/tclWinConsole.c,v
retrieving revision 1.7
diff -c -r1.7 tclWinConsole.c
*** tclWinConsole.c	15 Jan 2002 17:55:30 -0000	1.7
--- tclWinConsole.c	16 Aug 2002 21:31:56 -0000
***************
*** 79,84 ****
--- 79,87 ----
      HANDLE startWriter;		/* Auto-reset 
event used by the main thread to
  				 * signal when 
the writer thread should attempt
  				 * to write to the 
console. */
+     HANDLE stopWriter;		/* Auto-reset 
event used by the main thread to
+ 				 * signal when 
the writer thread should
+ 				 * terminate. */
      HANDLE startReader;		/* Auto-reset 
event used by the main thread to
  				 * signal when 
the reader thread should attempt
  				 * to read from 
the console. */
***************
*** 516,522 ****
  	 */
  
  	Tcl_MutexLock(&consoleMutex);
! 	TerminateThread(consolePtr->writeThread, 0);
  
  	/*
  	 * Wait for the thread to terminate.  This ensures 
that we are
--- 519,525 ----
  	 */
  
  	Tcl_MutexLock(&consoleMutex);
! 	SetEvent(consolePtr->stopWriter);
  
  	/*
  	 * Wait for the thread to terminate.  This ensures 
that we are
***************
*** 1134,1149 ****
  {
  
      ConsoleInfo *infoPtr = (ConsoleInfo *)arg;
      HANDLE *handle = infoPtr->handle;
      DWORD count, toWrite;
      char *buf;
  
      for (;;) {
  	/*
  	 * Wait for the main thread to signal before 
attempting to write.
  	 */
  
! 	WaitForSingleObject(infoPtr->startWriter, 
INFINITE);
  
  	buf = infoPtr->writeBuf;
  	toWrite = infoPtr->toWrite;
--- 1137,1163 ----
  {
  
      ConsoleInfo *infoPtr = (ConsoleInfo *)arg;
+     HANDLE events[2];
      HANDLE *handle = infoPtr->handle;
      DWORD count, toWrite;
      char *buf;
  
+     events[0] = infoPtr->stopWriter;
+     events[1] = infoPtr->startWriter;
+ 
      for (;;) {
+ 	DWORD dwWait;
+ 
  	/*
  	 * Wait for the main thread to signal before 
attempting to write.
  	 */
  
! 	dwWait = WaitForMultipleObjects(events, 2, 
FALSE, INFINITE);
! 
! 	if (dwWait != (WAIT_OBJECT_0 + 1)) {
! 	    /* either the stop event or some other error, so 
exit */
! 	    return 0;
! 	}
  
  	buf = infoPtr->writeBuf;
  	toWrite = infoPtr->toWrite;
***************
*** 1251,1256 ****
--- 1265,1271 ----
      if (permissions & TCL_WRITABLE) {
  	infoPtr->writable = CreateEvent(NULL, TRUE, 
TRUE, NULL);
  	infoPtr->startWriter = CreateEvent(NULL, FALSE, 
FALSE, NULL);
+ 	infoPtr->stopWriter = CreateEvent(NULL, FALSE, 
FALSE, NULL);
  	infoPtr->writeThread = CreateThread(NULL, 8000, 
ConsoleWriterThread,
  	        infoPtr, 0, &id);
      }


----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-08-16 11:56

Message:
Logged In: YES 
user_id=72656

I'm finding it a bit hard to reproduce, and now not at all.  
Could people please try replacing their current tcl83.dll with 
the one at http://www.tcl.tk/tcl83.dll.  The sig on it is:
634880 Aug 16 10:53 tcl83.dll
(md5) b35628568ddc4afed4f675d2d9a50faf  tcl83.dll

I can't hang anymore with python 2.2.1 at the Win98 
command prompt with:
   python \Python22\Tools\idle\idle.pyw

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-08-16 10:50

Message:
Logged In: YES 
user_id=72656

johnny - That actually helps a lot and fairly clearly indicates 
the source of this hanging problem.  To give more context to 
that area, this is in the final shutdown code where it is 
(obviously) shutting down the console I/O.  The reader is 
shutdown without a check for more input (why, we are 
exiting?), so there is no issue there.

The writer however wants to make sure that the console 
output channel is drained before exit.  A blocking channel 
that is not being flushed will cause a hang.

So the question is, what is the stdio setup for Tcl in 
Py/Tkinter?  That should be examined to see whether stdio is 
clear to flush on exit.

Perhaps you can also help with more debugging.  Could you 
wrap the problematic WaitForSingleObject call with
if (consolePtr->toWrite) { ...
and perhaps also print out what to write.  It may be that 
blocking output isn't the problem at all, but rather that we are 
never receiving the signal on consolePtr->writable (usually 
done in the writer thread).  The consolePtr->toWrite check 
will at least ensure flushed channels do not enter this 
potential hanging state.

----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-08-16 07:16

Message:
Logged In: YES 
user_id=143340

I have dug out the setup I used previously and, apart from 
using Python 2.2 instead of 2.0.1, have had a go at 
reproducing my previous results.

With a debug build of Tcl/Tk and threads disabled I have 
managed to get this stack trace when it locks on exit (after 
doing a break):

ConsoleCloseProc(int * 0x006a0ae4, Tcl_Interp * 
0x00000000) line 527 + 17 bytes
TclFinalizeIOSubsystem() line 241 + 20 bytes
Tcl_FinalizeThread() line 911
Tcl_Finalize() line 812
DllMain(HINSTANCE__ * 0x00970000, unsigned long 
0x00000000, void * 0x00000001) line 197
TCL83! _DllMainCRTStartup@12 + 80 bytes
KERNEL32! bff7ddd6()
KERNEL32! bff8d123()
8176b5fc()

It is hanging up in ConsoleCloseProc() in 'tclWinConsole.c'
at about line 527:
WaitForSingleObject(consolePtr->writeThread, INFINITE);

I tried changing the timeout from INFINITE to 100ms and 
testing the return value for WAIT_TIMEOUT. Sure enough it 
occasionaly printed a message (and didn't lock-up).

Don't know if this helps. Will try to reproduce the double 
free problem in the threaded build later,

cheers,
John.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-15 07:19

Message:
Logged In: YES 
user_id=6380

Just a note so I won't forget this: Jeff Hobbs once said the
code to look at is

tk/generic/tkConsole.c:Tk_InitConsoleChannels

----------------------------------------------------------------------

Comment By: David Gravereaux (davygrvy)
Date: 2002-08-15 06:23

Message:
Logged In: YES 
user_id=7549

Hi John,

I have seen Tcl extension DLLs that set exit handlers get 
called by Tcl after they were torn-down.  NT and Win9x seem 
to be a bit different in the order of what DLLs get torn-down.  
here's a note from some old code of mine:

#ifdef __WIN32__
    // It can happen that the HEAP could have already been 
unloaded
    // from an awkward teardown caused by a Ctrl+C or other.  
Win32
    // seems to do a teardown in reverse order and by the time 
Tcl
    // knows what's going on and Tcl_Finalize calls the exit
    // handlers, this extension's data (heap?) has already been
    // unloaded by the OS.  Do a quick legal check on the 
pointer
    // first.
    //
    if (IsBadReadPtr(adapt, sizeof(T *))) return;
#endif

what's the back/stacktrace?  who is calling 
Tcl_FinalizeNotifier?  And had anyone called it before during 
the shutdown phase? I can't say with much confidence that 
this is happening here, too.  Maybe..  Could Tk be telling Tcl 
shutdown?  That's sort of backwards, if so.

I run w2k here, so I can't help in debugging from a test case.  
tclsh with a threaded build doesn't even call Tcl_Finalize to 
avoid all this!

----------------------------------------------------------------------

Comment By: Donal K. Fellows (dkf)
Date: 2002-08-15 06:09

Message:
Logged In: YES 
user_id=79902

Firstly, on the matter of threads.  Tcl/Tk on Windows uses
threads internally even in non-threaded builds.  That's
Windows for you (in particular, you can get calls parachuted
in from completely separate threads with relatively little
warning.  Also, you need threaded helpers to handle
non-blocking waiting on some kinds of objects.)

It's a bit hard to work out if the problem's been fixed
without a stack-trace (preferably with debugging symbols
enabled so that we can see what the function names and
arguments to those functions are.)  I have no  chance of
replicating this bug here (I'm currently running IRIX, but
also have some access to Solaris and Linux...)

----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-08-15 05:15

Message:
Logged In: YES 
user_id=143340

Hi to davygrvy,

my fix isn't for a thread related (deadlock) type problem - it 
is a fix for a double free type problem which is presumably 
screwing up the heap and causing the C runtime to hang.

It *is* with a threaded build (THREADDEFINES = -
DTCL_THREADS=1) which I think I enabled because I was 
using  'after' and it didn't work unless threading was 
enabled - but I may be mis-remembering here!

Also, I ended up doing all this with the debug build and 
found the -GZ flag useful - in fact it pointed out the fact that 
there was a problem with the heap.

It is worth noting that I have only seen this on Win98 and 
that using 'pythonw.exe' did *not* prevent this from 
happening,

regards John.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-14 18:00

Message:
Logged In: YES 
user_id=6380

AFAIK we never distributed a threaded build.

----------------------------------------------------------------------

Comment By: David Gravereaux (davygrvy)
Date: 2002-08-14 17:01

Message:
Logged In: YES 
user_id=7549

To johnnypops,

Where in Tcl_FinalizeNotifier() is the dead-lock occuring and 
is this with a threaded build of Tcl?


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-07-02 12:39

Message:
Logged In: YES 
user_id=31435

Jeff, a long time ago Fredrik Lundh said he was able to 
reproduce this with a short wish script (no Python, no Tkinter, 
just Tcl/Tk + wish).  I'm reassigning this to /F in the hopes 
he'll remember how.

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-07-02 11:55

Message:
Logged In: YES 
user_id=72656

I appreciate that many others see this is a problem in 
embedding Tcl, but without any clear way to reproduce this in 
Tcl/Tk itself, it's very hard for me to fix it.  I don't think that 
there is anything done in 8.4 to fix this that I recall, but if 
someone finds that the problem "goes away" with 8.4, please 
report that.

For those of course that experience this with python, the 
simple and "correct" work-around is to launch with 
pythonw.exe instead of python.exe.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-06-26 10:40

Message:
Logged In: NO 

According to http://tcl.activestate.com ActiveTcl 8.4.0 is now 
available for download.  It is new as of June 24.  I don't know 
whether this will solve our problems or not, but it's worth 
looking into.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-06-19 06:36

Message:
Logged In: NO 

I just downloaded Ruby 1.6.6 for Windows, which also uses 
Tcl/Tk 8.3 and I experience exactly the same problem there. 
So this is definitely a Tcl problem (but we know that already).

----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-06-07 12:01

Message:
Logged In: YES 
user_id=143340

Hmmm. 
I run a Python Tcl/Tk application several times every day - 
the very application that prompted my bug-hunt.

I do use "pythonw.exe" to launch it, but it used to hang 
almost as badly as "python.exe".

Whilst developing this app I used "python.exe" and 
experienced no hang-ups.

The Tcl guys point out that this bug is only one of several 
possible causes of the hang-up, maybe you are just out of 
luck.

The patch has fixed the problem on three Win98 machines, 
all of which exhibited the problem before updating the DLLs.

One thought - are you sure there weren't multiple copies of 
the tcl83.dll and tk83.dll files? My (only) copies were 
in "D:\python20\DLLs"

good luck,
John.


----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-06-03 11:55

Message:
Logged In: YES 
user_id=72656

providing Tim with a fixed DLL exactly according to John 
Popplewell's patch did not fix the problem for him.  That 
makes it seem fishy that John really didn't see the problem 
any more.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-03 09:59

Message:
Logged In: YES 
user_id=31435

I tried replacing Python 2.2.1's tk83.dll and tcl83.dll (from 
Tcl/Tk 8.3.2) with newer matched sets from

A) PythonWare's py21 distribution (Tcl/Tk 8.3.3).

and again from

B) ActiveState's Tcl/Tk 8.3.4.

All the symptoms originally reported here persisted on 
Win98SE despite that.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-05-22 06:57

Message:
Logged In: NO 

I am new to Python and encountered this bug on my very first 
Tkinter application.  It persists in Python 2.2.1 under 
Windows Me. Needless to say, it makes a bad first 
impression.  Basically, this thread says that Tkinter has been 
broken for a year and a half on a popular platform at a time 
when Python is trying to expand its user base.  Hopefully, this 
bug will be corrected soon.

If Tcl/Tk 8.4 is not released shortly you might try repackaging 
Tkinter for Win32 with an earlier version of Tcl/Tk, such as 
8.0, that doesn't encounter this problem.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 19:36

Message:
Logged In: YES 
user_id=6380

The proper action is to wait until Tcl 8.3.5 is released,
and then shaming someone else in providing you with a set of
Windowsbinaries for Tcl. You may also ask Hobbs if there's a
Windows project file to build Tcl/Tk for Windows.

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-03-11 18:31

Message:
Logged In: YES 
user_id=72656

I did end up back-porting this to the 8.3.4+ Tcl CVS on 
2002-02-25, which means it will be in an eventual 8.3.5.  
It is already in the release 8.4 alpha series.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-09 17:50

Message:
Logged In: YES 
user_id=31435

Back to Guido:  Do you think you know what the proper 
action is?  (You said that's why you reopened it, and 
there's been no new info here since then.)

----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-02-25 16:55

Message:
Logged In: YES 
user_id=143340

I knew I wasn't getting to the heart of it ....

Almost a one-liner!

It has been seriously spoiling my (otherwise crash free) 
Python experience on Win9x - hope it gets fixed soon.

cheers,
John.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-02-25 15:39

Message:
Logged In: YES 
user_id=6380

Reopened until we know what the proper action is.

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-02-25 15:32

Message:
Logged In: YES 
user_id=72656

This is mostly correct, and is fixed in the 8.4 Tcl sources 
already (I guess we can backport this).  This was mentioned 
in SF Tcl bug (account for chopped URL):

https://sourceforge.net/tracker/?
func=detail&aid=217982&group_id=10894&atid=110894

and the code comment is:

    /*
     * Only finalize the notifier if a notifier was 
installed in the
     * current thread; there is a route in which this is not
     * guaranteed to be true (when tclWin32Dll.c:DllMain() 
is called
     * with the flag DLL_PROCESS_DETACH by the OS, which 
could be
     * doing so from a thread that's never previously been 
involved
     * with Tcl, e.g. the task manager) so this check is 
important.
     *
     * Fixes Bug #217982 reported by Hugh Vu and Gene 
Leache.
     */
    if (tsdPtr == NULL) {
	return;
    }


----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-02-25 14:41

Message:
Logged In: YES 
user_id=143340

This one has been torturing me for a while.

Managed to track it down to a problem inside Tcl.
For the Tcl8.3.4 source distribution the problem is in
the file win/tclWinNotify.c 

void Tcl_FinalizeNotifier(ClientData clientData)
{
    ThreadSpecificData *tsdPtr = 
                         (ThreadSpecificData *) clientData;

    /* sometimes called with tsdPtr == NULL */
    if ( tsdPtr != NULL )
    {
        DeleteCriticalSection(&tsdPtr->crit);
        CloseHandle(tsdPtr->event);

        /*
         * Clean up the timer and messaging 
         * window for this thread.
         */

        if (tsdPtr->hwnd) {
	    KillTimer(tsdPtr->hwnd, INTERVAL_TIMER);
            DestroyWindow(tsdPtr->hwnd);
        }
    }

    /*
     * If this is the last thread to use the notifier, 
     * unregister the notifier window class.
     */

    Tcl_MutexLock(&notifierMutex);
    if ( notifierCount && !--notifierCount ) {
	UnregisterClassA( "TclNotifier", 
                          TclWinGetTclInstance());
    }
    Tcl_MutexUnlock(&notifierMutex);
}

This bodge doesn't address the underlying problem but has 
stopped me from tearing all my hair out,

cheers,
John Popplewell.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-10-24 15:27

Message:
Logged In: YES 
user_id=31435

FYI, you don't need an IDE to do this -- in Win9x, hit 
Ctrl+Alt+Del and kill the process directly.

A saner <wink> solution is to develop under Win2K, which 
doesn't appear to suffer this problem (the only reports 
I've seen, and experienced myself, came from Win9x boxes).

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-10-24 01:52

Message:
Logged In: NO 

For those who are still trapped in this bug's hell, I will 
gladly share the one thing that saved my sanity:  
WingIDE's 'Kill' command will shut down the program with 
apparent 100% certainty and no fear of lockups.  WingIDE 
has its own issues, so its not a perfect solution, but if 
you are like me and Joe (above) who test in small 
iterations, then using 'Kill' to quit out of your app while 
testing is a workaround that may preserve your sanity.

Perhaps the python gods and the Wing guys can get together 
and tell us how to replicate 'kill' into our code.  For 
now, I'll use WingIDE to edit, and pythonw.exe for my final 
client's delivery.

----------------------------------------------------------------------

Comment By: Howard Lightstone (hlightstone)
Date: 2001-09-05 10:43

Message:
Logged In: YES 
user_id=66570

I sometimes get bunches of these....

A tool I use (Taskinfo2000) reports that (after killing 
winoldap):

python.exe is blocked on a mutex named OLESCELOCKMUTEX.
The reported state is "Console Terminating".  There appears 
to be only one (os) thread running.


----------------------------------------------------------------------

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: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=216289&group_id=5470


From noreply@sourceforge.net  Fri Aug 16 23:21:07 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Aug 2002 15:21:07 -0700
Subject: [Python-bugs-list] [ python-Bugs-595601 ] file (& socket) I/O are not thread safe
Message-ID: <E17fpSt-000822-00@usw-sf-web4.sourceforge.net>

Bugs item #595601, was opened at 2002-08-15 18:34
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595601&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Jeremy Hylton (jhylton)
Summary: file (& socket) I/O are not thread safe

Initial Comment:
We recently found an assertion failure in the universal
newline support when running a multithreaded program
where two threads used the same Python file object. 
The assert(stream != NULL) test in 
Py_UniversalNewlineFread() fails once in a blue moon,
where stream is the stdio FILE * that the fileobject
wraps.  Further analysis suggests that there is a race
condition between checking FILE * and using FILE * that
exists in at least Python 2.1 and up.

I'll actually describe the problem as it exists in
Python 2.2, because it is simpler to avoid the
universal newline code.  That code isn't the source of
the problem, although it's assert() uncovers it in a
clear way.

In file_read() (rev 2.141.6.5), the first thing it does
is check if f_fp (the FILE *) is NULL.  If so it raises
an IOError -- operation on closed file object.  Later,
file_read() enters a for loop that calls fread() until
enough bytes have been read.

	for (;;) {
		Py_BEGIN_ALLOW_THREADS
		errno = 0;
		chunksize = fread(BUF(v) + bytesread, 1,
				  buffersize - bytesread, f->f_fp);
		Py_END_ALLOW_THREADS
		if (chunksize == 0) {
			if (!ferror(f->f_fp))
				break;
			PyErr_SetFromErrno(PyExc_IOError);
			clearerr(f->f_fp);
			Py_DECREF(v);
			return NULL;
		}

The problem is that fread() is called after the global
interpreter lock is released.  Since the lock is
released, another Python thread could run and modify
the file object, changing the value of f->f_fp.  Under
the current interpreter lock scheme, it isn't safe to
use f->f_fp without holding the interpreter lock.

The current file_read() code can fail in a variety of
ways.  It's possible for a second thread to close the
file, which will set f->f_fp to NULL.  Who knows what
fread() will do when NULL is passed.

The universal newline code is squirrels the FILE * in a
local variable, which is worse.  If it happens that
another thread closes the file, at best the local
points to a closed FILE *.  But that memory could get
recycled and then there's no way to know what it points to.

socket I/O has a similar problem with unsafe sharing of
the file descriptor.  However, this problem seems less
severe in general, because we'd just be passing a bogus
file descriptor to a system call.  We don't have to
worry about whether stdio will dump core when passed a
bogus pointer.  There is a chance the a socket will be
closed and its file descriptor used for a different
socket.  So a call to recv() with one socket ends up
using a different socket.  That will be a nightmare to
debug, but it won't cause a segfault.  (And, in
general, files and sockets shouldn't be shared between
application threads unless the application is going to
make sure its safe.)

The solution to this problem is to use a
per-file-object lock to guard access to f->f_fp.  No
thread should read or right f->f_fp without holding the
lock.  To make sure that other threads get a chance to
run when there is contention for the file, the
file-object lock should never be held when the GIL is held.


----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2002-08-17 00:21

Message:
Logged In: YES 
user_id=45365

Uhm... Isn't it good enough if you don't hold the GIL while you acquire the file lock? When I looked at it I thought it would be (but then, I didn't look very hard:-).

And there may be another way around this problem too. If you're really only worried about closing (Python at the moment couldn't care less that when two threads write to the same file at the same time the output may be intermingled or other fun things may happen) then don't lock the file, but simply set a flag "keep your hands off the FILE*, I'm using it!" and in that case delay the close. You may want to protect the flag and the delayed close with a lock, I guess.

Or you could define this as a programmer error and raise an exception if one thread tries to close a file another thread is using. (The application will know much better how to handle the contention with locking or some other mechanism).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-08-16 17:26

Message:
Logged In: YES 
user_id=31435

To cheer you up, it's probably worse than that <wink>.  
While you're holding a file lock, in theory you dare not 
execute any code that may call back into Python, because 
the called code may try to do an operation on the file 
you've got locked, and then the whole system freezes. That 
is, independent of the GIL, it's not thoroughly safe to call 
PyObject_Print with a file lock held, because an object's 
__str__ may try to "do something" with the Python-level file 
object too.  The more depressing news is that a reentrant 
file lock would solve that one.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-08-16 17:04

Message:
Logged In: YES 
user_id=31392

I think I'm less worried about PyFile_AsFile() than I am
about PyFile_WriteObject().  The latter is invoked by the
print statement.  It extracts the FILE* using
PyFile_AsFile() and proceeds to pass it to PyObject_Print().
 PyObject_Print() MUST hold the GIL, but since it has the
raw FILE* it MUST hold the file lock.  But you can't hold
both locks :-(.


----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-08-15 22:49

Message:
Logged In: YES 
user_id=45365

I'm not sure your solution of locking in the file object is feasible. Every call of PyFile_AsFile() is dangerous, if the  code proceeds to release the GIL before using the FILE* it's in danger. And this code could be in extension modules too (I know there's quite a few in my own img package).

When I did the universal newlines patch I basically ignored the problem (thinking that no-one in their right mind would close a file in one thread while it's still in use in another: how wrong can one be:-).

The only real solution may be to get rid of PyFile_AsFile altogether, and replace it with PyFile_AsFileLocked() and PyFile_Unlock() and make these calls somehow work even when the GIL is held (possibly by temporarily releasing the GIL while acquiring the file lock).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595601&group_id=5470


From noreply@sourceforge.net  Fri Aug 16 23:43:58 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Aug 2002 15:43:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-595601 ] file (& socket) I/O are not thread safe
Message-ID: <E17fpp0-0001Jt-00@usw-sf-web5.sourceforge.net>

Bugs item #595601, was opened at 2002-08-15 12:34
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595601&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Jeremy Hylton (jhylton)
Summary: file (& socket) I/O are not thread safe

Initial Comment:
We recently found an assertion failure in the universal
newline support when running a multithreaded program
where two threads used the same Python file object. 
The assert(stream != NULL) test in 
Py_UniversalNewlineFread() fails once in a blue moon,
where stream is the stdio FILE * that the fileobject
wraps.  Further analysis suggests that there is a race
condition between checking FILE * and using FILE * that
exists in at least Python 2.1 and up.

I'll actually describe the problem as it exists in
Python 2.2, because it is simpler to avoid the
universal newline code.  That code isn't the source of
the problem, although it's assert() uncovers it in a
clear way.

In file_read() (rev 2.141.6.5), the first thing it does
is check if f_fp (the FILE *) is NULL.  If so it raises
an IOError -- operation on closed file object.  Later,
file_read() enters a for loop that calls fread() until
enough bytes have been read.

	for (;;) {
		Py_BEGIN_ALLOW_THREADS
		errno = 0;
		chunksize = fread(BUF(v) + bytesread, 1,
				  buffersize - bytesread, f->f_fp);
		Py_END_ALLOW_THREADS
		if (chunksize == 0) {
			if (!ferror(f->f_fp))
				break;
			PyErr_SetFromErrno(PyExc_IOError);
			clearerr(f->f_fp);
			Py_DECREF(v);
			return NULL;
		}

The problem is that fread() is called after the global
interpreter lock is released.  Since the lock is
released, another Python thread could run and modify
the file object, changing the value of f->f_fp.  Under
the current interpreter lock scheme, it isn't safe to
use f->f_fp without holding the interpreter lock.

The current file_read() code can fail in a variety of
ways.  It's possible for a second thread to close the
file, which will set f->f_fp to NULL.  Who knows what
fread() will do when NULL is passed.

The universal newline code is squirrels the FILE * in a
local variable, which is worse.  If it happens that
another thread closes the file, at best the local
points to a closed FILE *.  But that memory could get
recycled and then there's no way to know what it points to.

socket I/O has a similar problem with unsafe sharing of
the file descriptor.  However, this problem seems less
severe in general, because we'd just be passing a bogus
file descriptor to a system call.  We don't have to
worry about whether stdio will dump core when passed a
bogus pointer.  There is a chance the a socket will be
closed and its file descriptor used for a different
socket.  So a call to recv() with one socket ends up
using a different socket.  That will be a nightmare to
debug, but it won't cause a segfault.  (And, in
general, files and sockets shouldn't be shared between
application threads unless the application is going to
make sure its safe.)

The solution to this problem is to use a
per-file-object lock to guard access to f->f_fp.  No
thread should read or right f->f_fp without holding the
lock.  To make sure that other threads get a chance to
run when there is contention for the file, the
file-object lock should never be held when the GIL is held.


----------------------------------------------------------------------

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2002-08-16 18:43

Message:
Logged In: YES 
user_id=12800

Jack, your last paragraph sounds like a good idea <waiting
for Tim to shoot holes in it>.  Isn't the whole point to
avoid core dumps, not to "make it work right" whatever that
means?  We should take the simplest approach to avoiding
crashes.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-08-16 18:21

Message:
Logged In: YES 
user_id=45365

Uhm... Isn't it good enough if you don't hold the GIL while you acquire the file lock? When I looked at it I thought it would be (but then, I didn't look very hard:-).

And there may be another way around this problem too. If you're really only worried about closing (Python at the moment couldn't care less that when two threads write to the same file at the same time the output may be intermingled or other fun things may happen) then don't lock the file, but simply set a flag "keep your hands off the FILE*, I'm using it!" and in that case delay the close. You may want to protect the flag and the delayed close with a lock, I guess.

Or you could define this as a programmer error and raise an exception if one thread tries to close a file another thread is using. (The application will know much better how to handle the contention with locking or some other mechanism).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-08-16 11:26

Message:
Logged In: YES 
user_id=31435

To cheer you up, it's probably worse than that <wink>.  
While you're holding a file lock, in theory you dare not 
execute any code that may call back into Python, because 
the called code may try to do an operation on the file 
you've got locked, and then the whole system freezes. That 
is, independent of the GIL, it's not thoroughly safe to call 
PyObject_Print with a file lock held, because an object's 
__str__ may try to "do something" with the Python-level file 
object too.  The more depressing news is that a reentrant 
file lock would solve that one.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-08-16 11:04

Message:
Logged In: YES 
user_id=31392

I think I'm less worried about PyFile_AsFile() than I am
about PyFile_WriteObject().  The latter is invoked by the
print statement.  It extracts the FILE* using
PyFile_AsFile() and proceeds to pass it to PyObject_Print().
 PyObject_Print() MUST hold the GIL, but since it has the
raw FILE* it MUST hold the file lock.  But you can't hold
both locks :-(.


----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-08-15 16:49

Message:
Logged In: YES 
user_id=45365

I'm not sure your solution of locking in the file object is feasible. Every call of PyFile_AsFile() is dangerous, if the  code proceeds to release the GIL before using the FILE* it's in danger. And this code could be in extension modules too (I know there's quite a few in my own img package).

When I did the universal newlines patch I basically ignored the problem (thinking that no-one in their right mind would close a file in one thread while it's still in use in another: how wrong can one be:-).

The only real solution may be to get rid of PyFile_AsFile altogether, and replace it with PyFile_AsFileLocked() and PyFile_Unlock() and make these calls somehow work even when the GIL is held (possibly by temporarily releasing the GIL while acquiring the file lock).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595601&group_id=5470


From noreply@sourceforge.net  Sat Aug 17 00:03:26 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Aug 2002 16:03:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-216289 ] Programs using Tkinter sometimes can't shut down (Windows)
Message-ID: <E17fq7q-0001Jd-00@usw-sf-web2.sourceforge.net>

Bugs item #216289, was opened at 2000-10-06 20:25
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=216289&group_id=5470

Category: Windows
Group: Python 2.3
Status: Open
Resolution: Later
Priority: 3
Submitted By: Tim Peters (tim_one)
Assigned to: Fredrik Lundh (effbot)
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: Doug Henderson (djhender)
Date: 2002-08-16 17:03

Message:
Logged In: YES 
user_id=148444

I downloaded and tested the tcl83.dll from www.tcl.tk with 
Python 2.2.1 on Win98SE using my BugDemo.py script 
from a related bug report [231207]. Several test runs 
showed that a problem still exists. The app hangs until 
Winopldapp is killed, however this leaves tcl83.dll in use. 
The problem does not occur on every execution. Some 
types of activity seem to provoke the hang, for instance, 
minimizing and maximizing the window seems to increase 
the change that it will hang on exit.

----------------------------------------------------------------------

Comment By: David Gravereaux (davygrvy)
Date: 2002-08-16 15:53

Message:
Logged In: YES 
user_id=7549

Whoop, error in the patch..  consoleMutex might not need to 
be locked.  It could cause a new dead-lock.

----------------------------------------------------------------------

Comment By: David Gravereaux (davygrvy)
Date: 2002-08-16 15:41

Message:
Logged In: YES 
user_id=7549

>It is hanging up in ConsoleCloseProc() in 'tclWinConsole.c'
>at about line 527:
>WaitForSingleObject(consolePtr->writeThread, INFINITE);

Jeff, this might need the same attention the pipe reader 
thread got for that [exec] memory leak bug.  I think 
ConsoleWriterThread() should use WaitForMultipleObjects 
instead of WaitForSingleObject with a second event handle 
used to single a fall-out like the pipe reader thread does.  It 
appears that ConsoleCloseProc() has no way to signal the 
writer thread to close at all.

This doesn't address the blocking WriteFile() in 
ConsoleWriterThread(), though.  Is it blocking there, too?
Sorry for the large post.  I'm given the option to attach a file.

Index: tclWinConsole.c
=============================================
======================
RCS file: /cvsroot/tcl/tcl/win/tclWinConsole.c,v
retrieving revision 1.7
diff -c -r1.7 tclWinConsole.c
*** tclWinConsole.c	15 Jan 2002 17:55:30 -0000	1.7
--- tclWinConsole.c	16 Aug 2002 21:31:56 -0000
***************
*** 79,84 ****
--- 79,87 ----
      HANDLE startWriter;		/* Auto-reset 
event used by the main thread to
  				 * signal when 
the writer thread should attempt
  				 * to write to the 
console. */
+     HANDLE stopWriter;		/* Auto-reset 
event used by the main thread to
+ 				 * signal when 
the writer thread should
+ 				 * terminate. */
      HANDLE startReader;		/* Auto-reset 
event used by the main thread to
  				 * signal when 
the reader thread should attempt
  				 * to read from 
the console. */
***************
*** 516,522 ****
  	 */
  
  	Tcl_MutexLock(&consoleMutex);
! 	TerminateThread(consolePtr->writeThread, 0);
  
  	/*
  	 * Wait for the thread to terminate.  This ensures 
that we are
--- 519,525 ----
  	 */
  
  	Tcl_MutexLock(&consoleMutex);
! 	SetEvent(consolePtr->stopWriter);
  
  	/*
  	 * Wait for the thread to terminate.  This ensures 
that we are
***************
*** 1134,1149 ****
  {
  
      ConsoleInfo *infoPtr = (ConsoleInfo *)arg;
      HANDLE *handle = infoPtr->handle;
      DWORD count, toWrite;
      char *buf;
  
      for (;;) {
  	/*
  	 * Wait for the main thread to signal before 
attempting to write.
  	 */
  
! 	WaitForSingleObject(infoPtr->startWriter, 
INFINITE);
  
  	buf = infoPtr->writeBuf;
  	toWrite = infoPtr->toWrite;
--- 1137,1163 ----
  {
  
      ConsoleInfo *infoPtr = (ConsoleInfo *)arg;
+     HANDLE events[2];
      HANDLE *handle = infoPtr->handle;
      DWORD count, toWrite;
      char *buf;
  
+     events[0] = infoPtr->stopWriter;
+     events[1] = infoPtr->startWriter;
+ 
      for (;;) {
+ 	DWORD dwWait;
+ 
  	/*
  	 * Wait for the main thread to signal before 
attempting to write.
  	 */
  
! 	dwWait = WaitForMultipleObjects(events, 2, 
FALSE, INFINITE);
! 
! 	if (dwWait != (WAIT_OBJECT_0 + 1)) {
! 	    /* either the stop event or some other error, so 
exit */
! 	    return 0;
! 	}
  
  	buf = infoPtr->writeBuf;
  	toWrite = infoPtr->toWrite;
***************
*** 1251,1256 ****
--- 1265,1271 ----
      if (permissions & TCL_WRITABLE) {
  	infoPtr->writable = CreateEvent(NULL, TRUE, 
TRUE, NULL);
  	infoPtr->startWriter = CreateEvent(NULL, FALSE, 
FALSE, NULL);
+ 	infoPtr->stopWriter = CreateEvent(NULL, FALSE, 
FALSE, NULL);
  	infoPtr->writeThread = CreateThread(NULL, 8000, 
ConsoleWriterThread,
  	        infoPtr, 0, &id);
      }


----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-08-16 12:56

Message:
Logged In: YES 
user_id=72656

I'm finding it a bit hard to reproduce, and now not at all.  
Could people please try replacing their current tcl83.dll with 
the one at http://www.tcl.tk/tcl83.dll.  The sig on it is:
634880 Aug 16 10:53 tcl83.dll
(md5) b35628568ddc4afed4f675d2d9a50faf  tcl83.dll

I can't hang anymore with python 2.2.1 at the Win98 
command prompt with:
   python \Python22\Tools\idle\idle.pyw

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-08-16 11:50

Message:
Logged In: YES 
user_id=72656

johnny - That actually helps a lot and fairly clearly indicates 
the source of this hanging problem.  To give more context to 
that area, this is in the final shutdown code where it is 
(obviously) shutting down the console I/O.  The reader is 
shutdown without a check for more input (why, we are 
exiting?), so there is no issue there.

The writer however wants to make sure that the console 
output channel is drained before exit.  A blocking channel 
that is not being flushed will cause a hang.

So the question is, what is the stdio setup for Tcl in 
Py/Tkinter?  That should be examined to see whether stdio is 
clear to flush on exit.

Perhaps you can also help with more debugging.  Could you 
wrap the problematic WaitForSingleObject call with
if (consolePtr->toWrite) { ...
and perhaps also print out what to write.  It may be that 
blocking output isn't the problem at all, but rather that we are 
never receiving the signal on consolePtr->writable (usually 
done in the writer thread).  The consolePtr->toWrite check 
will at least ensure flushed channels do not enter this 
potential hanging state.

----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-08-16 08:16

Message:
Logged In: YES 
user_id=143340

I have dug out the setup I used previously and, apart from 
using Python 2.2 instead of 2.0.1, have had a go at 
reproducing my previous results.

With a debug build of Tcl/Tk and threads disabled I have 
managed to get this stack trace when it locks on exit (after 
doing a break):

ConsoleCloseProc(int * 0x006a0ae4, Tcl_Interp * 
0x00000000) line 527 + 17 bytes
TclFinalizeIOSubsystem() line 241 + 20 bytes
Tcl_FinalizeThread() line 911
Tcl_Finalize() line 812
DllMain(HINSTANCE__ * 0x00970000, unsigned long 
0x00000000, void * 0x00000001) line 197
TCL83! _DllMainCRTStartup@12 + 80 bytes
KERNEL32! bff7ddd6()
KERNEL32! bff8d123()
8176b5fc()

It is hanging up in ConsoleCloseProc() in 'tclWinConsole.c'
at about line 527:
WaitForSingleObject(consolePtr->writeThread, INFINITE);

I tried changing the timeout from INFINITE to 100ms and 
testing the return value for WAIT_TIMEOUT. Sure enough it 
occasionaly printed a message (and didn't lock-up).

Don't know if this helps. Will try to reproduce the double 
free problem in the threaded build later,

cheers,
John.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-15 08:19

Message:
Logged In: YES 
user_id=6380

Just a note so I won't forget this: Jeff Hobbs once said the
code to look at is

tk/generic/tkConsole.c:Tk_InitConsoleChannels

----------------------------------------------------------------------

Comment By: David Gravereaux (davygrvy)
Date: 2002-08-15 07:23

Message:
Logged In: YES 
user_id=7549

Hi John,

I have seen Tcl extension DLLs that set exit handlers get 
called by Tcl after they were torn-down.  NT and Win9x seem 
to be a bit different in the order of what DLLs get torn-down.  
here's a note from some old code of mine:

#ifdef __WIN32__
    // It can happen that the HEAP could have already been 
unloaded
    // from an awkward teardown caused by a Ctrl+C or other.  
Win32
    // seems to do a teardown in reverse order and by the time 
Tcl
    // knows what's going on and Tcl_Finalize calls the exit
    // handlers, this extension's data (heap?) has already been
    // unloaded by the OS.  Do a quick legal check on the 
pointer
    // first.
    //
    if (IsBadReadPtr(adapt, sizeof(T *))) return;
#endif

what's the back/stacktrace?  who is calling 
Tcl_FinalizeNotifier?  And had anyone called it before during 
the shutdown phase? I can't say with much confidence that 
this is happening here, too.  Maybe..  Could Tk be telling Tcl 
shutdown?  That's sort of backwards, if so.

I run w2k here, so I can't help in debugging from a test case.  
tclsh with a threaded build doesn't even call Tcl_Finalize to 
avoid all this!

----------------------------------------------------------------------

Comment By: Donal K. Fellows (dkf)
Date: 2002-08-15 07:09

Message:
Logged In: YES 
user_id=79902

Firstly, on the matter of threads.  Tcl/Tk on Windows uses
threads internally even in non-threaded builds.  That's
Windows for you (in particular, you can get calls parachuted
in from completely separate threads with relatively little
warning.  Also, you need threaded helpers to handle
non-blocking waiting on some kinds of objects.)

It's a bit hard to work out if the problem's been fixed
without a stack-trace (preferably with debugging symbols
enabled so that we can see what the function names and
arguments to those functions are.)  I have no  chance of
replicating this bug here (I'm currently running IRIX, but
also have some access to Solaris and Linux...)

----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-08-15 06:15

Message:
Logged In: YES 
user_id=143340

Hi to davygrvy,

my fix isn't for a thread related (deadlock) type problem - it 
is a fix for a double free type problem which is presumably 
screwing up the heap and causing the C runtime to hang.

It *is* with a threaded build (THREADDEFINES = -
DTCL_THREADS=1) which I think I enabled because I was 
using  'after' and it didn't work unless threading was 
enabled - but I may be mis-remembering here!

Also, I ended up doing all this with the debug build and 
found the -GZ flag useful - in fact it pointed out the fact that 
there was a problem with the heap.

It is worth noting that I have only seen this on Win98 and 
that using 'pythonw.exe' did *not* prevent this from 
happening,

regards John.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-14 19:00

Message:
Logged In: YES 
user_id=6380

AFAIK we never distributed a threaded build.

----------------------------------------------------------------------

Comment By: David Gravereaux (davygrvy)
Date: 2002-08-14 18:01

Message:
Logged In: YES 
user_id=7549

To johnnypops,

Where in Tcl_FinalizeNotifier() is the dead-lock occuring and 
is this with a threaded build of Tcl?


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-07-02 13:39

Message:
Logged In: YES 
user_id=31435

Jeff, a long time ago Fredrik Lundh said he was able to 
reproduce this with a short wish script (no Python, no Tkinter, 
just Tcl/Tk + wish).  I'm reassigning this to /F in the hopes 
he'll remember how.

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-07-02 12:55

Message:
Logged In: YES 
user_id=72656

I appreciate that many others see this is a problem in 
embedding Tcl, but without any clear way to reproduce this in 
Tcl/Tk itself, it's very hard for me to fix it.  I don't think that 
there is anything done in 8.4 to fix this that I recall, but if 
someone finds that the problem "goes away" with 8.4, please 
report that.

For those of course that experience this with python, the 
simple and "correct" work-around is to launch with 
pythonw.exe instead of python.exe.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-06-26 11:40

Message:
Logged In: NO 

According to http://tcl.activestate.com ActiveTcl 8.4.0 is now 
available for download.  It is new as of June 24.  I don't know 
whether this will solve our problems or not, but it's worth 
looking into.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-06-19 07:36

Message:
Logged In: NO 

I just downloaded Ruby 1.6.6 for Windows, which also uses 
Tcl/Tk 8.3 and I experience exactly the same problem there. 
So this is definitely a Tcl problem (but we know that already).

----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-06-07 13:01

Message:
Logged In: YES 
user_id=143340

Hmmm. 
I run a Python Tcl/Tk application several times every day - 
the very application that prompted my bug-hunt.

I do use "pythonw.exe" to launch it, but it used to hang 
almost as badly as "python.exe".

Whilst developing this app I used "python.exe" and 
experienced no hang-ups.

The Tcl guys point out that this bug is only one of several 
possible causes of the hang-up, maybe you are just out of 
luck.

The patch has fixed the problem on three Win98 machines, 
all of which exhibited the problem before updating the DLLs.

One thought - are you sure there weren't multiple copies of 
the tcl83.dll and tk83.dll files? My (only) copies were 
in "D:\python20\DLLs"

good luck,
John.


----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-06-03 12:55

Message:
Logged In: YES 
user_id=72656

providing Tim with a fixed DLL exactly according to John 
Popplewell's patch did not fix the problem for him.  That 
makes it seem fishy that John really didn't see the problem 
any more.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-03 10:59

Message:
Logged In: YES 
user_id=31435

I tried replacing Python 2.2.1's tk83.dll and tcl83.dll (from 
Tcl/Tk 8.3.2) with newer matched sets from

A) PythonWare's py21 distribution (Tcl/Tk 8.3.3).

and again from

B) ActiveState's Tcl/Tk 8.3.4.

All the symptoms originally reported here persisted on 
Win98SE despite that.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-05-22 07:57

Message:
Logged In: NO 

I am new to Python and encountered this bug on my very first 
Tkinter application.  It persists in Python 2.2.1 under 
Windows Me. Needless to say, it makes a bad first 
impression.  Basically, this thread says that Tkinter has been 
broken for a year and a half on a popular platform at a time 
when Python is trying to expand its user base.  Hopefully, this 
bug will be corrected soon.

If Tcl/Tk 8.4 is not released shortly you might try repackaging 
Tkinter for Win32 with an earlier version of Tcl/Tk, such as 
8.0, that doesn't encounter this problem.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 20:36

Message:
Logged In: YES 
user_id=6380

The proper action is to wait until Tcl 8.3.5 is released,
and then shaming someone else in providing you with a set of
Windowsbinaries for Tcl. You may also ask Hobbs if there's a
Windows project file to build Tcl/Tk for Windows.

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-03-11 19:31

Message:
Logged In: YES 
user_id=72656

I did end up back-porting this to the 8.3.4+ Tcl CVS on 
2002-02-25, which means it will be in an eventual 8.3.5.  
It is already in the release 8.4 alpha series.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-09 18:50

Message:
Logged In: YES 
user_id=31435

Back to Guido:  Do you think you know what the proper 
action is?  (You said that's why you reopened it, and 
there's been no new info here since then.)

----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-02-25 17:55

Message:
Logged In: YES 
user_id=143340

I knew I wasn't getting to the heart of it ....

Almost a one-liner!

It has been seriously spoiling my (otherwise crash free) 
Python experience on Win9x - hope it gets fixed soon.

cheers,
John.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-02-25 16:39

Message:
Logged In: YES 
user_id=6380

Reopened until we know what the proper action is.

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-02-25 16:32

Message:
Logged In: YES 
user_id=72656

This is mostly correct, and is fixed in the 8.4 Tcl sources 
already (I guess we can backport this).  This was mentioned 
in SF Tcl bug (account for chopped URL):

https://sourceforge.net/tracker/?
func=detail&aid=217982&group_id=10894&atid=110894

and the code comment is:

    /*
     * Only finalize the notifier if a notifier was 
installed in the
     * current thread; there is a route in which this is not
     * guaranteed to be true (when tclWin32Dll.c:DllMain() 
is called
     * with the flag DLL_PROCESS_DETACH by the OS, which 
could be
     * doing so from a thread that's never previously been 
involved
     * with Tcl, e.g. the task manager) so this check is 
important.
     *
     * Fixes Bug #217982 reported by Hugh Vu and Gene 
Leache.
     */
    if (tsdPtr == NULL) {
	return;
    }


----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-02-25 15:41

Message:
Logged In: YES 
user_id=143340

This one has been torturing me for a while.

Managed to track it down to a problem inside Tcl.
For the Tcl8.3.4 source distribution the problem is in
the file win/tclWinNotify.c 

void Tcl_FinalizeNotifier(ClientData clientData)
{
    ThreadSpecificData *tsdPtr = 
                         (ThreadSpecificData *) clientData;

    /* sometimes called with tsdPtr == NULL */
    if ( tsdPtr != NULL )
    {
        DeleteCriticalSection(&tsdPtr->crit);
        CloseHandle(tsdPtr->event);

        /*
         * Clean up the timer and messaging 
         * window for this thread.
         */

        if (tsdPtr->hwnd) {
	    KillTimer(tsdPtr->hwnd, INTERVAL_TIMER);
            DestroyWindow(tsdPtr->hwnd);
        }
    }

    /*
     * If this is the last thread to use the notifier, 
     * unregister the notifier window class.
     */

    Tcl_MutexLock(&notifierMutex);
    if ( notifierCount && !--notifierCount ) {
	UnregisterClassA( "TclNotifier", 
                          TclWinGetTclInstance());
    }
    Tcl_MutexUnlock(&notifierMutex);
}

This bodge doesn't address the underlying problem but has 
stopped me from tearing all my hair out,

cheers,
John Popplewell.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-10-24 16:27

Message:
Logged In: YES 
user_id=31435

FYI, you don't need an IDE to do this -- in Win9x, hit 
Ctrl+Alt+Del and kill the process directly.

A saner <wink> solution is to develop under Win2K, which 
doesn't appear to suffer this problem (the only reports 
I've seen, and experienced myself, came from Win9x boxes).

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-10-24 02:52

Message:
Logged In: NO 

For those who are still trapped in this bug's hell, I will 
gladly share the one thing that saved my sanity:  
WingIDE's 'Kill' command will shut down the program with 
apparent 100% certainty and no fear of lockups.  WingIDE 
has its own issues, so its not a perfect solution, but if 
you are like me and Joe (above) who test in small 
iterations, then using 'Kill' to quit out of your app while 
testing is a workaround that may preserve your sanity.

Perhaps the python gods and the Wing guys can get together 
and tell us how to replicate 'kill' into our code.  For 
now, I'll use WingIDE to edit, and pythonw.exe for my final 
client's delivery.

----------------------------------------------------------------------

Comment By: Howard Lightstone (hlightstone)
Date: 2001-09-05 11:43

Message:
Logged In: YES 
user_id=66570

I sometimes get bunches of these....

A tool I use (Taskinfo2000) reports that (after killing 
winoldap):

python.exe is blocked on a mutex named OLESCELOCKMUTEX.
The reported state is "Console Terminating".  There appears 
to be only one (os) thread running.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-04-02 14: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 22: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 19: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 13: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 10: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 08:40

Message:
Back to Tim since I have no clue what to do here.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-12 11: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 01: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: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=216289&group_id=5470


From noreply@sourceforge.net  Sat Aug 17 14:44:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Aug 2002 06:44:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-596422 ] build dumps core (binutils 2.13/solaris)
Message-ID: <E17g3sW-0006p6-00@usw-sf-web5.sourceforge.net>

Bugs item #596422, was opened at 2002-08-17 13:44
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=596422&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Koenig (arkoenig)
Assigned to: Nobody/Anonymous (nobody)
Summary: build dumps core (binutils 2.13/solaris)

Initial Comment:
Installing Python 2.2.1 on Solaris causes a core dump
during build (just after trying to load struct.so) if I
am using binutils 2.13.  This happens with either gcc
3.1.1 or gcc 3.2, on either solaris 7 or solaris 8.  I
suspect it happens on other combinations as well.

It works just fine with binutils 2.12.1, so the problem
appears to be in binutils, not Python per se.  The
attached file, contributed by Zack Weinberg
(zack@codesourcery.com), tests for the presence of the
problem; if it executes to completion, the problem
isn't there.

Perhaps it might make sense to put a similar test into
the Python installation procedure?



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=596422&group_id=5470


From noreply@sourceforge.net  Sat Aug 17 15:46:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Aug 2002 07:46:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-596434 ] textwrap has problems wrapping hyphens
Message-ID: <E17g4qW-0005UP-00@usw-sf-web2.sourceforge.net>

Bugs item #596434, was opened at 2002-08-17 10:46
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=596434&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: David Goodger (goodger)
Assigned to: Nobody/Anonymous (nobody)
Summary: textwrap has problems wrapping hyphens

Initial Comment:
(Greg already knows about this from private mail; 
this makes it "official".)

Long multi-word command-line options (begin 
with "--" and contain internal "-") inside text may be 
wrapped badly by textwrap.  For example, "--an-
option" may become "--\nan-option" or "--an-\
noption".  Perhaps words that begin with hyphens 
should not be wrapped at all?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=596434&group_id=5470


From noreply@sourceforge.net  Sat Aug 17 15:48:49 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Aug 2002 07:48:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-596434 ] textwrap has problems wrapping hyphens
Message-ID: <E17g4sj-0007uI-00@usw-sf-web5.sourceforge.net>

Bugs item #596434, was opened at 2002-08-17 10:46
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=596434&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: David Goodger (goodger)
>Assigned to: Greg Ward (gward)
Summary: textwrap has problems wrapping hyphens

Initial Comment:
(Greg already knows about this from private mail; 
this makes it "official".)

Long multi-word command-line options (begin 
with "--" and contain internal "-") inside text may be 
wrapped badly by textwrap.  For example, "--an-
option" may become "--\nan-option" or "--an-\
noption".  Perhaps words that begin with hyphens 
should not be wrapped at all?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=596434&group_id=5470


From noreply@sourceforge.net  Sat Aug 17 17:03:33 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Aug 2002 09:03:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-595919 ] popenN return only text mode pipes
Message-ID: <E17g633-0006jr-00@usw-sf-web2.sourceforge.net>

Bugs item #595919, was opened at 2002-08-16 05:25
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595919&group_id=5470

Category: Python Library
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Boyan Boyadjiev (bbboyadjiev)
>Assigned to: Martin v. Löwis (loewis)
Summary: popenN return only text mode pipes

Initial Comment:
The functions popen2, popen3 & popen 4 (module 
win32pipe) will return only text mode pipes even 
if the parameter mode is 'b'.

In the file win32popen.cpp on lines 363 
(popen2&popen4) and 398 (popen3) can be found 
the following code:
if (mode && _O_TEXT)
    {
      m1="r";
      m2="w";
    }
      else
    {
      m1="rb";
      m2="wb";
    }
The following change solves the problem :
if (mode & _O_TEXT)
    { ....



----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-17 12:03

Message:
Logged In: YES 
user_id=33168

win32popen.cpp is not in python.  The code you mention is in
posixmodule.c:3479 and 3511 in _PyPopen() for current cvs. 
Changing && -> & seems correct to me.  However, I don't
believe this can be tested on Unix.  

Martin, can you add anything?  Assign to me if you want me
to make the change.

----------------------------------------------------------------------

Comment By: Boyan Boyadjiev (bbboyadjiev)
Date: 2002-08-16 07:03

Message:
Logged In: YES 
user_id=595971

The same code (if (mode && _O_TEXT) ...) is used also in the function _PyPopen of the posix module 
(posixmodule.c).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595919&group_id=5470


From noreply@sourceforge.net  Sat Aug 17 17:08:22 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Aug 2002 09:08:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-585792 ] Invalid mmap crashes Python interpreter
Message-ID: <E17g67i-0006or-00@usw-sf-web2.sourceforge.net>

Bugs item #585792, was opened at 2002-07-24 04:52
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=585792&group_id=5470

Category: None
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: paul rubin (phr)
>Assigned to: Martin v. Löwis (loewis)
Summary: Invalid mmap crashes Python interpreter

Initial Comment:
This is under Red Hat 7.2, Linux kernel 2.4.7.   "x" is
an empty file, i.e. zero bytes long.

import mmap
f = open(x,"r+")m = mmap.mmap(f.fileno(), 10)
print m[1]

Crashes Python with a bus error.  Python should catch
the bus error signal
and raise an appropriate exception that the script can
catch.


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-17 12:08

Message:
Logged In: YES 
user_id=33168

Martin, would you like one last review and test on windows
before I check in?  Also, should this be backported to 2.2.?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-13 13:39

Message:
Logged In: YES 
user_id=33168

I can't test windows.  I've attached a patch which tries to
test windows doesn't raise an exception.
I also modified the NEWS to state this change affects
non-Windows platforms.

Tim/Martin, can you test (or at least review the test code)
that this works on Windows before I check it in?  Or let me
know if you want me to check it in.  It should be easy to
fix if it doesn't work on Windows.

Thanks.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-08-12 22:11

Message:
Logged In: NO 

I'd say the following is reasonable:

- on mmap object creation, stat the file and check its size
against the size arg passed to mmap.  Signal an error if the
file is smaller than the requested mmap size.  

- On access, compare the subscript to the mmap object size
and signal an error if out of bounds (presumably this is
done already)

- Figure out if another process can truncate the file while
the mmap is alive.  If yes, maybe add a method to the mmap
object that re-stats the file and makes sure it's still
larger than the mmap size.  

- Add warnings to the mmap documentation that weirdness can
result from the file size changing etc.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-12 12:31

Message:
Logged In: YES 
user_id=21627

I think we should special-case Windows, then. For the
mmapmodule patch proper, nothing needs to be done; for the
testsuite test, pass and fail are exactly reversed on
Windows (but then, we'd test the implementation of Windows,
so skipping that test sounds reasonable as well).

With those changes, the patch is fine.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-08-12 11:59

Message:
Logged In: YES 
user_id=31435

mmap() on WIndows doesn't care if you map more bytes 
than exist in the file -- if you do, it grows the file to match.

"""
If an application specifies a size for the file mapping object 
that is larger than the size of the actual named file on disk, 
the file on disk is grown to match the specified size of the 
file mapping object. If the file cannot be grown, this results 
in a failure to create the file mapping object. GetLastError 
will return ERROR_DISK_FULL.
"""

Like so:

>>> import mmap
>>> import os
>>> os.path.getsize('abc.abc')
12L
>>> f = file('abc.abc', 'r+')
>>> m = mmap.mmap(f.fileno(), 10000)
>>> m.close()
>>> os.path.getsize('abc.abc')
10000L
>>>


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-12 11:49

Message:
Logged In: YES 
user_id=33168

That last comment was supposed to be:  I don't know how
Windows behaves...

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-12 11:47

Message:
Logged In: YES 
user_id=33168

I thought the st_size was updated by the code in
new_buffersize.  It was only the position, so the comment
should go.  ValueError is fine with me.  Should I add an
entry to NEWS?  New patch attached w/NEWS and test.

There is another issue--Windows.  I how Windows behaves and
I can't test it.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-12 10:45

Message:
Logged In: YES 
user_id=21627

I'd say it is a ValueError if the map size is larger than
the file size, instead of silently decreasing the size:
Errors should never pass silently, Unless explicitly silenced.

On the trick of new_buffersize: I'm not sure I understand
what you are referring to: we don't use stdio in mmap at all.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-12 09:30

Message:
Logged In: YES 
user_id=33168

I wasn't sure if I could change the size.  For Solaris at
least, it seems this is the right thing to do.  Is it likely
that other systems allow the file size to change?  I've
forced the size to be the max(size_arg, size_of_file).  This
has the added benefit of working for writing too.  Prior to
this patch, writing past the end crashed on Linux.

There are 2 comments in the patch:  one worrying about the
file changing, the other producing a warning message if the
size argument is larger than the file.  Do we have to worry
about the size changing?  Should we tell the user what they did?

Sorry about the old style diff.  I remembered to do the cvs
-f diff part, but forgot the -C5.  My defaults are unified.
New context patch attached.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-08-12 03:45

Message:
Logged In: NO 

Please don't even think of adding a stat call to every
access.  The whole idea of mmap is to speed up access by
eliminating system calls when you touch the file contents. 
Checking the file size at map creation is reasonable.  Some
note should also be added to the mmap doc about possible
crashes if the file size changes.

>From a Python script writer's viewpoint, the most convenient
fix is for Python to catch the bus error signal and inspect
the stack to figure out that the trap occurred in the mmap
routine, then generate and return an appropriate Python
exception.  However, doing that is pretty
platform-dependent, and attempting it in all the Python
ports that support mmap doesn't sound practical.  

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-12 03:15

Message:
Logged In: YES 
user_id=21627

Ah, an old-style diff. I assume that goes into mmap_item?

I'd rather avoid the stat call on every access, and check
the size on map creation.

The Solaris man page says this about changing files:

     If the size of the mapped file changes  after  the 
call  to
     mmap()  as  a  result  of some other operation on the
mapped
     file, the effect of references to  portions  of  the 
mapped
     region  that  correspond to added or removed portions
of the
     file is unspecified.

So it appears that this is a case of "don"t do this, then",
and that it atleast won't crash - but we might want to
perform a few experiments.



----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-11 11:05

Message:
Logged In: YES 
user_id=33168

Martin, could you please review the patch?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-07-28 11:00

Message:
Logged In: YES 
user_id=33168

Attached is a patch which fixes this problem.  I'm not sure
this patch it correct nor appropriate.  But it stops the
crash.  I'm hoping some mmap expert can shed some light on this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=585792&group_id=5470


From noreply@sourceforge.net  Sat Aug 17 17:14:18 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Aug 2002 09:14:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-577530 ] del __builtins__ breaks out of rexec
Message-ID: <E17g6DS-0006uR-00@usw-sf-web2.sourceforge.net>

Bugs item #577530, was opened at 2002-07-04 15:01
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=577530&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1
Status: Open
Resolution: None
>Priority: 6
Submitted By: Eric Jacobs (ejums)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: del __builtins__ breaks out of rexec

Initial Comment:
Executing the statement "del __builtins__" in a
restricted execution environment (say, the test shell
in rexec.py) causes all restrictions to be bypassed.

This is caused by the fact that restriction policies
are implemented by having the "__builtins__" key in the
globals dictionary. It is a design error to implement
restriction policies with an object that can be
modified by the restricted code!

A temporary workaround would involve a modification to
rexec.py:

*** rexec.py	Sat Jun 22 22:57:46 2002
--- /home/eric/rexec.py	Tue Jul  2 16:08:03 2002
***************
*** 241,249 ****
      # Add a module -- return an existing module or
create one
  
      def add_module(self, mname):
!         if self.modules.has_key(mname):
!             return self.modules[mname]
!         self.modules[mname] = m =
self.hooks.new_module(mname)
          m.__builtins__ = self.modules['__builtin__']
          return m
  
--- 241,249 ----
      # Add a module -- return an existing module or
create one
  
      def add_module(self, mname):
!         if not self.modules.has_key(mname):
!             self.modules[mname] =
self.hooks.new_module(mname)
!         m = self.modules[mname]
          m.__builtins__ = self.modules['__builtin__']
          return m
  

However, the restriction execution feature is prone to
this sort of programming error by design, and it should
probably be fixed by having the builtins module be
specified explicitly when executing restricted code, so
that it doesn't accidentally fall back to the
unrestricted builtins inherited from the parent frame.


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-17 12:14

Message:
Logged In: YES 
user_id=33168

I have tested the patch attached and it seems to work.  I
don't know if the approach is a good solution.  Guido, if
you think this is acceptable, assign to me and I'll fix it.
 Since this is a security problem should it be backported to
2.1?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=577530&group_id=5470


From noreply@sourceforge.net  Sat Aug 17 17:41:47 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Aug 2002 09:41:47 -0700
Subject: [Python-bugs-list] [ python-Bugs-592527 ] comments taken as values in ConfigParser
Message-ID: <E17g6e3-0006bM-00@usw-sf-web4.sourceforge.net>

Bugs item #592527, was opened at 2002-08-08 05:11
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592527&group_id=5470

Category: Python Library
Group: 3rd Party
Status: Open
Resolution: None
Priority: 5
Submitted By: Art&#363;ras Kriukovas (drugelis)
Assigned to: Raymond Hettinger (rhettinger)
Summary: comments taken as values in ConfigParser

Initial Comment:
Let's say we have config file config.conf with contents:


[forms]
....
myParameter = myValue # my comment here :) 
# and my comment here
....

[other sections]
.......


We run python code:

    import sys, os
    from ConfigParser import *
    fileLocations = ['......./config.conf']
    parser = ConfigParser()
    parser.read(fileLocations)
    parser.sections()

and when we run:
    parser.get('forms', 'manoParameter')

we get:
    'myValue # my comment here :)'

The comment is also included as key value. The second
comment is left out as it should be.
The simpliest way to fix it probaby would be remove all
string after the first '#' char (that is to leave
string part to first '#' char).

----------------------------------------------------------------------

Comment By: Jonathan Simms (slyphon)
Date: 2002-08-17 11:41

Message:
Logged In: YES 
user_id=404786

Hello, 

In the documentation for the ConfigParser module, it 
says

"Lines *beginning* with "#" or ";" are ignored and may 
be used to provide comments. "

After reviewing the source for ConfigParser.py, as far 
as I can tell, the parser does NOT support end-of-line 
comments in config files.

Hope this helps, 
Jonathan

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592527&group_id=5470


From noreply@sourceforge.net  Sat Aug 17 18:09:13 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Aug 2002 10:09:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-585792 ] Invalid mmap crashes Python interpreter
Message-ID: <E17g74b-0007Bj-00@usw-sf-web1.sourceforge.net>

Bugs item #585792, was opened at 2002-07-24 10:52
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=585792&group_id=5470

Category: None
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Martin v. Löwis (loewis)
Summary: Invalid mmap crashes Python interpreter

Initial Comment:
This is under Red Hat 7.2, Linux kernel 2.4.7.   "x" is
an empty file, i.e. zero bytes long.

import mmap
f = open(x,"r+")m = mmap.mmap(f.fileno(), 10)
print m[1]

Crashes Python with a bus error.  Python should catch
the bus error signal
and raise an appropriate exception that the script can
catch.


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-08-17 19:09

Message:
Logged In: YES 
user_id=21627

I may be missing something: How precisely does this
special-case Windows in the test?

Apart from that, the patch is fine.

I'm uncertain on backporting it, because I'm uncertain how
backporting works at all since the PBF got instantiated. So
I'd suggest to mark this as a backport candidate, and let
the patch czar decide.



----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-17 18:08

Message:
Logged In: YES 
user_id=33168

Martin, would you like one last review and test on windows
before I check in?  Also, should this be backported to 2.2.?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-13 19:39

Message:
Logged In: YES 
user_id=33168

I can't test windows.  I've attached a patch which tries to
test windows doesn't raise an exception.
I also modified the NEWS to state this change affects
non-Windows platforms.

Tim/Martin, can you test (or at least review the test code)
that this works on Windows before I check it in?  Or let me
know if you want me to check it in.  It should be easy to
fix if it doesn't work on Windows.

Thanks.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-08-13 04:11

Message:
Logged In: NO 

I'd say the following is reasonable:

- on mmap object creation, stat the file and check its size
against the size arg passed to mmap.  Signal an error if the
file is smaller than the requested mmap size.  

- On access, compare the subscript to the mmap object size
and signal an error if out of bounds (presumably this is
done already)

- Figure out if another process can truncate the file while
the mmap is alive.  If yes, maybe add a method to the mmap
object that re-stats the file and makes sure it's still
larger than the mmap size.  

- Add warnings to the mmap documentation that weirdness can
result from the file size changing etc.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-12 18:31

Message:
Logged In: YES 
user_id=21627

I think we should special-case Windows, then. For the
mmapmodule patch proper, nothing needs to be done; for the
testsuite test, pass and fail are exactly reversed on
Windows (but then, we'd test the implementation of Windows,
so skipping that test sounds reasonable as well).

With those changes, the patch is fine.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-08-12 17:59

Message:
Logged In: YES 
user_id=31435

mmap() on WIndows doesn't care if you map more bytes 
than exist in the file -- if you do, it grows the file to match.

"""
If an application specifies a size for the file mapping object 
that is larger than the size of the actual named file on disk, 
the file on disk is grown to match the specified size of the 
file mapping object. If the file cannot be grown, this results 
in a failure to create the file mapping object. GetLastError 
will return ERROR_DISK_FULL.
"""

Like so:

>>> import mmap
>>> import os
>>> os.path.getsize('abc.abc')
12L
>>> f = file('abc.abc', 'r+')
>>> m = mmap.mmap(f.fileno(), 10000)
>>> m.close()
>>> os.path.getsize('abc.abc')
10000L
>>>


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-12 17:49

Message:
Logged In: YES 
user_id=33168

That last comment was supposed to be:  I don't know how
Windows behaves...

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-12 17:47

Message:
Logged In: YES 
user_id=33168

I thought the st_size was updated by the code in
new_buffersize.  It was only the position, so the comment
should go.  ValueError is fine with me.  Should I add an
entry to NEWS?  New patch attached w/NEWS and test.

There is another issue--Windows.  I how Windows behaves and
I can't test it.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-12 16:45

Message:
Logged In: YES 
user_id=21627

I'd say it is a ValueError if the map size is larger than
the file size, instead of silently decreasing the size:
Errors should never pass silently, Unless explicitly silenced.

On the trick of new_buffersize: I'm not sure I understand
what you are referring to: we don't use stdio in mmap at all.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-12 15:30

Message:
Logged In: YES 
user_id=33168

I wasn't sure if I could change the size.  For Solaris at
least, it seems this is the right thing to do.  Is it likely
that other systems allow the file size to change?  I've
forced the size to be the max(size_arg, size_of_file).  This
has the added benefit of working for writing too.  Prior to
this patch, writing past the end crashed on Linux.

There are 2 comments in the patch:  one worrying about the
file changing, the other producing a warning message if the
size argument is larger than the file.  Do we have to worry
about the size changing?  Should we tell the user what they did?

Sorry about the old style diff.  I remembered to do the cvs
-f diff part, but forgot the -C5.  My defaults are unified.
New context patch attached.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-08-12 09:45

Message:
Logged In: NO 

Please don't even think of adding a stat call to every
access.  The whole idea of mmap is to speed up access by
eliminating system calls when you touch the file contents. 
Checking the file size at map creation is reasonable.  Some
note should also be added to the mmap doc about possible
crashes if the file size changes.

>From a Python script writer's viewpoint, the most convenient
fix is for Python to catch the bus error signal and inspect
the stack to figure out that the trap occurred in the mmap
routine, then generate and return an appropriate Python
exception.  However, doing that is pretty
platform-dependent, and attempting it in all the Python
ports that support mmap doesn't sound practical.  

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-12 09:15

Message:
Logged In: YES 
user_id=21627

Ah, an old-style diff. I assume that goes into mmap_item?

I'd rather avoid the stat call on every access, and check
the size on map creation.

The Solaris man page says this about changing files:

     If the size of the mapped file changes  after  the 
call  to
     mmap()  as  a  result  of some other operation on the
mapped
     file, the effect of references to  portions  of  the 
mapped
     region  that  correspond to added or removed portions
of the
     file is unspecified.

So it appears that this is a case of "don"t do this, then",
and that it atleast won't crash - but we might want to
perform a few experiments.



----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-11 17:05

Message:
Logged In: YES 
user_id=33168

Martin, could you please review the patch?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-07-28 17:00

Message:
Logged In: YES 
user_id=33168

Attached is a patch which fixes this problem.  I'm not sure
this patch it correct nor appropriate.  But it stops the
crash.  I'm hoping some mmap expert can shed some light on this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=585792&group_id=5470


From noreply@sourceforge.net  Sat Aug 17 18:10:48 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Aug 2002 10:10:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-595919 ] popenN return only text mode pipes
Message-ID: <E17g768-00069o-00@usw-sf-web3.sourceforge.net>

Bugs item #595919, was opened at 2002-08-16 11:25
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595919&group_id=5470

Category: Python Library
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Boyan Boyadjiev (bbboyadjiev)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: popenN return only text mode pipes

Initial Comment:
The functions popen2, popen3 & popen 4 (module 
win32pipe) will return only text mode pipes even 
if the parameter mode is 'b'.

In the file win32popen.cpp on lines 363 
(popen2&popen4) and 398 (popen3) can be found 
the following code:
if (mode && _O_TEXT)
    {
      m1="r";
      m2="w";
    }
      else
    {
      m1="rb";
      m2="wb";
    }
The following change solves the problem :
if (mode & _O_TEXT)
    { ....



----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-08-17 19:10

Message:
Logged In: YES 
user_id=21627

That change looks fine; please implement it.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-17 18:03

Message:
Logged In: YES 
user_id=33168

win32popen.cpp is not in python.  The code you mention is in
posixmodule.c:3479 and 3511 in _PyPopen() for current cvs. 
Changing && -> & seems correct to me.  However, I don't
believe this can be tested on Unix.  

Martin, can you add anything?  Assign to me if you want me
to make the change.

----------------------------------------------------------------------

Comment By: Boyan Boyadjiev (bbboyadjiev)
Date: 2002-08-16 13:03

Message:
Logged In: YES 
user_id=595971

The same code (if (mode && _O_TEXT) ...) is used also in the function _PyPopen of the posix module 
(posixmodule.c).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595919&group_id=5470


From noreply@sourceforge.net  Sat Aug 17 18:11:28 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Aug 2002 10:11:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-585792 ] Invalid mmap crashes Python interpreter
Message-ID: <E17g76m-0006AS-00@usw-sf-web3.sourceforge.net>

Bugs item #585792, was opened at 2002-07-24 10:52
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=585792&group_id=5470

Category: None
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: paul rubin (phr)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: Invalid mmap crashes Python interpreter

Initial Comment:
This is under Red Hat 7.2, Linux kernel 2.4.7.   "x" is
an empty file, i.e. zero bytes long.

import mmap
f = open(x,"r+")m = mmap.mmap(f.fileno(), 10)
print m[1]

Crashes Python with a bus error.  Python should catch
the bus error signal
and raise an appropriate exception that the script can
catch.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-17 19:09

Message:
Logged In: YES 
user_id=21627

I may be missing something: How precisely does this
special-case Windows in the test?

Apart from that, the patch is fine.

I'm uncertain on backporting it, because I'm uncertain how
backporting works at all since the PBF got instantiated. So
I'd suggest to mark this as a backport candidate, and let
the patch czar decide.



----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-17 18:08

Message:
Logged In: YES 
user_id=33168

Martin, would you like one last review and test on windows
before I check in?  Also, should this be backported to 2.2.?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-13 19:39

Message:
Logged In: YES 
user_id=33168

I can't test windows.  I've attached a patch which tries to
test windows doesn't raise an exception.
I also modified the NEWS to state this change affects
non-Windows platforms.

Tim/Martin, can you test (or at least review the test code)
that this works on Windows before I check it in?  Or let me
know if you want me to check it in.  It should be easy to
fix if it doesn't work on Windows.

Thanks.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-08-13 04:11

Message:
Logged In: NO 

I'd say the following is reasonable:

- on mmap object creation, stat the file and check its size
against the size arg passed to mmap.  Signal an error if the
file is smaller than the requested mmap size.  

- On access, compare the subscript to the mmap object size
and signal an error if out of bounds (presumably this is
done already)

- Figure out if another process can truncate the file while
the mmap is alive.  If yes, maybe add a method to the mmap
object that re-stats the file and makes sure it's still
larger than the mmap size.  

- Add warnings to the mmap documentation that weirdness can
result from the file size changing etc.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-12 18:31

Message:
Logged In: YES 
user_id=21627

I think we should special-case Windows, then. For the
mmapmodule patch proper, nothing needs to be done; for the
testsuite test, pass and fail are exactly reversed on
Windows (but then, we'd test the implementation of Windows,
so skipping that test sounds reasonable as well).

With those changes, the patch is fine.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-08-12 17:59

Message:
Logged In: YES 
user_id=31435

mmap() on WIndows doesn't care if you map more bytes 
than exist in the file -- if you do, it grows the file to match.

"""
If an application specifies a size for the file mapping object 
that is larger than the size of the actual named file on disk, 
the file on disk is grown to match the specified size of the 
file mapping object. If the file cannot be grown, this results 
in a failure to create the file mapping object. GetLastError 
will return ERROR_DISK_FULL.
"""

Like so:

>>> import mmap
>>> import os
>>> os.path.getsize('abc.abc')
12L
>>> f = file('abc.abc', 'r+')
>>> m = mmap.mmap(f.fileno(), 10000)
>>> m.close()
>>> os.path.getsize('abc.abc')
10000L
>>>


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-12 17:49

Message:
Logged In: YES 
user_id=33168

That last comment was supposed to be:  I don't know how
Windows behaves...

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-12 17:47

Message:
Logged In: YES 
user_id=33168

I thought the st_size was updated by the code in
new_buffersize.  It was only the position, so the comment
should go.  ValueError is fine with me.  Should I add an
entry to NEWS?  New patch attached w/NEWS and test.

There is another issue--Windows.  I how Windows behaves and
I can't test it.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-12 16:45

Message:
Logged In: YES 
user_id=21627

I'd say it is a ValueError if the map size is larger than
the file size, instead of silently decreasing the size:
Errors should never pass silently, Unless explicitly silenced.

On the trick of new_buffersize: I'm not sure I understand
what you are referring to: we don't use stdio in mmap at all.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-12 15:30

Message:
Logged In: YES 
user_id=33168

I wasn't sure if I could change the size.  For Solaris at
least, it seems this is the right thing to do.  Is it likely
that other systems allow the file size to change?  I've
forced the size to be the max(size_arg, size_of_file).  This
has the added benefit of working for writing too.  Prior to
this patch, writing past the end crashed on Linux.

There are 2 comments in the patch:  one worrying about the
file changing, the other producing a warning message if the
size argument is larger than the file.  Do we have to worry
about the size changing?  Should we tell the user what they did?

Sorry about the old style diff.  I remembered to do the cvs
-f diff part, but forgot the -C5.  My defaults are unified.
New context patch attached.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-08-12 09:45

Message:
Logged In: NO 

Please don't even think of adding a stat call to every
access.  The whole idea of mmap is to speed up access by
eliminating system calls when you touch the file contents. 
Checking the file size at map creation is reasonable.  Some
note should also be added to the mmap doc about possible
crashes if the file size changes.

>From a Python script writer's viewpoint, the most convenient
fix is for Python to catch the bus error signal and inspect
the stack to figure out that the trap occurred in the mmap
routine, then generate and return an appropriate Python
exception.  However, doing that is pretty
platform-dependent, and attempting it in all the Python
ports that support mmap doesn't sound practical.  

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-12 09:15

Message:
Logged In: YES 
user_id=21627

Ah, an old-style diff. I assume that goes into mmap_item?

I'd rather avoid the stat call on every access, and check
the size on map creation.

The Solaris man page says this about changing files:

     If the size of the mapped file changes  after  the 
call  to
     mmap()  as  a  result  of some other operation on the
mapped
     file, the effect of references to  portions  of  the 
mapped
     region  that  correspond to added or removed portions
of the
     file is unspecified.

So it appears that this is a case of "don"t do this, then",
and that it atleast won't crash - but we might want to
perform a few experiments.



----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-11 17:05

Message:
Logged In: YES 
user_id=33168

Martin, could you please review the patch?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-07-28 17:00

Message:
Logged In: YES 
user_id=33168

Attached is a patch which fixes this problem.  I'm not sure
this patch it correct nor appropriate.  But it stops the
crash.  I'm hoping some mmap expert can shed some light on this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=585792&group_id=5470


From noreply@sourceforge.net  Sat Aug 17 21:01:57 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Aug 2002 13:01:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-577530 ] del __builtins__ breaks out of rexec
Message-ID: <E17g9ll-0000dm-00@usw-sf-web4.sourceforge.net>

Bugs item #577530, was opened at 2002-07-04 15:01
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=577530&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1
Status: Open
Resolution: None
>Priority: 4
Submitted By: Eric Jacobs (ejums)
Assigned to: Guido van Rossum (gvanrossum)
Summary: del __builtins__ breaks out of rexec

Initial Comment:
Executing the statement "del __builtins__" in a
restricted execution environment (say, the test shell
in rexec.py) causes all restrictions to be bypassed.

This is caused by the fact that restriction policies
are implemented by having the "__builtins__" key in the
globals dictionary. It is a design error to implement
restriction policies with an object that can be
modified by the restricted code!

A temporary workaround would involve a modification to
rexec.py:

*** rexec.py	Sat Jun 22 22:57:46 2002
--- /home/eric/rexec.py	Tue Jul  2 16:08:03 2002
***************
*** 241,249 ****
      # Add a module -- return an existing module or
create one
  
      def add_module(self, mname):
!         if self.modules.has_key(mname):
!             return self.modules[mname]
!         self.modules[mname] = m =
self.hooks.new_module(mname)
          m.__builtins__ = self.modules['__builtin__']
          return m
  
--- 241,249 ----
      # Add a module -- return an existing module or
create one
  
      def add_module(self, mname):
!         if not self.modules.has_key(mname):
!             self.modules[mname] =
self.hooks.new_module(mname)
!         m = self.modules[mname]
          m.__builtins__ = self.modules['__builtin__']
          return m
  

However, the restriction execution feature is prone to
this sort of programming error by design, and it should
probably be fixed by having the builtins module be
specified explicitly when executing restricted code, so
that it doesn't accidentally fall back to the
unrestricted builtins inherited from the parent frame.


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-17 16:01

Message:
Logged In: YES 
user_id=6380

I find it hard to believe that putting __builtins__ back
once per r_exec() call would be sufficient.

What if someone wrote "del __builtins__; import socket" ?

Backporting to 2.1 sounds like giving people a false sense
of security. If there's a message to be gotten out, it is
"don't trust rexec". This fix doesn't make me more confident
but less (even if applied).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-17 12:14

Message:
Logged In: YES 
user_id=33168

I have tested the patch attached and it seems to work.  I
don't know if the approach is a good solution.  Guido, if
you think this is acceptable, assign to me and I'll fix it.
 Since this is a security problem should it be backported to
2.1?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=577530&group_id=5470


From noreply@sourceforge.net  Sat Aug 17 22:45:58 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Aug 2002 14:45:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-596576 ] NetBSD 1.4.3, a.out, shared modules
Message-ID: <E17gBOQ-0003j3-00@usw-sf-web2.sourceforge.net>

Bugs item #596576, was opened at 2002-08-17 23:45
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=596576&group_id=5470

Category: Build
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Grzegorz Sobanski (lord-silk)
Assigned to: Nobody/Anonymous (nobody)
Summary: NetBSD 1.4.3, a.out, shared modules

Initial Comment:
Because of check in configure, it is using on a.out system ld to link shared 
modules on  a.out NetBSD. But it is run with both -Wl,-R and so it won't 
build any module ending in unusable installation. Had to modify  configure to 
get the package installed correctly.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=596576&group_id=5470


From noreply@sourceforge.net  Sun Aug 18 02:01:20 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Aug 2002 18:01:20 -0700
Subject: [Python-bugs-list] [ python-Bugs-595791 ] IDLE/Command Line Output Differ
Message-ID: <E17gERU-0004Ur-00@usw-sf-web3.sourceforge.net>

Bugs item #595791, was opened at 2002-08-15 19:01
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595791&group_id=5470

Category: IDLE
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: James Pomeroy (moody834)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: IDLE/Command Line Output Differ

Initial Comment:
Platform: OS X 10.1.5
XDarwin: 1.1 (XFree86 4.2)
IDLE: 0.8
Python: 2.2.1

Code (from Python Tutorial sec. 4.4) [I don't know if my 
indentation will be preserved here, but the code was indented per 
Python convention]:

>>> for n in range(2, 10):
...     for x in range(2, n):
...         if n % x == 0:
...            print n, 'equals', x, '*', n/x
...            break
...     else:
...          # loop fell through without finding a factor
...          print n, 'is a prime number'

Result in IDLE:

3 is a prime number
4 equals 2 * 2
5 is a prime number
5 is a prime number
5 is a prime number
6 equals 2 * 3
7 is a prime number
7 is a prime number
7 is a prime number
7 is a prime number
7 is a prime number
8 equals 2 * 4
9 is a prime number
9 equals 3 * 3

Result using (xterm) command line matched example given in 
Python Tutorial:

2 is a prime number
3 is a prime number
4 equals 2 * 2
5 is a prime number
6 equals 2 * 3
7 is a prime number
8 equals 2 * 4
9 equals 3 * 3

----------------------------------------------------------------------

Comment By: James Pomeroy (moody834)
Date: 2002-08-16 10:22

Message:
Logged In: YES 
user_id=448016

UPDATE:

This issue all appears if I use OS X's default terminal. Same output as 
with IDLE. So, only xterm produces the result expected.

----------------------------------------------------------------------

Comment By: Gregor Lingl (glingl)
Date: 2002-08-16 07:00

Message:
Logged In: YES 
user_id=505031

Apparently this is a bug in the INPUT to IDLE,
as the incorrect output is produced, if the else-part in 
the statement is incorrectly idented as part of the if-statement
instead as a part of the for-statement


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595791&group_id=5470


From noreply@sourceforge.net  Sun Aug 18 20:42:23 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Aug 2002 12:42:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-595791 ] IDLE/Command Line Output Differ
Message-ID: <E17gVwN-0003Ii-00@usw-sf-web5.sourceforge.net>

Bugs item #595791, was opened at 2002-08-15 19:01
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595791&group_id=5470

Category: IDLE
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: James Pomeroy (moody834)
Assigned to: Raymond Hettinger (rhettinger)
Summary: IDLE/Command Line Output Differ

Initial Comment:
Platform: OS X 10.1.5
XDarwin: 1.1 (XFree86 4.2)
IDLE: 0.8
Python: 2.2.1

Code (from Python Tutorial sec. 4.4) [I don't know if my 
indentation will be preserved here, but the code was indented per 
Python convention]:

>>> for n in range(2, 10):
...     for x in range(2, n):
...         if n % x == 0:
...            print n, 'equals', x, '*', n/x
...            break
...     else:
...          # loop fell through without finding a factor
...          print n, 'is a prime number'

Result in IDLE:

3 is a prime number
4 equals 2 * 2
5 is a prime number
5 is a prime number
5 is a prime number
6 equals 2 * 3
7 is a prime number
7 is a prime number
7 is a prime number
7 is a prime number
7 is a prime number
8 equals 2 * 4
9 is a prime number
9 equals 3 * 3

Result using (xterm) command line matched example given in 
Python Tutorial:

2 is a prime number
3 is a prime number
4 equals 2 * 2
5 is a prime number
6 equals 2 * 3
7 is a prime number
8 equals 2 * 4
9 equals 3 * 3

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-08-18 14:42

Message:
Logged In: YES 
user_id=80475

Hello James,

It looks like your bug report has an error in that it is 
not "indented per Python convention".  When it was hand 
typed into IDLE, the 'else' clause needed to be aligned with 
the outermost 'for' rather than the 'if' block.  That is an 
easy typo to make since IDLE automatically indents to 
most recent block and you have to hit backspace to move 
out a level.

Thank you for submitting the bug report.  If you find 
something else, please let us know.  In the meantime, I'll 
mark this one as invalid and close the report.

Raymond Hettinger

----------------------------------------------------------------------

Comment By: James Pomeroy (moody834)
Date: 2002-08-16 10:22

Message:
Logged In: YES 
user_id=448016

UPDATE:

This issue all appears if I use OS X's default terminal. Same output as 
with IDLE. So, only xterm produces the result expected.

----------------------------------------------------------------------

Comment By: Gregor Lingl (glingl)
Date: 2002-08-16 07:00

Message:
Logged In: YES 
user_id=505031

Apparently this is a bug in the INPUT to IDLE,
as the incorrect output is produced, if the else-part in 
the statement is incorrectly idented as part of the if-statement
instead as a part of the for-statement


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595791&group_id=5470


From noreply@sourceforge.net  Sun Aug 18 21:14:50 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Aug 2002 13:14:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-581529 ] bug in splituser(host) in urllib
Message-ID: <E17gWRm-0004m7-00@usw-sf-web3.sourceforge.net>

Bugs item #581529, was opened at 2002-07-14 23:36
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=581529&group_id=5470

Category: Python Library
Group: Python 2.2.1
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Chetan Sarva (csarva)
Assigned to: Jeremy Hylton (jhylton)
Summary: bug in splituser(host) in urllib

Initial Comment:
The splituser() method splits on the very first "@" it encounters 
which can lead to inaccurate results in certain cases (i.e. if the 
username portion contains an e-mail address). Splitting on the last 
"@" in the string will give the desired results every time.

 I'm 
not very good with regex's so I've given my simple solution as a 
sample below:

_userprog = None
def 
splituser(host):
    """splituser('user[:passwd]@host[:port]') --> 
'user[:passwd]', 'host[:port]'."""
    global _userprog
    if 
_userprog is None:
        x = host.rfind('@')
        if x != -1:
            return 
host[:x], host[x+1:]
        else:
            return None, host
            
        
#import re
        #_userprog = re.compile('^([^@]*)@(.*)$')

    
#match = _userprog.match(host)
    #if match: return 
map(unquote, match.group(1, 2))
    return None, host

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-08-18 15:14

Message:
Logged In: YES 
user_id=80475

Based on Jeremy's response, Jonathan Simms submitted 
patch 596581 which is I tested and then applied as 
urllib.py 1.150 and 1.135.6.4

Closing bug and related patch.

Thank you to Chetan for the bug report.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-08-13 10:42

Message:
Logged In: YES 
user_id=31392

The '@' in the userinfo is not legal according to RFC 2396.
 It must be escaped.

But I suppose other tools handle this without the escaping,
so we ought to also.  '@' isn't legal in the host part
either, but it's much less likely to occur there.



----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-11 10:30

Message:
Logged In: YES 
user_id=33168

Jeremy, how should this be fixed?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=581529&group_id=5470


From noreply@sourceforge.net  Sun Aug 18 21:19:14 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Aug 2002 13:19:14 -0700
Subject: [Python-bugs-list] [ python-Bugs-595791 ] IDLE/Command Line Output Differ
Message-ID: <E17gWW2-0001H2-00@usw-sf-web1.sourceforge.net>

Bugs item #595791, was opened at 2002-08-15 17:01
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595791&group_id=5470

Category: IDLE
Group: None
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: James Pomeroy (moody834)
Assigned to: Raymond Hettinger (rhettinger)
Summary: IDLE/Command Line Output Differ

Initial Comment:
Platform: OS X 10.1.5
XDarwin: 1.1 (XFree86 4.2)
IDLE: 0.8
Python: 2.2.1

Code (from Python Tutorial sec. 4.4) [I don't know if my 
indentation will be preserved here, but the code was indented per 
Python convention]:

>>> for n in range(2, 10):
...     for x in range(2, n):
...         if n % x == 0:
...            print n, 'equals', x, '*', n/x
...            break
...     else:
...          # loop fell through without finding a factor
...          print n, 'is a prime number'

Result in IDLE:

3 is a prime number
4 equals 2 * 2
5 is a prime number
5 is a prime number
5 is a prime number
6 equals 2 * 3
7 is a prime number
7 is a prime number
7 is a prime number
7 is a prime number
7 is a prime number
8 equals 2 * 4
9 is a prime number
9 equals 3 * 3

Result using (xterm) command line matched example given in 
Python Tutorial:

2 is a prime number
3 is a prime number
4 equals 2 * 2
5 is a prime number
6 equals 2 * 3
7 is a prime number
8 equals 2 * 4
9 equals 3 * 3

----------------------------------------------------------------------

>Comment By: James Pomeroy (moody834)
Date: 2002-08-18 13:19

Message:
Logged In: YES 
user_id=448016

Wow. Apparently I need a better prescription for my glasses. I I tried it 
again (mind you, when I submitted it the first time I had tried it a few 
times), and it worked perfectly.

Please accept my humble apologies. I don't know why I couldn't "see" 
that I was not copying the code exactly.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-08-18 12:42

Message:
Logged In: YES 
user_id=80475

Hello James,

It looks like your bug report has an error in that it is 
not "indented per Python convention".  When it was hand 
typed into IDLE, the 'else' clause needed to be aligned with 
the outermost 'for' rather than the 'if' block.  That is an 
easy typo to make since IDLE automatically indents to 
most recent block and you have to hit backspace to move 
out a level.

Thank you for submitting the bug report.  If you find 
something else, please let us know.  In the meantime, I'll 
mark this one as invalid and close the report.

Raymond Hettinger

----------------------------------------------------------------------

Comment By: James Pomeroy (moody834)
Date: 2002-08-16 08:22

Message:
Logged In: YES 
user_id=448016

UPDATE:

This issue all appears if I use OS X's default terminal. Same output as 
with IDLE. So, only xterm produces the result expected.

----------------------------------------------------------------------

Comment By: Gregor Lingl (glingl)
Date: 2002-08-16 05:00

Message:
Logged In: YES 
user_id=505031

Apparently this is a bug in the INPUT to IDLE,
as the incorrect output is produced, if the else-part in 
the statement is incorrectly idented as part of the if-statement
instead as a part of the for-statement


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595791&group_id=5470


From noreply@sourceforge.net  Sun Aug 18 21:31:21 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Aug 2002 13:31:21 -0700
Subject: [Python-bugs-list] [ python-Bugs-596866 ] cgi module: order of multiple values
Message-ID: <E17gWhl-0005Cb-00@usw-sf-web4.sourceforge.net>

Bugs item #596866, was opened at 2002-08-18 22:31
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=596866&group_id=5470

Category: Documentation
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Robert Siemer (siemer)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: cgi module: order of multiple values

Initial Comment:
The cgi module documentation is misleading in "Higher
Level Interface"
(http://python.org/doc/current/lib/node296.html).

The order of multiple values for the same name "may
vary from browser to browser and should not be counted
on". This should not be true.

It is instead true that the order is fixed for the mime
types application/x-www-form-urlencoded and
multipart/form-data (probably all types that the cgi
module is handling).

User agents should send these values in the order they
appear in the document as e.g. stated in the latest
HTML 4 recommendation on
http://www.w3.org/TR/html4/interact/forms.html#h-17.13.4

Bye,
	Robert

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=596866&group_id=5470


From noreply@sourceforge.net  Sun Aug 18 21:44:54 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Aug 2002 13:44:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-592527 ] comments taken as values in ConfigParser
Message-ID: <E17gWus-0005LK-00@usw-sf-web3.sourceforge.net>

Bugs item #592527, was opened at 2002-08-08 05:11
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592527&group_id=5470

Category: Python Library
Group: 3rd Party
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Art&#363;ras Kriukovas (drugelis)
Assigned to: Raymond Hettinger (rhettinger)
Summary: comments taken as values in ConfigParser

Initial Comment:
Let's say we have config file config.conf with contents:


[forms]
....
myParameter = myValue # my comment here :) 
# and my comment here
....

[other sections]
.......


We run python code:

    import sys, os
    from ConfigParser import *
    fileLocations = ['......./config.conf']
    parser = ConfigParser()
    parser.read(fileLocations)
    parser.sections()

and when we run:
    parser.get('forms', 'manoParameter')

we get:
    'myValue # my comment here :)'

The comment is also included as key value. The second
comment is left out as it should be.
The simpliest way to fix it probaby would be remove all
string after the first '#' char (that is to leave
string part to first '#' char).

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-08-18 15:44

Message:
Logged In: YES 
user_id=80475

Agreed, ConfigParser does match its documented 
behavior.  Exhancing the behavior to include mid-line 
comments would be problematic because some existing 
config files may already be using unescaped ; or # 
characters in the value field.

Marking bug as invalid and closing.

----------------------------------------------------------------------

Comment By: Jonathan Simms (slyphon)
Date: 2002-08-17 11:41

Message:
Logged In: YES 
user_id=404786

Hello, 

In the documentation for the ConfigParser module, it 
says

"Lines *beginning* with "#" or ";" are ignored and may 
be used to provide comments. "

After reviewing the source for ConfigParser.py, as far 
as I can tell, the parser does NOT support end-of-line 
comments in config files.

Hope this helps, 
Jonathan

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592527&group_id=5470


From noreply@sourceforge.net  Sun Aug 18 22:58:37 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Aug 2002 14:58:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-505562 ] Summary: "BuildApplet can destory the source file on Mac OS X"
Message-ID: <E17gY4D-00068W-00@usw-sf-web4.sourceforge.net>

Bugs item #505562, was opened at 2002-01-18 23:14
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=505562&group_id=5470

Category: Macintosh
Group: Python 2.1.1
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Russell Owen (reowen)
Assigned to: Jack Jansen (jackjansen)
>Summary: Summary: "BuildApplet can destory the source file on Mac OS X"

Initial Comment:
If the name of the file dropped on BuildApplet is the right length, BuildApplet will work and then will delete the source file!!! For instance dropping a file named "Cvt cmm -> Igor data 2-0 long name.py" onto BuildApple first produces a working droplet with name: "Cvt cmm -> Igor data 2#7F2E4" and then the source file simply vanishes. It's really gone, too (or perhaps moved and renamed) -- a disk search doesn't turn it up anywhere.

Making the file name significantly shorter causes everything to work normally. Making the file name significantly longer causes BuildApplet to exit immediately with no error message and nothing done. There seems to be a magic range of file name lengths that cause the source file to softly and silently vanish away.

Configuration:
- Mac OS X 10.1.2
- MacPython 2.1.1 configured for Carbon
- I have only one disk partition, formatted as Mac OS Extended, with tons of free space.

Further details available on request, but I hope the problem is easily reproducible. I tried it many times on my Mac and it always did the same thing.

I doubt the contents of the source file is relevant, but if it is, I do have a copy (with a shorter name!).

-- Russell

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2002-08-18 23:58

Message:
Logged In: YES 
user_id=45365

Not really fixed, but at least detected. BuildApplet (or actually the underlying buildtools module) now detects the situation and refuses to continue. The user is told to rename the file to something more safe.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-02-05 23:10

Message:
Logged In: YES 
user_id=45365

An Apple person on pythonmac-sig suggested this is indeed an Apple problem (and a serious one too, therefore). I've submitted it to the Apple bug reporter as ID 2854931.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-01-27 22:35

Message:
Logged In: YES 
user_id=45365

This turns out to be a very serious problem in the way OSX converts long filenames to FSSpecs. I'm taking the discussion to pythonmac-sig (for starters).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=505562&group_id=5470


From noreply@sourceforge.net  Sun Aug 18 23:19:48 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Aug 2002 15:19:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-588825 ] unittest.py, better error message
Message-ID: <E17gYOi-0003Wu-00@usw-sf-web1.sourceforge.net>

Bugs item #588825, was opened at 2002-07-30 17:29
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=588825&group_id=5470

Category: None
>Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Stefan Heimann (stefanheimann)
>Assigned to: Steve Purcell (purcell)
Summary: unittest.py, better error message

Initial Comment:
These two methods of the class TestCase are not very good:

    def failUnlessEqual(self, first, second, msg=None):
        """Fail if the two objects are unequal as
determined by the '!='
           operator.
        """
        if first != second:
            raise self.failureException, \
                  (msg or '%s != %s' % (`first`, `second`))

    def failIfEqual(self, first, second, msg=None):
        """Fail if the two objects are equal as
determined by the '=='
           operator.
        """
        if first == second:
            raise self.failureException, \
                  (msg or '%s == %s' % (`first`, `second`))

The first thing is that you should print the difference
of the given values like that:

'<%s> == <%s>' % (`first`, `second`)

The < and > delimits the string and so is is easier to
detect where the string starts and where it ends.

The second thing is that I would really like to see the
two values that are (not) equal even if I provide a
message. Maybe its better to raise the exception like that:

        if msg is not None:
            msg += ' Expected: <%s>, is: <%s>' %
(first, second)
        raise self.failureException, \
                  (msg or '%s != %s' % (`first`, `second`))

bye Stefan

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-08-18 17:19

Message:
Logged In: YES 
user_id=80475

Steve, would you like these implemented or left as is?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=588825&group_id=5470


From noreply@sourceforge.net  Sun Aug 18 23:50:45 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Aug 2002 15:50:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-583248 ] ConfigParser spaces in keys not read
Message-ID: <E17gYsf-0006so-00@usw-sf-web5.sourceforge.net>

Bugs item #583248, was opened at 2002-07-18 03:07
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=583248&group_id=5470

Category: Extension Modules
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin Thopmson (martinthompson)
>Assigned to: Jeremy Hylton (jhylton)
Summary: ConfigParser spaces in keys not read

Initial Comment:
ConfigParser will write, but not read keys with spaces in, eg
key with spaces in = 5
 raises a parse exception.

My fix, tested a small amount on one file!:  
Change regexp on Line 390 to
    OPTCRE = re.compile(
        r'(?P<option>[^=:]+?)'      # anything not an = or :, don;t grab the last space, leave for next bit
        r'[ \t]*(?P<vi>[:=])[ \t]*'           # any number of space/tab,
                                              # followed by separator
                                              # (either : or =), followed
                                              # by any # space/tab
        r'(?P<value>.*)$'                     # everything up to eol
        )




----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-08-18 17:50

Message:
Logged In: YES 
user_id=80475

Having spaces in the keys does not conflict with the 
documentation for ConfigParser; however, it is inconsistent 
with RFC 822 (which serves as a style guide):

"""The  field-name must be composed of printable ASCII 
characters  (i.e., characters that  have  values  between  
33.  and  126., decimal, except colon)."""

Still, there are valid use cases.  For instance, Windows 
style directory names are potentially useful as keys, yet 
the names allow internal spaces:

[DirectoryAttributes]
My Documents = Hide
My Pictures = Show

Jeremy, do you think multiword keys are the way to go?  If 
so, re-assign to me for implementation in Python 2.3.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=583248&group_id=5470


From noreply@sourceforge.net  Sun Aug 18 23:57:05 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Aug 2002 15:57:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-593154 ] Can't assign to __name__ or __bases__ of new class
Message-ID: <E17gYyn-00070X-00@usw-sf-web5.sourceforge.net>

Bugs item #593154, was opened at 2002-08-09 12:55
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=593154&group_id=5470

Category: Type/class unification
Group: Python 2.3
Status: Open
Resolution: None
Priority: 3
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Can't assign to __name__ or __bases__ of new class

Initial Comment:
While it's rarely useful, there *are* situations where
assigning to __name__ or __bases__ of a class might
make sense.  So maybe this should be allowed.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-08-18 17:57

Message:
Logged In: YES 
user_id=80475

Closing bug 591135 and merging it into this one.  Posting 
from Joost Jacob:

"""
In article: 
http://www.linuxjournal.com/article.php?sid=4540 
Chuck Esterbrook mentions an elegant technique 
called 'Mixin'. 

Assigning to __bases__ is useful if you want to add 
ancestors without changing the object's source code. 

It does not work with new-style classes because the 
.__bases__ attribute is now read-only. 
This is also mentioned on 
http://www.python.org/2.2.1/bugs.html 
at the bottom but I could not find a bug-report here at 
SF. 
"""

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-09 15:21

Message:
Logged In: YES 
user_id=6380

I should've mentioned that this is only a problem for
new-style classes. To see the difference, try "class
lcl(object):" instead of "class lcl:" in your example.

But perhaps you should consider using a metaclass if you
really want the class objects to have different names.

----------------------------------------------------------------------

Comment By: Gregory Smith (gregsmith)
Date: 2002-08-09 15:16

Message:
Logged In: YES 
user_id=292741

e.g.
def mkclass(cname,something):
    class lcl:
        def __init__(self):
       ... yada...
        def f(self, parm = something):
         ... yada ...

   ... yada...
    lcl.__name__ = cname
    return lcl


My understanding is that this function returns a different
class object (each cut from the same cloth, as it were)
each time it is called, but they all have the same name
by default.
If you are doing this (which is a cool thing to be able to do)
it certainly makes sense to give each class a different
name.  I just tried this,  however, and it seems to work.
__name__ got changed, and instances have the new name
in their default repr(). 



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=593154&group_id=5470


From noreply@sourceforge.net  Sun Aug 18 23:58:25 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Aug 2002 15:58:25 -0700
Subject: [Python-bugs-list] [ python-Bugs-591135 ] Mixin broken for new-style classes
Message-ID: <E17gZ05-0004CQ-00@usw-sf-web1.sourceforge.net>

Bugs item #591135, was opened at 2002-08-05 10:31
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=591135&group_id=5470

Category: None
Group: None
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Joost Jacob (jjacob)
Assigned to: Nobody/Anonymous (nobody)
Summary: Mixin broken for new-style classes

Initial Comment:

In article:
http://www.linuxjournal.com/article.php?sid=4540
Chuck Esterbrook mentions an elegant technique
called 'Mixin'.

Assigning to __bases__ is useful if you want to add
ancestors without changing the object's source code.

It does not work with new-style classes because the
 .__bases__ attribute is now read-only.
This is also mentioned on
http://www.python.org/2.2.1/bugs.html
at the bottom but I could not find a bug-report here at
SF.


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-08-18 17:58

Message:
Logged In: YES 
user_id=80475

Merged this bug report into SF bug 593154.
Closing this one so the discussion can all be in one place.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=591135&group_id=5470


From noreply@sourceforge.net  Mon Aug 19 01:03:35 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Aug 2002 17:03:35 -0700
Subject: [Python-bugs-list] [ python-Bugs-577513 ] ** in doc/current/lib/operator-map.html
Message-ID: <E17ga19-0007Tq-00@usw-sf-web4.sourceforge.net>

Bugs item #577513, was opened at 2002-07-04 13:12
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=577513&group_id=5470

>Category: Extension Modules
>Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jean-Bernard ADDOR (jbaddor)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: ** in doc/current/lib/operator-map.html

Initial Comment:
I would like to see the ** operator included in the
table at

http://www.python.org/doc/current/lib/operator-map.html

with an explanation why it has not been included in the
module operator.

Thank you,

	Jean-Bernard

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-08-18 19:03

Message:
Logged In: YES 
user_id=80475

Tim's right that __builtins__.pow() meets any need well 
enough.  It does raise the question of how operator.abs() 
made it in though it duplicates __builtins__.abs().

OTOH, the operator module does purport to have an 
equivalent for every operator and it would be nice to have 
a complete table.  In that spirit, an operator.c patch is 
attached.  If approved, I'll add the docs and unittests to 
Python 2.3 (don't think it belongs in 2.2).

GvR, please bless or curse this one so we can close it.

----------------------------------------------------------------------

Comment By: Jean-Bernard ADDOR (jbaddor)
Date: 2002-07-17 08:45

Message:
Logged In: YES 
user_id=573194

1. I propose it to be included in the table with a note, for
completness.

2. It has to be imported from math or Numeric or MA
(MaskedArray) with different behaviour in each case. As a
consequence it results better for me
to avoid the import from a specific package and use the
operator wich gives always what we expect, even with
argument of different types an operator wich could hide
these differences would be useful at least for me.

>>> math.pow(3,4)
81.0

>>> Numeric.power(Numeric.arange(5),2)
array([ 0,  1,  4,  9, 16])

>>> math.pow(Numeric.arange(5),2)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: only rank-0 arrays can be converted to Python
scalars.

>>> Numeric.arange(5)**2
array([ 0,  1,  4,  9, 16])

>>> 3**4
81

Python 2.0 (#9, Feb  2 2001, 12:17:02) 
[GCC 2.95.2 19991024 (release)] on linux2
>>> print Numeric.__version__ 
17.2.0



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-07-16 21:45

Message:
Logged In: YES 
user_id=31435

x**y is the same as pow(x, y).  pow() is a builtin function.  
There's no need to duplicate it in the operator module.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=577513&group_id=5470


From noreply@sourceforge.net  Mon Aug 19 01:44:57 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Aug 2002 17:44:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-595919 ] popenN return only text mode pipes
Message-ID: <E17gafB-0005ql-00@usw-sf-web1.sourceforge.net>

Bugs item #595919, was opened at 2002-08-16 05:25
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595919&group_id=5470

Category: Python Library
Group: Python 2.1.1
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Boyan Boyadjiev (bbboyadjiev)
>Assigned to: Tim Peters (tim_one)
Summary: popenN return only text mode pipes

Initial Comment:
The functions popen2, popen3 & popen 4 (module 
win32pipe) will return only text mode pipes even 
if the parameter mode is 'b'.

In the file win32popen.cpp on lines 363 
(popen2&popen4) and 398 (popen3) can be found 
the following code:
if (mode && _O_TEXT)
    {
      m1="r";
      m2="w";
    }
      else
    {
      m1="rb";
      m2="wb";
    }
The following change solves the problem :
if (mode & _O_TEXT)
    { ....



----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-08-18 20:44

Message:
Logged In: YES 
user_id=31435

I made the obvious changes here and checked them in, to 
the head and in the 2.2 maintenance branch.  Thanks for 
the report!  Neal, of course you're right that you couldn't 
test it on Windows.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-17 13:10

Message:
Logged In: YES 
user_id=21627

That change looks fine; please implement it.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-17 12:03

Message:
Logged In: YES 
user_id=33168

win32popen.cpp is not in python.  The code you mention is in
posixmodule.c:3479 and 3511 in _PyPopen() for current cvs. 
Changing && -> & seems correct to me.  However, I don't
believe this can be tested on Unix.  

Martin, can you add anything?  Assign to me if you want me
to make the change.

----------------------------------------------------------------------

Comment By: Boyan Boyadjiev (bbboyadjiev)
Date: 2002-08-16 07:03

Message:
Logged In: YES 
user_id=595971

The same code (if (mode && _O_TEXT) ...) is used also in the function _PyPopen of the posix module 
(posixmodule.c).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595919&group_id=5470


From noreply@sourceforge.net  Mon Aug 19 02:01:48 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Aug 2002 18:01:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-577513 ] ** in doc/current/lib/operator-map.html
Message-ID: <E17gavU-00068b-00@usw-sf-web1.sourceforge.net>

Bugs item #577513, was opened at 2002-07-04 14:12
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=577513&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Jean-Bernard ADDOR (jbaddor)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: ** in doc/current/lib/operator-map.html

Initial Comment:
I would like to see the ** operator included in the
table at

http://www.python.org/doc/current/lib/operator-map.html

with an explanation why it has not been included in the
module operator.

Thank you,

	Jean-Bernard

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-18 21:01

Message:
Logged In: YES 
user_id=6380

"Bless".

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-08-18 20:03

Message:
Logged In: YES 
user_id=80475

Tim's right that __builtins__.pow() meets any need well 
enough.  It does raise the question of how operator.abs() 
made it in though it duplicates __builtins__.abs().

OTOH, the operator module does purport to have an 
equivalent for every operator and it would be nice to have 
a complete table.  In that spirit, an operator.c patch is 
attached.  If approved, I'll add the docs and unittests to 
Python 2.3 (don't think it belongs in 2.2).

GvR, please bless or curse this one so we can close it.

----------------------------------------------------------------------

Comment By: Jean-Bernard ADDOR (jbaddor)
Date: 2002-07-17 09:45

Message:
Logged In: YES 
user_id=573194

1. I propose it to be included in the table with a note, for
completness.

2. It has to be imported from math or Numeric or MA
(MaskedArray) with different behaviour in each case. As a
consequence it results better for me
to avoid the import from a specific package and use the
operator wich gives always what we expect, even with
argument of different types an operator wich could hide
these differences would be useful at least for me.

>>> math.pow(3,4)
81.0

>>> Numeric.power(Numeric.arange(5),2)
array([ 0,  1,  4,  9, 16])

>>> math.pow(Numeric.arange(5),2)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: only rank-0 arrays can be converted to Python
scalars.

>>> Numeric.arange(5)**2
array([ 0,  1,  4,  9, 16])

>>> 3**4
81

Python 2.0 (#9, Feb  2 2001, 12:17:02) 
[GCC 2.95.2 19991024 (release)] on linux2
>>> print Numeric.__version__ 
17.2.0



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-07-16 22:45

Message:
Logged In: YES 
user_id=31435

x**y is the same as pow(x, y).  pow() is a builtin function.  
There's no need to duplicate it in the operator module.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=577513&group_id=5470


From noreply@sourceforge.net  Mon Aug 19 04:20:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Aug 2002 20:20:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-577513 ] ** in doc/current/lib/operator-map.html
Message-ID: <E17gd5y-0001n4-00@usw-sf-web4.sourceforge.net>

Bugs item #577513, was opened at 2002-07-04 13:12
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=577513&group_id=5470

Category: Extension Modules
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jean-Bernard ADDOR (jbaddor)
Assigned to: Raymond Hettinger (rhettinger)
Summary: ** in doc/current/lib/operator-map.html

Initial Comment:
I would like to see the ** operator included in the
table at

http://www.python.org/doc/current/lib/operator-map.html

with an explanation why it has not been included in the
module operator.

Thank you,

	Jean-Bernard

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-08-18 22:20

Message:
Logged In: YES 
user_id=80475

Jean-Bernard, thank you for the submission. 

Committed as:
operator.c 2.24
liboperator.tex 1.22
test_operator.py 1.10

Closing bug.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-18 20:01

Message:
Logged In: YES 
user_id=6380

"Bless".

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-08-18 19:03

Message:
Logged In: YES 
user_id=80475

Tim's right that __builtins__.pow() meets any need well 
enough.  It does raise the question of how operator.abs() 
made it in though it duplicates __builtins__.abs().

OTOH, the operator module does purport to have an 
equivalent for every operator and it would be nice to have 
a complete table.  In that spirit, an operator.c patch is 
attached.  If approved, I'll add the docs and unittests to 
Python 2.3 (don't think it belongs in 2.2).

GvR, please bless or curse this one so we can close it.

----------------------------------------------------------------------

Comment By: Jean-Bernard ADDOR (jbaddor)
Date: 2002-07-17 08:45

Message:
Logged In: YES 
user_id=573194

1. I propose it to be included in the table with a note, for
completness.

2. It has to be imported from math or Numeric or MA
(MaskedArray) with different behaviour in each case. As a
consequence it results better for me
to avoid the import from a specific package and use the
operator wich gives always what we expect, even with
argument of different types an operator wich could hide
these differences would be useful at least for me.

>>> math.pow(3,4)
81.0

>>> Numeric.power(Numeric.arange(5),2)
array([ 0,  1,  4,  9, 16])

>>> math.pow(Numeric.arange(5),2)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: only rank-0 arrays can be converted to Python
scalars.

>>> Numeric.arange(5)**2
array([ 0,  1,  4,  9, 16])

>>> 3**4
81

Python 2.0 (#9, Feb  2 2001, 12:17:02) 
[GCC 2.95.2 19991024 (release)] on linux2
>>> print Numeric.__version__ 
17.2.0



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-07-16 21:45

Message:
Logged In: YES 
user_id=31435

x**y is the same as pow(x, y).  pow() is a builtin function.  
There's no need to duplicate it in the operator module.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=577513&group_id=5470


From noreply@sourceforge.net  Mon Aug 19 05:39:10 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Aug 2002 21:39:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-552345 ] rfc822.parsedate() too strict
Message-ID: <E17geJq-0001Ah-00@usw-sf-web1.sourceforge.net>

Bugs item #552345, was opened at 2002-05-04 15:53
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=552345&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Barry A. Warsaw (bwarsaw)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: rfc822.parsedate() too strict

Initial Comment:
rfc822.parsedate('Wed,3 Apr 2002 14:58:26 +0800')
returns None.  Note the lack of space between the
command and the 3.  That space is actually optional in
RFC 2822, so it should parse the same as 
parsedate('Wed, 3 Apr 2002 14:58:26 +0800')


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-08-18 23:39

Message:
Logged In: YES 
user_id=80475

Added a patch and unittest which fix the reported 
problem.  Tried to adopt a style of accurate 
implementation that can be extended when we get a 
chance.  The style is to use regular expressions which 
relate directly back to the rfc2822 specification.

If approved, re-assign back to me for a commit to Py2.3.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=552345&group_id=5470


From noreply@sourceforge.net  Mon Aug 19 12:29:29 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Aug 2002 04:29:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-595217 ] asynchat problems multi-threaded
Message-ID: <E17gkiv-0002zg-00@usw-sf-web1.sourceforge.net>

Bugs item #595217, was opened at 2002-08-14 15:34
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595217&group_id=5470

Category: Python Library
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Dieter Maurer (dmaurer)
>Assigned to: A.M. Kuchling (akuchling)
Summary: asynchat problems multi-threaded

Initial Comment:
asynchat.async_chat.push has two problems when
used in an application where the pusher and the
main loop are run by different threads.

1.  A "push" does not wake up the main loop. This may 
result in long delays (the loop, by default, uses a timeout 
of 30 s). The work around is an explicit wakeup on the 
loop. I do not have a solution for Windows (more 
generally an OS where select does not work for pipes).
When select does work for pipes, a simple "wakeup"
can be implemented by writing to a pipe the main loop
is waiting for.

2. The "self.initiate_send" can lead to two identical
sends (which should be only one!) under the condition
above. Workaround is to remove the call. 


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595217&group_id=5470


From noreply@sourceforge.net  Mon Aug 19 15:27:14 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Aug 2002 07:27:14 -0700
Subject: [Python-bugs-list] [ python-Bugs-597177 ] Tiny tiny doc bug in regexp lib
Message-ID: <E17gnUw-0005gY-00@usw-sf-web4.sourceforge.net>

Bugs item #597177, was opened at 2002-08-19 14:27
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=597177&group_id=5470

Category: Documentation
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Koenig (arkoenig)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Tiny tiny doc bug in regexp lib

Initial Comment:
Section 4.2.4, in the description of "match", says:

The optional parameter endpos limits how far the string
will be searched; it will be as if the string is endpos
characters long, so only the characters from pos to
endpos will be searched for a match.

Shouldn't it be "as if the string is endpos-pos
characters long"?  Also, shouldn't it be "the
characters in the range [pos:endpos]" to avoid the
potential ambiguity (i.e. making it clearer that the
range does not include the character at index endpos)?

Finally, what happens if pos > endpos?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=597177&group_id=5470


From noreply@sourceforge.net  Mon Aug 19 15:45:48 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Aug 2002 07:45:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-595105 ] AESend on Jaguar
Message-ID: <E17gnmu-0007zT-00@usw-sf-web1.sourceforge.net>

Bugs item #595105, was opened at 2002-08-14 18:02
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595105&group_id=5470

Category: Macintosh
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexandre Parenteau (aubonbeurre)
Assigned to: Jack Jansen (jackjansen)
Summary: AESend on Jaguar

Initial Comment:
I wonder how many of you guys played with Jaguar 
(OSX 10.2). It is also my
first glance at gcc 3.1 that comes with 10.2. Everything 
was fine for
building Python, except for waste which has an 
obsolete libWaste.a (even in
August 1st Waste 2.1b1) which won't compile with 
gcc3.1. After I recompiled
waste with CodeWarrior 8.2 (MPTP: early access), it 
came OK.

I then run into some problems of checked out files 
because I'm using MacCvs
(see earlier message). I used the 'make 
frameworkinstall' scheme.

Now I'm experiencing the nice new architecture. I 
mostly use python from the
command line to invoke CodeWarrior thru AppleScripts, 
so I almost immeditly
run into a hanging problems of python :

        _err = AESend(&_self->ob_itself,
                      &reply,
                      sendMode,
                      sendPriority,
                      timeOutInTicks,
                      0L/*upp_AEIdleProc*/,
                      (AEFilterUPP)0);

I had to comment out upp_AEIdleProc (I tried several 
things, but that is the
only thing which helped). Jack, you might want to 
remember this one if the
problem is still in Jaguar. It hangs and finally times out. 
I've looked
inside this function and I can see the signal handling, 
but I'm not sure
what it is for.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2002-08-19 16:45

Message:
Logged In: YES 
user_id=45365

Alexandre,
I tried a few simple things with the AE module (talking to CodeWarrior) 
on Jaguar, but I can't get it to hang.

Could you give me an example script that shows the problem?

Also: I've been using MachoPython from the CVS HEAD, I assume 
you're using the same, right?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595105&group_id=5470


From noreply@sourceforge.net  Mon Aug 19 19:04:17 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Aug 2002 11:04:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-595537 ] pythonw has a console on Win98
Message-ID: <E17gqsz-0002vR-00@usw-sf-web5.sourceforge.net>

Bugs item #595537, was opened at 2002-08-15 14:34
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595537&group_id=5470

Category: Windows
Group: Python 2.2.1
Status: Open
Resolution: Works For Me
Priority: 5
Submitted By: Paul Spencer (pgs)
Assigned to: Tim Peters (tim_one)
Summary: pythonw has a console on Win98

Initial Comment:
executing a script with pythonw (2.2.1) on win98
results in a console window being visible.  I reverted
my application to Python 2.1.1 and it works fine. 

pythonw works okay on WinXP with 2.2.1 though.

----------------------------------------------------------------------

>Comment By: Paul Spencer (pgs)
Date: 2002-08-19 18:04

Message:
Logged In: YES 
user_id=52126

This works as you suggest.  I have actually managed to get
this problem with 2.1.1 as well now.  I think that the
problem is with GTK when a g_message or g_warning is issued,
it causes the console to open.  The console doesn't actually
appear right away, only when it gets to the g_message or
g_warning.  Any output that would have appeared before that
is missing, but any output after it does appear ( I think). 

I'm using pygtk0.6.6 to write a GTK-based python app, but
there's lots of C code too.

I will look in glib and see if I can find out what it might
be trying to do ... the unfortunate side effect of this is
that I doubt I can get you a short example unless you are
set up with pygtk.  I could provide binaries though ... 

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-08-15 23:18

Message:
Logged In: YES 
user_id=31435

Please give a specific, short example.  For example, if I 
double-click on this file from Explorer under Win98, using 
2.2.1, it plays the sound but no console window opens:

C:\Python22>type example.pyw
import winsound
winsound.Beep(3000, 1000)

C:\Python22>

What happens when you try that?  If a console window does 
pop up, check the your .pyw file assocation -- you may have 
damaged it.  .pyw (Python File (no console))'s Open action 
should be associated to

C:\PYTHON22\pythonw.exe "%1" %*

or to wherever you installed Python 2.2.1.

    



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595537&group_id=5470


From noreply@sourceforge.net  Mon Aug 19 19:13:39 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Aug 2002 11:13:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-595537 ] pythonw has a console on Win98
Message-ID: <E17gr23-0004Cb-00@usw-sf-web1.sourceforge.net>

Bugs item #595537, was opened at 2002-08-15 14:34
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595537&group_id=5470

Category: Windows
Group: Python 2.2.1
Status: Open
Resolution: Works For Me
Priority: 5
Submitted By: Paul Spencer (pgs)
Assigned to: Tim Peters (tim_one)
Summary: pythonw has a console on Win98

Initial Comment:
executing a script with pythonw (2.2.1) on win98
results in a console window being visible.  I reverted
my application to Python 2.1.1 and it works fine. 

pythonw works okay on WinXP with 2.2.1 though.

----------------------------------------------------------------------

>Comment By: Paul Spencer (pgs)
Date: 2002-08-19 18:13

Message:
Logged In: YES 
user_id=52126

it appears that glib forces a console window open under
windows, although I am not sure why this doesn't happen on
WinXP.

I am assuming you will mark as invalid?

----------------------------------------------------------------------

Comment By: Paul Spencer (pgs)
Date: 2002-08-19 18:04

Message:
Logged In: YES 
user_id=52126

This works as you suggest.  I have actually managed to get
this problem with 2.1.1 as well now.  I think that the
problem is with GTK when a g_message or g_warning is issued,
it causes the console to open.  The console doesn't actually
appear right away, only when it gets to the g_message or
g_warning.  Any output that would have appeared before that
is missing, but any output after it does appear ( I think). 

I'm using pygtk0.6.6 to write a GTK-based python app, but
there's lots of C code too.

I will look in glib and see if I can find out what it might
be trying to do ... the unfortunate side effect of this is
that I doubt I can get you a short example unless you are
set up with pygtk.  I could provide binaries though ... 

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-08-15 23:18

Message:
Logged In: YES 
user_id=31435

Please give a specific, short example.  For example, if I 
double-click on this file from Explorer under Win98, using 
2.2.1, it plays the sound but no console window opens:

C:\Python22>type example.pyw
import winsound
winsound.Beep(3000, 1000)

C:\Python22>

What happens when you try that?  If a console window does 
pop up, check the your .pyw file assocation -- you may have 
damaged it.  .pyw (Python File (no console))'s Open action 
should be associated to

C:\PYTHON22\pythonw.exe "%1" %*

or to wherever you installed Python 2.2.1.

    



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595537&group_id=5470


From noreply@sourceforge.net  Mon Aug 19 19:20:56 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Aug 2002 11:20:56 -0700
Subject: [Python-bugs-list] [ python-Bugs-595537 ] pythonw has a console on Win98
Message-ID: <E17gr96-0003H8-00@usw-sf-web5.sourceforge.net>

Bugs item #595537, was opened at 2002-08-15 10:34
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595537&group_id=5470

Category: Windows
Group: Python 2.2.1
Status: Open
Resolution: Works For Me
Priority: 5
Submitted By: Paul Spencer (pgs)
Assigned to: Tim Peters (tim_one)
Summary: pythonw has a console on Win98

Initial Comment:
executing a script with pythonw (2.2.1) on win98
results in a console window being visible.  I reverted
my application to Python 2.1.1 and it works fine. 

pythonw works okay on WinXP with 2.2.1 though.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-08-19 14:20

Message:
Logged In: YES 
user_id=31435

Thanks for the followup!  Unless you can dream up a reason 
for believing this is a bug in the Python core, I'm going to 
close this as 3rdParty.  pythonw doesn't open a console, 
but it can't prevent other code from opening consoles.  If 
pygtk or GTK are opening console windows, and that's 
inappropriate, you'll have to file a report with their 
developers (pygtk and GTK aren't part of the Python core, 
so their maintainers won't even see a report *here*).

----------------------------------------------------------------------

Comment By: Paul Spencer (pgs)
Date: 2002-08-19 14:13

Message:
Logged In: YES 
user_id=52126

it appears that glib forces a console window open under
windows, although I am not sure why this doesn't happen on
WinXP.

I am assuming you will mark as invalid?

----------------------------------------------------------------------

Comment By: Paul Spencer (pgs)
Date: 2002-08-19 14:04

Message:
Logged In: YES 
user_id=52126

This works as you suggest.  I have actually managed to get
this problem with 2.1.1 as well now.  I think that the
problem is with GTK when a g_message or g_warning is issued,
it causes the console to open.  The console doesn't actually
appear right away, only when it gets to the g_message or
g_warning.  Any output that would have appeared before that
is missing, but any output after it does appear ( I think). 

I'm using pygtk0.6.6 to write a GTK-based python app, but
there's lots of C code too.

I will look in glib and see if I can find out what it might
be trying to do ... the unfortunate side effect of this is
that I doubt I can get you a short example unless you are
set up with pygtk.  I could provide binaries though ... 

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-08-15 19:18

Message:
Logged In: YES 
user_id=31435

Please give a specific, short example.  For example, if I 
double-click on this file from Explorer under Win98, using 
2.2.1, it plays the sound but no console window opens:

C:\Python22>type example.pyw
import winsound
winsound.Beep(3000, 1000)

C:\Python22>

What happens when you try that?  If a console window does 
pop up, check the your .pyw file assocation -- you may have 
damaged it.  .pyw (Python File (no console))'s Open action 
should be associated to

C:\PYTHON22\pythonw.exe "%1" %*

or to wherever you installed Python 2.2.1.

    



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595537&group_id=5470


From noreply@sourceforge.net  Mon Aug 19 19:26:45 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Aug 2002 11:26:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-595537 ] pythonw has a console on Win98
Message-ID: <E17grEj-0004aJ-00@usw-sf-web1.sourceforge.net>

Bugs item #595537, was opened at 2002-08-15 10:34
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595537&group_id=5470

Category: Windows
>Group: 3rd Party
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Paul Spencer (pgs)
Assigned to: Tim Peters (tim_one)
Summary: pythonw has a console on Win98

Initial Comment:
executing a script with pythonw (2.2.1) on win98
results in a console window being visible.  I reverted
my application to Python 2.1.1 and it works fine. 

pythonw works okay on WinXP with 2.2.1 though.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-08-19 14:26

Message:
Logged In: YES 
user_id=31435

Since this has been traced to GTK, and we don't develop 
that code, I'm closing this as 3rdParty and WontFix.  I 
appreciate your pesistence in tracking this down!  It helps 
us when we get a clear resolution.  I'm just sorry it doesn't 
help you too <wink>.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-08-19 14:20

Message:
Logged In: YES 
user_id=31435

Thanks for the followup!  Unless you can dream up a reason 
for believing this is a bug in the Python core, I'm going to 
close this as 3rdParty.  pythonw doesn't open a console, 
but it can't prevent other code from opening consoles.  If 
pygtk or GTK are opening console windows, and that's 
inappropriate, you'll have to file a report with their 
developers (pygtk and GTK aren't part of the Python core, 
so their maintainers won't even see a report *here*).

----------------------------------------------------------------------

Comment By: Paul Spencer (pgs)
Date: 2002-08-19 14:13

Message:
Logged In: YES 
user_id=52126

it appears that glib forces a console window open under
windows, although I am not sure why this doesn't happen on
WinXP.

I am assuming you will mark as invalid?

----------------------------------------------------------------------

Comment By: Paul Spencer (pgs)
Date: 2002-08-19 14:04

Message:
Logged In: YES 
user_id=52126

This works as you suggest.  I have actually managed to get
this problem with 2.1.1 as well now.  I think that the
problem is with GTK when a g_message or g_warning is issued,
it causes the console to open.  The console doesn't actually
appear right away, only when it gets to the g_message or
g_warning.  Any output that would have appeared before that
is missing, but any output after it does appear ( I think). 

I'm using pygtk0.6.6 to write a GTK-based python app, but
there's lots of C code too.

I will look in glib and see if I can find out what it might
be trying to do ... the unfortunate side effect of this is
that I doubt I can get you a short example unless you are
set up with pygtk.  I could provide binaries though ... 

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-08-15 19:18

Message:
Logged In: YES 
user_id=31435

Please give a specific, short example.  For example, if I 
double-click on this file from Explorer under Win98, using 
2.2.1, it plays the sound but no console window opens:

C:\Python22>type example.pyw
import winsound
winsound.Beep(3000, 1000)

C:\Python22>

What happens when you try that?  If a console window does 
pop up, check the your .pyw file assocation -- you may have 
damaged it.  .pyw (Python File (no console))'s Open action 
should be associated to

C:\PYTHON22\pythonw.exe "%1" %*

or to wherever you installed Python 2.2.1.

    



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595537&group_id=5470


From noreply@sourceforge.net  Mon Aug 19 20:05:51 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Aug 2002 12:05:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-597318 ] tiny doc bug -- __rtruediv__
Message-ID: <E17grqZ-0005Wm-00@usw-sf-web1.sourceforge.net>

Bugs item #597318, was opened at 2002-08-19 19:05
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=597318&group_id=5470

Category: Documentation
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Koenig (arkoenig)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: tiny doc bug -- __rtruediv__

Initial Comment:
The language reference, section 3.3.6, fails to mention
__rtruediv__, which experiment shows is actually
implemented (and necessary if you want to overload
division when __future__.division is in effect).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=597318&group_id=5470


From noreply@sourceforge.net  Mon Aug 19 22:31:51 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Aug 2002 14:31:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-597401 ] python-mode 4.6 & syntax highlighting
Message-ID: <E17gu7r-00012D-00@usw-sf-web1.sourceforge.net>

Bugs item #597401, was opened at 2002-08-19 17:31
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=597401&group_id=5470

Category: Demos and Tools
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mikhail Terekhov (miketm)
Assigned to: Nobody/Anonymous (nobody)
Summary: python-mode 4.6 & syntax highlighting

Initial Comment:
 emacs 21.1.3 and python-mode 4.6 
 
The following fragment illustrates that single quote after 
triple quotes or single double quote after triple double 
quotes destroys syntax highlighting. 
 
    '''t'his is atest 
    test 
    ''' 
    test 
    te'st 
    test 
    """test 
    test 
    te"st 
    """ 
    test 
 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=597401&group_id=5470


From noreply@sourceforge.net  Mon Aug 19 23:08:25 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Aug 2002 15:08:25 -0700
Subject: [Python-bugs-list] [ python-Bugs-595350 ] string method bugs w/ 8bit, unicode args
Message-ID: <E17guhF-0001uH-00@usw-sf-web1.sourceforge.net>

Bugs item #595350, was opened at 2002-08-14 21:56
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595350&group_id=5470

Category: Unicode
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Inyeol Lee (inyeol)
Assigned to: Guido van Rossum (gvanrossum)
Summary: string method bugs w/ 8bit, unicode args

Initial Comment:
Python 2.2.1 (#1, Apr 10 2002, 18:25:16) 
[GCC 2.95.3 20010315 (release)] on sunos5

1. "abc".endswith("c") ->1
   "abc".endswith(u"c") -> 0 # bug.
   u"abc".endswith("c") -> 1
   u"abc".endswith(u"c") -> 1

2. "aaa".rfind("a") -> 2
   "aaa".rfind(u"a") -> 0 # bug.
   u"aaa".rfind("a") -> 2
   u"aaa".rfind(u"a") -> 2

   .rindex() has the same bug.

3. "abc".rfind("") -> 3
   "abc".rfind(u"") -> 0 # bug.
   u"abc".rfind("") -> 0 # bug.
   u"abc".rfind(u"") -> 0 # bug.

   .rindex() has the same bug.

4. "abc".replace("", "x") -> ValueError
   "abc".replace(u"", "x") -> u'abcxxxx' # bug.
   u"abc".replace("", "x") -> u'abcxxxx' # bug.
   u"abc".replace(u"", "x") -> u'abcxxxx' # bug.

   They should raise ValueError, or return u'xaxbxcx'.
   BTW, how about changing s.replace("") behavior to
return
   "xaxbxcx" (or u"xaxbxcx") for all 4 cases? It is
consistent
   with other string methods and re.sub() method.
   It seems that Guido doesn't mind changing this.

[Guido]
> If someone really wants 'abc'.replace('', '-') to
return '-a-b-c-',
> please submit patches for both 8-bit and Unicode
strings to
> SourceForge and assign to me.  I looked into this and
it's
> non-trivial: the implementation used for 8-bit
strings goes into an
> infinite loop when the pattern is empty, and the
Unicode
> implementation tacks '----' onto the end.  Please
supply doc and
> unittest patches too.  At least re does the right
thing already:

5. (it's not a bug)
   Except for .replace() above, s.split() is the only
string method
   which raises exception. How about changing this to
return
   unmodified string when empty string  is given as a
separator?
   This is consistent with re.split() behavior.

- Inyeol Lee

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-19 18:08

Message:
Logged In: YES 
user_id=6380

I'm still reviewing this.

Next time, please send context diffs; diffs relative to
current (or at least fairly recent :-) CVS would also be
appreciated.

Don't add the bug number in comments for each change; I will
have to remove all those manually now...

I'm uploading a version patch that applies cleanly to
current CVS; it's not ready yet (the Unicode tests fail and
I have to clean up the comments).

Backporting will be a bitch, because I don't want the
changes for x.replace('', ...) to be backported (new
functionality etc.).

----------------------------------------------------------------------

Comment By: Inyeol Lee (inyeol)
Date: 2002-08-16 13:45

Message:
Logged In: YES 
user_id=595280

uploaded patch for these bugs.  -Inyeol Lee

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595350&group_id=5470


From noreply@sourceforge.net  Mon Aug 19 23:26:29 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Aug 2002 15:26:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-597401 ] python-mode 4.6 & syntax highlighting
Message-ID: <E17guyj-0006GH-00@usw-sf-web3.sourceforge.net>

Bugs item #597401, was opened at 2002-08-19 17:31
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=597401&group_id=5470

Category: Demos and Tools
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Mikhail Terekhov (miketm)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: python-mode 4.6 & syntax highlighting

Initial Comment:
 emacs 21.1.3 and python-mode 4.6 
 
The following fragment illustrates that single quote after 
triple quotes or single double quote after triple double 
quotes destroys syntax highlighting. 
 
    '''t'his is atest 
    test 
    ''' 
    test 
    te'st 
    test 
    """test 
    test 
    te"st 
    """ 
    test 
 

----------------------------------------------------------------------

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2002-08-19 18:26

Message:
Logged In: YES 
user_id=12800

Sorry, there's nothing python-mode can do about this.  This
is simply a limitation of Emacs.  Here's the FAQ.

http://www.python.org/emacs/python-mode/faq.html

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=597401&group_id=5470


From noreply@sourceforge.net  Tue Aug 20 00:18:42 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Aug 2002 16:18:42 -0700
Subject: [Python-bugs-list] [ python-Bugs-597177 ] Tiny tiny doc bug in regexp lib
Message-ID: <E17gvnG-0000Gb-00@usw-sf-web4.sourceforge.net>

Bugs item #597177, was opened at 2002-08-19 09:27
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=597177&group_id=5470

Category: Documentation
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Koenig (arkoenig)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Tiny tiny doc bug in regexp lib

Initial Comment:
Section 4.2.4, in the description of "match", says:

The optional parameter endpos limits how far the string
will be searched; it will be as if the string is endpos
characters long, so only the characters from pos to
endpos will be searched for a match.

Shouldn't it be "as if the string is endpos-pos
characters long"?  Also, shouldn't it be "the
characters in the range [pos:endpos]" to avoid the
potential ambiguity (i.e. making it clearer that the
range does not include the character at index endpos)?

Finally, what happens if pos > endpos?


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-08-19 18:18

Message:
Logged In: YES 
user_id=80475

The suggestion of using "range[pos:endpos]" would be an 
improvement, but it suggests a contradiction to the 
preceding statement that the pos and endpos are not 
completely equivalent to string slicing.

IMHO, the docs are clearer as-is.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=597177&group_id=5470


From noreply@sourceforge.net  Tue Aug 20 00:23:41 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Aug 2002 16:23:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-597318 ] tiny doc bug -- __rtruediv__
Message-ID: <E17gvs5-0003az-00@usw-sf-web1.sourceforge.net>

Bugs item #597318, was opened at 2002-08-19 14:05
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=597318&group_id=5470

Category: Documentation
Group: Python 2.2.1
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Andrew Koenig (arkoenig)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: tiny doc bug -- __rtruediv__

Initial Comment:
The language reference, section 3.3.6, fails to mention
__rtruediv__, which experiment shows is actually
implemented (and necessary if you want to overload
division when __future__.division is in effect).

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-08-19 18:23

Message:
Logged In: YES 
user_id=80475

Good catch, but the time machine beat you to it.

See http://www.python.org/dev/doc/devel/ref/numeric-
types.html for the latest and greatest iteration of the 
docs.  Also, this change was backported to be in 2.2.2.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=597318&group_id=5470


From noreply@sourceforge.net  Tue Aug 20 05:59:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Aug 2002 21:59:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-597604 ] import cycle in distutils
Message-ID: <E17h17K-0005Ze-00@usw-sf-web4.sourceforge.net>

Bugs item #597604, was opened at 2002-08-19 22:59
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=597604&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Dalke (dalke)
Assigned to: Nobody/Anonymous (nobody)
Summary: import cycle in distutils

Initial Comment:
There is a import cycle in distutils which causes
4Suite's setup.py
to fail.  Here's the reproducible, using 2.3a0 from CVS
(latest
updated on 18 Aug)

% python
Python 2.3a0 (#3, Aug 19 2002, 01:46:45)
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> from distutils import dist
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.3/distutils/dist.py",
line 19, in ?
    from distutils.core import DEBUG
  File "/usr/local/lib/python2.3/distutils/core.py",
line 24, in ?
    from distutils.dist import Distribution
ImportError: cannot import name Distribution
>>>


However, I *can* do the following
% python
Python 2.3a0 (#3, Aug 19 2002, 01:46:45)
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> from distutils import core
>>> from distutils import dist
>>>

This doesn't exist in Python 2.2.

The cycle is obvious -- 'dist' imports 'core' imports
DEBUG from 'dist'.

I tried replacing things with
  from distutils import core

and using core.DEBUG instead of DEBUG, but that
caused a problem with Python's install.  Hence, no
patch included.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=597604&group_id=5470


From noreply@sourceforge.net  Tue Aug 20 15:00:42 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Aug 2002 07:00:42 -0700
Subject: [Python-bugs-list] [ python-Bugs-597177 ] Tiny tiny doc bug in regexp lib
Message-ID: <E17h9Yo-0005MS-00@usw-sf-web3.sourceforge.net>

Bugs item #597177, was opened at 2002-08-19 10:27
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=597177&group_id=5470

Category: Documentation
Group: Python 2.2.1
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Andrew Koenig (arkoenig)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Tiny tiny doc bug in regexp lib

Initial Comment:
Section 4.2.4, in the description of "match", says:

The optional parameter endpos limits how far the string
will be searched; it will be as if the string is endpos
characters long, so only the characters from pos to
endpos will be searched for a match.

Shouldn't it be "as if the string is endpos-pos
characters long"?  Also, shouldn't it be "the
characters in the range [pos:endpos]" to avoid the
potential ambiguity (i.e. making it clearer that the
range does not include the character at index endpos)?

Finally, what happens if pos > endpos?


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-08-20 10:00

Message:
Logged In: YES 
user_id=3066

I've made some clarifications, but perhaps not what Andrew
expected.  The behavior of endpos < pos is now described
explicitly.

Committed as Doc/lib/libre.tex revisions 1.86 and 1.73.6.9.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-08-19 19:18

Message:
Logged In: YES 
user_id=80475

The suggestion of using "range[pos:endpos]" would be an 
improvement, but it suggests a contradiction to the 
preceding statement that the pos and endpos are not 
completely equivalent to string slicing.

IMHO, the docs are clearer as-is.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=597177&group_id=5470


From noreply@sourceforge.net  Tue Aug 20 16:36:12 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Aug 2002 08:36:12 -0700
Subject: [Python-bugs-list] [ python-Bugs-597795 ] spawn*() doesn't handle errors well
Message-ID: <E17hB3E-0006h2-00@usw-sf-web1.sourceforge.net>

Bugs item #597795, was opened at 2002-08-20 08:36
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=597795&group_id=5470

Category: Python Library
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Hickey (gohickey)
Assigned to: Nobody/Anonymous (nobody)
Summary: spawn*() doesn't handle errors well

Initial Comment:
spawn*() routines are supposed to return the child's pid, 
but if an error occurs (such as bad parameters, etc.), it 
returns 127.  This "looks" like a valid pid, so the caller 
has no way of knowing if something when wrong.  
Throwing an exception would be much more 
informational (and python-esque).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=597795&group_id=5470


From noreply@sourceforge.net  Tue Aug 20 16:38:00 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Aug 2002 08:38:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-597797 ] exec*() doesn't handle errors well
Message-ID: <E17hB4y-0006MF-00@usw-sf-web2.sourceforge.net>

Bugs item #597797, was opened at 2002-08-20 08:38
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=597797&group_id=5470

Category: Python Library
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Hickey (gohickey)
Assigned to: Nobody/Anonymous (nobody)
Summary: exec*() doesn't handle errors well

Initial Comment:
If an error occurs in exec*(), (such as bad parameters, 
etc.) exec*() returns to the caller.  exec*() is not 
supposed to return.  Throwing an exception would be a 
better way to handle errors.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=597797&group_id=5470


From noreply@sourceforge.net  Tue Aug 20 17:35:43 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Aug 2002 09:35:43 -0700
Subject: [Python-bugs-list] [ python-Bugs-595350 ] string method bugs w/ 8bit, unicode args
Message-ID: <E17hByp-0006qp-00@usw-sf-web5.sourceforge.net>

Bugs item #595350, was opened at 2002-08-14 21:56
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595350&group_id=5470

Category: Unicode
Group: Python 2.2.1
Status: Open
>Resolution: Rejected
Priority: 5
Submitted By: Inyeol Lee (inyeol)
Assigned to: Guido van Rossum (gvanrossum)
Summary: string method bugs w/ 8bit, unicode args

Initial Comment:
Python 2.2.1 (#1, Apr 10 2002, 18:25:16) 
[GCC 2.95.3 20010315 (release)] on sunos5

1. "abc".endswith("c") ->1
   "abc".endswith(u"c") -> 0 # bug.
   u"abc".endswith("c") -> 1
   u"abc".endswith(u"c") -> 1

2. "aaa".rfind("a") -> 2
   "aaa".rfind(u"a") -> 0 # bug.
   u"aaa".rfind("a") -> 2
   u"aaa".rfind(u"a") -> 2

   .rindex() has the same bug.

3. "abc".rfind("") -> 3
   "abc".rfind(u"") -> 0 # bug.
   u"abc".rfind("") -> 0 # bug.
   u"abc".rfind(u"") -> 0 # bug.

   .rindex() has the same bug.

4. "abc".replace("", "x") -> ValueError
   "abc".replace(u"", "x") -> u'abcxxxx' # bug.
   u"abc".replace("", "x") -> u'abcxxxx' # bug.
   u"abc".replace(u"", "x") -> u'abcxxxx' # bug.

   They should raise ValueError, or return u'xaxbxcx'.
   BTW, how about changing s.replace("") behavior to
return
   "xaxbxcx" (or u"xaxbxcx") for all 4 cases? It is
consistent
   with other string methods and re.sub() method.
   It seems that Guido doesn't mind changing this.

[Guido]
> If someone really wants 'abc'.replace('', '-') to
return '-a-b-c-',
> please submit patches for both 8-bit and Unicode
strings to
> SourceForge and assign to me.  I looked into this and
it's
> non-trivial: the implementation used for 8-bit
strings goes into an
> infinite loop when the pattern is empty, and the
Unicode
> implementation tacks '----' onto the end.  Please
supply doc and
> unittest patches too.  At least re does the right
thing already:

5. (it's not a bug)
   Except for .replace() above, s.split() is the only
string method
   which raises exception. How about changing this to
return
   unmodified string when empty string  is given as a
separator?
   This is consistent with re.split() behavior.

- Inyeol Lee

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-20 12:35

Message:
Logged In: YES 
user_id=6380

I'm rejecting this patch.

The fixes for endswith(), rfind() and rindex() are already
in 2.3; these should be backported to 2.2 and I may use your
code for them.

I can't accept the new feature for replace() until you also
have a working patch for Unicode; I'm only +0 on this so I'm
not going to spend more time getting it right. Feel free to
submit a patch for *just* that here.

I don't want to accept the new feature for split(), because
I disagree that 'abc'.split('') should return ['abc']; if
anything, it should return ['', 'a', 'b', 'c', ''], but one
can argue about this and I think the ValueError is better.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-19 18:08

Message:
Logged In: YES 
user_id=6380

I'm still reviewing this.

Next time, please send context diffs; diffs relative to
current (or at least fairly recent :-) CVS would also be
appreciated.

Don't add the bug number in comments for each change; I will
have to remove all those manually now...

I'm uploading a version patch that applies cleanly to
current CVS; it's not ready yet (the Unicode tests fail and
I have to clean up the comments).

Backporting will be a bitch, because I don't want the
changes for x.replace('', ...) to be backported (new
functionality etc.).

----------------------------------------------------------------------

Comment By: Inyeol Lee (inyeol)
Date: 2002-08-16 13:45

Message:
Logged In: YES 
user_id=595280

uploaded patch for these bugs.  -Inyeol Lee

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595350&group_id=5470


From noreply@sourceforge.net  Tue Aug 20 18:33:13 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Aug 2002 10:33:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-595350 ] string method bugs w/ 8bit, unicode args
Message-ID: <E17hCsT-00085k-00@usw-sf-web2.sourceforge.net>

Bugs item #595350, was opened at 2002-08-14 21:56
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595350&group_id=5470

Category: Unicode
Group: Python 2.2.1
Status: Open
Resolution: Rejected
Priority: 5
Submitted By: Inyeol Lee (inyeol)
Assigned to: Guido van Rossum (gvanrossum)
Summary: string method bugs w/ 8bit, unicode args

Initial Comment:
Python 2.2.1 (#1, Apr 10 2002, 18:25:16) 
[GCC 2.95.3 20010315 (release)] on sunos5

1. "abc".endswith("c") ->1
   "abc".endswith(u"c") -> 0 # bug.
   u"abc".endswith("c") -> 1
   u"abc".endswith(u"c") -> 1

2. "aaa".rfind("a") -> 2
   "aaa".rfind(u"a") -> 0 # bug.
   u"aaa".rfind("a") -> 2
   u"aaa".rfind(u"a") -> 2

   .rindex() has the same bug.

3. "abc".rfind("") -> 3
   "abc".rfind(u"") -> 0 # bug.
   u"abc".rfind("") -> 0 # bug.
   u"abc".rfind(u"") -> 0 # bug.

   .rindex() has the same bug.

4. "abc".replace("", "x") -> ValueError
   "abc".replace(u"", "x") -> u'abcxxxx' # bug.
   u"abc".replace("", "x") -> u'abcxxxx' # bug.
   u"abc".replace(u"", "x") -> u'abcxxxx' # bug.

   They should raise ValueError, or return u'xaxbxcx'.
   BTW, how about changing s.replace("") behavior to
return
   "xaxbxcx" (or u"xaxbxcx") for all 4 cases? It is
consistent
   with other string methods and re.sub() method.
   It seems that Guido doesn't mind changing this.

[Guido]
> If someone really wants 'abc'.replace('', '-') to
return '-a-b-c-',
> please submit patches for both 8-bit and Unicode
strings to
> SourceForge and assign to me.  I looked into this and
it's
> non-trivial: the implementation used for 8-bit
strings goes into an
> infinite loop when the pattern is empty, and the
Unicode
> implementation tacks '----' onto the end.  Please
supply doc and
> unittest patches too.  At least re does the right
thing already:

5. (it's not a bug)
   Except for .replace() above, s.split() is the only
string method
   which raises exception. How about changing this to
return
   unmodified string when empty string  is given as a
separator?
   This is consistent with re.split() behavior.

- Inyeol Lee

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-20 13:33

Message:
Logged In: YES 
user_id=6380

Note: I've now applied your fixes for endswith and rfind
c.s. to Python 2.2 and 2.3.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-20 12:35

Message:
Logged In: YES 
user_id=6380

I'm rejecting this patch.

The fixes for endswith(), rfind() and rindex() are already
in 2.3; these should be backported to 2.2 and I may use your
code for them.

I can't accept the new feature for replace() until you also
have a working patch for Unicode; I'm only +0 on this so I'm
not going to spend more time getting it right. Feel free to
submit a patch for *just* that here.

I don't want to accept the new feature for split(), because
I disagree that 'abc'.split('') should return ['abc']; if
anything, it should return ['', 'a', 'b', 'c', ''], but one
can argue about this and I think the ValueError is better.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-19 18:08

Message:
Logged In: YES 
user_id=6380

I'm still reviewing this.

Next time, please send context diffs; diffs relative to
current (or at least fairly recent :-) CVS would also be
appreciated.

Don't add the bug number in comments for each change; I will
have to remove all those manually now...

I'm uploading a version patch that applies cleanly to
current CVS; it's not ready yet (the Unicode tests fail and
I have to clean up the comments).

Backporting will be a bitch, because I don't want the
changes for x.replace('', ...) to be backported (new
functionality etc.).

----------------------------------------------------------------------

Comment By: Inyeol Lee (inyeol)
Date: 2002-08-16 13:45

Message:
Logged In: YES 
user_id=595280

uploaded patch for these bugs.  -Inyeol Lee

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595350&group_id=5470


From noreply@sourceforge.net  Tue Aug 20 20:43:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Aug 2002 12:43:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-595601 ] file (& socket) I/O are not thread safe
Message-ID: <E17hEu7-0002ca-00@usw-sf-web2.sourceforge.net>

Bugs item #595601, was opened at 2002-08-15 12:34
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595601&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Jeremy Hylton (jhylton)
Summary: file (& socket) I/O are not thread safe

Initial Comment:
We recently found an assertion failure in the universal
newline support when running a multithreaded program
where two threads used the same Python file object. 
The assert(stream != NULL) test in 
Py_UniversalNewlineFread() fails once in a blue moon,
where stream is the stdio FILE * that the fileobject
wraps.  Further analysis suggests that there is a race
condition between checking FILE * and using FILE * that
exists in at least Python 2.1 and up.

I'll actually describe the problem as it exists in
Python 2.2, because it is simpler to avoid the
universal newline code.  That code isn't the source of
the problem, although it's assert() uncovers it in a
clear way.

In file_read() (rev 2.141.6.5), the first thing it does
is check if f_fp (the FILE *) is NULL.  If so it raises
an IOError -- operation on closed file object.  Later,
file_read() enters a for loop that calls fread() until
enough bytes have been read.

	for (;;) {
		Py_BEGIN_ALLOW_THREADS
		errno = 0;
		chunksize = fread(BUF(v) + bytesread, 1,
				  buffersize - bytesread, f->f_fp);
		Py_END_ALLOW_THREADS
		if (chunksize == 0) {
			if (!ferror(f->f_fp))
				break;
			PyErr_SetFromErrno(PyExc_IOError);
			clearerr(f->f_fp);
			Py_DECREF(v);
			return NULL;
		}

The problem is that fread() is called after the global
interpreter lock is released.  Since the lock is
released, another Python thread could run and modify
the file object, changing the value of f->f_fp.  Under
the current interpreter lock scheme, it isn't safe to
use f->f_fp without holding the interpreter lock.

The current file_read() code can fail in a variety of
ways.  It's possible for a second thread to close the
file, which will set f->f_fp to NULL.  Who knows what
fread() will do when NULL is passed.

The universal newline code is squirrels the FILE * in a
local variable, which is worse.  If it happens that
another thread closes the file, at best the local
points to a closed FILE *.  But that memory could get
recycled and then there's no way to know what it points to.

socket I/O has a similar problem with unsafe sharing of
the file descriptor.  However, this problem seems less
severe in general, because we'd just be passing a bogus
file descriptor to a system call.  We don't have to
worry about whether stdio will dump core when passed a
bogus pointer.  There is a chance the a socket will be
closed and its file descriptor used for a different
socket.  So a call to recv() with one socket ends up
using a different socket.  That will be a nightmare to
debug, but it won't cause a segfault.  (And, in
general, files and sockets shouldn't be shared between
application threads unless the application is going to
make sure its safe.)

The solution to this problem is to use a
per-file-object lock to guard access to f->f_fp.  No
thread should read or right f->f_fp without holding the
lock.  To make sure that other threads get a chance to
run when there is contention for the file, the
file-object lock should never be held when the GIL is held.


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-20 15:43

Message:
Logged In: YES 
user_id=6380

Wow. This is harder than I thought! :-(

We should be able to solve whatever problem there is with
'print'. The PyFile_AsFile() API may have to become
obsolete, *or* we may have to add a separate call to access
the lock. I'll have to think about it more.

----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2002-08-16 18:43

Message:
Logged In: YES 
user_id=12800

Jack, your last paragraph sounds like a good idea <waiting
for Tim to shoot holes in it>.  Isn't the whole point to
avoid core dumps, not to "make it work right" whatever that
means?  We should take the simplest approach to avoiding
crashes.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-08-16 18:21

Message:
Logged In: YES 
user_id=45365

Uhm... Isn't it good enough if you don't hold the GIL while you acquire the file lock? When I looked at it I thought it would be (but then, I didn't look very hard:-).

And there may be another way around this problem too. If you're really only worried about closing (Python at the moment couldn't care less that when two threads write to the same file at the same time the output may be intermingled or other fun things may happen) then don't lock the file, but simply set a flag "keep your hands off the FILE*, I'm using it!" and in that case delay the close. You may want to protect the flag and the delayed close with a lock, I guess.

Or you could define this as a programmer error and raise an exception if one thread tries to close a file another thread is using. (The application will know much better how to handle the contention with locking or some other mechanism).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-08-16 11:26

Message:
Logged In: YES 
user_id=31435

To cheer you up, it's probably worse than that <wink>.  
While you're holding a file lock, in theory you dare not 
execute any code that may call back into Python, because 
the called code may try to do an operation on the file 
you've got locked, and then the whole system freezes. That 
is, independent of the GIL, it's not thoroughly safe to call 
PyObject_Print with a file lock held, because an object's 
__str__ may try to "do something" with the Python-level file 
object too.  The more depressing news is that a reentrant 
file lock would solve that one.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-08-16 11:04

Message:
Logged In: YES 
user_id=31392

I think I'm less worried about PyFile_AsFile() than I am
about PyFile_WriteObject().  The latter is invoked by the
print statement.  It extracts the FILE* using
PyFile_AsFile() and proceeds to pass it to PyObject_Print().
 PyObject_Print() MUST hold the GIL, but since it has the
raw FILE* it MUST hold the file lock.  But you can't hold
both locks :-(.


----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-08-15 16:49

Message:
Logged In: YES 
user_id=45365

I'm not sure your solution of locking in the file object is feasible. Every call of PyFile_AsFile() is dangerous, if the  code proceeds to release the GIL before using the FILE* it's in danger. And this code could be in extension modules too (I know there's quite a few in my own img package).

When I did the universal newlines patch I basically ignored the problem (thinking that no-one in their right mind would close a file in one thread while it's still in use in another: how wrong can one be:-).

The only real solution may be to get rid of PyFile_AsFile altogether, and replace it with PyFile_AsFileLocked() and PyFile_Unlock() and make these calls somehow work even when the GIL is held (possibly by temporarily releasing the GIL while acquiring the file lock).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595601&group_id=5470


From noreply@sourceforge.net  Tue Aug 20 20:44:00 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Aug 2002 12:44:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-595837 ] pickle_complex in copy_reg.py
Message-ID: <E17hEv2-00031p-00@usw-sf-web5.sourceforge.net>

Bugs item #595837, was opened at 2002-08-15 23:28
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595837&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Neal Norwitz (nnorwitz)
Summary: pickle_complex in copy_reg.py

Initial Comment:
This code is in copy_reg.py from 1997:

def pickle_complex(c):
    return complex, (c.real, c.imag)

pickle(type(1j), pickle_complex, complex)

I'm not sure if the function pickle_complex() is
necessary, but it definitely seems that the line after
should be commented out or removed.  pickle_complex()
is not in the doc either.

(I was building WITHOUT_COMPLEX and found this problem.)

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-20 15:44

Message:
Logged In: YES 
user_id=6380

I'm rejecting this as invalid. Neal, if you disagree, just
reopen and assign to me.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-15 23:49

Message:
Logged In: YES 
user_id=6380

Without that line you can't pickle complex numbers. Maybe it
should fail gracefully if complex doesn't exist. Feel free
to check in a fix for that.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595837&group_id=5470


From noreply@sourceforge.net  Tue Aug 20 20:51:04 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Aug 2002 12:51:04 -0700
Subject: [Python-bugs-list] [ python-Bugs-597919 ] compiler package and SET_LINENO
Message-ID: <E17hF1s-0003Ai-00@usw-sf-web5.sourceforge.net>

Bugs item #597919, was opened at 2002-08-20 15:51
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=597919&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Jeremy Hylton (jhylton)
Summary: compiler package and SET_LINENO

Initial Comment:
The compiler package should not issue SET_LINENO
instructions any more.  Running the Zope 2.7 test suite
produces this traceback:

Traceback (most recent call last):
  File "test.py", line 433, in ?
    process_args()
  File "test.py", line 397, in process_args
    bad = main(module_filter, test_filter)
  File "test.py", line 308, in main
    runner(files, test_filter, debug)
  File "test.py", line 275, in runner
    s = get_suite(file)
  File "test.py", line 230, in get_suite
    mod = package_import(modname)
  File "test.py", line 211, in package_import
    mod = __import__(modname)
  File
"/home/fdrake/projects/Zope/Zope2.7/lib/python/RestrictedPython/tests/testRestrictions.py",
line 64, in ?
    create_rmodule()
  File
"/home/fdrake/projects/Zope/Zope2.7/lib/python/RestrictedPython/tests/testRestrictions.py",
line 55, in create_rmodule
    code = compile_restricted(source, fn, 'exec')
  File
"/home/fdrake/projects/Zope/Zope2.7/lib/python/RestrictedPython/RCompile.py",
line 147, in compile_restricted
    gen.compile()
  File
"/usr/local/lib/python2.3/compiler/pycodegen.py", line
123, in compile
    self.code = gen.getCode()
  File
"/usr/local/lib/python2.3/compiler/pycodegen.py", line
252, in getCode
    return self.graph.getCode()
  File "/usr/local/lib/python2.3/compiler/pyassem.py",
line 378, in getCode
    self.convertArgs()
  File "/usr/local/lib/python2.3/compiler/pyassem.py",
line 484, in convertArgs
    self.insts[i] = opname, conv(self, oparg)
  File "/usr/local/lib/python2.3/compiler/pyassem.py",
line 520, in _convert_LOAD_CONST
    arg = arg.getCode()
  File
"/usr/local/lib/python2.3/compiler/pycodegen.py", line
252, in getCode
    return self.graph.getCode()
  File "/usr/local/lib/python2.3/compiler/pyassem.py",
line 380, in getCode
    self.makeByteCode()
  File "/usr/local/lib/python2.3/compiler/pyassem.py",
line 585, in makeByteCode   
lnotab.addCode(self.opnum[opname], lo, hi)
KeyError: SET_LINENO


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=597919&group_id=5470


From noreply@sourceforge.net  Tue Aug 20 21:45:04 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Aug 2002 13:45:04 -0700
Subject: [Python-bugs-list] [ python-Bugs-597938 ] Core dump when using mmap.
Message-ID: <E17hFs8-0005oc-00@usw-sf-web1.sourceforge.net>

Bugs item #597938, was opened at 2002-08-20 15:45
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=597938&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Stephen P. White (thaden)
Assigned to: Nobody/Anonymous (nobody)
Summary: Core dump when using mmap.

Initial Comment:
Ok, it is dumb to read from a file before it is written
to.  But, via mmap I did it by accident and it dumped
core.  Here is a simple linux example which will do it.

d0lxac1% touch dummy
d0lxac1% python
Python 2.1 (#3, May 16 2001, 15:15:15)
[GCC 2.95.2 19991024 (release)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import os,mmap
>>> x = os.open('dummy',os.O_RDWR)
>>> m = mmap.mmap(x,4700)
>>> m.read(47)
Bus error (core dumped)
d0lxac1%

Yeah, its dumb, but should it really dump core?

Thanks.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=597938&group_id=5470


From noreply@sourceforge.net  Tue Aug 20 21:49:18 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Aug 2002 13:49:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-595601 ] file (& socket) I/O are not thread safe
Message-ID: <E17hFwE-0004kD-00@usw-sf-web3.sourceforge.net>

Bugs item #595601, was opened at 2002-08-15 16:34
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595601&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Jeremy Hylton (jhylton)
Summary: file (& socket) I/O are not thread safe

Initial Comment:
We recently found an assertion failure in the universal
newline support when running a multithreaded program
where two threads used the same Python file object. 
The assert(stream != NULL) test in 
Py_UniversalNewlineFread() fails once in a blue moon,
where stream is the stdio FILE * that the fileobject
wraps.  Further analysis suggests that there is a race
condition between checking FILE * and using FILE * that
exists in at least Python 2.1 and up.

I'll actually describe the problem as it exists in
Python 2.2, because it is simpler to avoid the
universal newline code.  That code isn't the source of
the problem, although it's assert() uncovers it in a
clear way.

In file_read() (rev 2.141.6.5), the first thing it does
is check if f_fp (the FILE *) is NULL.  If so it raises
an IOError -- operation on closed file object.  Later,
file_read() enters a for loop that calls fread() until
enough bytes have been read.

	for (;;) {
		Py_BEGIN_ALLOW_THREADS
		errno = 0;
		chunksize = fread(BUF(v) + bytesread, 1,
				  buffersize - bytesread, f->f_fp);
		Py_END_ALLOW_THREADS
		if (chunksize == 0) {
			if (!ferror(f->f_fp))
				break;
			PyErr_SetFromErrno(PyExc_IOError);
			clearerr(f->f_fp);
			Py_DECREF(v);
			return NULL;
		}

The problem is that fread() is called after the global
interpreter lock is released.  Since the lock is
released, another Python thread could run and modify
the file object, changing the value of f->f_fp.  Under
the current interpreter lock scheme, it isn't safe to
use f->f_fp without holding the interpreter lock.

The current file_read() code can fail in a variety of
ways.  It's possible for a second thread to close the
file, which will set f->f_fp to NULL.  Who knows what
fread() will do when NULL is passed.

The universal newline code is squirrels the FILE * in a
local variable, which is worse.  If it happens that
another thread closes the file, at best the local
points to a closed FILE *.  But that memory could get
recycled and then there's no way to know what it points to.

socket I/O has a similar problem with unsafe sharing of
the file descriptor.  However, this problem seems less
severe in general, because we'd just be passing a bogus
file descriptor to a system call.  We don't have to
worry about whether stdio will dump core when passed a
bogus pointer.  There is a chance the a socket will be
closed and its file descriptor used for a different
socket.  So a call to recv() with one socket ends up
using a different socket.  That will be a nightmare to
debug, but it won't cause a segfault.  (And, in
general, files and sockets shouldn't be shared between
application threads unless the application is going to
make sure its safe.)

The solution to this problem is to use a
per-file-object lock to guard access to f->f_fp.  No
thread should read or right f->f_fp without holding the
lock.  To make sure that other threads get a chance to
run when there is contention for the file, the
file-object lock should never be held when the GIL is held.


----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-08-20 20:49

Message:
Logged In: YES 
user_id=31392

Here's a checkpoint of current progress.  The patch applies
cleanly and even compiles.  It works most of the time, but
it causes a bunch of test failures.  I haven't had time to
debug the errors, two likely errors are incorrect
propagation of errors from across the release lock boundary.
 (The error checking goes on inside so that clearerr() can
be called while the file lock is held but
PyErr_SetFromErrno() can be called while the GIL is held.) 
The other source of errors is typos -- like calling LOCK
when you mean UNLOCK.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-20 19:43

Message:
Logged In: YES 
user_id=6380

Wow. This is harder than I thought! :-(

We should be able to solve whatever problem there is with
'print'. The PyFile_AsFile() API may have to become
obsolete, *or* we may have to add a separate call to access
the lock. I'll have to think about it more.

----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2002-08-16 22:43

Message:
Logged In: YES 
user_id=12800

Jack, your last paragraph sounds like a good idea <waiting
for Tim to shoot holes in it>.  Isn't the whole point to
avoid core dumps, not to "make it work right" whatever that
means?  We should take the simplest approach to avoiding
crashes.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-08-16 22:21

Message:
Logged In: YES 
user_id=45365

Uhm... Isn't it good enough if you don't hold the GIL while you acquire the file lock? When I looked at it I thought it would be (but then, I didn't look very hard:-).

And there may be another way around this problem too. If you're really only worried about closing (Python at the moment couldn't care less that when two threads write to the same file at the same time the output may be intermingled or other fun things may happen) then don't lock the file, but simply set a flag "keep your hands off the FILE*, I'm using it!" and in that case delay the close. You may want to protect the flag and the delayed close with a lock, I guess.

Or you could define this as a programmer error and raise an exception if one thread tries to close a file another thread is using. (The application will know much better how to handle the contention with locking or some other mechanism).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-08-16 15:26

Message:
Logged In: YES 
user_id=31435

To cheer you up, it's probably worse than that <wink>.  
While you're holding a file lock, in theory you dare not 
execute any code that may call back into Python, because 
the called code may try to do an operation on the file 
you've got locked, and then the whole system freezes. That 
is, independent of the GIL, it's not thoroughly safe to call 
PyObject_Print with a file lock held, because an object's 
__str__ may try to "do something" with the Python-level file 
object too.  The more depressing news is that a reentrant 
file lock would solve that one.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-08-16 15:04

Message:
Logged In: YES 
user_id=31392

I think I'm less worried about PyFile_AsFile() than I am
about PyFile_WriteObject().  The latter is invoked by the
print statement.  It extracts the FILE* using
PyFile_AsFile() and proceeds to pass it to PyObject_Print().
 PyObject_Print() MUST hold the GIL, but since it has the
raw FILE* it MUST hold the file lock.  But you can't hold
both locks :-(.


----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-08-15 20:49

Message:
Logged In: YES 
user_id=45365

I'm not sure your solution of locking in the file object is feasible. Every call of PyFile_AsFile() is dangerous, if the  code proceeds to release the GIL before using the FILE* it's in danger. And this code could be in extension modules too (I know there's quite a few in my own img package).

When I did the universal newlines patch I basically ignored the problem (thinking that no-one in their right mind would close a file in one thread while it's still in use in another: how wrong can one be:-).

The only real solution may be to get rid of PyFile_AsFile altogether, and replace it with PyFile_AsFileLocked() and PyFile_Unlock() and make these calls somehow work even when the GIL is held (possibly by temporarily releasing the GIL while acquiring the file lock).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595601&group_id=5470


From noreply@sourceforge.net  Tue Aug 20 22:19:26 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Aug 2002 14:19:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-586926 ] Empty genindex.html pages
Message-ID: <E17hGPO-0000jr-00@usw-sf-web4.sourceforge.net>

Bugs item #586926, was opened at 2002-07-26 10:25
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=586926&group_id=5470

Category: Documentation
Group: Python 2.3
>Status: Open
Resolution: Invalid
Priority: 6
Submitted By: Matthias Klose (doko)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Empty genindex.html pages

Initial Comment:
When building the html docs, empty index pages are 
generated.

$ ls -l html/*/genindex.html
-rw-r--r--    1 doko     doko         3341 Jul 26 11:53 
html/api/genindex.html
-rw-r--r--    1 doko     doko         3433 Jul 26 11:59 
html/lib/genindex.html
-rw-r--r--    1 doko     doko         3436 Jul 26 12:00 
html/mac/genindex.html
-rw-r--r--    1 doko     doko         3322 Jul 26 12:00 
html/ref/genindex.html

compared to 2.1.3, built with texinfo-4.1:

$ ls -l html/*/genindex.html
-rw-r--r--    1 doko     doko        51726 Jul 26 11:42 
html/api/genindex.html
-rw-r--r--    1 doko     doko       310251 Jul 26 11:47 
html/lib/genindex.html
-rw-r--r--    1 doko     doko        28449 Jul 26 11:48 
html/mac/genindex.html
-rw-r--r--    1 doko     doko        73766 Jul 26 11:48 
html/ref/genindex.html

building the 2.1.3 docs with texinfo-4.2 fails as well. For 
2.2.1 and current CVS the empty files are generated 
independent of the texinfo version.

An account on a build environment can be provided 
(Debian 3.0).

----------------------------------------------------------------------

>Comment By: Matthias Klose (doko)
Date: 2002-08-20 21:19

Message:
Logged In: YES 
user_id=60903

Attached is the build log. The patches applied are mostly
patches for Debian specific file locations and build hints.
The default python version is 2.1.3, however the make for
the Doc dir is called with PYTHON=<newly_built_python>.

perl is 5.6.1
latex2html is 2000-beta1


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-08-14 17:15

Message:
Logged In: YES 
user_id=3066

Please provide a detailed list of steps you took from a
clean checkout.  If you can provide a typescript (using the
"script" command at your shell), I'd appreciate it.  Version
numbers for LaTeX2HTML, the installed version of Python, and
Perl would be helpful.

----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2002-08-10 06:12

Message:
Logged In: YES 
user_id=60903

Just rechecked. The problem is still there (trying to
generate the documentation for today's CVS).


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-08-09 21:28

Message:
Logged In: YES 
user_id=3066

This problem appears to have disappeared in the development
versions of the documentation at some point since the report
was filed.

If you see this only on documentation you generate rather
than the standarad documentation from python.org, please let
me know.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=586926&group_id=5470


From noreply@sourceforge.net  Tue Aug 20 22:32:30 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Aug 2002 14:32:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-589427 ] standard include paths on command line
Message-ID: <E17hGc2-00012s-00@usw-sf-web4.sourceforge.net>

Bugs item #589427, was opened at 2002-08-01 00:13
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=589427&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: Remind
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Skip Montanaro (montanaro)
Summary: standard include paths on command line

Initial Comment:
when compiling shared modules (using gcc-3.1.1), 
standard include paths are included (by setup.py?) in 
the include path, which can change the search order. 
gcc-3.1 warns about:

building 'xreadlines' extension
gcc-3.1 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -
fPIC -I. -I/home/packages/pyt
hon2.3/python2.3-2.2.90/./Include -I/usr/include -
I/usr/local/include -I/home/pa
ckages/python2.3/python2.3-2.2.90/Include -
I/home/packages/python2.3/python2.3-2
.2.90/build-static -
c /home/packages/python2.3/python2.3-
2.2.90/Modules/xreadlin
esmodule.c -o build/temp.linux-i686-
2.3/xreadlinesmodule.o
gcc -shared build/temp.linux-i686-
2.3/xreadlinesmodule.o -L/usr/lib -L/usr/local
/lib -o build/lib.linux-i686-2.3/xreadlines.so
building 'array' extension
gcc-3.1 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -
fPIC -I. -I/hocc1: warning: c
hanging search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory

In this case, /usr/include and /usr/local/include should 
not be included on the command line.


----------------------------------------------------------------------

>Comment By: Matthias Klose (doko)
Date: 2002-08-20 21:32

Message:
Logged In: YES 
user_id=60903

Two more problems:

On Debian, the db headers are installed in /usr/include.

- This directory is not searched and bsddb not built.

- Adding '/usr/include' to setup.py in the db setup,
   the header is found, but /usr/include added to
   the command line.

One unrelated thing is that the bsddb setup adds
-R/usr/lib, which is not support on Linux by gcc-3.2.


----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-08-14 02:29

Message:
Logged In: YES 
user_id=44345

Doko, are you still having problems?  I really have nothing to go on here.  I 
don't see /usr/include turning up on the command line and don't have a 
Debian system to try things out on. (Does the SF compile farm?)

Skip


----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-08-05 15:25

Message:
Logged In: YES 
user_id=44345

Sorry guys, I'm coming in on this late.  

I'm done with the bsddb trickery.  In any case /usr/include is not added 
as a -I argument under any circumstances in the bsddb build section of 
setup.py.  Various Linux vendors allow you to install multiple versions of 
Berkeley DB simultaneously.  The only way you can guarantee that a 
particular version is compiled against and linked with is to add the 
appropriate -I and -L flags to the command line.  On RedHat-derived 
systems the include files are in /usr/include/db{1,2,3,4} if installed as part 
of a system install, while if you install from Sleepycat source I believe it's 
/usr/local/BerkeleyDB<version>/include.   I can't really get rid of the 
RH-related include directories. 

Wait a minute.  I take some of that back.  *If* you are foolish enough to 
uncomment the section of code which enables compilation and linkage 
with Berkeley DB 1.85, you might wind up with -I/usr/include on the 
command line to build the bsddb module.  I will correct that (make it so 
/usr/include isn't added to the -I flag) and also reorder the directory 
search so system include directories are scanned after non-system 
directories.

How's this going to help the OP?  I thought the problem he saw was 
more pervasive (xreadlines, _ssl, etc).



----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-08-05 14:51

Message:
Logged In: YES 
user_id=6656

Skip, are you still working on the bsddb related bits of
setup.py?  Can you look into how /usr/include is getting
onto the commandline?


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-04 12:47

Message:
Logged In: YES 
user_id=21627

I can't reproduce this. With the current CVS, on Debian,
with --prefix=/usr, I get

gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC
-DWITH_APPINIT=1 -I/usr/include/tcl8.3 -I/usr/X11R6/include
-I. -I/vol/marvin-vol8/loewis/python/dist/src/./Include
-I/usr/local/include
-I/vol/marvin-vol8/loewis/python/dist/src/Include
-I/vol/marvin-vol8/loewis/python/dist/src -c
/vol/marvin-vol8/loewis/python/dist/src/Modules/_tkinter.c
-o build/temp.linux-i686-2.3/_tkinter.o

So it won't add -I/usr/include to the command line options.

----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2002-08-03 16:30

Message:
Logged In: YES 
user_id=60903

No. It's:

 - bsddb
 - dbm
 - _tkinter

all modules, which are installed in /usr at least on Debian
GNU/Linux (but maybe on other distros as well).

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-08-03 16:19

Message:
Logged In: YES 
user_id=6656

It's only the _ssl module, right?  I've fixed that.

The -R/usr/lib and -L/usr/lib's come from various database
modules, the configuration of which is under review anyway.
 I hope those doing the reviewing have seen this bug traffic...

----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2002-08-03 15:56

Message:
Logged In: YES 
user_id=60903

build log attached. please tell me if you need an account on
a Debian machine (doko   debian org).
configure \
        --with-gcc=gcc-3.1 \
        --with-cxx=g++-3.1 \
        --prefix=/usr \
        --with-fpectl \
        --enable-ipv6


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-08-03 15:12

Message:
Logged In: YES 
user_id=6656

Really?  Nuts.  They're not on my machine.

What arguments are you passing to configure?

----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2002-08-02 21:48

Message:
Logged In: YES 
user_id=60903

Thanks for the fix, however when building shared modules,
-I/usr/include and -L/usr/lib are still passed to the compiler.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-02 14:05

Message:
Logged In: YES 
user_id=21627

And indeed, we should not remove /usr/local/include, since
the system compiler may not be gcc.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-08-02 13:56

Message:
Logged In: YES 
user_id=6656

OK, done, in

setup.py revision 1.100

I don't see us removing /usr/local/include from the command
line.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-02 13:49

Message:
Logged In: YES 
user_id=21627

The patch looks fine to me, please apply it.

I still think that the bogus warning should be removed from
gcc entirely.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-08-02 12:54

Message:
Logged In: YES 
user_id=6656

OK, can you try the attached patch?

Martin, does this look OK to you?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-08-02 08:53

Message:
Logged In: YES 
user_id=6656

Ah, sorry!

Hmm.  Now I don't see the problem, i.e. for me
-I/usr/include is not part of the command line passed to the
compiler.

Are you building from up-to-date CVS?  Though I don't recall
any recent changes in this area.  Ahh, you're running
".../configure --prefix=/usr", right?

I'll dig.

----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2002-08-01 20:23

Message:
Logged In: YES 
user_id=60903

I disagree. The discussion is on /usr/local/include. We are 
talking about /usr/include, which is a system include dir on 
almost all systems.

See the thread "gcc 3.2's cpp breaks configure scripts" at 
http://gcc.gnu.org/ml/gcc/2002-07/, i.e.:

http://gcc.gnu.org/ml/gcc/2002-07/msg01527.html

Inclusion of /usr/include can lead to errors, as explained in:
http://gcc.gnu.org/ml/gcc/2002-07/msg01541.html

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-08-01 09:08

Message:
Logged In: YES 
user_id=6656

This has been deemed a bug in gcc, see this thread:

http://mail.python.org/pipermail/python-dev/2002-June/025990.html

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=589427&group_id=5470


From noreply@sourceforge.net  Wed Aug 21 00:54:09 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Aug 2002 16:54:09 -0700
Subject: [Python-bugs-list] [ python-Bugs-595350 ] string method bugs w/ 8bit, unicode args
Message-ID: <E17hIp7-0004QE-00@usw-sf-web4.sourceforge.net>

Bugs item #595350, was opened at 2002-08-15 01:56
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595350&group_id=5470

Category: Unicode
Group: Python 2.2.1
Status: Open
Resolution: Rejected
Priority: 5
Submitted By: Inyeol Lee (inyeol)
Assigned to: Guido van Rossum (gvanrossum)
Summary: string method bugs w/ 8bit, unicode args

Initial Comment:
Python 2.2.1 (#1, Apr 10 2002, 18:25:16) 
[GCC 2.95.3 20010315 (release)] on sunos5

1. "abc".endswith("c") ->1
   "abc".endswith(u"c") -> 0 # bug.
   u"abc".endswith("c") -> 1
   u"abc".endswith(u"c") -> 1

2. "aaa".rfind("a") -> 2
   "aaa".rfind(u"a") -> 0 # bug.
   u"aaa".rfind("a") -> 2
   u"aaa".rfind(u"a") -> 2

   .rindex() has the same bug.

3. "abc".rfind("") -> 3
   "abc".rfind(u"") -> 0 # bug.
   u"abc".rfind("") -> 0 # bug.
   u"abc".rfind(u"") -> 0 # bug.

   .rindex() has the same bug.

4. "abc".replace("", "x") -> ValueError
   "abc".replace(u"", "x") -> u'abcxxxx' # bug.
   u"abc".replace("", "x") -> u'abcxxxx' # bug.
   u"abc".replace(u"", "x") -> u'abcxxxx' # bug.

   They should raise ValueError, or return u'xaxbxcx'.
   BTW, how about changing s.replace("") behavior to
return
   "xaxbxcx" (or u"xaxbxcx") for all 4 cases? It is
consistent
   with other string methods and re.sub() method.
   It seems that Guido doesn't mind changing this.

[Guido]
> If someone really wants 'abc'.replace('', '-') to
return '-a-b-c-',
> please submit patches for both 8-bit and Unicode
strings to
> SourceForge and assign to me.  I looked into this and
it's
> non-trivial: the implementation used for 8-bit
strings goes into an
> infinite loop when the pattern is empty, and the
Unicode
> implementation tacks '----' onto the end.  Please
supply doc and
> unittest patches too.  At least re does the right
thing already:

5. (it's not a bug)
   Except for .replace() above, s.split() is the only
string method
   which raises exception. How about changing this to
return
   unmodified string when empty string  is given as a
separator?
   This is consistent with re.split() behavior.

- Inyeol Lee

----------------------------------------------------------------------

>Comment By: Inyeol Lee (inyeol)
Date: 2002-08-20 23:54

Message:
Logged In: YES 
user_id=595280

s.replace() patched, unittest updated from current CVS.
Tested with 2.2.1, but it should work fine with 2.3a, since
the codes
affected by this patch didn't changed since 2.2.1.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-20 17:33

Message:
Logged In: YES 
user_id=6380

Note: I've now applied your fixes for endswith and rfind
c.s. to Python 2.2 and 2.3.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-20 16:35

Message:
Logged In: YES 
user_id=6380

I'm rejecting this patch.

The fixes for endswith(), rfind() and rindex() are already
in 2.3; these should be backported to 2.2 and I may use your
code for them.

I can't accept the new feature for replace() until you also
have a working patch for Unicode; I'm only +0 on this so I'm
not going to spend more time getting it right. Feel free to
submit a patch for *just* that here.

I don't want to accept the new feature for split(), because
I disagree that 'abc'.split('') should return ['abc']; if
anything, it should return ['', 'a', 'b', 'c', ''], but one
can argue about this and I think the ValueError is better.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-19 22:08

Message:
Logged In: YES 
user_id=6380

I'm still reviewing this.

Next time, please send context diffs; diffs relative to
current (or at least fairly recent :-) CVS would also be
appreciated.

Don't add the bug number in comments for each change; I will
have to remove all those manually now...

I'm uploading a version patch that applies cleanly to
current CVS; it's not ready yet (the Unicode tests fail and
I have to clean up the comments).

Backporting will be a bitch, because I don't want the
changes for x.replace('', ...) to be backported (new
functionality etc.).

----------------------------------------------------------------------

Comment By: Inyeol Lee (inyeol)
Date: 2002-08-16 17:45

Message:
Logged In: YES 
user_id=595280

uploaded patch for these bugs.  -Inyeol Lee

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595350&group_id=5470


From noreply@sourceforge.net  Wed Aug 21 06:04:43 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Aug 2002 22:04:43 -0700
Subject: [Python-bugs-list] [ python-Bugs-598097 ] SocketType is not type(socket)
Message-ID: <E17hNff-0003HF-00@usw-sf-web2.sourceforge.net>

Bugs item #598097, was opened at 2002-08-21 14:04
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=598097&group_id=5470

Category: Python Library
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: June Kim (juneaftn)
Assigned to: Nobody/Anonymous (nobody)
Summary: SocketType is not type(socket)

Initial Comment:
Python 2.2.* and 2.3.a0 on win 32

>>> from socket import *
>>> s=socket(AF_INET,SOCK_STREAM)
>>> type(s) is SocketType
False (or 0)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=598097&group_id=5470


From noreply@sourceforge.net  Wed Aug 21 10:08:42 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 21 Aug 2002 02:08:42 -0700
Subject: [Python-bugs-list] [ python-Bugs-597919 ] compiler package and SET_LINENO
Message-ID: <E17hRTm-0003Yg-00@usw-sf-web1.sourceforge.net>

Bugs item #597919, was opened at 2002-08-20 19:51
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=597919&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Jeremy Hylton (jhylton)
Summary: compiler package and SET_LINENO

Initial Comment:
The compiler package should not issue SET_LINENO
instructions any more.  Running the Zope 2.7 test suite
produces this traceback:

Traceback (most recent call last):
  File "test.py", line 433, in ?
    process_args()
  File "test.py", line 397, in process_args
    bad = main(module_filter, test_filter)
  File "test.py", line 308, in main
    runner(files, test_filter, debug)
  File "test.py", line 275, in runner
    s = get_suite(file)
  File "test.py", line 230, in get_suite
    mod = package_import(modname)
  File "test.py", line 211, in package_import
    mod = __import__(modname)
  File
"/home/fdrake/projects/Zope/Zope2.7/lib/python/RestrictedPython/tests/testRestrictions.py",
line 64, in ?
    create_rmodule()
  File
"/home/fdrake/projects/Zope/Zope2.7/lib/python/RestrictedPython/tests/testRestrictions.py",
line 55, in create_rmodule
    code = compile_restricted(source, fn, 'exec')
  File
"/home/fdrake/projects/Zope/Zope2.7/lib/python/RestrictedPython/RCompile.py",
line 147, in compile_restricted
    gen.compile()
  File
"/usr/local/lib/python2.3/compiler/pycodegen.py", line
123, in compile
    self.code = gen.getCode()
  File
"/usr/local/lib/python2.3/compiler/pycodegen.py", line
252, in getCode
    return self.graph.getCode()
  File "/usr/local/lib/python2.3/compiler/pyassem.py",
line 378, in getCode
    self.convertArgs()
  File "/usr/local/lib/python2.3/compiler/pyassem.py",
line 484, in convertArgs
    self.insts[i] = opname, conv(self, oparg)
  File "/usr/local/lib/python2.3/compiler/pyassem.py",
line 520, in _convert_LOAD_CONST
    arg = arg.getCode()
  File
"/usr/local/lib/python2.3/compiler/pycodegen.py", line
252, in getCode
    return self.graph.getCode()
  File "/usr/local/lib/python2.3/compiler/pyassem.py",
line 380, in getCode
    self.makeByteCode()
  File "/usr/local/lib/python2.3/compiler/pyassem.py",
line 585, in makeByteCode   
lnotab.addCode(self.opnum[opname], lo, hi)
KeyError: SET_LINENO


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-08-21 09:08

Message:
Logged In: YES 
user_id=6656

This is my fault, obviously.

I'm prepared to do some legwork to fix this problem, but don't really understand the code well enough to judge the best approach.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=597919&group_id=5470


From noreply@sourceforge.net  Wed Aug 21 10:33:34 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 21 Aug 2002 02:33:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-598160 ] import _tkinter python dumps core.
Message-ID: <E17hRrq-0007hR-00@usw-sf-web2.sourceforge.net>

Bugs item #598160, was opened at 2002-08-21 11:33
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=598160&group_id=5470

Category: Build
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Göran Uddeborg (goeran)
Assigned to: Nobody/Anonymous (nobody)
Summary: import _tkinter python dumps core.

Initial Comment:
We are trying to build python on a HP-UX 11.00 using gcc
3.1. But when it  comes to the stage when it tries to
load _tkinter i.e. 
   import _tkinter
python dumps core.

running gdb on the core file gives us that it get's a
segfault on the line Python/import.c:210 i.e 
	if (interp->modules == NULL)
and yes, interp is null...
any clue how to continue?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=598160&group_id=5470


From noreply@sourceforge.net  Wed Aug 21 20:25:17 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 21 Aug 2002 12:25:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-596866 ] cgi module: order of multiple values
Message-ID: <E17hb6T-0002d1-00@usw-sf-web4.sourceforge.net>

Bugs item #596866, was opened at 2002-08-18 16:31
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=596866&group_id=5470

Category: Documentation
Group: Python 2.2.1
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Robert Siemer (siemer)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: cgi module: order of multiple values

Initial Comment:
The cgi module documentation is misleading in "Higher
Level Interface"
(http://python.org/doc/current/lib/node296.html).

The order of multiple values for the same name "may
vary from browser to browser and should not be counted
on". This should not be true.

It is instead true that the order is fixed for the mime
types application/x-www-form-urlencoded and
multipart/form-data (probably all types that the cgi
module is handling).

User agents should send these values in the order they
appear in the document as e.g. stated in the latest
HTML 4 recommendation on
http://www.w3.org/TR/html4/interact/forms.html#h-17.13.4

Bye,
	Robert

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-08-21 15:25

Message:
Logged In: YES 
user_id=3066

I maintain that the documentation is correct, though it may
be clarified somewhat.  A CGI script should not rely that
browsers fully conform to the latest version of every
specification, even the HTML specification.  There's nothing
to prevent a client from submitting a request based on an
older version of a form, or without a form at all.

I've added the clarification in Doc/lib/libcgi.tex revisions
1.37 and 1.35.4.2.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=596866&group_id=5470


From noreply@sourceforge.net  Wed Aug 21 21:22:56 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 21 Aug 2002 13:22:56 -0700
Subject: [Python-bugs-list] [ python-Bugs-598451 ] The KeyError message doesn't use repr on the key value reported
Message-ID: <E17hc0G-0003ZI-00@usw-sf-web2.sourceforge.net>

Bugs item #598451, was opened at 2002-08-21 12:22
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=598451&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: R. David Murray (rdmurray)
Assigned to: Nobody/Anonymous (nobody)
Summary: The KeyError message doesn't use repr on the key value reported

Initial Comment:
>>> {}[1]
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
KeyError: 1
>>> {}['']
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
KeyError

Note that the second message is very confusing if you don't
know that it means the KeyError is on a blank key.  In any
case I think KeyError should use repr on the key value in
order to make it clear what is being used as the key.  According
to zigg, that should also fix the fact that the : goes missing
in the second case.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=598451&group_id=5470


From noreply@sourceforge.net  Wed Aug 21 21:57:58 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 21 Aug 2002 13:57:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-588768 ] add main to py_pycompile
Message-ID: <E17hcYA-0004l5-00@usw-sf-web3.sourceforge.net>

Bugs item #588768, was opened at 2002-07-30 16:34
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=588768&group_id=5470

Category: Python Library
Group: Feature Request
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: add main to py_pycompile

Initial Comment:
[From http://bugs.debian.org/139971]

This is a request for a _script_ to compile a single
(or more) .py files instead of compiling a complete
directory. The proposal is to add a main to
py_pycompile.py which compiles all files given on the
command line.


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-08-21 16:57

Message:
Logged In: YES 
user_id=3066

Checked in a modified version of the patch and updated
documentaiton as Lib/py_compile.py 1.23 and
Doc/lib/libpycompile.tex 1.3.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-08-11 12:31

Message:
Logged In: YES 
user_id=31435

Reassigned to Fred as I've never used this script -- it 
sounds harmless enough that the real question may be 
whether Fred wants to document it <wink>.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-11 11:16

Message:
Logged In: YES 
user_id=33168

I don't know if this should really be done, but it's easy
enough to add.  Patch attached.  Tim, is this worthwhile or
should it be rejected?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=588768&group_id=5470


From noreply@sourceforge.net  Wed Aug 21 23:27:52 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 21 Aug 2002 15:27:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-588711 ] imaplib: prefix-quoted strings
Message-ID: <E17hdxA-0005xs-00@usw-sf-web4.sourceforge.net>

Bugs item #588711, was opened at 2002-07-31 05:07
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=588711&group_id=5470

Category: Python Library
Group: Python 2.2.1
>Status: Closed
>Resolution: Duplicate
Priority: 7
Submitted By: Matthias Klose (doko)
Assigned to: Piers Lauder (pierslauder)
Summary: imaplib: prefix-quoted strings

Initial Comment:
[From Debian BTS http://bugs.debian.org/150485]

From: John Goerzen <jgoerzen@quovix.com>
Subject: python2.2: imaplib: doesn't properly support
prefix-quoted strings

imaplib's fetch command is totally useless with many
servers.

They'll send the message body in this form:
{100}
Headers here, body here, (100 characters worth)

This is specified in RFC2060 secion 4.3.  imaplib's
fetch chokes on
"unexpected data" in the response.

imaplib should receive this prefix-quoted string
properly and return it in a
non-quoted fashion.

As it is, it is totally impossible to read messages
from most imap servers.

----------------------------------------------------------------------

>Comment By: Piers Lauder (pierslauder)
Date: 2002-08-22 08:27

Message:
Logged In: YES 
user_id=196212

This has been established to be the same bug report as
571334 "imaplib
fetch is broken" which has been fixed. This is a duplicate.
Closed.


----------------------------------------------------------------------

Comment By: Piers Lauder (pierslauder)
Date: 2002-08-03 20:53

Message:
Logged In: YES 
user_id=196212

(Apologies for delay in responding, i've been away.)

This command has been working fine for ages, so I'm
surprised it has suddenly stopped working. It still works
on my imap server which sends prefix-quoted
strings for fetch responses.

Can you run the test at the bottom of imaplib.py with
debugging turned on and e-mail me the output?

  python imaplib.py -d5 <imap_server_host>

Repeat if for each of the different imap servers you are
having the problem with (it would help if you could identify
the imap server version as well.)

That will help me track down the problem. Thanks!

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-07-31 18:29

Message:
Logged In: YES 
user_id=6656

Maybe you can stop test_imaplib failing while you're at it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=588711&group_id=5470


From noreply@sourceforge.net  Thu Aug 22 01:08:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 21 Aug 2002 17:08:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-216289 ] Programs using Tkinter sometimes can't shut down (Windows)
Message-ID: <E17hfW7-0007VY-00@usw-sf-web2.sourceforge.net>

Bugs item #216289, was opened at 2000-10-07 02:25
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=216289&group_id=5470

Category: Windows
Group: Python 2.3
Status: Open
Resolution: Later
Priority: 3
Submitted By: Tim Peters (tim_one)
Assigned to: Fredrik Lundh (effbot)
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: John Popplewell (johnnypops)
Date: 2002-08-22 00:08

Message:
Logged In: YES 
user_id=143340

Hi,

tried wrapping the WaitForSingleObject() with if (consolePtr-
>toWrite) { ... as suggested. Solves the problem for me in 
debug and release builds (without thread support).

What is "the tcl83.dll from www.tcl.tk", what changes does 
it include?

cheers,
John.


----------------------------------------------------------------------

Comment By: Doug Henderson (djhender)
Date: 2002-08-16 23:03

Message:
Logged In: YES 
user_id=148444

I downloaded and tested the tcl83.dll from www.tcl.tk with 
Python 2.2.1 on Win98SE using my BugDemo.py script 
from a related bug report [231207]. Several test runs 
showed that a problem still exists. The app hangs until 
Winopldapp is killed, however this leaves tcl83.dll in use. 
The problem does not occur on every execution. Some 
types of activity seem to provoke the hang, for instance, 
minimizing and maximizing the window seems to increase 
the change that it will hang on exit.

----------------------------------------------------------------------

Comment By: David Gravereaux (davygrvy)
Date: 2002-08-16 21:53

Message:
Logged In: YES 
user_id=7549

Whoop, error in the patch..  consoleMutex might not need to 
be locked.  It could cause a new dead-lock.

----------------------------------------------------------------------

Comment By: David Gravereaux (davygrvy)
Date: 2002-08-16 21:41

Message:
Logged In: YES 
user_id=7549

>It is hanging up in ConsoleCloseProc() in 'tclWinConsole.c'
>at about line 527:
>WaitForSingleObject(consolePtr->writeThread, INFINITE);

Jeff, this might need the same attention the pipe reader 
thread got for that [exec] memory leak bug.  I think 
ConsoleWriterThread() should use WaitForMultipleObjects 
instead of WaitForSingleObject with a second event handle 
used to single a fall-out like the pipe reader thread does.  It 
appears that ConsoleCloseProc() has no way to signal the 
writer thread to close at all.

This doesn't address the blocking WriteFile() in 
ConsoleWriterThread(), though.  Is it blocking there, too?
Sorry for the large post.  I'm given the option to attach a file.

Index: tclWinConsole.c
=============================================
======================
RCS file: /cvsroot/tcl/tcl/win/tclWinConsole.c,v
retrieving revision 1.7
diff -c -r1.7 tclWinConsole.c
*** tclWinConsole.c	15 Jan 2002 17:55:30 -0000	1.7
--- tclWinConsole.c	16 Aug 2002 21:31:56 -0000
***************
*** 79,84 ****
--- 79,87 ----
      HANDLE startWriter;		/* Auto-reset 
event used by the main thread to
  				 * signal when 
the writer thread should attempt
  				 * to write to the 
console. */
+     HANDLE stopWriter;		/* Auto-reset 
event used by the main thread to
+ 				 * signal when 
the writer thread should
+ 				 * terminate. */
      HANDLE startReader;		/* Auto-reset 
event used by the main thread to
  				 * signal when 
the reader thread should attempt
  				 * to read from 
the console. */
***************
*** 516,522 ****
  	 */
  
  	Tcl_MutexLock(&consoleMutex);
! 	TerminateThread(consolePtr->writeThread, 0);
  
  	/*
  	 * Wait for the thread to terminate.  This ensures 
that we are
--- 519,525 ----
  	 */
  
  	Tcl_MutexLock(&consoleMutex);
! 	SetEvent(consolePtr->stopWriter);
  
  	/*
  	 * Wait for the thread to terminate.  This ensures 
that we are
***************
*** 1134,1149 ****
  {
  
      ConsoleInfo *infoPtr = (ConsoleInfo *)arg;
      HANDLE *handle = infoPtr->handle;
      DWORD count, toWrite;
      char *buf;
  
      for (;;) {
  	/*
  	 * Wait for the main thread to signal before 
attempting to write.
  	 */
  
! 	WaitForSingleObject(infoPtr->startWriter, 
INFINITE);
  
  	buf = infoPtr->writeBuf;
  	toWrite = infoPtr->toWrite;
--- 1137,1163 ----
  {
  
      ConsoleInfo *infoPtr = (ConsoleInfo *)arg;
+     HANDLE events[2];
      HANDLE *handle = infoPtr->handle;
      DWORD count, toWrite;
      char *buf;
  
+     events[0] = infoPtr->stopWriter;
+     events[1] = infoPtr->startWriter;
+ 
      for (;;) {
+ 	DWORD dwWait;
+ 
  	/*
  	 * Wait for the main thread to signal before 
attempting to write.
  	 */
  
! 	dwWait = WaitForMultipleObjects(events, 2, 
FALSE, INFINITE);
! 
! 	if (dwWait != (WAIT_OBJECT_0 + 1)) {
! 	    /* either the stop event or some other error, so 
exit */
! 	    return 0;
! 	}
  
  	buf = infoPtr->writeBuf;
  	toWrite = infoPtr->toWrite;
***************
*** 1251,1256 ****
--- 1265,1271 ----
      if (permissions & TCL_WRITABLE) {
  	infoPtr->writable = CreateEvent(NULL, TRUE, 
TRUE, NULL);
  	infoPtr->startWriter = CreateEvent(NULL, FALSE, 
FALSE, NULL);
+ 	infoPtr->stopWriter = CreateEvent(NULL, FALSE, 
FALSE, NULL);
  	infoPtr->writeThread = CreateThread(NULL, 8000, 
ConsoleWriterThread,
  	        infoPtr, 0, &id);
      }


----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-08-16 18:56

Message:
Logged In: YES 
user_id=72656

I'm finding it a bit hard to reproduce, and now not at all.  
Could people please try replacing their current tcl83.dll with 
the one at http://www.tcl.tk/tcl83.dll.  The sig on it is:
634880 Aug 16 10:53 tcl83.dll
(md5) b35628568ddc4afed4f675d2d9a50faf  tcl83.dll

I can't hang anymore with python 2.2.1 at the Win98 
command prompt with:
   python \Python22\Tools\idle\idle.pyw

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-08-16 17:50

Message:
Logged In: YES 
user_id=72656

johnny - That actually helps a lot and fairly clearly indicates 
the source of this hanging problem.  To give more context to 
that area, this is in the final shutdown code where it is 
(obviously) shutting down the console I/O.  The reader is 
shutdown without a check for more input (why, we are 
exiting?), so there is no issue there.

The writer however wants to make sure that the console 
output channel is drained before exit.  A blocking channel 
that is not being flushed will cause a hang.

So the question is, what is the stdio setup for Tcl in 
Py/Tkinter?  That should be examined to see whether stdio is 
clear to flush on exit.

Perhaps you can also help with more debugging.  Could you 
wrap the problematic WaitForSingleObject call with
if (consolePtr->toWrite) { ...
and perhaps also print out what to write.  It may be that 
blocking output isn't the problem at all, but rather that we are 
never receiving the signal on consolePtr->writable (usually 
done in the writer thread).  The consolePtr->toWrite check 
will at least ensure flushed channels do not enter this 
potential hanging state.

----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-08-16 14:16

Message:
Logged In: YES 
user_id=143340

I have dug out the setup I used previously and, apart from 
using Python 2.2 instead of 2.0.1, have had a go at 
reproducing my previous results.

With a debug build of Tcl/Tk and threads disabled I have 
managed to get this stack trace when it locks on exit (after 
doing a break):

ConsoleCloseProc(int * 0x006a0ae4, Tcl_Interp * 
0x00000000) line 527 + 17 bytes
TclFinalizeIOSubsystem() line 241 + 20 bytes
Tcl_FinalizeThread() line 911
Tcl_Finalize() line 812
DllMain(HINSTANCE__ * 0x00970000, unsigned long 
0x00000000, void * 0x00000001) line 197
TCL83! _DllMainCRTStartup@12 + 80 bytes
KERNEL32! bff7ddd6()
KERNEL32! bff8d123()
8176b5fc()

It is hanging up in ConsoleCloseProc() in 'tclWinConsole.c'
at about line 527:
WaitForSingleObject(consolePtr->writeThread, INFINITE);

I tried changing the timeout from INFINITE to 100ms and 
testing the return value for WAIT_TIMEOUT. Sure enough it 
occasionaly printed a message (and didn't lock-up).

Don't know if this helps. Will try to reproduce the double 
free problem in the threaded build later,

cheers,
John.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-15 14:19

Message:
Logged In: YES 
user_id=6380

Just a note so I won't forget this: Jeff Hobbs once said the
code to look at is

tk/generic/tkConsole.c:Tk_InitConsoleChannels

----------------------------------------------------------------------

Comment By: David Gravereaux (davygrvy)
Date: 2002-08-15 13:23

Message:
Logged In: YES 
user_id=7549

Hi John,

I have seen Tcl extension DLLs that set exit handlers get 
called by Tcl after they were torn-down.  NT and Win9x seem 
to be a bit different in the order of what DLLs get torn-down.  
here's a note from some old code of mine:

#ifdef __WIN32__
    // It can happen that the HEAP could have already been 
unloaded
    // from an awkward teardown caused by a Ctrl+C or other.  
Win32
    // seems to do a teardown in reverse order and by the time 
Tcl
    // knows what's going on and Tcl_Finalize calls the exit
    // handlers, this extension's data (heap?) has already been
    // unloaded by the OS.  Do a quick legal check on the 
pointer
    // first.
    //
    if (IsBadReadPtr(adapt, sizeof(T *))) return;
#endif

what's the back/stacktrace?  who is calling 
Tcl_FinalizeNotifier?  And had anyone called it before during 
the shutdown phase? I can't say with much confidence that 
this is happening here, too.  Maybe..  Could Tk be telling Tcl 
shutdown?  That's sort of backwards, if so.

I run w2k here, so I can't help in debugging from a test case.  
tclsh with a threaded build doesn't even call Tcl_Finalize to 
avoid all this!

----------------------------------------------------------------------

Comment By: Donal K. Fellows (dkf)
Date: 2002-08-15 13:09

Message:
Logged In: YES 
user_id=79902

Firstly, on the matter of threads.  Tcl/Tk on Windows uses
threads internally even in non-threaded builds.  That's
Windows for you (in particular, you can get calls parachuted
in from completely separate threads with relatively little
warning.  Also, you need threaded helpers to handle
non-blocking waiting on some kinds of objects.)

It's a bit hard to work out if the problem's been fixed
without a stack-trace (preferably with debugging symbols
enabled so that we can see what the function names and
arguments to those functions are.)  I have no  chance of
replicating this bug here (I'm currently running IRIX, but
also have some access to Solaris and Linux...)

----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-08-15 12:15

Message:
Logged In: YES 
user_id=143340

Hi to davygrvy,

my fix isn't for a thread related (deadlock) type problem - it 
is a fix for a double free type problem which is presumably 
screwing up the heap and causing the C runtime to hang.

It *is* with a threaded build (THREADDEFINES = -
DTCL_THREADS=1) which I think I enabled because I was 
using  'after' and it didn't work unless threading was 
enabled - but I may be mis-remembering here!

Also, I ended up doing all this with the debug build and 
found the -GZ flag useful - in fact it pointed out the fact that 
there was a problem with the heap.

It is worth noting that I have only seen this on Win98 and 
that using 'pythonw.exe' did *not* prevent this from 
happening,

regards John.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-15 01:00

Message:
Logged In: YES 
user_id=6380

AFAIK we never distributed a threaded build.

----------------------------------------------------------------------

Comment By: David Gravereaux (davygrvy)
Date: 2002-08-15 00:01

Message:
Logged In: YES 
user_id=7549

To johnnypops,

Where in Tcl_FinalizeNotifier() is the dead-lock occuring and 
is this with a threaded build of Tcl?


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-07-02 19:39

Message:
Logged In: YES 
user_id=31435

Jeff, a long time ago Fredrik Lundh said he was able to 
reproduce this with a short wish script (no Python, no Tkinter, 
just Tcl/Tk + wish).  I'm reassigning this to /F in the hopes 
he'll remember how.

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-07-02 18:55

Message:
Logged In: YES 
user_id=72656

I appreciate that many others see this is a problem in 
embedding Tcl, but without any clear way to reproduce this in 
Tcl/Tk itself, it's very hard for me to fix it.  I don't think that 
there is anything done in 8.4 to fix this that I recall, but if 
someone finds that the problem "goes away" with 8.4, please 
report that.

For those of course that experience this with python, the 
simple and "correct" work-around is to launch with 
pythonw.exe instead of python.exe.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-06-26 17:40

Message:
Logged In: NO 

According to http://tcl.activestate.com ActiveTcl 8.4.0 is now 
available for download.  It is new as of June 24.  I don't know 
whether this will solve our problems or not, but it's worth 
looking into.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-06-19 13:36

Message:
Logged In: NO 

I just downloaded Ruby 1.6.6 for Windows, which also uses 
Tcl/Tk 8.3 and I experience exactly the same problem there. 
So this is definitely a Tcl problem (but we know that already).

----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-06-07 19:01

Message:
Logged In: YES 
user_id=143340

Hmmm. 
I run a Python Tcl/Tk application several times every day - 
the very application that prompted my bug-hunt.

I do use "pythonw.exe" to launch it, but it used to hang 
almost as badly as "python.exe".

Whilst developing this app I used "python.exe" and 
experienced no hang-ups.

The Tcl guys point out that this bug is only one of several 
possible causes of the hang-up, maybe you are just out of 
luck.

The patch has fixed the problem on three Win98 machines, 
all of which exhibited the problem before updating the DLLs.

One thought - are you sure there weren't multiple copies of 
the tcl83.dll and tk83.dll files? My (only) copies were 
in "D:\python20\DLLs"

good luck,
John.


----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-06-03 18:55

Message:
Logged In: YES 
user_id=72656

providing Tim with a fixed DLL exactly according to John 
Popplewell's patch did not fix the problem for him.  That 
makes it seem fishy that John really didn't see the problem 
any more.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-03 16:59

Message:
Logged In: YES 
user_id=31435

I tried replacing Python 2.2.1's tk83.dll and tcl83.dll (from 
Tcl/Tk 8.3.2) with newer matched sets from

A) PythonWare's py21 distribution (Tcl/Tk 8.3.3).

and again from

B) ActiveState's Tcl/Tk 8.3.4.

All the symptoms originally reported here persisted on 
Win98SE despite that.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-05-22 13:57

Message:
Logged In: NO 

I am new to Python and encountered this bug on my very first 
Tkinter application.  It persists in Python 2.2.1 under 
Windows Me. Needless to say, it makes a bad first 
impression.  Basically, this thread says that Tkinter has been 
broken for a year and a half on a popular platform at a time 
when Python is trying to expand its user base.  Hopefully, this 
bug will be corrected soon.

If Tcl/Tk 8.4 is not released shortly you might try repackaging 
Tkinter for Win32 with an earlier version of Tcl/Tk, such as 
8.0, that doesn't encounter this problem.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-23 03:36

Message:
Logged In: YES 
user_id=6380

The proper action is to wait until Tcl 8.3.5 is released,
and then shaming someone else in providing you with a set of
Windowsbinaries for Tcl. You may also ask Hobbs if there's a
Windows project file to build Tcl/Tk for Windows.

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-03-12 02:31

Message:
Logged In: YES 
user_id=72656

I did end up back-porting this to the 8.3.4+ Tcl CVS on 
2002-02-25, which means it will be in an eventual 8.3.5.  
It is already in the release 8.4 alpha series.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-10 01:50

Message:
Logged In: YES 
user_id=31435

Back to Guido:  Do you think you know what the proper 
action is?  (You said that's why you reopened it, and 
there's been no new info here since then.)

----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-02-26 00:55

Message:
Logged In: YES 
user_id=143340

I knew I wasn't getting to the heart of it ....

Almost a one-liner!

It has been seriously spoiling my (otherwise crash free) 
Python experience on Win9x - hope it gets fixed soon.

cheers,
John.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-02-25 23:39

Message:
Logged In: YES 
user_id=6380

Reopened until we know what the proper action is.

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-02-25 23:32

Message:
Logged In: YES 
user_id=72656

This is mostly correct, and is fixed in the 8.4 Tcl sources 
already (I guess we can backport this).  This was mentioned 
in SF Tcl bug (account for chopped URL):

https://sourceforge.net/tracker/?
func=detail&aid=217982&group_id=10894&atid=110894

and the code comment is:

    /*
     * Only finalize the notifier if a notifier was 
installed in the
     * current thread; there is a route in which this is not
     * guaranteed to be true (when tclWin32Dll.c:DllMain() 
is called
     * with the flag DLL_PROCESS_DETACH by the OS, which 
could be
     * doing so from a thread that's never previously been 
involved
     * with Tcl, e.g. the task manager) so this check is 
important.
     *
     * Fixes Bug #217982 reported by Hugh Vu and Gene 
Leache.
     */
    if (tsdPtr == NULL) {
	return;
    }


----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-02-25 22:41

Message:
Logged In: YES 
user_id=143340

This one has been torturing me for a while.

Managed to track it down to a problem inside Tcl.
For the Tcl8.3.4 source distribution the problem is in
the file win/tclWinNotify.c 

void Tcl_FinalizeNotifier(ClientData clientData)
{
    ThreadSpecificData *tsdPtr = 
                         (ThreadSpecificData *) clientData;

    /* sometimes called with tsdPtr == NULL */
    if ( tsdPtr != NULL )
    {
        DeleteCriticalSection(&tsdPtr->crit);
        CloseHandle(tsdPtr->event);

        /*
         * Clean up the timer and messaging 
         * window for this thread.
         */

        if (tsdPtr->hwnd) {
	    KillTimer(tsdPtr->hwnd, INTERVAL_TIMER);
            DestroyWindow(tsdPtr->hwnd);
        }
    }

    /*
     * If this is the last thread to use the notifier, 
     * unregister the notifier window class.
     */

    Tcl_MutexLock(&notifierMutex);
    if ( notifierCount && !--notifierCount ) {
	UnregisterClassA( "TclNotifier", 
                          TclWinGetTclInstance());
    }
    Tcl_MutexUnlock(&notifierMutex);
}

This bodge doesn't address the underlying problem but has 
stopped me from tearing all my hair out,

cheers,
John Popplewell.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-10-24 22:27

Message:
Logged In: YES 
user_id=31435

FYI, you don't need an IDE to do this -- in Win9x, hit 
Ctrl+Alt+Del and kill the process directly.

A saner <wink> solution is to develop under Win2K, which 
doesn't appear to suffer this problem (the only reports 
I've seen, and experienced myself, came from Win9x boxes).

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-10-24 08:52

Message:
Logged In: NO 

For those who are still trapped in this bug's hell, I will 
gladly share the one thing that saved my sanity:  
WingIDE's 'Kill' command will shut down the program with 
apparent 100% certainty and no fear of lockups.  WingIDE 
has its own issues, so its not a perfect solution, but if 
you are like me and Joe (above) who test in small 
iterations, then using 'Kill' to quit out of your app while 
testing is a workaround that may preserve your sanity.

Perhaps the python gods and the Wing guys can get together 
and tell us how to replicate 'kill' into our code.  For 
now, I'll use WingIDE to edit, and pythonw.exe for my final 
client's delivery.

----------------------------------------------------------------------

Comment By: Howard Lightstone (hlightstone)
Date: 2001-09-05 17:43

Message:
Logged In: YES 
user_id=66570

I sometimes get bunches of these....

A tool I use (Taskinfo2000) reports that (after killing 
winoldap):

python.exe is blocked on a mutex named OLESCELOCKMUTEX.
The reported state is "Console Terminating".  There appears 
to be only one (os) thread running.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-04-02 20: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-06 05: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-13 02: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 20: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 16: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 14:40

Message:
Back to Tim since I have no clue what to do here.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-12 17: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 07: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: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=216289&group_id=5470


From noreply@sourceforge.net  Thu Aug 22 15:37:53 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 22 Aug 2002 07:37:53 -0700
Subject: [Python-bugs-list] [ python-Bugs-598797 ] HTTPConnection memory leak
Message-ID: <E17ht5t-0003Ww-00@usw-sf-web5.sourceforge.net>

Bugs item #598797, was opened at 2002-08-22 10:37
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=598797&group_id=5470

Category: Python Library
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Moales (mmoales)
Assigned to: Nobody/Anonymous (nobody)
Summary: HTTPConnection memory leak

Initial Comment:
This may be related to bugs 559117 and 592645.

I am using Python 2.2.1 (#34, 4/9/2002) on Windows 
2000 (5.00.2195, Service Pack 2).  Similar to bug 
559117, I see a steady increase of 4K in the size of the 
process after every 10 seconds or so.  Here's my test 
script:

import httplib
import time

for i in range(1000):
    conn = httplib.HTTPConnection("www.python.org")
    conn.request("GET", "/index.html")
    r1 = conn.getresponse()
    time.sleep(0.5)
    conn.close()




----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=598797&group_id=5470


From noreply@sourceforge.net  Thu Aug 22 16:52:11 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 22 Aug 2002 08:52:11 -0700
Subject: [Python-bugs-list] [ python-Bugs-595350 ] string method bugs w/ 8bit, unicode args
Message-ID: <E17huFn-0007RU-00@usw-sf-web2.sourceforge.net>

Bugs item #595350, was opened at 2002-08-14 21:56
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595350&group_id=5470

Category: Unicode
>Group: Python 2.3
Status: Open
Resolution: Rejected
Priority: 5
Submitted By: Inyeol Lee (inyeol)
Assigned to: Guido van Rossum (gvanrossum)
Summary: string method bugs w/ 8bit, unicode args

Initial Comment:
Python 2.2.1 (#1, Apr 10 2002, 18:25:16) 
[GCC 2.95.3 20010315 (release)] on sunos5

1. "abc".endswith("c") ->1
   "abc".endswith(u"c") -> 0 # bug.
   u"abc".endswith("c") -> 1
   u"abc".endswith(u"c") -> 1

2. "aaa".rfind("a") -> 2
   "aaa".rfind(u"a") -> 0 # bug.
   u"aaa".rfind("a") -> 2
   u"aaa".rfind(u"a") -> 2

   .rindex() has the same bug.

3. "abc".rfind("") -> 3
   "abc".rfind(u"") -> 0 # bug.
   u"abc".rfind("") -> 0 # bug.
   u"abc".rfind(u"") -> 0 # bug.

   .rindex() has the same bug.

4. "abc".replace("", "x") -> ValueError
   "abc".replace(u"", "x") -> u'abcxxxx' # bug.
   u"abc".replace("", "x") -> u'abcxxxx' # bug.
   u"abc".replace(u"", "x") -> u'abcxxxx' # bug.

   They should raise ValueError, or return u'xaxbxcx'.
   BTW, how about changing s.replace("") behavior to
return
   "xaxbxcx" (or u"xaxbxcx") for all 4 cases? It is
consistent
   with other string methods and re.sub() method.
   It seems that Guido doesn't mind changing this.

[Guido]
> If someone really wants 'abc'.replace('', '-') to
return '-a-b-c-',
> please submit patches for both 8-bit and Unicode
strings to
> SourceForge and assign to me.  I looked into this and
it's
> non-trivial: the implementation used for 8-bit
strings goes into an
> infinite loop when the pattern is empty, and the
Unicode
> implementation tacks '----' onto the end.  Please
supply doc and
> unittest patches too.  At least re does the right
thing already:

5. (it's not a bug)
   Except for .replace() above, s.split() is the only
string method
   which raises exception. How about changing this to
return
   unmodified string when empty string  is given as a
separator?
   This is consistent with re.split() behavior.

- Inyeol Lee

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-22 11:52

Message:
Logged In: YES 
user_id=6380

Hrm. You uploaded a gzipped tarball containing 5 separate
context diff files; and these were reverse diffs (created by
doing "diff -c new old). I prefer a single file containing
multiple forward context diffs. I've uploaded your patch in
the form that I'd like to see (taken relative to current CVS).

But there's a worse problem: your code contains a bug.
Consider this example:

u'abc'.replace('', '-', 0)

This correctly returns u'abc'.

Bot now try this:

class U(unicode): pass
U(u'abc').replace('', '-', 0)

This returns u'-ab' !!!

Please fix this.

I'm also still waiting for a  documentation update.

----------------------------------------------------------------------

Comment By: Inyeol Lee (inyeol)
Date: 2002-08-20 19:54

Message:
Logged In: YES 
user_id=595280

s.replace() patched, unittest updated from current CVS.
Tested with 2.2.1, but it should work fine with 2.3a, since
the codes
affected by this patch didn't changed since 2.2.1.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-20 13:33

Message:
Logged In: YES 
user_id=6380

Note: I've now applied your fixes for endswith and rfind
c.s. to Python 2.2 and 2.3.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-20 12:35

Message:
Logged In: YES 
user_id=6380

I'm rejecting this patch.

The fixes for endswith(), rfind() and rindex() are already
in 2.3; these should be backported to 2.2 and I may use your
code for them.

I can't accept the new feature for replace() until you also
have a working patch for Unicode; I'm only +0 on this so I'm
not going to spend more time getting it right. Feel free to
submit a patch for *just* that here.

I don't want to accept the new feature for split(), because
I disagree that 'abc'.split('') should return ['abc']; if
anything, it should return ['', 'a', 'b', 'c', ''], but one
can argue about this and I think the ValueError is better.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-19 18:08

Message:
Logged In: YES 
user_id=6380

I'm still reviewing this.

Next time, please send context diffs; diffs relative to
current (or at least fairly recent :-) CVS would also be
appreciated.

Don't add the bug number in comments for each change; I will
have to remove all those manually now...

I'm uploading a version patch that applies cleanly to
current CVS; it's not ready yet (the Unicode tests fail and
I have to clean up the comments).

Backporting will be a bitch, because I don't want the
changes for x.replace('', ...) to be backported (new
functionality etc.).

----------------------------------------------------------------------

Comment By: Inyeol Lee (inyeol)
Date: 2002-08-16 13:45

Message:
Logged In: YES 
user_id=595280

uploaded patch for these bugs.  -Inyeol Lee

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595350&group_id=5470


From noreply@sourceforge.net  Thu Aug 22 16:52:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 22 Aug 2002 08:52:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-595350 ] string method bugs w/ 8bit, unicode args
Message-ID: <E17huFe-0007RE-00@usw-sf-web2.sourceforge.net>

Bugs item #595350, was opened at 2002-08-14 21:56
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595350&group_id=5470

Category: Unicode
Group: Python 2.2.1
Status: Open
Resolution: Rejected
Priority: 5
Submitted By: Inyeol Lee (inyeol)
Assigned to: Guido van Rossum (gvanrossum)
Summary: string method bugs w/ 8bit, unicode args

Initial Comment:
Python 2.2.1 (#1, Apr 10 2002, 18:25:16) 
[GCC 2.95.3 20010315 (release)] on sunos5

1. "abc".endswith("c") ->1
   "abc".endswith(u"c") -> 0 # bug.
   u"abc".endswith("c") -> 1
   u"abc".endswith(u"c") -> 1

2. "aaa".rfind("a") -> 2
   "aaa".rfind(u"a") -> 0 # bug.
   u"aaa".rfind("a") -> 2
   u"aaa".rfind(u"a") -> 2

   .rindex() has the same bug.

3. "abc".rfind("") -> 3
   "abc".rfind(u"") -> 0 # bug.
   u"abc".rfind("") -> 0 # bug.
   u"abc".rfind(u"") -> 0 # bug.

   .rindex() has the same bug.

4. "abc".replace("", "x") -> ValueError
   "abc".replace(u"", "x") -> u'abcxxxx' # bug.
   u"abc".replace("", "x") -> u'abcxxxx' # bug.
   u"abc".replace(u"", "x") -> u'abcxxxx' # bug.

   They should raise ValueError, or return u'xaxbxcx'.
   BTW, how about changing s.replace("") behavior to
return
   "xaxbxcx" (or u"xaxbxcx") for all 4 cases? It is
consistent
   with other string methods and re.sub() method.
   It seems that Guido doesn't mind changing this.

[Guido]
> If someone really wants 'abc'.replace('', '-') to
return '-a-b-c-',
> please submit patches for both 8-bit and Unicode
strings to
> SourceForge and assign to me.  I looked into this and
it's
> non-trivial: the implementation used for 8-bit
strings goes into an
> infinite loop when the pattern is empty, and the
Unicode
> implementation tacks '----' onto the end.  Please
supply doc and
> unittest patches too.  At least re does the right
thing already:

5. (it's not a bug)
   Except for .replace() above, s.split() is the only
string method
   which raises exception. How about changing this to
return
   unmodified string when empty string  is given as a
separator?
   This is consistent with re.split() behavior.

- Inyeol Lee

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-22 11:52

Message:
Logged In: YES 
user_id=6380

Hrm. You uploaded a gzipped tarball containing 5 separate
context diff files; and these were reverse diffs (created by
doing "diff -c new old). I prefer a single file containing
multiple forward context diffs. I've uploaded your patch in
the form that I'd like to see (taken relative to current CVS).

But there's a worse problem: your code contains a bug.
Consider this example:

u'abc'.replace('', '-', 0)

This correctly returns u'abc'.

Bot now try this:

class U(unicode): pass
U(u'abc').replace('', '-', 0)

This returns u'-ab' !!!

Please fix this.

I'm also still waiting for a  documentation update.

----------------------------------------------------------------------

Comment By: Inyeol Lee (inyeol)
Date: 2002-08-20 19:54

Message:
Logged In: YES 
user_id=595280

s.replace() patched, unittest updated from current CVS.
Tested with 2.2.1, but it should work fine with 2.3a, since
the codes
affected by this patch didn't changed since 2.2.1.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-20 13:33

Message:
Logged In: YES 
user_id=6380

Note: I've now applied your fixes for endswith and rfind
c.s. to Python 2.2 and 2.3.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-20 12:35

Message:
Logged In: YES 
user_id=6380

I'm rejecting this patch.

The fixes for endswith(), rfind() and rindex() are already
in 2.3; these should be backported to 2.2 and I may use your
code for them.

I can't accept the new feature for replace() until you also
have a working patch for Unicode; I'm only +0 on this so I'm
not going to spend more time getting it right. Feel free to
submit a patch for *just* that here.

I don't want to accept the new feature for split(), because
I disagree that 'abc'.split('') should return ['abc']; if
anything, it should return ['', 'a', 'b', 'c', ''], but one
can argue about this and I think the ValueError is better.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-19 18:08

Message:
Logged In: YES 
user_id=6380

I'm still reviewing this.

Next time, please send context diffs; diffs relative to
current (or at least fairly recent :-) CVS would also be
appreciated.

Don't add the bug number in comments for each change; I will
have to remove all those manually now...

I'm uploading a version patch that applies cleanly to
current CVS; it's not ready yet (the Unicode tests fail and
I have to clean up the comments).

Backporting will be a bitch, because I don't want the
changes for x.replace('', ...) to be backported (new
functionality etc.).

----------------------------------------------------------------------

Comment By: Inyeol Lee (inyeol)
Date: 2002-08-16 13:45

Message:
Logged In: YES 
user_id=595280

uploaded patch for these bugs.  -Inyeol Lee

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595350&group_id=5470


From noreply@sourceforge.net  Thu Aug 22 17:39:22 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 22 Aug 2002 09:39:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-597919 ] compiler package and SET_LINENO
Message-ID: <E17huzS-00009H-00@usw-sf-web2.sourceforge.net>

Bugs item #597919, was opened at 2002-08-20 19:51
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=597919&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Jeremy Hylton (jhylton)
Summary: compiler package and SET_LINENO

Initial Comment:
The compiler package should not issue SET_LINENO
instructions any more.  Running the Zope 2.7 test suite
produces this traceback:

Traceback (most recent call last):
  File "test.py", line 433, in ?
    process_args()
  File "test.py", line 397, in process_args
    bad = main(module_filter, test_filter)
  File "test.py", line 308, in main
    runner(files, test_filter, debug)
  File "test.py", line 275, in runner
    s = get_suite(file)
  File "test.py", line 230, in get_suite
    mod = package_import(modname)
  File "test.py", line 211, in package_import
    mod = __import__(modname)
  File
"/home/fdrake/projects/Zope/Zope2.7/lib/python/RestrictedPython/tests/testRestrictions.py",
line 64, in ?
    create_rmodule()
  File
"/home/fdrake/projects/Zope/Zope2.7/lib/python/RestrictedPython/tests/testRestrictions.py",
line 55, in create_rmodule
    code = compile_restricted(source, fn, 'exec')
  File
"/home/fdrake/projects/Zope/Zope2.7/lib/python/RestrictedPython/RCompile.py",
line 147, in compile_restricted
    gen.compile()
  File
"/usr/local/lib/python2.3/compiler/pycodegen.py", line
123, in compile
    self.code = gen.getCode()
  File
"/usr/local/lib/python2.3/compiler/pycodegen.py", line
252, in getCode
    return self.graph.getCode()
  File "/usr/local/lib/python2.3/compiler/pyassem.py",
line 378, in getCode
    self.convertArgs()
  File "/usr/local/lib/python2.3/compiler/pyassem.py",
line 484, in convertArgs
    self.insts[i] = opname, conv(self, oparg)
  File "/usr/local/lib/python2.3/compiler/pyassem.py",
line 520, in _convert_LOAD_CONST
    arg = arg.getCode()
  File
"/usr/local/lib/python2.3/compiler/pycodegen.py", line
252, in getCode
    return self.graph.getCode()
  File "/usr/local/lib/python2.3/compiler/pyassem.py",
line 380, in getCode
    self.makeByteCode()
  File "/usr/local/lib/python2.3/compiler/pyassem.py",
line 585, in makeByteCode   
lnotab.addCode(self.opnum[opname], lo, hi)
KeyError: SET_LINENO


----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-08-22 16:39

Message:
Logged In: YES 
user_id=31392

A grep for SET_LINENO in the compiler package source will be
somewhat helpful.  There are very few places that actually
emit the instructions.  I thought they could just be
removed, but the lnotab is generated *from* the SET_LINENO
instructions.  So we need to come up with a different way to
generate the lnotab.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-08-21 09:08

Message:
Logged In: YES 
user_id=6656

This is my fault, obviously.

I'm prepared to do some legwork to fix this problem, but don't really understand the code well enough to judge the best approach.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=597919&group_id=5470


From noreply@sourceforge.net  Thu Aug 22 18:09:57 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 22 Aug 2002 10:09:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-598097 ] SocketType is not type(socket)
Message-ID: <E17hvT3-00033D-00@usw-sf-web3.sourceforge.net>

Bugs item #598097, was opened at 2002-08-21 05:04
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=598097&group_id=5470

Category: Python Library
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: June Kim (juneaftn)
>Assigned to: Tim Peters (tim_one)
Summary: SocketType is not type(socket)

Initial Comment:
Python 2.2.* and 2.3.a0 on win 32

>>> from socket import *
>>> s=socket(AF_INET,SOCK_STREAM)
>>> type(s) is SocketType
False (or 0)

----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-08-22 17:09

Message:
Logged In: YES 
user_id=31392

This code works as expected on Linux, so it must be Tim's fault.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=598097&group_id=5470


From noreply@sourceforge.net  Thu Aug 22 18:02:44 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 22 Aug 2002 10:02:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-598797 ] HTTPConnection memory leak
Message-ID: <E17hvM4-0002vb-00@usw-sf-web3.sourceforge.net>

Bugs item #598797, was opened at 2002-08-22 14:37
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=598797&group_id=5470

Category: Python Library
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Moales (mmoales)
>Assigned to: Jeremy Hylton (jhylton)
Summary: HTTPConnection memory leak

Initial Comment:
This may be related to bugs 559117 and 592645.

I am using Python 2.2.1 (#34, 4/9/2002) on Windows 
2000 (5.00.2195, Service Pack 2).  Similar to bug 
559117, I see a steady increase of 4K in the size of the 
process after every 10 seconds or so.  Here's my test 
script:

import httplib
import time

for i in range(1000):
    conn = httplib.HTTPConnection("www.python.org")
    conn.request("GET", "/index.html")
    r1 = conn.getresponse()
    time.sleep(0.5)
    conn.close()




----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=598797&group_id=5470


From noreply@sourceforge.net  Thu Aug 22 18:26:50 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 22 Aug 2002 10:26:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-598097 ] SocketType is not type(socket)
Message-ID: <E17hvjO-0003Hz-00@usw-sf-web3.sourceforge.net>

Bugs item #598097, was opened at 2002-08-21 01:04
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=598097&group_id=5470

Category: Python Library
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: June Kim (juneaftn)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: SocketType is not type(socket)

Initial Comment:
Python 2.2.* and 2.3.a0 on win 32

>>> from socket import *
>>> s=socket(AF_INET,SOCK_STREAM)
>>> type(s) is SocketType
False (or 0)

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-08-22 13:26

Message:
Logged In: YES 
user_id=31435

I'm sure it's Bill Gates's fault, so reassigning it to Bill's uncle.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-08-22 13:09

Message:
Logged In: YES 
user_id=31392

This code works as expected on Linux, so it must be Tim's fault.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=598097&group_id=5470


From noreply@sourceforge.net  Thu Aug 22 18:31:51 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 22 Aug 2002 10:31:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-598097 ] SocketType is not type(socket)
Message-ID: <E17hvoF-0007gZ-00@usw-sf-web5.sourceforge.net>

Bugs item #598097, was opened at 2002-08-21 01:04
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=598097&group_id=5470

Category: Python Library
Group: Platform-specific
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: June Kim (juneaftn)
Assigned to: Guido van Rossum (gvanrossum)
Summary: SocketType is not type(socket)

Initial Comment:
Python 2.2.* and 2.3.a0 on win 32

>>> from socket import *
>>> s=socket(AF_INET,SOCK_STREAM)
>>> type(s) is SocketType
False (or 0)

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-22 13:31

Message:
Logged In: YES 
user_id=6380

Thanks for reporting. Fixed in CVS for Python 2.3.

I hope you can live with this being broken in Python 2.2*
(and all versions before).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-08-22 13:26

Message:
Logged In: YES 
user_id=31435

I'm sure it's Bill Gates's fault, so reassigning it to Bill's uncle.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-08-22 13:09

Message:
Logged In: YES 
user_id=31392

This code works as expected on Linux, so it must be Tim's fault.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=598097&group_id=5470


From noreply@sourceforge.net  Thu Aug 22 21:44:55 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 22 Aug 2002 13:44:55 -0700
Subject: [Python-bugs-list] [ python-Bugs-598981 ] Python not handling cText
Message-ID: <E17hyp5-00052i-00@usw-sf-web2.sourceforge.net>

Bugs item #598981, was opened at 2002-08-22 13:44
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=598981&group_id=5470

Category: Macintosh
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Robin Siebler (robinsiebler)
Assigned to: Jack Jansen (jackjansen)
Summary: Python not handling cText

Initial Comment:
I have the following AppleScript which I have also converted 
to Python:

tell application "CodeWarrior IDE"
    activate
    open file file1
    disassemble file file2
    set xText to (get text of document 1)
end tell

I had some difficulty converting the last command into 
Python, but the below should work (or so I have been told):

import CodeWarrior, time

cw = CodeWarrior.CodeWarrior(start=1)
time.sleep(5)
cw.activate()
cw.open(file1)
cw.disassemble_file(file2)
time.sleep(5)
xtext = app('CodeWarrior IDE').document[1].text

However, instead of the text that I expect, xtext is equal to 
'app('CodeWarrior IDE').document[1].text.all'

Bill Fancher looked at CodeWarrior and said that it is 
returning cText which is not being handled by Python.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=598981&group_id=5470


From noreply@sourceforge.net  Thu Aug 22 21:48:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 22 Aug 2002 13:48:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-598981 ] Python not handling cText
Message-ID: <E17hys7-000561-00@usw-sf-web2.sourceforge.net>

Bugs item #598981, was opened at 2002-08-22 13:44
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=598981&group_id=5470

Category: Macintosh
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Robin Siebler (robinsiebler)
Assigned to: Jack Jansen (jackjansen)
Summary: Python not handling cText

Initial Comment:
I have the following AppleScript which I have also converted 
to Python:

tell application "CodeWarrior IDE"
    activate
    open file file1
    disassemble file file2
    set xText to (get text of document 1)
end tell

I had some difficulty converting the last command into 
Python, but the below should work (or so I have been told):

import CodeWarrior, time

cw = CodeWarrior.CodeWarrior(start=1)
time.sleep(5)
cw.activate()
cw.open(file1)
cw.disassemble_file(file2)
time.sleep(5)
xtext = app('CodeWarrior IDE').document[1].text

However, instead of the text that I expect, xtext is equal to 
'app('CodeWarrior IDE').document[1].text.all'

Bill Fancher looked at CodeWarrior and said that it is 
returning cText which is not being handled by Python.

----------------------------------------------------------------------

>Comment By: Robin Siebler (robinsiebler)
Date: 2002-08-22 13:48

Message:
Logged In: YES 
user_id=572605

I made a typo:
    xtext = app('CodeWarrior IDE').document[1].text 
should be:
    xtext = cw.get(CodeWarrior.text(CodeWarrior.document(1)))


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=598981&group_id=5470


From noreply@sourceforge.net  Thu Aug 22 22:04:54 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 22 Aug 2002 14:04:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-596434 ] textwrap has problems wrapping hyphens
Message-ID: <E17hz8Q-0005dc-00@usw-sf-web4.sourceforge.net>

Bugs item #596434, was opened at 2002-08-17 10:46
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=596434&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: David Goodger (goodger)
Assigned to: Greg Ward (gward)
Summary: textwrap has problems wrapping hyphens

Initial Comment:
(Greg already knows about this from private mail; 
this makes it "official".)

Long multi-word command-line options (begin 
with "--" and contain internal "-") inside text may be 
wrapped badly by textwrap.  For example, "--an-
option" may become "--\nan-option" or "--an-\
noption".  Perhaps words that begin with hyphens 
should not be wrapped at all?

----------------------------------------------------------------------

>Comment By: Greg Ward (gward)
Date: 2002-08-22 17:04

Message:
Logged In: YES 
user_id=14422

Thanks for the reminder, David!

Fixed in Lib/textwrap.py rev 1.14.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=596434&group_id=5470


From noreply@sourceforge.net  Fri Aug 23 09:26:13 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 23 Aug 2002 01:26:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-599128 ] .replace() bug when subclassing unicode
Message-ID: <E17i9ll-0007Kw-00@usw-sf-web2.sourceforge.net>

Bugs item #599128, was opened at 2002-08-23 08:26
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599128&group_id=5470

Category: Unicode
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Inyeol Lee (inyeol)
Assigned to: M.-A. Lemburg (lemburg)
Summary: .replace() bug when subclassing unicode

Initial Comment:
Python 2.2.1 (#1, Apr 10 2002, 18:25:16) 
[GCC 2.95.3 20010315 (release)] on sunos5

>>> class U(unicode): pass
>>> U(u'abc').replace('ab', '__', 0)
u'__c'

-Inyeol Lee

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599128&group_id=5470


From noreply@sourceforge.net  Fri Aug 23 09:27:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 23 Aug 2002 01:27:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-599128 ] .replace() bug when subclassing unicode
Message-ID: <E17i9mY-0007Lm-00@usw-sf-web2.sourceforge.net>

Bugs item #599128, was opened at 2002-08-23 08:26
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599128&group_id=5470

Category: Unicode
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Inyeol Lee (inyeol)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: .replace() bug when subclassing unicode

Initial Comment:
Python 2.2.1 (#1, Apr 10 2002, 18:25:16) 
[GCC 2.95.3 20010315 (release)] on sunos5

>>> class U(unicode): pass
>>> U(u'abc').replace('ab', '__', 0)
u'__c'

-Inyeol Lee

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599128&group_id=5470


From noreply@sourceforge.net  Fri Aug 23 10:39:13 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 23 Aug 2002 02:39:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-597919 ] compiler package and SET_LINENO
Message-ID: <E17iAuP-0000dy-00@usw-sf-web5.sourceforge.net>

Bugs item #597919, was opened at 2002-08-20 19:51
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=597919&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Jeremy Hylton (jhylton)
Summary: compiler package and SET_LINENO

Initial Comment:
The compiler package should not issue SET_LINENO
instructions any more.  Running the Zope 2.7 test suite
produces this traceback:

Traceback (most recent call last):
  File "test.py", line 433, in ?
    process_args()
  File "test.py", line 397, in process_args
    bad = main(module_filter, test_filter)
  File "test.py", line 308, in main
    runner(files, test_filter, debug)
  File "test.py", line 275, in runner
    s = get_suite(file)
  File "test.py", line 230, in get_suite
    mod = package_import(modname)
  File "test.py", line 211, in package_import
    mod = __import__(modname)
  File
"/home/fdrake/projects/Zope/Zope2.7/lib/python/RestrictedPython/tests/testRestrictions.py",
line 64, in ?
    create_rmodule()
  File
"/home/fdrake/projects/Zope/Zope2.7/lib/python/RestrictedPython/tests/testRestrictions.py",
line 55, in create_rmodule
    code = compile_restricted(source, fn, 'exec')
  File
"/home/fdrake/projects/Zope/Zope2.7/lib/python/RestrictedPython/RCompile.py",
line 147, in compile_restricted
    gen.compile()
  File
"/usr/local/lib/python2.3/compiler/pycodegen.py", line
123, in compile
    self.code = gen.getCode()
  File
"/usr/local/lib/python2.3/compiler/pycodegen.py", line
252, in getCode
    return self.graph.getCode()
  File "/usr/local/lib/python2.3/compiler/pyassem.py",
line 378, in getCode
    self.convertArgs()
  File "/usr/local/lib/python2.3/compiler/pyassem.py",
line 484, in convertArgs
    self.insts[i] = opname, conv(self, oparg)
  File "/usr/local/lib/python2.3/compiler/pyassem.py",
line 520, in _convert_LOAD_CONST
    arg = arg.getCode()
  File
"/usr/local/lib/python2.3/compiler/pycodegen.py", line
252, in getCode
    return self.graph.getCode()
  File "/usr/local/lib/python2.3/compiler/pyassem.py",
line 380, in getCode
    self.makeByteCode()
  File "/usr/local/lib/python2.3/compiler/pyassem.py",
line 585, in makeByteCode   
lnotab.addCode(self.opnum[opname], lo, hi)
KeyError: SET_LINENO


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-08-23 09:39

Message:
Logged In: YES 
user_id=6656

Believe it or not, I'd actually got that far myself <wink>.

If it'd been that easy, the changes would have been part of
my original SET_LINENO removal patch.

I guess the first question to answer is where does the
lnotab live during compilation?  In the CodeGenerator?  Then
logic has to move from PyFlowGraph.makeByteCode to
CodeGenerator.set_lineno.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-08-22 16:39

Message:
Logged In: YES 
user_id=31392

A grep for SET_LINENO in the compiler package source will be
somewhat helpful.  There are very few places that actually
emit the instructions.  I thought they could just be
removed, but the lnotab is generated *from* the SET_LINENO
instructions.  So we need to come up with a different way to
generate the lnotab.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-08-21 09:08

Message:
Logged In: YES 
user_id=6656

This is my fault, obviously.

I'm prepared to do some legwork to fix this problem, but don't really understand the code well enough to judge the best approach.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=597919&group_id=5470


From noreply@sourceforge.net  Fri Aug 23 11:06:56 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 23 Aug 2002 03:06:56 -0700
Subject: [Python-bugs-list] [ python-Bugs-595350 ] string method bugs w/ 8bit, unicode args
Message-ID: <E17iBLE-0000GQ-00@usw-sf-web2.sourceforge.net>

Bugs item #595350, was opened at 2002-08-15 01:56
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595350&group_id=5470

Category: Unicode
Group: Python 2.3
Status: Open
Resolution: Rejected
Priority: 5
Submitted By: Inyeol Lee (inyeol)
Assigned to: Guido van Rossum (gvanrossum)
Summary: string method bugs w/ 8bit, unicode args

Initial Comment:
Python 2.2.1 (#1, Apr 10 2002, 18:25:16) 
[GCC 2.95.3 20010315 (release)] on sunos5

1. "abc".endswith("c") ->1
   "abc".endswith(u"c") -> 0 # bug.
   u"abc".endswith("c") -> 1
   u"abc".endswith(u"c") -> 1

2. "aaa".rfind("a") -> 2
   "aaa".rfind(u"a") -> 0 # bug.
   u"aaa".rfind("a") -> 2
   u"aaa".rfind(u"a") -> 2

   .rindex() has the same bug.

3. "abc".rfind("") -> 3
   "abc".rfind(u"") -> 0 # bug.
   u"abc".rfind("") -> 0 # bug.
   u"abc".rfind(u"") -> 0 # bug.

   .rindex() has the same bug.

4. "abc".replace("", "x") -> ValueError
   "abc".replace(u"", "x") -> u'abcxxxx' # bug.
   u"abc".replace("", "x") -> u'abcxxxx' # bug.
   u"abc".replace(u"", "x") -> u'abcxxxx' # bug.

   They should raise ValueError, or return u'xaxbxcx'.
   BTW, how about changing s.replace("") behavior to
return
   "xaxbxcx" (or u"xaxbxcx") for all 4 cases? It is
consistent
   with other string methods and re.sub() method.
   It seems that Guido doesn't mind changing this.

[Guido]
> If someone really wants 'abc'.replace('', '-') to
return '-a-b-c-',
> please submit patches for both 8-bit and Unicode
strings to
> SourceForge and assign to me.  I looked into this and
it's
> non-trivial: the implementation used for 8-bit
strings goes into an
> infinite loop when the pattern is empty, and the
Unicode
> implementation tacks '----' onto the end.  Please
supply doc and
> unittest patches too.  At least re does the right
thing already:

5. (it's not a bug)
   Except for .replace() above, s.split() is the only
string method
   which raises exception. How about changing this to
return
   unmodified string when empty string  is given as a
separator?
   This is consistent with re.split() behavior.

- Inyeol Lee

----------------------------------------------------------------------

>Comment By: Inyeol Lee (inyeol)
Date: 2002-08-23 10:06

Message:
Logged In: YES 
user_id=595280

bug fixed.

I think we don't need to update .replace() documentation.
I checked latest doc on string methods, such as .count() or
.find(),
still there's no coment on empty string behavior for other
methods.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-22 15:52

Message:
Logged In: YES 
user_id=6380

Hrm. You uploaded a gzipped tarball containing 5 separate
context diff files; and these were reverse diffs (created by
doing "diff -c new old). I prefer a single file containing
multiple forward context diffs. I've uploaded your patch in
the form that I'd like to see (taken relative to current CVS).

But there's a worse problem: your code contains a bug.
Consider this example:

u'abc'.replace('', '-', 0)

This correctly returns u'abc'.

Bot now try this:

class U(unicode): pass
U(u'abc').replace('', '-', 0)

This returns u'-ab' !!!

Please fix this.

I'm also still waiting for a  documentation update.

----------------------------------------------------------------------

Comment By: Inyeol Lee (inyeol)
Date: 2002-08-20 23:54

Message:
Logged In: YES 
user_id=595280

s.replace() patched, unittest updated from current CVS.
Tested with 2.2.1, but it should work fine with 2.3a, since
the codes
affected by this patch didn't changed since 2.2.1.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-20 17:33

Message:
Logged In: YES 
user_id=6380

Note: I've now applied your fixes for endswith and rfind
c.s. to Python 2.2 and 2.3.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-20 16:35

Message:
Logged In: YES 
user_id=6380

I'm rejecting this patch.

The fixes for endswith(), rfind() and rindex() are already
in 2.3; these should be backported to 2.2 and I may use your
code for them.

I can't accept the new feature for replace() until you also
have a working patch for Unicode; I'm only +0 on this so I'm
not going to spend more time getting it right. Feel free to
submit a patch for *just* that here.

I don't want to accept the new feature for split(), because
I disagree that 'abc'.split('') should return ['abc']; if
anything, it should return ['', 'a', 'b', 'c', ''], but one
can argue about this and I think the ValueError is better.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-19 22:08

Message:
Logged In: YES 
user_id=6380

I'm still reviewing this.

Next time, please send context diffs; diffs relative to
current (or at least fairly recent :-) CVS would also be
appreciated.

Don't add the bug number in comments for each change; I will
have to remove all those manually now...

I'm uploading a version patch that applies cleanly to
current CVS; it's not ready yet (the Unicode tests fail and
I have to clean up the comments).

Backporting will be a bitch, because I don't want the
changes for x.replace('', ...) to be backported (new
functionality etc.).

----------------------------------------------------------------------

Comment By: Inyeol Lee (inyeol)
Date: 2002-08-16 17:45

Message:
Logged In: YES 
user_id=595280

uploaded patch for these bugs.  -Inyeol Lee

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595350&group_id=5470


From noreply@sourceforge.net  Fri Aug 23 11:07:56 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 23 Aug 2002 03:07:56 -0700
Subject: [Python-bugs-list] [ python-Bugs-599128 ] .replace() bug when subclassing unicode
Message-ID: <E17iBMC-0004AR-00@usw-sf-web1.sourceforge.net>

Bugs item #599128, was opened at 2002-08-23 08:26
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599128&group_id=5470

Category: Unicode
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Inyeol Lee (inyeol)
>Assigned to: M.-A. Lemburg (lemburg)
Summary: .replace() bug when subclassing unicode

Initial Comment:
Python 2.2.1 (#1, Apr 10 2002, 18:25:16) 
[GCC 2.95.3 20010315 (release)] on sunos5

>>> class U(unicode): pass
>>> U(u'abc').replace('ab', '__', 0)
u'__c'

-Inyeol Lee

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599128&group_id=5470


From noreply@sourceforge.net  Fri Aug 23 11:16:18 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 23 Aug 2002 03:16:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-599163 ] execfile() not show filename when IOErro
Message-ID: <E17iBUI-0002ZU-00@usw-sf-web3.sourceforge.net>

Bugs item #599163, was opened at 2002-08-23 10:16
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599163&group_id=5470

Category: Python Library
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Inyeol Lee (inyeol)
Assigned to: Nobody/Anonymous (nobody)
Summary: execfile() not show filename when IOErro

Initial Comment:
Python 2.2.1 (#1, Apr 10 2002, 18:25:16) 
[GCC 2.95.3 20010315 (release)] on sunos5
>>> try: execfile('non_existent_file')
... except IOError, msg: msg.__dict__

{'errno': 2, 'args': (2, 'No such file or directory'),
'strerror': 'No such file or directory', 'filename':
None}

There should be a filename, not None.

-Inyeol Lee 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599163&group_id=5470


From noreply@sourceforge.net  Fri Aug 23 15:01:04 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 23 Aug 2002 07:01:04 -0700
Subject: [Python-bugs-list] [ python-Bugs-599248 ] ext module generation problem
Message-ID: <E17iEzo-00059a-00@usw-sf-web4.sourceforge.net>

Bugs item #599248, was opened at 2002-08-23 10:01
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599248&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Stefan Seefeld (stefan)
Assigned to: Nobody/Anonymous (nobody)
Summary: ext module generation problem

Initial Comment:
when compiling an extension module, the source file
location
is not mirrored into the object file location, i.e.
subdirectories
are ignored (foo/bar/baz.c is compiled to baz.o, not
foo/bar/baz.o)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599248&group_id=5470


From noreply@sourceforge.net  Fri Aug 23 15:19:06 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 23 Aug 2002 07:19:06 -0700
Subject: [Python-bugs-list] [ python-Bugs-599254 ] Py_SAFE_DOWNCAST assert in marshal.c
Message-ID: <E17iFHG-0005Rt-00@usw-sf-web4.sourceforge.net>

Bugs item #599254, was opened at 2002-08-23 14:19
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599254&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: John Ehresman (jpe)
Assigned to: Nobody/Anonymous (nobody)
Summary: Py_SAFE_DOWNCAST assert in marshal.c

Initial Comment:
In a win32 debug build (compiled with VC++ 6.0) of
Python 2.2.0 using the default options, the
Py_SAFE_DOWNCAST assertion check fails on line 64 of
marshal.c when c is 0x8c.  The VC++ quick watch window
displays 0xffffff8c as the value of the expression
'(int)(char)c'.  The following code will trigger the
assertion:

import marshal
marshal.dumps([0x8c] * 1000)

I am downloading the latest VC++ service pack now to
see if that makes a difference.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599254&group_id=5470


From noreply@sourceforge.net  Fri Aug 23 15:24:25 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 23 Aug 2002 07:24:25 -0700
Subject: [Python-bugs-list] [ python-Bugs-599254 ] Py_SAFE_DOWNCAST assert in marshal.c
Message-ID: <E17iFMP-0005Zz-00@usw-sf-web4.sourceforge.net>

Bugs item #599254, was opened at 2002-08-23 14:19
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599254&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: John Ehresman (jpe)
>Assigned to: Michael Hudson (mwh)
Summary: Py_SAFE_DOWNCAST assert in marshal.c

Initial Comment:
In a win32 debug build (compiled with VC++ 6.0) of
Python 2.2.0 using the default options, the
Py_SAFE_DOWNCAST assertion check fails on line 64 of
marshal.c when c is 0x8c.  The VC++ quick watch window
displays 0xffffff8c as the value of the expression
'(int)(char)c'.  The following code will trigger the
assertion:

import marshal
marshal.dumps([0x8c] * 1000)

I am downloading the latest VC++ service pack now to
see if that makes a difference.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-08-23 14:24

Message:
Logged In: YES 
user_id=6656

Unless I'm much mistaken, this is a dup of:

[ 588452 ] $DEBUG_PYTHON -O freeze.py broken

which was fixed just a few weeks ago.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599254&group_id=5470


From noreply@sourceforge.net  Fri Aug 23 15:29:58 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 23 Aug 2002 07:29:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-599254 ] Py_SAFE_DOWNCAST assert in marshal.c
Message-ID: <E17iFRm-0007ON-00@usw-sf-web3.sourceforge.net>

Bugs item #599254, was opened at 2002-08-23 10:19
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599254&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
Status: Closed
Resolution: Duplicate
Priority: 5
Submitted By: John Ehresman (jpe)
Assigned to: Michael Hudson (mwh)
Summary: Py_SAFE_DOWNCAST assert in marshal.c

Initial Comment:
In a win32 debug build (compiled with VC++ 6.0) of
Python 2.2.0 using the default options, the
Py_SAFE_DOWNCAST assertion check fails on line 64 of
marshal.c when c is 0x8c.  The VC++ quick watch window
displays 0xffffff8c as the value of the expression
'(int)(char)c'.  The following code will trigger the
assertion:

import marshal
marshal.dumps([0x8c] * 1000)

I am downloading the latest VC++ service pack now to
see if that makes a difference.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-08-23 10:29

Message:
Logged In: YES 
user_id=31435

Yes, it's a duplicate, fixed in current CVS.  IIRC, nobody 
has backported the fix to the 2.2 line.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-08-23 10:24

Message:
Logged In: YES 
user_id=6656

Unless I'm much mistaken, this is a dup of:

[ 588452 ] $DEBUG_PYTHON -O freeze.py broken

which was fixed just a few weeks ago.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599254&group_id=5470


From noreply@sourceforge.net  Fri Aug 23 15:33:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 23 Aug 2002 07:33:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-599254 ] Py_SAFE_DOWNCAST assert in marshal.c
Message-ID: <E17iFVE-0007Tj-00@usw-sf-web3.sourceforge.net>

Bugs item #599254, was opened at 2002-08-23 14:19
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599254&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
Status: Closed
Resolution: Duplicate
Priority: 5
Submitted By: John Ehresman (jpe)
Assigned to: Michael Hudson (mwh)
Summary: Py_SAFE_DOWNCAST assert in marshal.c

Initial Comment:
In a win32 debug build (compiled with VC++ 6.0) of
Python 2.2.0 using the default options, the
Py_SAFE_DOWNCAST assertion check fails on line 64 of
marshal.c when c is 0x8c.  The VC++ quick watch window
displays 0xffffff8c as the value of the expression
'(int)(char)c'.  The following code will trigger the
assertion:

import marshal
marshal.dumps([0x8c] * 1000)

I am downloading the latest VC++ service pack now to
see if that makes a difference.

----------------------------------------------------------------------

>Comment By: John Ehresman (jpe)
Date: 2002-08-23 14:33

Message:
Logged In: YES 
user_id=22785

Thanks.  It is a duplicate.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-08-23 14:29

Message:
Logged In: YES 
user_id=31435

Yes, it's a duplicate, fixed in current CVS.  IIRC, nobody 
has backported the fix to the 2.2 line.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-08-23 14:24

Message:
Logged In: YES 
user_id=6656

Unless I'm much mistaken, this is a dup of:

[ 588452 ] $DEBUG_PYTHON -O freeze.py broken

which was fixed just a few weeks ago.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599254&group_id=5470


From noreply@sourceforge.net  Fri Aug 23 16:17:17 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 23 Aug 2002 08:17:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-599254 ] Py_SAFE_DOWNCAST assert in marshal.c
Message-ID: <E17iGBZ-0006Lg-00@usw-sf-web2.sourceforge.net>

Bugs item #599254, was opened at 2002-08-23 16:19
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599254&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
Status: Closed
Resolution: Duplicate
Priority: 5
Submitted By: John Ehresman (jpe)
Assigned to: Michael Hudson (mwh)
Summary: Py_SAFE_DOWNCAST assert in marshal.c

Initial Comment:
In a win32 debug build (compiled with VC++ 6.0) of
Python 2.2.0 using the default options, the
Py_SAFE_DOWNCAST assertion check fails on line 64 of
marshal.c when c is 0x8c.  The VC++ quick watch window
displays 0xffffff8c as the value of the expression
'(int)(char)c'.  The following code will trigger the
assertion:

import marshal
marshal.dumps([0x8c] * 1000)

I am downloading the latest VC++ service pack now to
see if that makes a difference.

----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2002-08-23 17:17

Message:
Logged In: YES 
user_id=11105

To Tim: I've marked it as bugfix candidate in the checkin 
message. Isn't this enough?

"""
Fix SF 588452: debug build crashes on marshal.dumps([128] 
* 1000).
See there for a description.

Added test case.

Bugfix candidate for 2.2.x, not sure about previous versions:
probably low priority, because virtually no one runs debug 
builds.
"""

----------------------------------------------------------------------

Comment By: John Ehresman (jpe)
Date: 2002-08-23 16:33

Message:
Logged In: YES 
user_id=22785

Thanks.  It is a duplicate.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-08-23 16:29

Message:
Logged In: YES 
user_id=31435

Yes, it's a duplicate, fixed in current CVS.  IIRC, nobody 
has backported the fix to the 2.2 line.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-08-23 16:24

Message:
Logged In: YES 
user_id=6656

Unless I'm much mistaken, this is a dup of:

[ 588452 ] $DEBUG_PYTHON -O freeze.py broken

which was fixed just a few weeks ago.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599254&group_id=5470


From noreply@sourceforge.net  Fri Aug 23 16:23:31 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 23 Aug 2002 08:23:31 -0700
Subject: [Python-bugs-list] [ python-Bugs-599254 ] Py_SAFE_DOWNCAST assert in marshal.c
Message-ID: <E17iGHb-0006WI-00@usw-sf-web2.sourceforge.net>

Bugs item #599254, was opened at 2002-08-23 10:19
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599254&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
Status: Closed
Resolution: Duplicate
Priority: 5
Submitted By: John Ehresman (jpe)
Assigned to: Michael Hudson (mwh)
Summary: Py_SAFE_DOWNCAST assert in marshal.c

Initial Comment:
In a win32 debug build (compiled with VC++ 6.0) of
Python 2.2.0 using the default options, the
Py_SAFE_DOWNCAST assertion check fails on line 64 of
marshal.c when c is 0x8c.  The VC++ quick watch window
displays 0xffffff8c as the value of the expression
'(int)(char)c'.  The following code will trigger the
assertion:

import marshal
marshal.dumps([0x8c] * 1000)

I am downloading the latest VC++ service pack now to
see if that makes a difference.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-08-23 11:23

Message:
Logged In: YES 
user_id=31435

Thomas, yes, that's fine!  I wasn't accusing <wink>, just 
trying to tell the OP the current status.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2002-08-23 11:17

Message:
Logged In: YES 
user_id=11105

To Tim: I've marked it as bugfix candidate in the checkin 
message. Isn't this enough?

"""
Fix SF 588452: debug build crashes on marshal.dumps([128] 
* 1000).
See there for a description.

Added test case.

Bugfix candidate for 2.2.x, not sure about previous versions:
probably low priority, because virtually no one runs debug 
builds.
"""

----------------------------------------------------------------------

Comment By: John Ehresman (jpe)
Date: 2002-08-23 10:33

Message:
Logged In: YES 
user_id=22785

Thanks.  It is a duplicate.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-08-23 10:29

Message:
Logged In: YES 
user_id=31435

Yes, it's a duplicate, fixed in current CVS.  IIRC, nobody 
has backported the fix to the 2.2 line.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-08-23 10:24

Message:
Logged In: YES 
user_id=6656

Unless I'm much mistaken, this is a dup of:

[ 588452 ] $DEBUG_PYTHON -O freeze.py broken

which was fixed just a few weeks ago.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599254&group_id=5470


From noreply@sourceforge.net  Fri Aug 23 16:25:55 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 23 Aug 2002 08:25:55 -0700
Subject: [Python-bugs-list] [ python-Bugs-599254 ] Py_SAFE_DOWNCAST assert in marshal.c
Message-ID: <E17iGJv-0006ar-00@usw-sf-web2.sourceforge.net>

Bugs item #599254, was opened at 2002-08-23 16:19
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599254&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
Status: Closed
Resolution: Duplicate
Priority: 5
Submitted By: John Ehresman (jpe)
Assigned to: Michael Hudson (mwh)
Summary: Py_SAFE_DOWNCAST assert in marshal.c

Initial Comment:
In a win32 debug build (compiled with VC++ 6.0) of
Python 2.2.0 using the default options, the
Py_SAFE_DOWNCAST assertion check fails on line 64 of
marshal.c when c is 0x8c.  The VC++ quick watch window
displays 0xffffff8c as the value of the expression
'(int)(char)c'.  The following code will trigger the
assertion:

import marshal
marshal.dumps([0x8c] * 1000)

I am downloading the latest VC++ service pack now to
see if that makes a difference.

----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2002-08-23 17:25

Message:
Logged In: YES 
user_id=11105

Great. Sorry for the misunderstanding.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-08-23 17:23

Message:
Logged In: YES 
user_id=31435

Thomas, yes, that's fine!  I wasn't accusing <wink>, just 
trying to tell the OP the current status.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2002-08-23 17:17

Message:
Logged In: YES 
user_id=11105

To Tim: I've marked it as bugfix candidate in the checkin 
message. Isn't this enough?

"""
Fix SF 588452: debug build crashes on marshal.dumps([128] 
* 1000).
See there for a description.

Added test case.

Bugfix candidate for 2.2.x, not sure about previous versions:
probably low priority, because virtually no one runs debug 
builds.
"""

----------------------------------------------------------------------

Comment By: John Ehresman (jpe)
Date: 2002-08-23 16:33

Message:
Logged In: YES 
user_id=22785

Thanks.  It is a duplicate.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-08-23 16:29

Message:
Logged In: YES 
user_id=31435

Yes, it's a duplicate, fixed in current CVS.  IIRC, nobody 
has backported the fix to the 2.2 line.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-08-23 16:24

Message:
Logged In: YES 
user_id=6656

Unless I'm much mistaken, this is a dup of:

[ 588452 ] $DEBUG_PYTHON -O freeze.py broken

which was fixed just a few weeks ago.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599254&group_id=5470


From noreply@sourceforge.net  Fri Aug 23 16:43:07 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 23 Aug 2002 08:43:07 -0700
Subject: [Python-bugs-list] [ python-Bugs-599294 ] randrange overflow
Message-ID: <E17iGaZ-0000SE-00@usw-sf-web3.sourceforge.net>

Bugs item #599294, was opened at 2002-08-23 10:43
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599294&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Vadim Suvorov (xxx-bad)
Assigned to: Nobody/Anonymous (nobody)
Summary: randrange overflow

Initial Comment:
random.randrange causes overflow if range size is 
bigger than maximum integer:

~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> randrange(-0x7fffffff, 0x7fffffff)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "...\Python22\lib\random.py", line 299, in 
randrange
    return istart + int(self.random() *
OverflowError: float too large to convert
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

versions: Python 2.2, 2.2.1

The suggested change is to include 'istart' before 
conversion to 'int', thus normalizing intermediate 
result:

return int(istart + self.random() * (istop - istart))

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599294&group_id=5470


From noreply@sourceforge.net  Fri Aug 23 17:44:51 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 23 Aug 2002 09:44:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-599294 ] randrange overflow
Message-ID: <E17iHYJ-0001z4-00@usw-sf-web3.sourceforge.net>

Bugs item #599294, was opened at 2002-08-23 11:43
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599294&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Vadim Suvorov (xxx-bad)
>Assigned to: Tim Peters (tim_one)
Summary: randrange overflow

Initial Comment:
random.randrange causes overflow if range size is 
bigger than maximum integer:

~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> randrange(-0x7fffffff, 0x7fffffff)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "...\Python22\lib\random.py", line 299, in 
randrange
    return istart + int(self.random() *
OverflowError: float too large to convert
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

versions: Python 2.2, 2.2.1

The suggested change is to include 'istart' before 
conversion to 'int', thus normalizing intermediate 
result:

return int(istart + self.random() * (istop - istart))

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-08-23 12:44

Message:
Logged In: YES 
user_id=31435

Closed as Duplicate; see bug report 594996.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599294&group_id=5470


From noreply@sourceforge.net  Fri Aug 23 19:22:18 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 23 Aug 2002 11:22:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-595350 ] string method bugs w/ 8bit, unicode args
Message-ID: <E17iJ4c-0002RS-00@usw-sf-web2.sourceforge.net>

Bugs item #595350, was opened at 2002-08-14 21:56
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595350&group_id=5470

Category: Unicode
Group: Python 2.3
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Inyeol Lee (inyeol)
Assigned to: Guido van Rossum (gvanrossum)
Summary: string method bugs w/ 8bit, unicode args

Initial Comment:
Python 2.2.1 (#1, Apr 10 2002, 18:25:16) 
[GCC 2.95.3 20010315 (release)] on sunos5

1. "abc".endswith("c") ->1
   "abc".endswith(u"c") -> 0 # bug.
   u"abc".endswith("c") -> 1
   u"abc".endswith(u"c") -> 1

2. "aaa".rfind("a") -> 2
   "aaa".rfind(u"a") -> 0 # bug.
   u"aaa".rfind("a") -> 2
   u"aaa".rfind(u"a") -> 2

   .rindex() has the same bug.

3. "abc".rfind("") -> 3
   "abc".rfind(u"") -> 0 # bug.
   u"abc".rfind("") -> 0 # bug.
   u"abc".rfind(u"") -> 0 # bug.

   .rindex() has the same bug.

4. "abc".replace("", "x") -> ValueError
   "abc".replace(u"", "x") -> u'abcxxxx' # bug.
   u"abc".replace("", "x") -> u'abcxxxx' # bug.
   u"abc".replace(u"", "x") -> u'abcxxxx' # bug.

   They should raise ValueError, or return u'xaxbxcx'.
   BTW, how about changing s.replace("") behavior to
return
   "xaxbxcx" (or u"xaxbxcx") for all 4 cases? It is
consistent
   with other string methods and re.sub() method.
   It seems that Guido doesn't mind changing this.

[Guido]
> If someone really wants 'abc'.replace('', '-') to
return '-a-b-c-',
> please submit patches for both 8-bit and Unicode
strings to
> SourceForge and assign to me.  I looked into this and
it's
> non-trivial: the implementation used for 8-bit
strings goes into an
> infinite loop when the pattern is empty, and the
Unicode
> implementation tacks '----' onto the end.  Please
supply doc and
> unittest patches too.  At least re does the right
thing already:

5. (it's not a bug)
   Except for .replace() above, s.split() is the only
string method
   which raises exception. How about changing this to
return
   unmodified string when empty string  is given as a
separator?
   This is consistent with re.split() behavior.

- Inyeol Lee

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-23 14:22

Message:
Logged In: YES 
user_id=6380

Thanks for the fix, I've checked this in now.

I'll update the docs because I want it to be explicit about
this (and so we can say this is a new feature in 2.3).

----------------------------------------------------------------------

Comment By: Inyeol Lee (inyeol)
Date: 2002-08-23 06:06

Message:
Logged In: YES 
user_id=595280

bug fixed.

I think we don't need to update .replace() documentation.
I checked latest doc on string methods, such as .count() or
.find(),
still there's no coment on empty string behavior for other
methods.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-22 11:52

Message:
Logged In: YES 
user_id=6380

Hrm. You uploaded a gzipped tarball containing 5 separate
context diff files; and these were reverse diffs (created by
doing "diff -c new old). I prefer a single file containing
multiple forward context diffs. I've uploaded your patch in
the form that I'd like to see (taken relative to current CVS).

But there's a worse problem: your code contains a bug.
Consider this example:

u'abc'.replace('', '-', 0)

This correctly returns u'abc'.

Bot now try this:

class U(unicode): pass
U(u'abc').replace('', '-', 0)

This returns u'-ab' !!!

Please fix this.

I'm also still waiting for a  documentation update.

----------------------------------------------------------------------

Comment By: Inyeol Lee (inyeol)
Date: 2002-08-20 19:54

Message:
Logged In: YES 
user_id=595280

s.replace() patched, unittest updated from current CVS.
Tested with 2.2.1, but it should work fine with 2.3a, since
the codes
affected by this patch didn't changed since 2.2.1.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-20 13:33

Message:
Logged In: YES 
user_id=6380

Note: I've now applied your fixes for endswith and rfind
c.s. to Python 2.2 and 2.3.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-20 12:35

Message:
Logged In: YES 
user_id=6380

I'm rejecting this patch.

The fixes for endswith(), rfind() and rindex() are already
in 2.3; these should be backported to 2.2 and I may use your
code for them.

I can't accept the new feature for replace() until you also
have a working patch for Unicode; I'm only +0 on this so I'm
not going to spend more time getting it right. Feel free to
submit a patch for *just* that here.

I don't want to accept the new feature for split(), because
I disagree that 'abc'.split('') should return ['abc']; if
anything, it should return ['', 'a', 'b', 'c', ''], but one
can argue about this and I think the ValueError is better.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-19 18:08

Message:
Logged In: YES 
user_id=6380

I'm still reviewing this.

Next time, please send context diffs; diffs relative to
current (or at least fairly recent :-) CVS would also be
appreciated.

Don't add the bug number in comments for each change; I will
have to remove all those manually now...

I'm uploading a version patch that applies cleanly to
current CVS; it's not ready yet (the Unicode tests fail and
I have to clean up the comments).

Backporting will be a bitch, because I don't want the
changes for x.replace('', ...) to be backported (new
functionality etc.).

----------------------------------------------------------------------

Comment By: Inyeol Lee (inyeol)
Date: 2002-08-16 13:45

Message:
Logged In: YES 
user_id=595280

uploaded patch for these bugs.  -Inyeol Lee

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595350&group_id=5470


From noreply@sourceforge.net  Fri Aug 23 19:50:39 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 23 Aug 2002 11:50:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-599128 ] .replace() bug when subclassing unicode
Message-ID: <E17iJW3-0004iW-00@usw-sf-web3.sourceforge.net>

Bugs item #599128, was opened at 2002-08-23 04:26
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599128&group_id=5470

Category: Unicode
Group: Python 2.2.1
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Inyeol Lee (inyeol)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: .replace() bug when subclassing unicode

Initial Comment:
Python 2.2.1 (#1, Apr 10 2002, 18:25:16) 
[GCC 2.95.3 20010315 (release)] on sunos5

>>> class U(unicode): pass
>>> U(u'abc').replace('ab', '__', 0)
u'__c'

-Inyeol Lee

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-23 14:50

Message:
Logged In: YES 
user_id=6380

Fixed in 2.3. Marked as bugfix candidate for 2.2.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599128&group_id=5470


From noreply@sourceforge.net  Fri Aug 23 20:16:04 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 23 Aug 2002 12:16:04 -0700
Subject: [Python-bugs-list] [ python-Bugs-599377 ] re searches don't work with 4-byte unico
Message-ID: <E17iJue-00057V-00@usw-sf-web3.sourceforge.net>

Bugs item #599377, was opened at 2002-08-23 19:16
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599377&group_id=5470

Category: Python Library
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Fulton (dcjim)
Assigned to: Nobody/Anonymous (nobody)
Summary: re searches don't work with 4-byte unico

Initial Comment:
For Python 2.2.1 or the CVS head, as of this posting, 
with Python configured for 4-byte unicode
(--enable-unicode=ucs4)
searches against unicode regular expressions that use 
characters above \xff don't seem to work.

Here's an example:

  invalid_xml_char = re.compile(u'[\ud800-\udfff]')
  invalid_xml_char.search(u'\ud800')

returns None, rather than a match.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599377&group_id=5470


From noreply@sourceforge.net  Fri Aug 23 20:25:31 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 23 Aug 2002 12:25:31 -0700
Subject: [Python-bugs-list] [ python-Bugs-599377 ] re searches don't work with 4-byte unico
Message-ID: <E17iK3n-0004uj-00@usw-sf-web5.sourceforge.net>

Bugs item #599377, was opened at 2002-08-23 15:16
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599377&group_id=5470

Category: Python Library
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Fulton (dcjim)
>Assigned to: Fredrik Lundh (effbot)
Summary: re searches don't work with 4-byte unico

Initial Comment:
For Python 2.2.1 or the CVS head, as of this posting, 
with Python configured for 4-byte unicode
(--enable-unicode=ucs4)
searches against unicode regular expressions that use 
characters above \xff don't seem to work.

Here's an example:

  invalid_xml_char = re.compile(u'[\ud800-\udfff]')
  invalid_xml_char.search(u'\ud800')

returns None, rather than a match.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599377&group_id=5470


From noreply@sourceforge.net  Fri Aug 23 20:26:37 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 23 Aug 2002 12:26:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-599248 ] ext module generation problem
Message-ID: <E17iK4r-0005KU-00@usw-sf-web3.sourceforge.net>

Bugs item #599248, was opened at 2002-08-23 10:01
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599248&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Stefan Seefeld (stefan)
Assigned to: Nobody/Anonymous (nobody)
Summary: ext module generation problem

Initial Comment:
when compiling an extension module, the source file
location
is not mirrored into the object file location, i.e.
subdirectories
are ignored (foo/bar/baz.c is compiled to baz.o, not
foo/bar/baz.o)

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-08-23 15:26

Message:
Logged In: YES 
user_id=3066

Why is this a problem?  Are you running into name clashes?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599248&group_id=5470


From noreply@sourceforge.net  Fri Aug 23 20:31:33 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 23 Aug 2002 12:31:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-599248 ] ext module generation problem
Message-ID: <E17iK9d-0000HO-00@usw-sf-web1.sourceforge.net>

Bugs item #599248, was opened at 2002-08-23 10:01
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599248&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Stefan Seefeld (stefan)
Assigned to: Nobody/Anonymous (nobody)
Summary: ext module generation problem

Initial Comment:
when compiling an extension module, the source file
location
is not mirrored into the object file location, i.e.
subdirectories
are ignored (foo/bar/baz.c is compiled to baz.o, not
foo/bar/baz.o)

----------------------------------------------------------------------

>Comment By: Stefan Seefeld (stefan)
Date: 2002-08-23 15:31

Message:
Logged In: YES 
user_id=764

precisely.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-08-23 15:26

Message:
Logged In: YES 
user_id=3066

Why is this a problem?  Are you running into name clashes?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599248&group_id=5470


From noreply@sourceforge.net  Sat Aug 24 00:00:48 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 23 Aug 2002 16:00:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-599452 ] Method resolution order in Py 2.2 - 2.3
Message-ID: <E17iNQ8-0005Sd-00@usw-sf-web4.sourceforge.net>

Bugs item #599452, was opened at 2002-08-24 03:00
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599452&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Alex A. Naanou (alex_nanou)
Assigned to: Nobody/Anonymous (nobody)
Summary: Method resolution order in Py 2.2 - 2.3

Initial Comment:
-- from "What's new in Python 2.2" 
      section 2.3 "Multiple Inheritance: The Diamond Rule"
"""
Multiple inheritance has also been made more useful 
through changing the rules under which names are 
resolved.
"""

Well, for a feature that was officially "introduced" in
version 2.2 it shows a remarkable lack of presence 
(even in the CVS versions of 2.3)!!
// though, I could have missed something (an elephant in
// my backyard!), if so please point it out...


Description:
Actually, there is nothing wrong... the function in 
question is just not changed since version 2.1.x, thus 
we get the old style lookup table (Method resolution 
order).
I'll try not to get too carried away.. here is an 
example 'almost' literally taken from that same section 
of the documentation mentioned above:

---cut---
class A:
    def save(self):
        return "I am 'A.save'"
class B(A):
    pass
class C(A):
    def save(self):
        return "I am 'C.save'"
class D(B,C):
    pass

print D().save()

---uncut---

Expected Results:
  something printed EXACTLY like:
>>> I am 'C.save'


Actual Result:
//here is the part where I faint...   :|
we get:
>>> I am 'A.save'


The results are identical for:
- Python 2.2
- Python 2.2.1
- Python 2.3 (CVS)


Thanks!!


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599452&group_id=5470


From noreply@sourceforge.net  Sat Aug 24 00:30:21 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 23 Aug 2002 16:30:21 -0700
Subject: [Python-bugs-list] [ python-Bugs-599452 ] Method resolution order in Py 2.2 - 2.3
Message-ID: <E17iNsj-0000mM-00@usw-sf-web3.sourceforge.net>

Bugs item #599452, was opened at 2002-08-23 23:00
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599452&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Alex A. Naanou (alex_nanou)
Assigned to: Nobody/Anonymous (nobody)
Summary: Method resolution order in Py 2.2 - 2.3

Initial Comment:
-- from "What's new in Python 2.2" 
      section 2.3 "Multiple Inheritance: The Diamond Rule"
"""
Multiple inheritance has also been made more useful 
through changing the rules under which names are 
resolved.
"""

Well, for a feature that was officially "introduced" in
version 2.2 it shows a remarkable lack of presence 
(even in the CVS versions of 2.3)!!
// though, I could have missed something (an elephant in
// my backyard!), if so please point it out...


Description:
Actually, there is nothing wrong... the function in 
question is just not changed since version 2.1.x, thus 
we get the old style lookup table (Method resolution 
order).
I'll try not to get too carried away.. here is an 
example 'almost' literally taken from that same section 
of the documentation mentioned above:

---cut---
class A:
    def save(self):
        return "I am 'A.save'"
class B(A):
    pass
class C(A):
    def save(self):
        return "I am 'C.save'"
class D(B,C):
    pass

print D().save()

---uncut---

Expected Results:
  something printed EXACTLY like:
>>> I am 'C.save'


Actual Result:
//here is the part where I faint...   :|
we get:
>>> I am 'A.save'


The results are identical for:
- Python 2.2
- Python 2.2.1
- Python 2.3 (CVS)


Thanks!!


----------------------------------------------------------------------

>Comment By: Neil Schemenauer (nascheme)
Date: 2002-08-23 23:30

Message:
Logged In: YES 
user_id=35752

You need to make 'A' subclass from 'object' in order to get
the new
MRO behavior.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599452&group_id=5470


From noreply@sourceforge.net  Sat Aug 24 18:24:59 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 24 Aug 2002 10:24:59 -0700
Subject: [Python-bugs-list] [ python-Bugs-599679 ] CRAM-MD5 module
Message-ID: <E17ieeh-0006G5-00@usw-sf-web1.sourceforge.net>

Bugs item #599679, was opened at 2002-08-24 17:24
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599679&group_id=5470

Category: Extension Modules
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: CRAM-MD5 module

Initial Comment:
[Taken from http://bugs.debian.org/154283]

A request to provide CRAM-MD5 authentification (in
imaplib).


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599679&group_id=5470


From noreply@sourceforge.net  Sat Aug 24 18:28:44 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 24 Aug 2002 10:28:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-599681 ] SocketServer wrong about allow_reuse_add
Message-ID: <E17ieiK-0006LX-00@usw-sf-web1.sourceforge.net>

Bugs item #599681, was opened at 2002-08-24 17:28
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599681&group_id=5470

Category: Documentation
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: SocketServer wrong about allow_reuse_add

Initial Comment:
the docs for SocketServer document:

 The server classes support the following class variables:

 allow_reuse_address
 Whether the server will allow the reuse of an address.
This defaults to
 true, and can be set in subclasses to change the policy. 

But clearly, it does not default to true:

poseidon:[/usr/lib] grep allow_reuse_address
python2.?/SocketServer.py
python2.1/SocketServer.py:    allow_reuse_address = 0
python2.1/SocketServer.py:        if
self.allow_reuse_address:
python2.1/SocketServer.py:    allow_reuse_address = 0
python2.2/SocketServer.py:    allow_reuse_address = 0
python2.2/SocketServer.py:        if
self.allow_reuse_address:
python2.2/SocketServer.py:    allow_reuse_address = 0



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599681&group_id=5470


From noreply@sourceforge.net  Sat Aug 24 23:14:57 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 24 Aug 2002 15:14:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-599757 ] sub[n] not working as expected.
Message-ID: <E17ijBJ-0003AL-00@usw-sf-web3.sourceforge.net>

Bugs item #599757, was opened at 2002-08-24 16:14
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599757&group_id=5470

Category: Regular Expressions
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Travis Shirk (nicfit)
Assigned to: Fredrik Lundh (effbot)
Summary: sub[n] not working as expected.

Initial Comment:
I'm running into what looks to be a bug in the python
2.2 re module.
These examples should demonstrate the problem.

Using Python 1.5.2:
import re;
data =
"\xFF\x00\xE0\xD3\xD3\xE4\x95\xFF\x00\x00\x11\xFF\x00\xF5"
data1 =
re.compile(r"\xFF\x00([\xE0-\xFF])").sub(r"\xFF\1", data);
print data1
'\377\340\323\323\344\225\377\000\000\021\377\365'


This output is exactly what I expect, but now see what
happens in 
2.2.1:
import re;
data =
"\xFF\x00\xE0\xD3\xD3\xE4\x95\xFF\x00\x00\x11\xFF\x00\xF5"
data1 =
re.compile(r"\xFF\x00([\xE0-\xFF])").sub(r"\xFF\1", data);
print data1
'\xFF\xe0\xd3\xd3\xe4\x95\xff\x00\x00\x11\xFF\xf5'

I like the hex output over the octal in 1.5, but the
substitution is
clearly wrong.  Notice each spot containing "\" in the
last result.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599757&group_id=5470


From noreply@sourceforge.net  Sun Aug 25 01:28:34 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 24 Aug 2002 17:28:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-577530 ] del __builtins__ breaks out of rexec
Message-ID: <E17ilGc-0004Yd-00@usw-sf-web3.sourceforge.net>

Bugs item #577530, was opened at 2002-07-04 21:01
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=577530&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 4
Submitted By: Eric Jacobs (ejums)
Assigned to: Guido van Rossum (gvanrossum)
Summary: del __builtins__ breaks out of rexec

Initial Comment:
Executing the statement "del __builtins__" in a
restricted execution environment (say, the test shell
in rexec.py) causes all restrictions to be bypassed.

This is caused by the fact that restriction policies
are implemented by having the "__builtins__" key in the
globals dictionary. It is a design error to implement
restriction policies with an object that can be
modified by the restricted code!

A temporary workaround would involve a modification to
rexec.py:

*** rexec.py	Sat Jun 22 22:57:46 2002
--- /home/eric/rexec.py	Tue Jul  2 16:08:03 2002
***************
*** 241,249 ****
      # Add a module -- return an existing module or
create one
  
      def add_module(self, mname):
!         if self.modules.has_key(mname):
!             return self.modules[mname]
!         self.modules[mname] = m =
self.hooks.new_module(mname)
          m.__builtins__ = self.modules['__builtin__']
          return m
  
--- 241,249 ----
      # Add a module -- return an existing module or
create one
  
      def add_module(self, mname):
!         if not self.modules.has_key(mname):
!             self.modules[mname] =
self.hooks.new_module(mname)
!         m = self.modules[mname]
          m.__builtins__ = self.modules['__builtin__']
          return m
  

However, the restriction execution feature is prone to
this sort of programming error by design, and it should
probably be fixed by having the builtins module be
specified explicitly when executing restricted code, so
that it doesn't accidentally fall back to the
unrestricted builtins inherited from the parent frame.


----------------------------------------------------------------------

Comment By: Samuele Pedroni (pedronis)
Date: 2002-08-25 02:28

Message:
Logged In: YES 
user_id=61408

In jython we don't even try to support rexec.

I have checked with 1.5.2 and the problem was already 
there, which probably means rexec is understressed and 
underused.

my two cts

OTOH "don't trust rexec" is not stated in the 
documentation, and if it is really that the message that 
should go out, then maybe it is better to just deprecate 
rexec.



----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-17 22:01

Message:
Logged In: YES 
user_id=6380

I find it hard to believe that putting __builtins__ back
once per r_exec() call would be sufficient.

What if someone wrote "del __builtins__; import socket" ?

Backporting to 2.1 sounds like giving people a false sense
of security. If there's a message to be gotten out, it is
"don't trust rexec". This fix doesn't make me more confident
but less (even if applied).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-17 18:14

Message:
Logged In: YES 
user_id=33168

I have tested the patch attached and it seems to work.  I
don't know if the approach is a good solution.  Guido, if
you think this is acceptable, assign to me and I'll fix it.
 Since this is a security problem should it be backported to
2.1?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=577530&group_id=5470


From noreply@sourceforge.net  Sun Aug 25 08:39:50 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 25 Aug 2002 00:39:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-599838 ] httplib.connect broken in 2.1 branch
Message-ID: <E17irzy-0003S2-00@usw-sf-web1.sourceforge.net>

Bugs item #599838, was opened at 2002-08-25 07:39
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599838&group_id=5470

Category: Python Library
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: httplib.connect broken in 2.1 branch

Initial Comment:
In the current 2.1 branch, httplib.connect uses
socket.getaddrinfo, which is not available in 2.1:

>>> urllib.connect()

  File "/usr/lib/python2.1/httplib.py", line 509, in
connect 
    for res in socket.getaddrinfo(self.host, self.port, 0, 
AttributeError: 'socket' module has no attribute
'getaddrinfo' 

Introduced in Revison 1.42.10.7 , Fri Jul 12 14:23:38
2002 UTC (6 weeks, 1 day ago) by jhylton 


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599838&group_id=5470


From noreply@sourceforge.net  Sun Aug 25 08:40:12 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 25 Aug 2002 00:40:12 -0700
Subject: [Python-bugs-list] [ python-Bugs-599838 ] httplib.connect broken in 2.1 branch
Message-ID: <E17is0K-0008Jh-00@usw-sf-web2.sourceforge.net>

Bugs item #599838, was opened at 2002-08-25 07:39
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599838&group_id=5470

Category: Python Library
Group: Python 2.1.2
Status: Open
Resolution: None
>Priority: 7
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: httplib.connect broken in 2.1 branch

Initial Comment:
In the current 2.1 branch, httplib.connect uses
socket.getaddrinfo, which is not available in 2.1:

>>> urllib.connect()

  File "/usr/lib/python2.1/httplib.py", line 509, in
connect 
    for res in socket.getaddrinfo(self.host, self.port, 0, 
AttributeError: 'socket' module has no attribute
'getaddrinfo' 

Introduced in Revison 1.42.10.7 , Fri Jul 12 14:23:38
2002 UTC (6 weeks, 1 day ago) by jhylton 


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599838&group_id=5470


From noreply@sourceforge.net  Sun Aug 25 11:04:57 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 25 Aug 2002 03:04:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-599869 ] NameError value is not the name error
Message-ID: <E17iuGP-0005cV-00@usw-sf-web1.sourceforge.net>

Bugs item #599869, was opened at 2002-08-25 12:04
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599869&group_id=5470

Category: Documentation
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Pedro Rodriguez (pedro_rodriguez)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: NameError value is not the name error

Initial Comment:
NameError value was the faulty name in 1.5.2, but it
isn't in 2.2.

try:
    a
except NameError, e:
    print e.args

Reports in 1.5.2 :
('a',)

Reports in 2.2 :
("name 'a' is not defined",)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599869&group_id=5470


From noreply@sourceforge.net  Sun Aug 25 13:31:39 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 25 Aug 2002 05:31:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-599679 ] CRAM-MD5 module
Message-ID: <E17iwYN-00037s-00@usw-sf-web4.sourceforge.net>

Bugs item #599679, was opened at 2002-08-24 19:24
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599679&group_id=5470

Category: Extension Modules
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: CRAM-MD5 module

Initial Comment:
[Taken from http://bugs.debian.org/154283]

A request to provide CRAM-MD5 authentification (in
imaplib).


----------------------------------------------------------------------

Comment By: Gerhard Häring (ghaering)
Date: 2002-08-25 14:31

Message:
Logged In: YES 
user_id=163326

Well, the necessary code could probably be found in
smtplib.py. Perhaps it only needs to be adapted.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599679&group_id=5470


From noreply@sourceforge.net  Sun Aug 25 13:41:30 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 25 Aug 2002 05:41:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-588756 ] python should obey the FHS
Message-ID: <E17iwhu-0003Jv-00@usw-sf-web5.sourceforge.net>

Bugs item #588756, was opened at 2002-07-30 22:12
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=588756&group_id=5470

Category: Installation
Group: Feature Request
Status: Open
Resolution: None
Priority: 3
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: python should obey the FHS

Initial Comment:
[From: http://bugs.debian.org/134762]

FHS Compliance - .py{,c} are architecture independant
thus belong in /usr/share

The Python manual makes it clear that byte compiled
python files are
 platform independant, and thus belong in
arch-independant packages and stored in /usr/share, as
per the FHS recommendations for such things.

So the request is to store them in
<prefix>/share/pythonX.Y.


----------------------------------------------------------------------

Comment By: Gerhard Häring (ghaering)
Date: 2002-08-25 14:41

Message:
Logged In: YES 
user_id=163326

Python runs on dozens of platforms besides Debian Linux.
Thus the Linux FHS shouldn't concern Python at all. I'd
propose to close this bug as "Invalid".

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-03 13:13

Message:
Logged In: YES 
user_id=21627

I think this requires a PEP. A Python package can consist of
byte code modules and extension modules; arranging the
package loader to find those in different directories is a
challenge.

----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2002-07-30 22:15

Message:
Logged In: YES 
user_id=60903

FHS: Filesystem Hierarchy Standard

    http://www.pathname.com/fhs/


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=588756&group_id=5470


From noreply@sourceforge.net  Sun Aug 25 14:39:45 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 25 Aug 2002 06:39:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-597938 ] Core dump when using mmap.
Message-ID: <E17ixcH-0002GJ-00@usw-sf-web1.sourceforge.net>

Bugs item #597938, was opened at 2002-08-20 16:45
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=597938&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Stephen P. White (thaden)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: Core dump when using mmap.

Initial Comment:
Ok, it is dumb to read from a file before it is written
to.  But, via mmap I did it by accident and it dumped
core.  Here is a simple linux example which will do it.

d0lxac1% touch dummy
d0lxac1% python
Python 2.1 (#3, May 16 2001, 15:15:15)
[GCC 2.95.2 19991024 (release)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import os,mmap
>>> x = os.open('dummy',os.O_RDWR)
>>> m = mmap.mmap(x,4700)
>>> m.read(47)
Bus error (core dumped)
d0lxac1%

Yeah, its dumb, but should it really dump core?

Thanks.



----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-25 09:39

Message:
Logged In: YES 
user_id=33168

This is a duplicate of 585792.  Closing.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=597938&group_id=5470


From noreply@sourceforge.net  Sun Aug 25 15:29:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 25 Aug 2002 07:29:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-596434 ] textwrap has problems wrapping hyphens
Message-ID: <E17iyON-0003IY-00@usw-sf-web1.sourceforge.net>

Bugs item #596434, was opened at 2002-08-17 10:46
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=596434&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Open
Resolution: Fixed
Priority: 5
Submitted By: David Goodger (goodger)
Assigned to: Greg Ward (gward)
Summary: textwrap has problems wrapping hyphens

Initial Comment:
(Greg already knows about this from private mail; 
this makes it "official".)

Long multi-word command-line options (begin 
with "--" and contain internal "-") inside text may be 
wrapped badly by textwrap.  For example, "--an-
option" may become "--\nan-option" or "--an-\
noption".  Perhaps words that begin with hyphens 
should not be wrapped at all?

----------------------------------------------------------------------

>Comment By: David Goodger (goodger)
Date: 2002-08-25 10:29

Message:
Logged In: YES 
user_id=7733

There's still an edge case that gives poor results.  Try 
wrapping "--text--.".  It will wrap like "--text/--/.", leaving 
just the period (".") or the dashes & period ("--.") on the 
next line.  The latter may or may not be a problem, but 
I'd say wrapping just the sentence-ending period 
definitely *is* a problem.

A more plausible example is "what the--.".

----------------------------------------------------------------------

Comment By: Greg Ward (gward)
Date: 2002-08-22 17:04

Message:
Logged In: YES 
user_id=14422

Thanks for the reminder, David!

Fixed in Lib/textwrap.py rev 1.14.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=596434&group_id=5470


From noreply@sourceforge.net  Sun Aug 25 17:32:18 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 25 Aug 2002 09:32:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-599681 ] SocketServer wrong about allow_reuse_add
Message-ID: <E17j0JG-0000RM-00@usw-sf-web2.sourceforge.net>

Bugs item #599681, was opened at 2002-08-24 12:28
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599681&group_id=5470

Category: Documentation
Group: Python 2.2.1
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: SocketServer wrong about allow_reuse_add

Initial Comment:
the docs for SocketServer document:

 The server classes support the following class variables:

 allow_reuse_address
 Whether the server will allow the reuse of an address.
This defaults to
 true, and can be set in subclasses to change the policy. 

But clearly, it does not default to true:

poseidon:[/usr/lib] grep allow_reuse_address
python2.?/SocketServer.py
python2.1/SocketServer.py:    allow_reuse_address = 0
python2.1/SocketServer.py:        if
self.allow_reuse_address:
python2.1/SocketServer.py:    allow_reuse_address = 0
python2.2/SocketServer.py:    allow_reuse_address = 0
python2.2/SocketServer.py:        if
self.allow_reuse_address:
python2.2/SocketServer.py:    allow_reuse_address = 0



----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-08-25 11:32

Message:
Logged In: YES 
user_id=80475

Thanks for the bug report.

Docs fixed-up.  See:  libsocksvr.tex 1.15 and 1.14.22.1

Closing bug report.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599681&group_id=5470


From noreply@sourceforge.net  Sun Aug 25 17:39:21 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 25 Aug 2002 09:39:21 -0700
Subject: [Python-bugs-list] [ python-Bugs-599869 ] NameError value is not the name error
Message-ID: <E17j0Q5-0000Xa-00@usw-sf-web2.sourceforge.net>

Bugs item #599869, was opened at 2002-08-25 05:04
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599869&group_id=5470

Category: Documentation
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Pedro Rodriguez (pedro_rodriguez)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: NameError value is not the name error

Initial Comment:
NameError value was the faulty name in 1.5.2, but it
isn't in 2.2.

try:
    a
except NameError, e:
    print e.args

Reports in 1.5.2 :
('a',)

Reports in 2.2 :
("name 'a' is not defined",)


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-08-25 11:39

Message:
Logged In: YES 
user_id=80475

Where does this apper in the docs?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599869&group_id=5470


From noreply@sourceforge.net  Mon Aug 26 02:37:40 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 25 Aug 2002 18:37:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-600007 ] Another dealloc stack killer
Message-ID: <E17j8p2-0004Mc-00@usw-sf-web1.sourceforge.net>

Bugs item #600007, was opened at 2002-08-25 21:37
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=600007&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Another dealloc stack killer

Initial Comment:
>From c.l.py:

"""
From: Pavel Pergamenshchik <pp64@cornell.edu>
Sent: Sunday, August 25, 2002 9:17 PM
To: python-list@python.org
Subject: Python 2.2.1 bug

I found a way to break Python 2.2.1 (at least) both on 
Linux and Windows.
...

eval("int" + ".__call__"*100000)

at the prompt, then press ctrl-D or ctrl-Z to edit. This 
will result in a segfault on Linux and some 
weird "unknown software exception" thing on Windows.
"""

At shutdown, the C stack is blown by a very deep 
nest of

_Py_Dealloc
wrapper_dealloc

calls.  That was under current CVS head; I'm sure it's 
the same deal in 2.2.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=600007&group_id=5470


From noreply@sourceforge.net  Mon Aug 26 08:38:21 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 26 Aug 2002 00:38:21 -0700
Subject: [Python-bugs-list] [ python-Bugs-599869 ] NameError value is not the name error
Message-ID: <E17jES5-0001NO-00@usw-sf-web4.sourceforge.net>

Bugs item #599869, was opened at 2002-08-25 12:04
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599869&group_id=5470

Category: Documentation
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Pedro Rodriguez (pedro_rodriguez)
Assigned to: Raymond Hettinger (rhettinger)
Summary: NameError value is not the name error

Initial Comment:
NameError value was the faulty name in 1.5.2, but it
isn't in 2.2.

try:
    a
except NameError, e:
    print e.args

Reports in 1.5.2 :
('a',)

Reports in 2.2 :
("name 'a' is not defined",)


----------------------------------------------------------------------

>Comment By: Pedro Rodriguez (pedro_rodriguez)
Date: 2002-08-26 09:38

Message:
Logged In: YES 
user_id=426450

http://www.python.org/doc/current/lib/module-exceptions.html
-
exception NameError
Raised when a local or global name is not found. This
applies only to unqualified names. The associated value is
the name that could not be found.
-

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-08-25 18:39

Message:
Logged In: YES 
user_id=80475

Where does this apper in the docs?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599869&group_id=5470


From noreply@sourceforge.net  Mon Aug 26 14:56:07 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 26 Aug 2002 06:56:07 -0700
Subject: [Python-bugs-list] [ python-Bugs-600007 ] Another dealloc stack killer
Message-ID: <E17jKLf-0004y4-00@usw-sf-web5.sourceforge.net>

Bugs item #600007, was opened at 2002-08-25 21:37
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=600007&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
>Priority: 3
Submitted By: Tim Peters (tim_one)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Another dealloc stack killer

Initial Comment:
>From c.l.py:

"""
From: Pavel Pergamenshchik <pp64@cornell.edu>
Sent: Sunday, August 25, 2002 9:17 PM
To: python-list@python.org
Subject: Python 2.2.1 bug

I found a way to break Python 2.2.1 (at least) both on 
Linux and Windows.
...

eval("int" + ".__call__"*100000)

at the prompt, then press ctrl-D or ctrl-Z to edit. This 
will result in a segfault on Linux and some 
weird "unknown software exception" thing on Windows.
"""

At shutdown, the C stack is blown by a very deep 
nest of

_Py_Dealloc
wrapper_dealloc

calls.  That was under current CVS head; I'm sure it's 
the same deal in 2.2.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-26 09:56

Message:
Logged In: YES 
user_id=6380

Hm, I cannot reproduce this on Linux, with either the
2.2maintenance branch or 2.3. I trust that it's a problem
though. Reducing priority.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=600007&group_id=5470


From noreply@sourceforge.net  Mon Aug 26 15:06:54 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 26 Aug 2002 07:06:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-600007 ] Another dealloc stack killer
Message-ID: <E17jKW6-0002wg-00@usw-sf-web1.sourceforge.net>

Bugs item #600007, was opened at 2002-08-25 21:37
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=600007&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Tim Peters (tim_one)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Another dealloc stack killer

Initial Comment:
>From c.l.py:

"""
From: Pavel Pergamenshchik <pp64@cornell.edu>
Sent: Sunday, August 25, 2002 9:17 PM
To: python-list@python.org
Subject: Python 2.2.1 bug

I found a way to break Python 2.2.1 (at least) both on 
Linux and Windows.
...

eval("int" + ".__call__"*100000)

at the prompt, then press ctrl-D or ctrl-Z to edit. This 
will result in a segfault on Linux and some 
weird "unknown software exception" thing on Windows.
"""

At shutdown, the C stack is blown by a very deep 
nest of

_Py_Dealloc
wrapper_dealloc

calls.  That was under current CVS head; I'm sure it's 
the same deal in 2.2.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-08-26 10:06

Message:
Logged In: YES 
user_id=31435

I suppose you need to reduce your stack limit, or boost the 
multiplier, then.  I would agree it's hard to get excited 
about this one <wink>.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-26 09:56

Message:
Logged In: YES 
user_id=6380

Hm, I cannot reproduce this on Linux, with either the
2.2maintenance branch or 2.3. I trust that it's a problem
though. Reducing priority.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=600007&group_id=5470


From noreply@sourceforge.net  Mon Aug 26 19:24:42 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 26 Aug 2002 11:24:42 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-600362 ] relocate cgi.parse_qs() into urlparse
Message-ID: <E17jOXa-0000HR-00@usw-sf-web4.sourceforge.net>

Feature Requests item #600362, was opened at 2002-08-26 18:24
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=600362&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Danny Yoo (dyoo)
Assigned to: Nobody/Anonymous (nobody)
Summary: relocate cgi.parse_qs() into urlparse

Initial Comment:
The location of the url-handling functions are
distributed among several modules, and it would be good
to consolidate them to make them easier to find.

The urlparse.urlparse() function splits an url into its
relative pieces.  However, it does not parse out the
query string into a dictionary --- that role is played
by cgi.parse_qs().  And to convert a dictionary back to
a query string, the programmer needs to know that that
function is in urllib.urlencode.


It would be nice to have cgi.parse_qs() and
urllib.urlencode() in a unified place, within in the
urlparse module if appropriate.  This will help reduce
the amount of hunting-and-pecking that beginners do
when they're trying to deal with URLs.


See:

http://mail.python.org/pipermail/tutor/2002-August/016823.html

for more information.

Thanks!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=600362&group_id=5470


From noreply@sourceforge.net  Tue Aug 27 16:05:44 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 27 Aug 2002 08:05:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-599869 ] NameError value is not the name error
Message-ID: <E17jhua-00070i-00@usw-sf-web3.sourceforge.net>

Bugs item #599869, was opened at 2002-08-25 10:04
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599869&group_id=5470

Category: Documentation
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Pedro Rodriguez (pedro_rodriguez)
Assigned to: Raymond Hettinger (rhettinger)
Summary: NameError value is not the name error

Initial Comment:
NameError value was the faulty name in 1.5.2, but it
isn't in 2.2.

try:
    a
except NameError, e:
    print e.args

Reports in 1.5.2 :
('a',)

Reports in 2.2 :
("name 'a' is not defined",)


----------------------------------------------------------------------

>Comment By: Peter Schneider-Kamp (nowonder)
Date: 2002-08-27 15:05

Message:
Logged In: YES 
user_id=14463

What do you mean? Pedro gave a link. Just search for
'NameError' on that page.

If you are referring to the cvs docs, the appropriate file is:
dist/src/Doc/lib/libexcs.tex, line 209f

Pedro is right in that current practice is incosistent with old
practice AND documentation.

----------------------------------------------------------------------

Comment By: Pedro Rodriguez (pedro_rodriguez)
Date: 2002-08-26 07:38

Message:
Logged In: YES 
user_id=426450

http://www.python.org/doc/current/lib/module-exceptions.html
-
exception NameError
Raised when a local or global name is not found. This
applies only to unqualified names. The associated value is
the name that could not be found.
-

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-08-25 16:39

Message:
Logged In: YES 
user_id=80475

Where does this apper in the docs?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599869&group_id=5470


From noreply@sourceforge.net  Tue Aug 27 16:48:00 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 27 Aug 2002 08:48:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-599838 ] httplib.connect broken in 2.1 branch
Message-ID: <E17jiZU-0003Ye-00@usw-sf-web1.sourceforge.net>

Bugs item #599838, was opened at 2002-08-25 07:39
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599838&group_id=5470

Category: Python Library
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 7
Submitted By: Matthias Klose (doko)
>Assigned to: Jeremy Hylton (jhylton)
Summary: httplib.connect broken in 2.1 branch

Initial Comment:
In the current 2.1 branch, httplib.connect uses
socket.getaddrinfo, which is not available in 2.1:

>>> urllib.connect()

  File "/usr/lib/python2.1/httplib.py", line 509, in
connect 
    for res in socket.getaddrinfo(self.host, self.port, 0, 
AttributeError: 'socket' module has no attribute
'getaddrinfo' 

Introduced in Revison 1.42.10.7 , Fri Jul 12 14:23:38
2002 UTC (6 weeks, 1 day ago) by jhylton 


----------------------------------------------------------------------

>Comment By: Peter Schneider-Kamp (nowonder)
Date: 2002-08-27 15:47

Message:
Logged In: YES 
user_id=14463

This bug is a consequence of the backport changes from
1.34.2.4 to 1.34.2.5 of dist/src/Lib/httplib.py.

Possible resolutions:
a) backport ipv6 updates of dist/src/Modules/socketmodule.c
(happened around revision 1.153) to release21-maint
XOR
b) undo part of the backport of dist/src/Lib/httplib.py,
especially
    HTTPConnection.connect()

Assigning this to Jeremy as he checked in the backport changes.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599838&group_id=5470


From noreply@sourceforge.net  Tue Aug 27 17:22:15 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 27 Aug 2002 09:22:15 -0700
Subject: [Python-bugs-list] [ python-Bugs-599757 ] sub[n] not working as expected.
Message-ID: <E17jj6d-0007ZH-00@usw-sf-web4.sourceforge.net>

Bugs item #599757, was opened at 2002-08-24 22:14
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599757&group_id=5470

Category: Regular Expressions
Group: Python 2.2.1
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Travis Shirk (nicfit)
Assigned to: Fredrik Lundh (effbot)
Summary: sub[n] not working as expected.

Initial Comment:
I'm running into what looks to be a bug in the python
2.2 re module.
These examples should demonstrate the problem.

Using Python 1.5.2:
import re;
data =
"\xFF\x00\xE0\xD3\xD3\xE4\x95\xFF\x00\x00\x11\xFF\x00\xF5"
data1 =
re.compile(r"\xFF\x00([\xE0-\xFF])").sub(r"\xFF\1", data);
print data1
'\377\340\323\323\344\225\377\000\000\021\377\365'


This output is exactly what I expect, but now see what
happens in 
2.2.1:
import re;
data =
"\xFF\x00\xE0\xD3\xD3\xE4\x95\xFF\x00\x00\x11\xFF\x00\xF5"
data1 =
re.compile(r"\xFF\x00([\xE0-\xFF])").sub(r"\xFF\1", data);
print data1
'\xFF\xe0\xd3\xd3\xe4\x95\xff\x00\x00\x11\xFF\xf5'

I like the hex output over the octal in 1.5, but the
substitution is
clearly wrong.  Notice each spot containing "\" in the
last result.


----------------------------------------------------------------------

>Comment By: Peter Schneider-Kamp (nowonder)
Date: 2002-08-27 16:22

Message:
Logged In: YES 
user_id=14463

The substitution is correct. Notice that the r"..." raw
string given to sub in this example has length 6, not length
3! As you can see from the case, \xFF is a string of length
4 and has no close relationship to the singleton string \xff.

If you use .sub("\xFF\1", data) instead you will achieve
the desired result.

Note that the raw string passed to re.compile() also does
not contain the character \xff itself, but as described in
the documentation, re is able to parse the \xHH-style
character escapes.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599757&group_id=5470


From noreply@sourceforge.net  Tue Aug 27 17:49:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 27 Aug 2002 09:49:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-599377 ] re searches don't work with 4-byte unico
Message-ID: <E17jjWx-00086g-00@usw-sf-web4.sourceforge.net>

Bugs item #599377, was opened at 2002-08-23 19:16
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599377&group_id=5470

Category: Python Library
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Fulton (dcjim)
Assigned to: Fredrik Lundh (effbot)
Summary: re searches don't work with 4-byte unico

Initial Comment:
For Python 2.2.1 or the CVS head, as of this posting, 
with Python configured for 4-byte unicode
(--enable-unicode=ucs4)
searches against unicode regular expressions that use 
characters above \xff don't seem to work.

Here's an example:

  invalid_xml_char = re.compile(u'[\ud800-\udfff]')
  invalid_xml_char.search(u'\ud800')

returns None, rather than a match.


----------------------------------------------------------------------

>Comment By: Peter Schneider-Kamp (nowonder)
Date: 2002-08-27 16:49

Message:
Logged In: YES 
user_id=14463

I could reproduce this behaviour exactly. No idea what is
causing it, though.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599377&group_id=5470


From noreply@sourceforge.net  Tue Aug 27 17:59:28 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 27 Aug 2002 09:59:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-599163 ] execfile() not show filename when IOErro
Message-ID: <E17jjge-0008IC-00@usw-sf-web4.sourceforge.net>

Bugs item #599163, was opened at 2002-08-23 10:16
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599163&group_id=5470

Category: Python Library
Group: Python 2.2.1
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Inyeol Lee (inyeol)
Assigned to: Nobody/Anonymous (nobody)
Summary: execfile() not show filename when IOErro

Initial Comment:
Python 2.2.1 (#1, Apr 10 2002, 18:25:16) 
[GCC 2.95.3 20010315 (release)] on sunos5
>>> try: execfile('non_existent_file')
... except IOError, msg: msg.__dict__

{'errno': 2, 'args': (2, 'No such file or directory'),
'strerror': 'No such file or directory', 'filename':
None}

There should be a filename, not None.

-Inyeol Lee 

----------------------------------------------------------------------

>Comment By: Peter Schneider-Kamp (nowonder)
Date: 2002-08-27 16:59

Message:
Logged In: YES 
user_id=14463

execfile incorrectly called PyErr_SetFromErrno instead of
PyErr_SetFromErrnoWithFilename.

Resolution is obvious and already committed to cvs.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599163&group_id=5470


From noreply@sourceforge.net  Tue Aug 27 20:51:26 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 27 Aug 2002 12:51:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-600952 ] Installing w/o admin generates key error
Message-ID: <E17jmN4-0005Oz-00@usw-sf-web3.sourceforge.net>

Bugs item #600952, was opened at 2002-08-27 19:49
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=600952&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Phil Rittenhouse (prittenh)
>Assigned to: Thomas Heller (theller)
Summary: Installing w/o admin generates key error

Initial Comment:
I encountered the following problem when trying to 
install a package I had generated with distutils 
(Python 2.2 on Win2k, logged in as a user without 
adminstrative priveleges):

When the installer was run, it would go through the 
steps nicely, but towards the end, it generated two 
errors:
        "Could not open key
Software\Microsoft\Windows\CurrentVersion\Unins
tall"
        "Could not create key  dsp-py2.1"

At first I thought the problem might be the result 
of installing Python as Administrator, and the 
package as just a user, so I re-installed Python as a 
user, but I still got the same error.  I ran my test on 
Win2K with both Python 2.1 and 2.2, and I always 
got the same result.

I tracked the code generating the error to install.c in
distutils-1.0.2/misc (see below).  I did some 
digging and it appears that to use 
KEY_ALL_ACCESS, the code must be running
with Administrator privileges.   I checked the CVS 
archives to see if KEY_ALL_ACCESS is
still being used, and it is.

I made the following changes to install.c (from 
Distutils 1.0.2), recompiled, and it  works now.
796c796
<                         KEY_CREATE_SUB_KEY,
---
>                         KEY_ALL_ACCESS,
806c806
<                           KEY_WRITE,
---
>                           KEY_ALL_ACCESS,
1177c1177
<                KEY_WRITE,
---
>                KEY_ALL_ACCESS,
1208c1208
<                KEY_WRITE,
---
>                KEY_ALL_ACCESS,


I chose KEY_CREATE_SUB_KEY for the open, since 
that is the only operation that will be performed
on it.   For the new key itself, I chose KEY_WRITE, 
since that was also the minimal operation.  While I
was at it, I changed the code for deleting the 
registry key and value to also use the minimal 
KEY_WRITE.  The last two changes allowed the 
uninstaller to work properly when run as a normal 
user.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=600952&group_id=5470


From noreply@sourceforge.net  Tue Aug 27 20:49:55 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 27 Aug 2002 12:49:55 -0700
Subject: [Python-bugs-list] [ python-Bugs-600952 ] Installing w/o admin generates key error
Message-ID: <E17jmLb-0003lZ-00@usw-sf-web4.sourceforge.net>

Bugs item #600952, was opened at 2002-08-27 19:49
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=600952&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Phil Rittenhouse (prittenh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Installing w/o admin generates key error

Initial Comment:
I encountered the following problem when trying to 
install a package I had generated with distutils 
(Python 2.2 on Win2k, logged in as a user without 
adminstrative priveleges):

When the installer was run, it would go through the 
steps nicely, but towards the end, it generated two 
errors:
        "Could not open key
Software\Microsoft\Windows\CurrentVersion\Unins
tall"
        "Could not create key  dsp-py2.1"

At first I thought the problem might be the result 
of installing Python as Administrator, and the 
package as just a user, so I re-installed Python as a 
user, but I still got the same error.  I ran my test on 
Win2K with both Python 2.1 and 2.2, and I always 
got the same result.

I tracked the code generating the error to install.c in
distutils-1.0.2/misc (see below).  I did some 
digging and it appears that to use 
KEY_ALL_ACCESS, the code must be running
with Administrator privileges.   I checked the CVS 
archives to see if KEY_ALL_ACCESS is
still being used, and it is.

I made the following changes to install.c (from 
Distutils 1.0.2), recompiled, and it  works now.
796c796
<                         KEY_CREATE_SUB_KEY,
---
>                         KEY_ALL_ACCESS,
806c806
<                           KEY_WRITE,
---
>                           KEY_ALL_ACCESS,
1177c1177
<                KEY_WRITE,
---
>                KEY_ALL_ACCESS,
1208c1208
<                KEY_WRITE,
---
>                KEY_ALL_ACCESS,


I chose KEY_CREATE_SUB_KEY for the open, since 
that is the only operation that will be performed
on it.   For the new key itself, I chose KEY_WRITE, 
since that was also the minimal operation.  While I
was at it, I changed the code for deleting the 
registry key and value to also use the minimal 
KEY_WRITE.  The last two changes allowed the 
uninstaller to work properly when run as a normal 
user.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=600952&group_id=5470


From noreply@sourceforge.net  Tue Aug 27 21:09:35 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 27 Aug 2002 13:09:35 -0700
Subject: [Python-bugs-list] [ python-Bugs-577782 ] resire readonly memory mapped file
Message-ID: <E17jmed-0000yT-00@usw-sf-web5.sourceforge.net>

Bugs item #577782, was opened at 2002-07-05 10:07
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=577782&group_id=5470

Category: Windows
Group: None
Status: Open
>Resolution: Works For Me
Priority: 5
Submitted By: Grzegorz Makarewicz (makaron)
Assigned to: Tim Peters (tim_one)
Summary: resire readonly memory mapped file

Initial Comment:

When file is open as readonly and mmf if created as R/O
too, then resizing this mapping will change its
protection and desired acces to read-write.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-08-27 16:09

Message:
Logged In: YES 
user_id=31435

Which version of Python are you talking about?  Also, please 
give a concrete example so we don't have to guess at what 
you mean.  Here's mine:

"""
import mmap

f = open('in.txt', 'rb')
m = mmap.mmap(f.fileno(), 0, 
access=mmap.ACCESS_READ)
f.close()

print `m[:]`
m.resize(5)
"""
The m.resizes() attempt yields a TypeError, "mmap can't 
resize a readonly or copy-on-write memory map".  I tried this 
under current CVS, and under 2.2.1, on Win2K.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=577782&group_id=5470


From noreply@sourceforge.net  Tue Aug 27 21:20:48 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 27 Aug 2002 13:20:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-590207 ] PyMapping_Keys unexported in dll
Message-ID: <E17jmpU-00018c-00@usw-sf-web5.sourceforge.net>

Bugs item #590207, was opened at 2002-08-02 11:38
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=590207&group_id=5470

Category: Windows
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Marco Beri (marcoberi)
Assigned to: Tim Peters (tim_one)
Summary: PyMapping_Keys unexported in dll

Initial Comment:
PyMapping_Keys (as lots of other C API) is not 
exported in python22.dll.

Moreover, with a binary search I find an undocumented 
PyMapping_Size function.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-08-27 16:20

Message:
Logged In: YES 
user_id=31435

PyMapping_Keys is a macro -- it can't be exported, as there 
is no function of that name.  Its expansion is supplied by 
including Python.h.

PyMapping_Size is deliberately undocumented; it's an 
obsolete name for PyMapping_Length.  Note that the point 
isn't to export every conceivable entry point, it's to make the 
documented C API available.  A lot of stuff in the header files 
exists only for backward compatibility with obsolete spellings.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=590207&group_id=5470


From noreply@sourceforge.net  Tue Aug 27 23:43:29 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 27 Aug 2002 15:43:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-599838 ] httplib.connect broken in 2.1 branch
Message-ID: <E17jp3Z-0006XX-00@usw-sf-web2.sourceforge.net>

Bugs item #599838, was opened at 2002-08-25 07:39
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599838&group_id=5470

Category: Python Library
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 7
Submitted By: Matthias Klose (doko)
Assigned to: Jeremy Hylton (jhylton)
Summary: httplib.connect broken in 2.1 branch

Initial Comment:
In the current 2.1 branch, httplib.connect uses
socket.getaddrinfo, which is not available in 2.1:

>>> urllib.connect()

  File "/usr/lib/python2.1/httplib.py", line 509, in
connect 
    for res in socket.getaddrinfo(self.host, self.port, 0, 
AttributeError: 'socket' module has no attribute
'getaddrinfo' 

Introduced in Revison 1.42.10.7 , Fri Jul 12 14:23:38
2002 UTC (6 weeks, 1 day ago) by jhylton 


----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-08-27 22:43

Message:
Logged In: YES 
user_id=31392

I'll check into it, but why priority 7?  If there aren't
plans to do a 2.1.4 release soon, then I would call this a
low priority.


----------------------------------------------------------------------

Comment By: Peter Schneider-Kamp (nowonder)
Date: 2002-08-27 15:47

Message:
Logged In: YES 
user_id=14463

This bug is a consequence of the backport changes from
1.34.2.4 to 1.34.2.5 of dist/src/Lib/httplib.py.

Possible resolutions:
a) backport ipv6 updates of dist/src/Modules/socketmodule.c
(happened around revision 1.153) to release21-maint
XOR
b) undo part of the backport of dist/src/Lib/httplib.py,
especially
    HTTPConnection.connect()

Assigning this to Jeremy as he checked in the backport changes.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599838&group_id=5470


From noreply@sourceforge.net  Wed Aug 28 00:55:40 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 27 Aug 2002 16:55:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-599869 ] NameError value is not the name error
Message-ID: <E17jqBQ-0000Zw-00@usw-sf-web4.sourceforge.net>

Bugs item #599869, was opened at 2002-08-25 05:04
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599869&group_id=5470

Category: Documentation
Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Pedro Rodriguez (pedro_rodriguez)
Assigned to: Raymond Hettinger (rhettinger)
Summary: NameError value is not the name error

Initial Comment:
NameError value was the faulty name in 1.5.2, but it
isn't in 2.2.

try:
    a
except NameError, e:
    print e.args

Reports in 1.5.2 :
('a',)

Reports in 2.2 :
("name 'a' is not defined",)


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-08-27 18:55

Message:
Logged In: YES 
user_id=80475

Pedro, thanks for the submitting the bug report.

Updated documentation.
See Docs/lib/libexecs.tex 1.48 and 1.43.6.1

Closing bug.



----------------------------------------------------------------------

Comment By: Peter Schneider-Kamp (nowonder)
Date: 2002-08-27 10:05

Message:
Logged In: YES 
user_id=14463

What do you mean? Pedro gave a link. Just search for
'NameError' on that page.

If you are referring to the cvs docs, the appropriate file is:
dist/src/Doc/lib/libexcs.tex, line 209f

Pedro is right in that current practice is incosistent with old
practice AND documentation.

----------------------------------------------------------------------

Comment By: Pedro Rodriguez (pedro_rodriguez)
Date: 2002-08-26 02:38

Message:
Logged In: YES 
user_id=426450

http://www.python.org/doc/current/lib/module-exceptions.html
-
exception NameError
Raised when a local or global name is not found. This
applies only to unqualified names. The associated value is
the name that could not be found.
-

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-08-25 11:39

Message:
Logged In: YES 
user_id=80475

Where does this apper in the docs?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599869&group_id=5470


From noreply@sourceforge.net  Wed Aug 28 02:03:45 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 27 Aug 2002 18:03:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-601077 ] bug in new execvpe
Message-ID: <E17jrFJ-0005oU-00@usw-sf-web1.sourceforge.net>

Bugs item #601077, was opened at 2002-08-27 21:03
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=601077&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Nobody/Anonymous (nobody)
Summary: bug in new execvpe

Initial Comment:
From: "Steve M. Robbins" <steven.robbins@videotron.ca>


I think the patch associated with this thread has an
unintended
consequence.

In
http://mail.python.org/pipermail/python-dev/2002-August/027229.html
Zack pointed out three flaws in the original code:

    [...]
    Third, if an error other than the expected one
comes back, the
    loop clobbers the saved exception info and keeps
going.  Consider
    the situation where PATH=/bin:/usr/bin, /bin/foobar
exists but is
    not executable by the invoking user, and
/usr/bin/foobar does not
    exist.  The exception thrown will be 'No such file
or directory',
    not the expected 'Permission denied'.

The patch, as I understand it, changes the behaviour so
as to raise
the exception "Permission denied" in this case.

Consider a similar situation in which both /bin/foobar
(not executable
by the user) and /usr/bin/foobar (executable by the
user) exist.
Given the command "foobar", the shell will execute
/usr/bin/foobar.
If I understand the patch correctly, python will give
up when it
encounters /bin/foobar and raise the "Permission
denied" exception.

I believe this just happened to me today.  I had a
shell script named
"gcc" in ~/bin (first on my path) some months back. 
When I was
finished with it, I just did "chmod -x ~/bin/gcc" and
forgot about it.
Today was the first time since this patch went in that
I ran gcc via
python (using scipy's weave).  Boy was I surprised at
the message
"unable to execute gcc: Permission denied"!

I guess the fix is to save the EPERM exception and keep
going
in case there is an executable later in the path.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=601077&group_id=5470


From noreply@sourceforge.net  Wed Aug 28 02:06:41 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 27 Aug 2002 18:06:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-601077 ] bug in new execvpe
Message-ID: <E17jrI9-0005rk-00@usw-sf-web1.sourceforge.net>

Bugs item #601077, was opened at 2002-08-27 21:03
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=601077&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Nobody/Anonymous (nobody)
Summary: bug in new execvpe

Initial Comment:
From: "Steve M. Robbins" <steven.robbins@videotron.ca>


I think the patch associated with this thread has an
unintended
consequence.

In
http://mail.python.org/pipermail/python-dev/2002-August/027229.html
Zack pointed out three flaws in the original code:

    [...]
    Third, if an error other than the expected one
comes back, the
    loop clobbers the saved exception info and keeps
going.  Consider
    the situation where PATH=/bin:/usr/bin, /bin/foobar
exists but is
    not executable by the invoking user, and
/usr/bin/foobar does not
    exist.  The exception thrown will be 'No such file
or directory',
    not the expected 'Permission denied'.

The patch, as I understand it, changes the behaviour so
as to raise
the exception "Permission denied" in this case.

Consider a similar situation in which both /bin/foobar
(not executable
by the user) and /usr/bin/foobar (executable by the
user) exist.
Given the command "foobar", the shell will execute
/usr/bin/foobar.
If I understand the patch correctly, python will give
up when it
encounters /bin/foobar and raise the "Permission
denied" exception.

I believe this just happened to me today.  I had a
shell script named
"gcc" in ~/bin (first on my path) some months back. 
When I was
finished with it, I just did "chmod -x ~/bin/gcc" and
forgot about it.
Today was the first time since this patch went in that
I ran gcc via
python (using scipy's weave).  Boy was I surprised at
the message
"unable to execute gcc: Permission denied"!

I guess the fix is to save the EPERM exception and keep
going
in case there is an executable later in the path.


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-27 21:06

Message:
Logged In: YES 
user_id=6380

Since I applied Zack's patch to the trunk as well as to the
2.2 maintenance branch, this needs to be fixed in both places.

This worked correctly in 2.1 and 2.2 (and in 2.2.1, but I
haven't tested that).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=601077&group_id=5470


From noreply@sourceforge.net  Wed Aug 28 05:48:50 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 27 Aug 2002 21:48:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-599838 ] httplib.connect broken in 2.1 branch
Message-ID: <E17jul8-0001id-00@usw-sf-web5.sourceforge.net>

Bugs item #599838, was opened at 2002-08-25 07:39
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599838&group_id=5470

Category: Python Library
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 7
Submitted By: Matthias Klose (doko)
Assigned to: Jeremy Hylton (jhylton)
Summary: httplib.connect broken in 2.1 branch

Initial Comment:
In the current 2.1 branch, httplib.connect uses
socket.getaddrinfo, which is not available in 2.1:

>>> urllib.connect()

  File "/usr/lib/python2.1/httplib.py", line 509, in
connect 
    for res in socket.getaddrinfo(self.host, self.port, 0, 
AttributeError: 'socket' module has no attribute
'getaddrinfo' 

Introduced in Revison 1.42.10.7 , Fri Jul 12 14:23:38
2002 UTC (6 weeks, 1 day ago) by jhylton 


----------------------------------------------------------------------

>Comment By: Matthias Klose (doko)
Date: 2002-08-28 04:48

Message:
Logged In: YES 
user_id=60903

IMO a maintainance branch should be in a releasable state
anytime. This one is a regression, so I raised the priority.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-08-27 22:43

Message:
Logged In: YES 
user_id=31392

I'll check into it, but why priority 7?  If there aren't
plans to do a 2.1.4 release soon, then I would call this a
low priority.


----------------------------------------------------------------------

Comment By: Peter Schneider-Kamp (nowonder)
Date: 2002-08-27 15:47

Message:
Logged In: YES 
user_id=14463

This bug is a consequence of the backport changes from
1.34.2.4 to 1.34.2.5 of dist/src/Lib/httplib.py.

Possible resolutions:
a) backport ipv6 updates of dist/src/Modules/socketmodule.c
(happened around revision 1.153) to release21-maint
XOR
b) undo part of the backport of dist/src/Lib/httplib.py,
especially
    HTTPConnection.connect()

Assigning this to Jeremy as he checked in the backport changes.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599838&group_id=5470


From noreply@sourceforge.net  Wed Aug 28 11:24:22 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 28 Aug 2002 03:24:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-601202 ] Indentation bug after # in python-mode
Message-ID: <E17jzzq-0002LD-00@usw-sf-web4.sourceforge.net>

Bugs item #601202, was opened at 2002-08-28 14:24
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=601202&group_id=5470

Category: Demos and Tools
Group: 3rd Party
Status: Open
Resolution: None
Priority: 5
Submitted By: Victor V. Kryukov (vtail)
Assigned to: Nobody/Anonymous (nobody)
Summary: Indentation bug after # in python-mode

Initial Comment:
If you type following code in python-mode in Emacs:
==>
def main()
a=5
b=4
<==
then go to the 3rd line and put # as a first symbol in that 
string and go to 4th line and type something, the 
indentation of the 4th line will be the same as of 1st, 
with no way to change it (i.e. pressing Tab again doesn't 
help). 

That is very annoying and if just want to comment 
something and write several lines after that.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=601202&group_id=5470


From noreply@sourceforge.net  Wed Aug 28 14:12:31 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 28 Aug 2002 06:12:31 -0700
Subject: [Python-bugs-list] [ python-Bugs-601202 ] Indentation bug after # in python-mode
Message-ID: <E17k2cZ-0006GZ-00@usw-sf-web4.sourceforge.net>

Bugs item #601202, was opened at 2002-08-28 06:24
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=601202&group_id=5470

Category: Demos and Tools
Group: 3rd Party
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Victor V. Kryukov (vtail)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Indentation bug after # in python-mode

Initial Comment:
If you type following code in python-mode in Emacs:
==>
def main()
a=5
b=4
<==
then go to the 3rd line and put # as a first symbol in that 
string and go to 4th line and type something, the 
indentation of the 4th line will be the same as of 1st, 
with no way to change it (i.e. pressing Tab again doesn't 
help). 

That is very annoying and if just want to comment 
something and write several lines after that.



----------------------------------------------------------------------

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2002-08-28 09:12

Message:
Logged In: YES 
user_id=12800

This is by design.  See py-honor-comment-indentation

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=601202&group_id=5470


From noreply@sourceforge.net  Wed Aug 28 17:14:30 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 28 Aug 2002 09:14:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-601392 ] weird header wrapping in email.Generator
Message-ID: <E17k5Sg-0000EI-00@usw-sf-web1.sourceforge.net>

Bugs item #601392, was opened at 2002-08-28 12:14
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=601392&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Ward (gward)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: weird header wrapping in email.Generator

Initial Comment:
I have discovered a particular header line that 
email.Generator does not wrap very well.  Here it is, 
mangled by my web browser and SF:

Received: from 
modemcable093.139-201-24.que.mc.videotron.ca 
([24.201.139.93] helo=cthulhu.gerg.ca)
        by kronos.mems-exchange.org with esmtp (Exim 
4.05)
        id 17k4h5-00034i-00
        for test@mems-exchange.org; Wed, 28 Aug 2002 
11:25:20 -0400

(Only one line, the first, is particularly long.  The other 
three lines all fit comfortably in 78 columns.)

(Oh, I'll try to attach a message consisting solely of this 
header line along with my test script.)

With Python 2.2.1, email.Message.as_string() wraps this 
header line as:

Received: from 
modemcable093.139-201-24.que.mc.videotron.ca 
([24.201.139.93]
        helo=cthulhu.gerg.ca)
        by kronos.mems-exchange.org with esmtp (Exim 
4.05)
        id
        17k4h5-00034i-00
        for test@mems-exchange.org; Wed, 28 Aug 2002 
11:25:20 -0400

(The oddity there is the word "id" alone on a line.)

With CVS Python (as of 10 minutes ago), it's wrapped as:

Received: from 
modemcable093.139-201-24.que.mc.videotron.ca 
([24.201.139.93]
        helo=cthulhu.gerg.ca)
        by kronos.mems-exchange.org with esmtp (Exim 
4.05)id 17k4h5-00034i-00
        for test@mems-exchange.org; Wed, 28 Aug 2002 
11:25:20 -0400

(Note how "id ..." is jammed right up against "(Exim 
4.05)".)



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=601392&group_id=5470


From noreply@sourceforge.net  Wed Aug 28 17:28:28 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 28 Aug 2002 09:28:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-601392 ] weird header wrapping in email.Generator
Message-ID: <E17k5gC-0000bS-00@usw-sf-web1.sourceforge.net>

Bugs item #601392, was opened at 2002-08-28 12:14
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=601392&group_id=5470

Category: Python Library
>Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Ward (gward)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: weird header wrapping in email.Generator

Initial Comment:
I have discovered a particular header line that 
email.Generator does not wrap very well.  Here it is, 
mangled by my web browser and SF:

Received: from 
modemcable093.139-201-24.que.mc.videotron.ca 
([24.201.139.93] helo=cthulhu.gerg.ca)
        by kronos.mems-exchange.org with esmtp (Exim 
4.05)
        id 17k4h5-00034i-00
        for test@mems-exchange.org; Wed, 28 Aug 2002 
11:25:20 -0400

(Only one line, the first, is particularly long.  The other 
three lines all fit comfortably in 78 columns.)

(Oh, I'll try to attach a message consisting solely of this 
header line along with my test script.)

With Python 2.2.1, email.Message.as_string() wraps this 
header line as:

Received: from 
modemcable093.139-201-24.que.mc.videotron.ca 
([24.201.139.93]
        helo=cthulhu.gerg.ca)
        by kronos.mems-exchange.org with esmtp (Exim 
4.05)
        id
        17k4h5-00034i-00
        for test@mems-exchange.org; Wed, 28 Aug 2002 
11:25:20 -0400

(The oddity there is the word "id" alone on a line.)

With CVS Python (as of 10 minutes ago), it's wrapped as:

Received: from 
modemcable093.139-201-24.que.mc.videotron.ca 
([24.201.139.93]
        helo=cthulhu.gerg.ca)
        by kronos.mems-exchange.org with esmtp (Exim 
4.05)id 17k4h5-00034i-00
        for test@mems-exchange.org; Wed, 28 Aug 2002 
11:25:20 -0400

(Note how "id ..." is jammed right up against "(Exim 
4.05)".)



----------------------------------------------------------------------

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2002-08-28 12:28

Message:
Logged In: YES 
user_id=12800

Verified.  Here's a one-file example that illustrates the bug.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=601392&group_id=5470


From noreply@sourceforge.net  Wed Aug 28 21:53:52 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 28 Aug 2002 13:53:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-601534 ] xmlrpclib ignores CDATA
Message-ID: <E17k9p2-0002vC-00@usw-sf-web3.sourceforge.net>

Bugs item #601534, was opened at 2002-08-28 22:53
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=601534&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: xmlrpclib ignores CDATA

Initial Comment:
The SlowParser in xmlrpclib ignores CDATA character
data sections. No handler is defined for it so any
XML-RPC client that escapes parameter values with a
CDATA section will result in empty parameters being
passed on to the application.

The fix is simple, add a self.handle_cdata =
target.data line in the SlowParser __init__.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=601534&group_id=5470


From noreply@sourceforge.net  Thu Aug 29 00:30:25 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 28 Aug 2002 16:30:25 -0700
Subject: [Python-bugs-list] [ python-Bugs-600007 ] Another dealloc stack killer
Message-ID: <E17kCGX-0003FW-00@usw-sf-web2.sourceforge.net>

Bugs item #600007, was opened at 2002-08-25 21:37
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=600007&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Tim Peters (tim_one)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Another dealloc stack killer

Initial Comment:
>From c.l.py:

"""
From: Pavel Pergamenshchik <pp64@cornell.edu>
Sent: Sunday, August 25, 2002 9:17 PM
To: python-list@python.org
Subject: Python 2.2.1 bug

I found a way to break Python 2.2.1 (at least) both on 
Linux and Windows.
...

eval("int" + ".__call__"*100000)

at the prompt, then press ctrl-D or ctrl-Z to edit. This 
will result in a segfault on Linux and some 
weird "unknown software exception" thing on Windows.
"""

At shutdown, the C stack is blown by a very deep 
nest of

_Py_Dealloc
wrapper_dealloc

calls.  That was under current CVS head; I'm sure it's 
the same deal in 2.2.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-28 19:30

Message:
Logged In: YES 
user_id=33168

The threshold was 300000 for me on Linux.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-08-26 10:06

Message:
Logged In: YES 
user_id=31435

I suppose you need to reduce your stack limit, or boost the 
multiplier, then.  I would agree it's hard to get excited 
about this one <wink>.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-26 09:56

Message:
Logged In: YES 
user_id=6380

Hm, I cannot reproduce this on Linux, with either the
2.2maintenance branch or 2.3. I trust that it's a problem
though. Reducing priority.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=600007&group_id=5470


From noreply@sourceforge.net  Thu Aug 29 10:53:50 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 29 Aug 2002 02:53:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-601775 ] some int results that should be bool
Message-ID: <E17kLzq-0005hR-00@usw-sf-web2.sourceforge.net>

Bugs item #601775, was opened at 2002-08-29 12:53
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=601775&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Christos Georgiou (tzot)
Assigned to: Nobody/Anonymous (nobody)
Summary: some int results that should be bool

Initial Comment:
Posting this as a SF bug since the relevant patch would 
be very small.  (I can post it as a patch if requested, 
though).

1.
cStringIO.c, line 136, IO_isatty returns PyInt_FromLong
(0), while this should be PyBool_FromLong(0).
StringIO.isatty returns False --which is <type bool>-- 
and so should cStringIO.

Note: documentation states that file-like objects not 
being real files should not define this method.  Perhaps 
it should be removed from cStringIO and StringIO.

2.
posixmodule.c, line 759, posix_access returns 
PyInt_FromLong.  It should be PyBool_FromLong.

3. (rather indifferent, this one)
svmodule.c, line 393, sv_IsVideoDisplayed should return 
a bool also.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=601775&group_id=5470


From noreply@sourceforge.net  Thu Aug 29 10:56:08 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 29 Aug 2002 02:56:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-601775 ] some int results that should be bool
Message-ID: <E17kM24-0002ez-00@usw-sf-web5.sourceforge.net>

Bugs item #601775, was opened at 2002-08-29 12:53
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=601775&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
>Priority: 3
Submitted By: Christos Georgiou (tzot)
Assigned to: Nobody/Anonymous (nobody)
Summary: some int results that should be bool

Initial Comment:
Posting this as a SF bug since the relevant patch would 
be very small.  (I can post it as a patch if requested, 
though).

1.
cStringIO.c, line 136, IO_isatty returns PyInt_FromLong
(0), while this should be PyBool_FromLong(0).
StringIO.isatty returns False --which is <type bool>-- 
and so should cStringIO.

Note: documentation states that file-like objects not 
being real files should not define this method.  Perhaps 
it should be removed from cStringIO and StringIO.

2.
posixmodule.c, line 759, posix_access returns 
PyInt_FromLong.  It should be PyBool_FromLong.

3. (rather indifferent, this one)
svmodule.c, line 393, sv_IsVideoDisplayed should return 
a bool also.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=601775&group_id=5470


From noreply@sourceforge.net  Thu Aug 29 15:45:56 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 29 Aug 2002 07:45:56 -0700
Subject: [Python-bugs-list] [ python-Bugs-594893 ] printing email object deletes whitespace
Message-ID: <E17kQYW-0005L1-00@usw-sf-web3.sourceforge.net>

Bugs item #594893, was opened at 2002-08-13 23:59
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594893&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: printing email object deletes whitespace

Initial Comment:
I certain situations when printing email Message objects (I think), 
whitespace in headers disappears.  The attached zip file 
demonstrates this problem.  In email.orig, there is a line break 
followed by a TAB in the X-Vm-v5-Data header at the end of the 
first continuation line.  In email.new, which was generated by 
printing an email.Message object, the line break and TAB are gone, 
but no SPACE was inserted in their place.

This example is from a larger program which reads in a Unix 
mailbox like so:

    msgdict = {}
    i = 0
    for msg in mailbox.PortableUnixMailbox(f,
                                 email.Parser.Parser().parse):
        subj = msg["subject"]
        item = msgdict.get(subj) or []
        item.append((i, msg))
        msgdict[subj] = item
        i += 1

runs through msgdict and deletes a bunch of messages matching 
various criteria, then prints out those which remain retaining the 
relative order they had in the original mailbox:

    msglist = []
    for val in msgdict.values():
        msglist.extend(val)
    msglist.sort()
    for i,msg in msglist:
        print msg

email.orig was plucked from the input mailbox and email.new from 
the output mailbox.


----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2002-08-29 09:45

Message:
Logged In: YES 
user_id=44345

Hmmm...  Sometimes seems to *add* whitespace as well.  Here's an 
example using the X-Face: header:

Before:

X-Face: 
$LeJ8}Gzj%b'dmF:@bMiTrpT|UL=3O!CG~3;}dS[43`qefo('''9?B=2a0u*B4u+a)$"DYl
 S

After:

X-Face: $LeJ8}Gzj%b'dmF:@bMiTrpT|UL=3O!CG~3;
	}dS[43`qefo('''9?B=2a0u*B4u+a)$"DYlS



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594893&group_id=5470


From noreply@sourceforge.net  Thu Aug 29 17:26:30 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 29 Aug 2002 09:26:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-601392 ] weird header wrapping in email.Generator
Message-ID: <E17kS7q-0007Za-00@usw-sf-web1.sourceforge.net>

Bugs item #601392, was opened at 2002-08-28 11:14
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=601392&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Ward (gward)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: weird header wrapping in email.Generator

Initial Comment:
I have discovered a particular header line that 
email.Generator does not wrap very well.  Here it is, 
mangled by my web browser and SF:

Received: from 
modemcable093.139-201-24.que.mc.videotron.ca 
([24.201.139.93] helo=cthulhu.gerg.ca)
        by kronos.mems-exchange.org with esmtp (Exim 
4.05)
        id 17k4h5-00034i-00
        for test@mems-exchange.org; Wed, 28 Aug 2002 
11:25:20 -0400

(Only one line, the first, is particularly long.  The other 
three lines all fit comfortably in 78 columns.)

(Oh, I'll try to attach a message consisting solely of this 
header line along with my test script.)

With Python 2.2.1, email.Message.as_string() wraps this 
header line as:

Received: from 
modemcable093.139-201-24.que.mc.videotron.ca 
([24.201.139.93]
        helo=cthulhu.gerg.ca)
        by kronos.mems-exchange.org with esmtp (Exim 
4.05)
        id
        17k4h5-00034i-00
        for test@mems-exchange.org; Wed, 28 Aug 2002 
11:25:20 -0400

(The oddity there is the word "id" alone on a line.)

With CVS Python (as of 10 minutes ago), it's wrapped as:

Received: from 
modemcable093.139-201-24.que.mc.videotron.ca 
([24.201.139.93]
        helo=cthulhu.gerg.ca)
        by kronos.mems-exchange.org with esmtp (Exim 
4.05)id 17k4h5-00034i-00
        for test@mems-exchange.org; Wed, 28 Aug 2002 
11:25:20 -0400

(Note how "id ..." is jammed right up against "(Exim 
4.05)".)



----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2002-08-29 11:26

Message:
Logged In: YES 
user_id=44345

I believe this is a duplicate of the bug report I filed:

    http://python.org/sf/594893

One or the other should probably be closed.


----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2002-08-28 11:28

Message:
Logged In: YES 
user_id=12800

Verified.  Here's a one-file example that illustrates the bug.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=601392&group_id=5470


From noreply@sourceforge.net  Thu Aug 29 19:53:50 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 29 Aug 2002 11:53:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-602029 ] smtplib mishandles empty sender
Message-ID: <E17kUQQ-0006Ho-00@usw-sf-web4.sourceforge.net>

Bugs item #602029, was opened at 2002-08-29 14:53
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602029&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Ward (gward)
Assigned to: Nobody/Anonymous (nobody)
Summary: smtplib mishandles empty sender

Initial Comment:
If you pass a non-empty string to SMTP.mail(), it gets it 
right, ie.
  smtp.mail("gward@python.net")
becomes
  MAIL FROM:<gward@python.net>

But if you pass the empty string, things go badly:
  smtp.mail("")
becomes
  MAIL FROM:
which most SMTP servers should reject.  (I only tried 
one.)

The culprit appears to be the "if not m" branch in 
quoteaddr().  One possible fix:

--- smtplib.py  8 Aug 2002 20:19:18 -0000       1.61
+++ smtplib.py  29 Aug 2002 18:52:42 -0000
@@ -173,11 +173,7 @@
         m=rfc822.parseaddr(addr)[1]
     except AttributeError:
         pass
-    if not m:
-        #something weird here.. punt -ddm
-        return addr
-    else:
-        return "<%s>" % m
+    return "<%s>" % m
 
 def quotedata(data):
     """Quote data for email.

Another possible fix:
--- smtplib.py  8 Aug 2002 20:19:18 -0000       1.61
+++ smtplib.py  29 Aug 2002 18:53:28 -0000
@@ -168,6 +168,8 @@
 
     Should be able to handle anything rfc822.parseaddr 
can handle.
     """
+    if addr == "":
+        return "<>"
     m=None
     try:
         m=rfc822.parseaddr(addr)[1]


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602029&group_id=5470


From noreply@sourceforge.net  Thu Aug 29 21:12:55 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 29 Aug 2002 13:12:55 -0700
Subject: [Python-bugs-list] [ python-Bugs-599838 ] httplib.connect broken in 2.1 branch
Message-ID: <E17kVex-0007sS-00@usw-sf-web4.sourceforge.net>

Bugs item #599838, was opened at 2002-08-25 07:39
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599838&group_id=5470

Category: Python Library
Group: Python 2.1.2
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Matthias Klose (doko)
Assigned to: Jeremy Hylton (jhylton)
Summary: httplib.connect broken in 2.1 branch

Initial Comment:
In the current 2.1 branch, httplib.connect uses
socket.getaddrinfo, which is not available in 2.1:

>>> urllib.connect()

  File "/usr/lib/python2.1/httplib.py", line 509, in
connect 
    for res in socket.getaddrinfo(self.host, self.port, 0, 
AttributeError: 'socket' module has no attribute
'getaddrinfo' 

Introduced in Revison 1.42.10.7 , Fri Jul 12 14:23:38
2002 UTC (6 weeks, 1 day ago) by jhylton 


----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-08-29 20:12

Message:
Logged In: YES 
user_id=31392

Fixed in rev. 1.34.2.6 of httplib.py


----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2002-08-28 04:48

Message:
Logged In: YES 
user_id=60903

IMO a maintainance branch should be in a releasable state
anytime. This one is a regression, so I raised the priority.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-08-27 22:43

Message:
Logged In: YES 
user_id=31392

I'll check into it, but why priority 7?  If there aren't
plans to do a 2.1.4 release soon, then I would call this a
low priority.


----------------------------------------------------------------------

Comment By: Peter Schneider-Kamp (nowonder)
Date: 2002-08-27 15:47

Message:
Logged In: YES 
user_id=14463

This bug is a consequence of the backport changes from
1.34.2.4 to 1.34.2.5 of dist/src/Lib/httplib.py.

Possible resolutions:
a) backport ipv6 updates of dist/src/Modules/socketmodule.c
(happened around revision 1.153) to release21-maint
XOR
b) undo part of the backport of dist/src/Lib/httplib.py,
especially
    HTTPConnection.connect()

Assigning this to Jeremy as he checked in the backport changes.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599838&group_id=5470


From noreply@sourceforge.net  Thu Aug 29 22:13:41 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 29 Aug 2002 14:13:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-602102 ] configure finds c++ w/o --with-cxx
Message-ID: <E17kWbl-0002xM-00@usw-sf-web2.sourceforge.net>

Bugs item #602102, was opened at 2002-08-29 17:13
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602102&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jay T Miller (jaytmiller)
Assigned to: Nobody/Anonymous (nobody)
Summary: configure finds c++ w/o --with-cxx

Initial Comment:
When I run configure on today's Python CVS HEAD (2.3a0)
on an Alpha/Tru64 machine, configure finds c++ even
though I didn't ask for it (and it doesn't work):

odoalpha2> ./configure --prefix=$HOME/work --without-gcc
checking MACHDEP... osf1V5
checking for --without-gcc... yes
checking for --with-cxx=<compiler>... no
checking for c++... c++
checking for C++ compiler default output... a.out
checking whether the C++ compiler works...
1129800:./a.out: /sbin/loader: Fatal Error: Cannot map
library libstdc++.so.2.9.0
configure: error: cannot run C++ compiled programs.
If you meant to cross compile, use `--host'.

Is this a bug?  Is there a simple work around?  



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602102&group_id=5470


From noreply@sourceforge.net  Fri Aug 30 06:40:49 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 29 Aug 2002 22:40:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-602232 ] dict-proxy lacks iter* methods.
Message-ID: <E17keWX-000472-00@usw-sf-web3.sourceforge.net>

Bugs item #602232, was opened at 2002-08-30 01:40
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602232&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Fincher (jemfinch)
Assigned to: Nobody/Anonymous (nobody)
Summary: dict-proxy lacks iter* methods.

Initial Comment:
One would think that, as long as the point of dict-proxy 
is to simply be a read-only dictionary, it should replicate 
all methods that make sense for a read-only dictionary.  
As such, it should have iteritems, iterkeys, and 
itervalues methods.

I don't know any C wizardry, so I can't offer any 
patches, just the suggestion.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602232&group_id=5470


From noreply@sourceforge.net  Fri Aug 30 07:25:49 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 29 Aug 2002 23:25:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-602245 ] os.popen() negative error code IOError
Message-ID: <E17kfE5-0003Jz-00@usw-sf-web5.sourceforge.net>

Bugs item #602245, was opened at 2002-08-30 06:25
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602245&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Delaney (tcdelaney)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.popen() negative error code IOError

Initial Comment:
Windows 2000, Python 2.0.1, 2.1.1, 2.2.

When a negative return code is received by the os.popen
() family, an IOError is raised when the last pipe from the 
process is closed.

The following code demonstrates the problem:

import sys
import os
import traceback

if __name__ == '__main__':

    if len(sys.argv) == 1:
        
        try:
            r = os.popen('%s %s %s' % (sys.executable, 
sys.argv[0], -1,))
            r.close()
        except IOError:
            traceback.print_exc()

        try:
            w, r = os.popen2('%s %s %s' % 
(sys.executable, sys.argv[0], -1,))
            w.close()
            r.close()
        except IOError:
            traceback.print_exc()

        try:
            w, r, e = os.popen3('%s %s %s' % 
(sys.executable, sys.argv[0], -1,))
            w.close()
            r.close()
            e.close()
        except IOError:
            traceback.print_exc()

    else:
        sys.exit(int(sys.argv[1]))

---------- Run ----------
Traceback (most recent call last):
  File "Q:\Viper\src\webvis\tests\test.py", line 11, in ?
    r.close()
IOError: (0, 'Error')
Traceback (most recent call last):
  File "Q:\Viper\src\webvis\tests\test.py", line 18, in ?
    r.close()
IOError: (0, 'Error')
Traceback (most recent call last):
  File "Q:\Viper\src\webvis\tests\test.py", line 26, in ?
    e.close()
IOError: (0, 'Error')


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602245&group_id=5470


From noreply@sourceforge.net  Fri Aug 30 07:57:05 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 29 Aug 2002 23:57:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-588756 ] python should obey the FHS
Message-ID: <E17kfiL-0000D8-00@usw-sf-web4.sourceforge.net>

Bugs item #588756, was opened at 2002-07-30 20:12
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=588756&group_id=5470

Category: Installation
Group: Feature Request
Status: Open
Resolution: None
Priority: 3
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: python should obey the FHS

Initial Comment:
[From: http://bugs.debian.org/134762]

FHS Compliance - .py{,c} are architecture independant
thus belong in /usr/share

The Python manual makes it clear that byte compiled
python files are
 platform independant, and thus belong in
arch-independant packages and stored in /usr/share, as
per the FHS recommendations for such things.

So the request is to store them in
<prefix>/share/pythonX.Y.


----------------------------------------------------------------------

>Comment By: Matthias Klose (doko)
Date: 2002-08-30 06:57

Message:
Logged In: YES 
user_id=60903

The reason given to close the report seems to be invalid.
The FHS has nothing to with Debian (except that we follow
the FHS). The FHS is targeted at Unix distributions, so it's
neither limited to a single distribution nor to Linux
distributions in general.

----------------------------------------------------------------------

Comment By: Gerhard Häring (ghaering)
Date: 2002-08-25 12:41

Message:
Logged In: YES 
user_id=163326

Python runs on dozens of platforms besides Debian Linux.
Thus the Linux FHS shouldn't concern Python at all. I'd
propose to close this bug as "Invalid".

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-03 11:13

Message:
Logged In: YES 
user_id=21627

I think this requires a PEP. A Python package can consist of
byte code modules and extension modules; arranging the
package loader to find those in different directories is a
challenge.

----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2002-07-30 20:15

Message:
Logged In: YES 
user_id=60903

FHS: Filesystem Hierarchy Standard

    http://www.pathname.com/fhs/


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=588756&group_id=5470


From noreply@sourceforge.net  Fri Aug 30 08:26:11 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 30 Aug 2002 00:26:11 -0700
Subject: [Python-bugs-list] [ python-Bugs-602259 ] 3rd parameter for Tkinter.scan_dragto
Message-ID: <E17kgAV-0004Xr-00@usw-sf-web2.sourceforge.net>

Bugs item #602259, was opened at 2002-08-30 07:26
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602259&group_id=5470

Category: Tkinter
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: 3rd parameter for Tkinter.scan_dragto

Initial Comment:
In Tk8.3 (possibly earlier), one can add a third
optional parameter, called "gain", which determines the
multiplier used when performing the panning operation.
 The Tkinter call does not allow this parameter to be
passed in the resultant Tk's default gain of 10 is
often unusable.

Work around is to just do this call manually:

    self.canv.tk.call(self.canv._w, 'scan', 'dragto',
event.x, event.y, 1)

uses a gain of `1'.

[from http://bugs.debian.org/158168]


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602259&group_id=5470


From noreply@sourceforge.net  Fri Aug 30 09:35:15 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 30 Aug 2002 01:35:15 -0700
Subject: [Python-bugs-list] [ python-Bugs-588756 ] python should obey the FHS
Message-ID: <E17khFL-0002Nf-00@usw-sf-web4.sourceforge.net>

Bugs item #588756, was opened at 2002-07-30 22:12
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=588756&group_id=5470

Category: Installation
Group: Feature Request
Status: Open
Resolution: None
Priority: 3
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: python should obey the FHS

Initial Comment:
[From: http://bugs.debian.org/134762]

FHS Compliance - .py{,c} are architecture independant
thus belong in /usr/share

The Python manual makes it clear that byte compiled
python files are
 platform independant, and thus belong in
arch-independant packages and stored in /usr/share, as
per the FHS recommendations for such things.

So the request is to store them in
<prefix>/share/pythonX.Y.


----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2002-08-30 10:35

Message:
Logged In: YES 
user_id=45365

I'm confused. If you configure with --exec-prefix=/foo --prefix=/foo/share/pythonX.Y isn't that good enough?

If it's good enough (i.e. if it allows you to build a Python that adheres to the FHS if you are so inclined) that I agree with ghaering: there's no reason to force people to adhere to the Filesystem Hierarchy Standard, so let's close the bug.

If it is impossible to make an FHS-compliant distribution with the current setup: please explain.

----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2002-08-30 08:57

Message:
Logged In: YES 
user_id=60903

The reason given to close the report seems to be invalid.
The FHS has nothing to with Debian (except that we follow
the FHS). The FHS is targeted at Unix distributions, so it's
neither limited to a single distribution nor to Linux
distributions in general.

----------------------------------------------------------------------

Comment By: Gerhard Häring (ghaering)
Date: 2002-08-25 14:41

Message:
Logged In: YES 
user_id=163326

Python runs on dozens of platforms besides Debian Linux.
Thus the Linux FHS shouldn't concern Python at all. I'd
propose to close this bug as "Invalid".

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-03 13:13

Message:
Logged In: YES 
user_id=21627

I think this requires a PEP. A Python package can consist of
byte code modules and extension modules; arranging the
package loader to find those in different directories is a
challenge.

----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2002-07-30 22:15

Message:
Logged In: YES 
user_id=60903

FHS: Filesystem Hierarchy Standard

    http://www.pathname.com/fhs/


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=588756&group_id=5470


From noreply@sourceforge.net  Fri Aug 30 09:37:06 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 30 Aug 2002 01:37:06 -0700
Subject: [Python-bugs-list] [ python-Bugs-602291 ] Bgen should learn about booleans
Message-ID: <E17khH8-0006oJ-00@usw-sf-web5.sourceforge.net>

Bugs item #602291, was opened at 2002-08-30 10:37
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602291&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: Bgen should learn about booleans

Initial Comment:
Bgen should be taught about booleans, and the various Mac toolbox modules too.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602291&group_id=5470


From noreply@sourceforge.net  Fri Aug 30 09:47:44 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 30 Aug 2002 01:47:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-602295 ] Core dump in 2.2.1
Message-ID: <E17khRQ-0006MM-00@usw-sf-web2.sourceforge.net>

Bugs item #602295, was opened at 2002-08-30 04:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602295&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Fincher (jemfinch)
Assigned to: Nobody/Anonymous (nobody)
Summary: Core dump in 2.2.1

Initial Comment:
$ python
Python 2.2.1 (#1, Aug 23 2002, 05:57:24)
[GCC 2.95.3-5 (cygwin special)] on cygwin
Type "help", "copyright", "credits" or "license" for more 
information.
>>> class C(object):
...   __slots__ = ()
...
>>> c = C()
>>> del c.__class__
Segmentation fault (core dumped)

Attached is the stack dump.  I didn't see any actual 
core dump.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602295&group_id=5470


From noreply@sourceforge.net  Fri Aug 30 10:58:23 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 30 Aug 2002 02:58:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-602295 ] Core dump in 2.2.1
Message-ID: <E17kiXn-0000Ux-00@usw-sf-web5.sourceforge.net>

Bugs item #602295, was opened at 2002-08-30 08:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602295&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Jeremy Fincher (jemfinch)
>Assigned to: Michael Hudson (mwh)
Summary: Core dump in 2.2.1

Initial Comment:
$ python
Python 2.2.1 (#1, Aug 23 2002, 05:57:24)
[GCC 2.95.3-5 (cygwin special)] on cygwin
Type "help", "copyright", "credits" or "license" for more 
information.
>>> class C(object):
...   __slots__ = ()
...
>>> c = C()
>>> del c.__class__
Segmentation fault (core dumped)

Attached is the stack dump.  I didn't see any actual 
core dump.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-08-30 09:58

Message:
Logged In: YES 
user_id=6656

I think this is a dup of

[ 541883 ] delattr() causes python to segfault

which has been fixed on the trunk and on the 22-maint branch.

At any rate, your test no longer fails for me.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602295&group_id=5470


From noreply@sourceforge.net  Fri Aug 30 11:07:10 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 30 Aug 2002 03:07:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-601775 ] some int results that should be bool
Message-ID: <E17kigI-0000fW-00@usw-sf-web5.sourceforge.net>

Bugs item #601775, was opened at 2002-08-29 12:53
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=601775&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 3
Submitted By: Christos Georgiou (tzot)
>Assigned to: Jeremy Hylton (jhylton)
Summary: some int results that should be bool

Initial Comment:
Posting this as a SF bug since the relevant patch would 
be very small.  (I can post it as a patch if requested, 
though).

1.
cStringIO.c, line 136, IO_isatty returns PyInt_FromLong
(0), while this should be PyBool_FromLong(0).
StringIO.isatty returns False --which is <type bool>-- 
and so should cStringIO.

Note: documentation states that file-like objects not 
being real files should not define this method.  Perhaps 
it should be removed from cStringIO and StringIO.

2.
posixmodule.c, line 759, posix_access returns 
PyInt_FromLong.  It should be PyBool_FromLong.

3. (rather indifferent, this one)
svmodule.c, line 393, sv_IsVideoDisplayed should return 
a bool also.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=601775&group_id=5470


From noreply@sourceforge.net  Fri Aug 30 11:52:45 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 30 Aug 2002 03:52:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-588756 ] python should obey the FHS
Message-ID: <E17kjOO-0005l6-00@usw-sf-web4.sourceforge.net>

Bugs item #588756, was opened at 2002-07-30 20:12
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=588756&group_id=5470

Category: Installation
Group: Feature Request
Status: Open
Resolution: None
Priority: 3
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: python should obey the FHS

Initial Comment:
[From: http://bugs.debian.org/134762]

FHS Compliance - .py{,c} are architecture independant
thus belong in /usr/share

The Python manual makes it clear that byte compiled
python files are
 platform independant, and thus belong in
arch-independant packages and stored in /usr/share, as
per the FHS recommendations for such things.

So the request is to store them in
<prefix>/share/pythonX.Y.


----------------------------------------------------------------------

>Comment By: Matthias Klose (doko)
Date: 2002-08-30 10:52

Message:
Logged In: YES 
user_id=60903

Not yet.

--prefix=/foo/share/pythonX.Y would lead to
/foo/share/pythonX.Y/lib/pythonX.Y.

The SCRIPTDIR is somewhat hardcoded in getpath.c. So it's
not possible
to install into /foo/share/pythonX.Y, only
/foo/share/lib/pythonX.Y is supported.

The FHS doesn't specify where to put files inside
/usr/share, but most distributions put application specific
files directly in /usr/share.


----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-08-30 08:35

Message:
Logged In: YES 
user_id=45365

I'm confused. If you configure with --exec-prefix=/foo --prefix=/foo/share/pythonX.Y isn't that good enough?

If it's good enough (i.e. if it allows you to build a Python that adheres to the FHS if you are so inclined) that I agree with ghaering: there's no reason to force people to adhere to the Filesystem Hierarchy Standard, so let's close the bug.

If it is impossible to make an FHS-compliant distribution with the current setup: please explain.

----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2002-08-30 06:57

Message:
Logged In: YES 
user_id=60903

The reason given to close the report seems to be invalid.
The FHS has nothing to with Debian (except that we follow
the FHS). The FHS is targeted at Unix distributions, so it's
neither limited to a single distribution nor to Linux
distributions in general.

----------------------------------------------------------------------

Comment By: Gerhard Häring (ghaering)
Date: 2002-08-25 12:41

Message:
Logged In: YES 
user_id=163326

Python runs on dozens of platforms besides Debian Linux.
Thus the Linux FHS shouldn't concern Python at all. I'd
propose to close this bug as "Invalid".

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-03 11:13

Message:
Logged In: YES 
user_id=21627

I think this requires a PEP. A Python package can consist of
byte code modules and extension modules; arranging the
package loader to find those in different directories is a
challenge.

----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2002-07-30 20:15

Message:
Logged In: YES 
user_id=60903

FHS: Filesystem Hierarchy Standard

    http://www.pathname.com/fhs/


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=588756&group_id=5470


From noreply@sourceforge.net  Fri Aug 30 12:13:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 30 Aug 2002 04:13:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-602345 ] option for not writing .py[co] files
Message-ID: <E17kji3-00016G-00@usw-sf-web3.sourceforge.net>

Bugs item #602345, was opened at 2002-08-30 11:13
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602345&group_id=5470

Category: Python Interpreter Core
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: option for not writing .py[co] files

Initial Comment:
[destilled from http://bugs.debian.org/96111]

Currently python tries to write the .py[co] files even
in situations, where it will fail, like on read-only
mounted file systems.

In other situations I don't want python trying to write
the compiled files, i.e. having installed the modules
as root as part of a distribution, compiled them
correctly, there is no need to write them. Or compiling
.py files which are configuration files.

Is it reasonable to add an option to python
(--dont-write-compiled-files) to the interpreter, which
doesn't write them? This would not affect existing code
at all.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602345&group_id=5470


From noreply@sourceforge.net  Fri Aug 30 12:13:23 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 30 Aug 2002 04:13:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-602345 ] option for not writing .py[co] files
Message-ID: <E17kjiN-0002L8-00@usw-sf-web5.sourceforge.net>

Bugs item #602345, was opened at 2002-08-30 11:13
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602345&group_id=5470

Category: Python Interpreter Core
Group: Feature Request
Status: Open
Resolution: None
>Priority: 3
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: option for not writing .py[co] files

Initial Comment:
[destilled from http://bugs.debian.org/96111]

Currently python tries to write the .py[co] files even
in situations, where it will fail, like on read-only
mounted file systems.

In other situations I don't want python trying to write
the compiled files, i.e. having installed the modules
as root as part of a distribution, compiled them
correctly, there is no need to write them. Or compiling
.py files which are configuration files.

Is it reasonable to add an option to python
(--dont-write-compiled-files) to the interpreter, which
doesn't write them? This would not affect existing code
at all.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602345&group_id=5470


From noreply@sourceforge.net  Fri Aug 30 12:30:17 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 30 Aug 2002 04:30:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-588756 ] python should obey the FHS
Message-ID: <E17kjyj-0002pg-00@usw-sf-web5.sourceforge.net>

Bugs item #588756, was opened at 2002-07-30 20:12
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=588756&group_id=5470

Category: Installation
Group: Feature Request
Status: Open
Resolution: None
Priority: 3
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: python should obey the FHS

Initial Comment:
[From: http://bugs.debian.org/134762]

FHS Compliance - .py{,c} are architecture independant
thus belong in /usr/share

The Python manual makes it clear that byte compiled
python files are
 platform independant, and thus belong in
arch-independant packages and stored in /usr/share, as
per the FHS recommendations for such things.

So the request is to store them in
<prefix>/share/pythonX.Y.


----------------------------------------------------------------------

>Comment By: Matthias Klose (doko)
Date: 2002-08-30 11:30

Message:
Logged In: YES 
user_id=60903

when configured with --prefix=/usr/share and
--exec-prefix=/usr, python installs the header files into
/usr/share/include/pythonX.Y, which is at least unusual.
According to the FHS these files should go into
/usr/include/pythonX.Y


----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2002-08-30 10:52

Message:
Logged In: YES 
user_id=60903

Not yet.

--prefix=/foo/share/pythonX.Y would lead to
/foo/share/pythonX.Y/lib/pythonX.Y.

The SCRIPTDIR is somewhat hardcoded in getpath.c. So it's
not possible
to install into /foo/share/pythonX.Y, only
/foo/share/lib/pythonX.Y is supported.

The FHS doesn't specify where to put files inside
/usr/share, but most distributions put application specific
files directly in /usr/share.


----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-08-30 08:35

Message:
Logged In: YES 
user_id=45365

I'm confused. If you configure with --exec-prefix=/foo --prefix=/foo/share/pythonX.Y isn't that good enough?

If it's good enough (i.e. if it allows you to build a Python that adheres to the FHS if you are so inclined) that I agree with ghaering: there's no reason to force people to adhere to the Filesystem Hierarchy Standard, so let's close the bug.

If it is impossible to make an FHS-compliant distribution with the current setup: please explain.

----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2002-08-30 06:57

Message:
Logged In: YES 
user_id=60903

The reason given to close the report seems to be invalid.
The FHS has nothing to with Debian (except that we follow
the FHS). The FHS is targeted at Unix distributions, so it's
neither limited to a single distribution nor to Linux
distributions in general.

----------------------------------------------------------------------

Comment By: Gerhard Häring (ghaering)
Date: 2002-08-25 12:41

Message:
Logged In: YES 
user_id=163326

Python runs on dozens of platforms besides Debian Linux.
Thus the Linux FHS shouldn't concern Python at all. I'd
propose to close this bug as "Invalid".

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-03 11:13

Message:
Logged In: YES 
user_id=21627

I think this requires a PEP. A Python package can consist of
byte code modules and extension modules; arranging the
package loader to find those in different directories is a
challenge.

----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2002-07-30 20:15

Message:
Logged In: YES 
user_id=60903

FHS: Filesystem Hierarchy Standard

    http://www.pathname.com/fhs/


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=588756&group_id=5470


From noreply@sourceforge.net  Fri Aug 30 12:47:19 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 30 Aug 2002 04:47:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-595105 ] AESend on Jaguar
Message-ID: <E17kkFD-00071f-00@usw-sf-web4.sourceforge.net>

Bugs item #595105, was opened at 2002-08-14 18:02
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595105&group_id=5470

Category: Macintosh
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexandre Parenteau (aubonbeurre)
Assigned to: Jack Jansen (jackjansen)
Summary: AESend on Jaguar

Initial Comment:
I wonder how many of you guys played with Jaguar 
(OSX 10.2). It is also my
first glance at gcc 3.1 that comes with 10.2. Everything 
was fine for
building Python, except for waste which has an 
obsolete libWaste.a (even in
August 1st Waste 2.1b1) which won't compile with 
gcc3.1. After I recompiled
waste with CodeWarrior 8.2 (MPTP: early access), it 
came OK.

I then run into some problems of checked out files 
because I'm using MacCvs
(see earlier message). I used the 'make 
frameworkinstall' scheme.

Now I'm experiencing the nice new architecture. I 
mostly use python from the
command line to invoke CodeWarrior thru AppleScripts, 
so I almost immeditly
run into a hanging problems of python :

        _err = AESend(&_self->ob_itself,
                      &reply,
                      sendMode,
                      sendPriority,
                      timeOutInTicks,
                      0L/*upp_AEIdleProc*/,
                      (AEFilterUPP)0);

I had to comment out upp_AEIdleProc (I tried several 
things, but that is the
only thing which helped). Jack, you might want to 
remember this one if the
problem is still in Jaguar. It hangs and finally times out. 
I've looked
inside this function and I can see the signal handling, 
but I'm not sure
what it is for.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2002-08-30 13:47

Message:
Logged In: YES 
user_id=45365

The problem turns out to be that under Jaguar you must *not* pass an 
idle routine if you haven't done all the correct toolbox initializations yet.

To verify this, do something like "import EasyDialogs; 
EasyDialogs.Message("There we go")" at the start of your script. 
Everything now works fine.

Somehow, if you haven't initialized, the idle routine will be called with 
random garbage, and it will be called continuously.

The question is: what's the best way to fix this? I noticed that even a 
simple Carbon.Evt.WaitNextEvent(0,0) in your test script is enough to 
make it work. Should we call this in the init_AE() routine? in AESend()?


----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-08-19 16:45

Message:
Logged In: YES 
user_id=45365

Alexandre,
I tried a few simple things with the AE module (talking to CodeWarrior) 
on Jaguar, but I can't get it to hang.

Could you give me an example script that shows the problem?

Also: I've been using MachoPython from the CVS HEAD, I assume 
you're using the same, right?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595105&group_id=5470


From noreply@sourceforge.net  Fri Aug 30 13:33:11 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 30 Aug 2002 05:33:11 -0700
Subject: [Python-bugs-list] [ python-Bugs-588756 ] python should obey the FHS
Message-ID: <E17kkxb-0007up-00@usw-sf-web4.sourceforge.net>

Bugs item #588756, was opened at 2002-07-30 22:12
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=588756&group_id=5470

Category: Installation
Group: Feature Request
Status: Open
Resolution: None
Priority: 3
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: python should obey the FHS

Initial Comment:
[From: http://bugs.debian.org/134762]

FHS Compliance - .py{,c} are architecture independant
thus belong in /usr/share

The Python manual makes it clear that byte compiled
python files are
 platform independant, and thus belong in
arch-independant packages and stored in /usr/share, as
per the FHS recommendations for such things.

So the request is to store them in
<prefix>/share/pythonX.Y.


----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2002-08-30 14:33

Message:
Logged In: YES 
user_id=45365

Well... the usual way in which people implemented sharing between 
architectures was that the /usr/share hierarchy duplicated the other 
hierarchies (i.e. with bin, lib, etc), and it was simply mounted cross-
platform from an nfs server. That's the architecture the Python install 
was created for. I have no idea why FHS modified this test-and-tried 
layout that's been in use for at least 15 years.

But: if you really want the other layout, why not submit a fix to 
configure.in and Makefile.pre.in? Simply add, say, --fhs-prefix=/usr/
share and if that option is present override the Makefile.pre.in 
declarations for SCRIPTDIR, LIBDEST and INCLUDEDIR?

(Hmm, coming to think of it: it seems rather silly that the FHS puts 
include files into /usr/include, where they aren't shared... If there's one 
thing that can be crossplatform it's source code....)

----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2002-08-30 13:30

Message:
Logged In: YES 
user_id=60903

when configured with --prefix=/usr/share and
--exec-prefix=/usr, python installs the header files into
/usr/share/include/pythonX.Y, which is at least unusual.
According to the FHS these files should go into
/usr/include/pythonX.Y


----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2002-08-30 12:52

Message:
Logged In: YES 
user_id=60903

Not yet.

--prefix=/foo/share/pythonX.Y would lead to
/foo/share/pythonX.Y/lib/pythonX.Y.

The SCRIPTDIR is somewhat hardcoded in getpath.c. So it's
not possible
to install into /foo/share/pythonX.Y, only
/foo/share/lib/pythonX.Y is supported.

The FHS doesn't specify where to put files inside
/usr/share, but most distributions put application specific
files directly in /usr/share.


----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-08-30 10:35

Message:
Logged In: YES 
user_id=45365

I'm confused. If you configure with --exec-prefix=/foo --prefix=/foo/share/pythonX.Y isn't that good enough?

If it's good enough (i.e. if it allows you to build a Python that adheres to the FHS if you are so inclined) that I agree with ghaering: there's no reason to force people to adhere to the Filesystem Hierarchy Standard, so let's close the bug.

If it is impossible to make an FHS-compliant distribution with the current setup: please explain.

----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2002-08-30 08:57

Message:
Logged In: YES 
user_id=60903

The reason given to close the report seems to be invalid.
The FHS has nothing to with Debian (except that we follow
the FHS). The FHS is targeted at Unix distributions, so it's
neither limited to a single distribution nor to Linux
distributions in general.

----------------------------------------------------------------------

Comment By: Gerhard Häring (ghaering)
Date: 2002-08-25 14:41

Message:
Logged In: YES 
user_id=163326

Python runs on dozens of platforms besides Debian Linux.
Thus the Linux FHS shouldn't concern Python at all. I'd
propose to close this bug as "Invalid".

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-03 13:13

Message:
Logged In: YES 
user_id=21627

I think this requires a PEP. A Python package can consist of
byte code modules and extension modules; arranging the
package loader to find those in different directories is a
challenge.

----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2002-07-30 22:15

Message:
Logged In: YES 
user_id=60903

FHS: Filesystem Hierarchy Standard

    http://www.pathname.com/fhs/


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=588756&group_id=5470


From noreply@sourceforge.net  Fri Aug 30 13:33:12 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 30 Aug 2002 05:33:12 -0700
Subject: [Python-bugs-list] [ python-Bugs-588756 ] python should obey the FHS
Message-ID: <E17kkxc-0007ut-00@usw-sf-web4.sourceforge.net>

Bugs item #588756, was opened at 2002-07-30 22:12
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=588756&group_id=5470

Category: Installation
Group: Feature Request
Status: Open
Resolution: None
Priority: 3
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: python should obey the FHS

Initial Comment:
[From: http://bugs.debian.org/134762]

FHS Compliance - .py{,c} are architecture independant
thus belong in /usr/share

The Python manual makes it clear that byte compiled
python files are
 platform independant, and thus belong in
arch-independant packages and stored in /usr/share, as
per the FHS recommendations for such things.

So the request is to store them in
<prefix>/share/pythonX.Y.


----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2002-08-30 14:33

Message:
Logged In: YES 
user_id=45365

Well... the usual way in which people implemented sharing between 
architectures was that the /usr/share hierarchy duplicated the other 
hierarchies (i.e. with bin, lib, etc), and it was simply mounted cross-
platform from an nfs server. That's the architecture the Python install 
was created for. I have no idea why FHS modified this test-and-tried 
layout that's been in use for at least 15 years.

But: if you really want the other layout, why not submit a fix to 
configure.in and Makefile.pre.in? Simply add, say, --fhs-prefix=/usr/
share and if that option is present override the Makefile.pre.in 
declarations for SCRIPTDIR, LIBDEST and INCLUDEDIR?

(Hmm, coming to think of it: it seems rather silly that the FHS puts 
include files into /usr/include, where they aren't shared... If there's one 
thing that can be crossplatform it's source code....)

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-08-30 14:33

Message:
Logged In: YES 
user_id=45365

Well... the usual way in which people implemented sharing between 
architectures was that the /usr/share hierarchy duplicated the other 
hierarchies (i.e. with bin, lib, etc), and it was simply mounted cross-
platform from an nfs server. That's the architecture the Python install 
was created for. I have no idea why FHS modified this test-and-tried 
layout that's been in use for at least 15 years.

But: if you really want the other layout, why not submit a fix to 
configure.in and Makefile.pre.in? Simply add, say, --fhs-prefix=/usr/
share and if that option is present override the Makefile.pre.in 
declarations for SCRIPTDIR, LIBDEST and INCLUDEDIR?

(Hmm, coming to think of it: it seems rather silly that the FHS puts 
include files into /usr/include, where they aren't shared... If there's one 
thing that can be crossplatform it's source code....)

----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2002-08-30 13:30

Message:
Logged In: YES 
user_id=60903

when configured with --prefix=/usr/share and
--exec-prefix=/usr, python installs the header files into
/usr/share/include/pythonX.Y, which is at least unusual.
According to the FHS these files should go into
/usr/include/pythonX.Y


----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2002-08-30 12:52

Message:
Logged In: YES 
user_id=60903

Not yet.

--prefix=/foo/share/pythonX.Y would lead to
/foo/share/pythonX.Y/lib/pythonX.Y.

The SCRIPTDIR is somewhat hardcoded in getpath.c. So it's
not possible
to install into /foo/share/pythonX.Y, only
/foo/share/lib/pythonX.Y is supported.

The FHS doesn't specify where to put files inside
/usr/share, but most distributions put application specific
files directly in /usr/share.


----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-08-30 10:35

Message:
Logged In: YES 
user_id=45365

I'm confused. If you configure with --exec-prefix=/foo --prefix=/foo/share/pythonX.Y isn't that good enough?

If it's good enough (i.e. if it allows you to build a Python that adheres to the FHS if you are so inclined) that I agree with ghaering: there's no reason to force people to adhere to the Filesystem Hierarchy Standard, so let's close the bug.

If it is impossible to make an FHS-compliant distribution with the current setup: please explain.

----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2002-08-30 08:57

Message:
Logged In: YES 
user_id=60903

The reason given to close the report seems to be invalid.
The FHS has nothing to with Debian (except that we follow
the FHS). The FHS is targeted at Unix distributions, so it's
neither limited to a single distribution nor to Linux
distributions in general.

----------------------------------------------------------------------

Comment By: Gerhard Häring (ghaering)
Date: 2002-08-25 14:41

Message:
Logged In: YES 
user_id=163326

Python runs on dozens of platforms besides Debian Linux.
Thus the Linux FHS shouldn't concern Python at all. I'd
propose to close this bug as "Invalid".

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-03 13:13

Message:
Logged In: YES 
user_id=21627

I think this requires a PEP. A Python package can consist of
byte code modules and extension modules; arranging the
package loader to find those in different directories is a
challenge.

----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2002-07-30 22:15

Message:
Logged In: YES 
user_id=60903

FHS: Filesystem Hierarchy Standard

    http://www.pathname.com/fhs/


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=588756&group_id=5470


From noreply@sourceforge.net  Fri Aug 30 13:38:28 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 30 Aug 2002 05:38:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-602245 ] os.popen() negative error code IOError
Message-ID: <E17kl2i-00028w-00@usw-sf-web2.sourceforge.net>

Bugs item #602245, was opened at 2002-08-30 01:25
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602245&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Delaney (tcdelaney)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.popen() negative error code IOError

Initial Comment:
Windows 2000, Python 2.0.1, 2.1.1, 2.2.

When a negative return code is received by the os.popen
() family, an IOError is raised when the last pipe from the 
process is closed.

The following code demonstrates the problem:

import sys
import os
import traceback

if __name__ == '__main__':

    if len(sys.argv) == 1:
        
        try:
            r = os.popen('%s %s %s' % (sys.executable, 
sys.argv[0], -1,))
            r.close()
        except IOError:
            traceback.print_exc()

        try:
            w, r = os.popen2('%s %s %s' % 
(sys.executable, sys.argv[0], -1,))
            w.close()
            r.close()
        except IOError:
            traceback.print_exc()

        try:
            w, r, e = os.popen3('%s %s %s' % 
(sys.executable, sys.argv[0], -1,))
            w.close()
            r.close()
            e.close()
        except IOError:
            traceback.print_exc()

    else:
        sys.exit(int(sys.argv[1]))

---------- Run ----------
Traceback (most recent call last):
  File "Q:\Viper\src\webvis\tests\test.py", line 11, in ?
    r.close()
IOError: (0, 'Error')
Traceback (most recent call last):
  File "Q:\Viper\src\webvis\tests\test.py", line 18, in ?
    r.close()
IOError: (0, 'Error')
Traceback (most recent call last):
  File "Q:\Viper\src\webvis\tests\test.py", line 26, in ?
    e.close()
IOError: (0, 'Error')


----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2002-08-30 07:38

Message:
Logged In: YES 
user_id=44345

Attached Tim's code so it's more readily accessible to testers.
BTW, works fine for me on Linux.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602245&group_id=5470


From noreply@sourceforge.net  Fri Aug 30 13:58:14 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 30 Aug 2002 05:58:14 -0700
Subject: [Python-bugs-list] [ python-Bugs-602398 ] Jaguar "install" does not overwrite
Message-ID: <E17klLq-0003of-00@usw-sf-web3.sourceforge.net>

Bugs item #602398, was opened at 2002-08-30 14:58
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602398&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: Jaguar "install" does not overwrite

Initial Comment:
Jaguar has a new version of the "install" program (taken from 4.4BSD, according to the man page) which uses copy in stead of move to install stuff. This makes it fail when you re-install Python.

An obvious fix is to use install-sh, but this has the disadvantage of being dead slow.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602398&group_id=5470


From noreply@sourceforge.net  Fri Aug 30 14:15:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 30 Aug 2002 06:15:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-602102 ] configure finds c++ w/o --with-cxx
Message-ID: <E17klc6-0008CP-00@usw-sf-web1.sourceforge.net>

Bugs item #602102, was opened at 2002-08-29 17:13
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602102&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jay T Miller (jaytmiller)
Assigned to: Nobody/Anonymous (nobody)
Summary: configure finds c++ w/o --with-cxx

Initial Comment:
When I run configure on today's Python CVS HEAD (2.3a0)
on an Alpha/Tru64 machine, configure finds c++ even
though I didn't ask for it (and it doesn't work):

odoalpha2> ./configure --prefix=$HOME/work --without-gcc
checking MACHDEP... osf1V5
checking for --without-gcc... yes
checking for --with-cxx=<compiler>... no
checking for c++... c++
checking for C++ compiler default output... a.out
checking whether the C++ compiler works...
1129800:./a.out: /sbin/loader: Fatal Error: Cannot map
library libstdc++.so.2.9.0
configure: error: cannot run C++ compiled programs.
If you meant to cross compile, use `--host'.

Is this a bug?  Is there a simple work around?  



----------------------------------------------------------------------

Comment By: Jay T Miller (jaytmiller)
Date: 2002-08-30 09:15

Message:
Logged In: YES 
user_id=320512

Sorry about this one guys.   Looks like the secret is:

--with-cxx=no  

Please close this.







----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602102&group_id=5470


From noreply@sourceforge.net  Fri Aug 30 15:05:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 30 Aug 2002 07:05:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-602245 ] os.popen() negative error code IOError
Message-ID: <E17kmOt-0000rO-00@usw-sf-web1.sourceforge.net>

Bugs item #602245, was opened at 2002-08-30 02:25
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602245&group_id=5470

>Category: Windows
>Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Delaney (tcdelaney)
>Assigned to: Mark Hammond (mhammond)
Summary: os.popen() negative error code IOError

Initial Comment:
Windows 2000, Python 2.0.1, 2.1.1, 2.2.

When a negative return code is received by the os.popen
() family, an IOError is raised when the last pipe from the 
process is closed.

The following code demonstrates the problem:

import sys
import os
import traceback

if __name__ == '__main__':

    if len(sys.argv) == 1:
        
        try:
            r = os.popen('%s %s %s' % (sys.executable, 
sys.argv[0], -1,))
            r.close()
        except IOError:
            traceback.print_exc()

        try:
            w, r = os.popen2('%s %s %s' % 
(sys.executable, sys.argv[0], -1,))
            w.close()
            r.close()
        except IOError:
            traceback.print_exc()

        try:
            w, r, e = os.popen3('%s %s %s' % 
(sys.executable, sys.argv[0], -1,))
            w.close()
            r.close()
            e.close()
        except IOError:
            traceback.print_exc()

    else:
        sys.exit(int(sys.argv[1]))

---------- Run ----------
Traceback (most recent call last):
  File "Q:\Viper\src\webvis\tests\test.py", line 11, in ?
    r.close()
IOError: (0, 'Error')
Traceback (most recent call last):
  File "Q:\Viper\src\webvis\tests\test.py", line 18, in ?
    r.close()
IOError: (0, 'Error')
Traceback (most recent call last):
  File "Q:\Viper\src\webvis\tests\test.py", line 26, in ?
    e.close()
IOError: (0, 'Error')


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-30 10:05

Message:
Logged In: YES 
user_id=6380

I suppose this is one for Mark Hammond...

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-08-30 08:38

Message:
Logged In: YES 
user_id=44345

Attached Tim's code so it's more readily accessible to testers.
BTW, works fine for me on Linux.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602245&group_id=5470


From noreply@sourceforge.net  Fri Aug 30 15:44:20 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 30 Aug 2002 07:44:20 -0700
Subject: [Python-bugs-list] [ python-Bugs-602444 ] non greedy match bug
Message-ID: <E17kn0W-0007F0-00@usw-sf-web5.sourceforge.net>

Bugs item #602444, was opened at 2002-08-30 10:44
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602444&group_id=5470

Category: Regular Expressions
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Robert Roy (rjroy)
Assigned to: Fredrik Lundh (effbot)
Summary: non greedy match bug

Initial Comment:
When using the following re to extract all objects from a 
PDF file, I get a maximum recursion limit exceeded error.

Attached is a pdf file that will reproduce the error.

If I do import pre as re, it works fine.

platform is Win2k, Python 2.2.1 build #34

#######
import re

GETOBJECT = re.compile(r'\d+\s+\d+\s+obj.+?endobj', 
re.I|re.S|re.M)

pdf = open('userguide.pdf', 'rb').read()
all = GETOBJECT.findall(pdf)
print len(all)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602444&group_id=5470


From noreply@sourceforge.net  Fri Aug 30 21:24:23 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 30 Aug 2002 13:24:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-588756 ] python should obey the FHS
Message-ID: <E17ksJb-0001Lm-00@usw-sf-web4.sourceforge.net>

Bugs item #588756, was opened at 2002-07-30 22:12
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=588756&group_id=5470

Category: Installation
Group: Feature Request
Status: Open
Resolution: None
Priority: 3
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: python should obey the FHS

Initial Comment:
[From: http://bugs.debian.org/134762]

FHS Compliance - .py{,c} are architecture independant
thus belong in /usr/share

The Python manual makes it clear that byte compiled
python files are
 platform independant, and thus belong in
arch-independant packages and stored in /usr/share, as
per the FHS recommendations for such things.

So the request is to store them in
<prefix>/share/pythonX.Y.


----------------------------------------------------------------------

Comment By: Gerhard Häring (ghaering)
Date: 2002-08-30 22:24

Message:
Logged In: YES 
user_id=163326

I assume that the Python directory layout is the same on all
currently supported platforms by Python. I really don't know
enough to be sure - the less that's true, the less my
following argument will be valid:

There are really two concerns:
1) make Python conform to the FHS
2) make Python behave the same cross-platform (Windows,
Unix, Mac, BeOS, OS/2, VMS, AS/400, ...)

You can't have both unless you force the FHS directory
layout onto all other platforms. I personally think that 2)
is a good thing.

I welcome the proposal of a configuration option to make
Python FHS-compliant, but I think it should not be the
default. Btw. you'd probably have to patch distutils, too.

Jack said that Pyhon include files should be cross-platform.
AFAIK they are, with one exceptions: pyconfig.h.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-08-30 14:33

Message:
Logged In: YES 
user_id=45365

Well... the usual way in which people implemented sharing between 
architectures was that the /usr/share hierarchy duplicated the other 
hierarchies (i.e. with bin, lib, etc), and it was simply mounted cross-
platform from an nfs server. That's the architecture the Python install 
was created for. I have no idea why FHS modified this test-and-tried 
layout that's been in use for at least 15 years.

But: if you really want the other layout, why not submit a fix to 
configure.in and Makefile.pre.in? Simply add, say, --fhs-prefix=/usr/
share and if that option is present override the Makefile.pre.in 
declarations for SCRIPTDIR, LIBDEST and INCLUDEDIR?

(Hmm, coming to think of it: it seems rather silly that the FHS puts 
include files into /usr/include, where they aren't shared... If there's one 
thing that can be crossplatform it's source code....)

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-08-30 14:33

Message:
Logged In: YES 
user_id=45365

Well... the usual way in which people implemented sharing between 
architectures was that the /usr/share hierarchy duplicated the other 
hierarchies (i.e. with bin, lib, etc), and it was simply mounted cross-
platform from an nfs server. That's the architecture the Python install 
was created for. I have no idea why FHS modified this test-and-tried 
layout that's been in use for at least 15 years.

But: if you really want the other layout, why not submit a fix to 
configure.in and Makefile.pre.in? Simply add, say, --fhs-prefix=/usr/
share and if that option is present override the Makefile.pre.in 
declarations for SCRIPTDIR, LIBDEST and INCLUDEDIR?

(Hmm, coming to think of it: it seems rather silly that the FHS puts 
include files into /usr/include, where they aren't shared... If there's one 
thing that can be crossplatform it's source code....)

----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2002-08-30 13:30

Message:
Logged In: YES 
user_id=60903

when configured with --prefix=/usr/share and
--exec-prefix=/usr, python installs the header files into
/usr/share/include/pythonX.Y, which is at least unusual.
According to the FHS these files should go into
/usr/include/pythonX.Y


----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2002-08-30 12:52

Message:
Logged In: YES 
user_id=60903

Not yet.

--prefix=/foo/share/pythonX.Y would lead to
/foo/share/pythonX.Y/lib/pythonX.Y.

The SCRIPTDIR is somewhat hardcoded in getpath.c. So it's
not possible
to install into /foo/share/pythonX.Y, only
/foo/share/lib/pythonX.Y is supported.

The FHS doesn't specify where to put files inside
/usr/share, but most distributions put application specific
files directly in /usr/share.


----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-08-30 10:35

Message:
Logged In: YES 
user_id=45365

I'm confused. If you configure with --exec-prefix=/foo --prefix=/foo/share/pythonX.Y isn't that good enough?

If it's good enough (i.e. if it allows you to build a Python that adheres to the FHS if you are so inclined) that I agree with ghaering: there's no reason to force people to adhere to the Filesystem Hierarchy Standard, so let's close the bug.

If it is impossible to make an FHS-compliant distribution with the current setup: please explain.

----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2002-08-30 08:57

Message:
Logged In: YES 
user_id=60903

The reason given to close the report seems to be invalid.
The FHS has nothing to with Debian (except that we follow
the FHS). The FHS is targeted at Unix distributions, so it's
neither limited to a single distribution nor to Linux
distributions in general.

----------------------------------------------------------------------

Comment By: Gerhard Häring (ghaering)
Date: 2002-08-25 14:41

Message:
Logged In: YES 
user_id=163326

Python runs on dozens of platforms besides Debian Linux.
Thus the Linux FHS shouldn't concern Python at all. I'd
propose to close this bug as "Invalid".

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-03 13:13

Message:
Logged In: YES 
user_id=21627

I think this requires a PEP. A Python package can consist of
byte code modules and extension modules; arranging the
package loader to find those in different directories is a
challenge.

----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2002-07-30 22:15

Message:
Logged In: YES 
user_id=60903

FHS: Filesystem Hierarchy Standard

    http://www.pathname.com/fhs/


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=588756&group_id=5470


From noreply@sourceforge.net  Fri Aug 30 21:32:50 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 30 Aug 2002 13:32:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-588756 ] python should obey the FHS
Message-ID: <E17ksRm-0001Zy-00@usw-sf-web4.sourceforge.net>

Bugs item #588756, was opened at 2002-07-30 22:12
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=588756&group_id=5470

Category: Installation
Group: Feature Request
Status: Open
Resolution: None
Priority: 3
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: python should obey the FHS

Initial Comment:
[From: http://bugs.debian.org/134762]

FHS Compliance - .py{,c} are architecture independant
thus belong in /usr/share

The Python manual makes it clear that byte compiled
python files are
 platform independant, and thus belong in
arch-independant packages and stored in /usr/share, as
per the FHS recommendations for such things.

So the request is to store them in
<prefix>/share/pythonX.Y.


----------------------------------------------------------------------

Comment By: Gerhard Häring (ghaering)
Date: 2002-08-30 22:32

Message:
Logged In: YES 
user_id=163326

Sorry, Matthias. I was confusing the FHS with the Linux
Standard Base.

----------------------------------------------------------------------

Comment By: Gerhard Häring (ghaering)
Date: 2002-08-30 22:24

Message:
Logged In: YES 
user_id=163326

I assume that the Python directory layout is the same on all
currently supported platforms by Python. I really don't know
enough to be sure - the less that's true, the less my
following argument will be valid:

There are really two concerns:
1) make Python conform to the FHS
2) make Python behave the same cross-platform (Windows,
Unix, Mac, BeOS, OS/2, VMS, AS/400, ...)

You can't have both unless you force the FHS directory
layout onto all other platforms. I personally think that 2)
is a good thing.

I welcome the proposal of a configuration option to make
Python FHS-compliant, but I think it should not be the
default. Btw. you'd probably have to patch distutils, too.

Jack said that Pyhon include files should be cross-platform.
AFAIK they are, with one exceptions: pyconfig.h.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-08-30 14:33

Message:
Logged In: YES 
user_id=45365

Well... the usual way in which people implemented sharing between 
architectures was that the /usr/share hierarchy duplicated the other 
hierarchies (i.e. with bin, lib, etc), and it was simply mounted cross-
platform from an nfs server. That's the architecture the Python install 
was created for. I have no idea why FHS modified this test-and-tried 
layout that's been in use for at least 15 years.

But: if you really want the other layout, why not submit a fix to 
configure.in and Makefile.pre.in? Simply add, say, --fhs-prefix=/usr/
share and if that option is present override the Makefile.pre.in 
declarations for SCRIPTDIR, LIBDEST and INCLUDEDIR?

(Hmm, coming to think of it: it seems rather silly that the FHS puts 
include files into /usr/include, where they aren't shared... If there's one 
thing that can be crossplatform it's source code....)

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-08-30 14:33

Message:
Logged In: YES 
user_id=45365

Well... the usual way in which people implemented sharing between 
architectures was that the /usr/share hierarchy duplicated the other 
hierarchies (i.e. with bin, lib, etc), and it was simply mounted cross-
platform from an nfs server. That's the architecture the Python install 
was created for. I have no idea why FHS modified this test-and-tried 
layout that's been in use for at least 15 years.

But: if you really want the other layout, why not submit a fix to 
configure.in and Makefile.pre.in? Simply add, say, --fhs-prefix=/usr/
share and if that option is present override the Makefile.pre.in 
declarations for SCRIPTDIR, LIBDEST and INCLUDEDIR?

(Hmm, coming to think of it: it seems rather silly that the FHS puts 
include files into /usr/include, where they aren't shared... If there's one 
thing that can be crossplatform it's source code....)

----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2002-08-30 13:30

Message:
Logged In: YES 
user_id=60903

when configured with --prefix=/usr/share and
--exec-prefix=/usr, python installs the header files into
/usr/share/include/pythonX.Y, which is at least unusual.
According to the FHS these files should go into
/usr/include/pythonX.Y


----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2002-08-30 12:52

Message:
Logged In: YES 
user_id=60903

Not yet.

--prefix=/foo/share/pythonX.Y would lead to
/foo/share/pythonX.Y/lib/pythonX.Y.

The SCRIPTDIR is somewhat hardcoded in getpath.c. So it's
not possible
to install into /foo/share/pythonX.Y, only
/foo/share/lib/pythonX.Y is supported.

The FHS doesn't specify where to put files inside
/usr/share, but most distributions put application specific
files directly in /usr/share.


----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-08-30 10:35

Message:
Logged In: YES 
user_id=45365

I'm confused. If you configure with --exec-prefix=/foo --prefix=/foo/share/pythonX.Y isn't that good enough?

If it's good enough (i.e. if it allows you to build a Python that adheres to the FHS if you are so inclined) that I agree with ghaering: there's no reason to force people to adhere to the Filesystem Hierarchy Standard, so let's close the bug.

If it is impossible to make an FHS-compliant distribution with the current setup: please explain.

----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2002-08-30 08:57

Message:
Logged In: YES 
user_id=60903

The reason given to close the report seems to be invalid.
The FHS has nothing to with Debian (except that we follow
the FHS). The FHS is targeted at Unix distributions, so it's
neither limited to a single distribution nor to Linux
distributions in general.

----------------------------------------------------------------------

Comment By: Gerhard Häring (ghaering)
Date: 2002-08-25 14:41

Message:
Logged In: YES 
user_id=163326

Python runs on dozens of platforms besides Debian Linux.
Thus the Linux FHS shouldn't concern Python at all. I'd
propose to close this bug as "Invalid".

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-03 13:13

Message:
Logged In: YES 
user_id=21627

I think this requires a PEP. A Python package can consist of
byte code modules and extension modules; arranging the
package loader to find those in different directories is a
challenge.

----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2002-07-30 22:15

Message:
Logged In: YES 
user_id=60903

FHS: Filesystem Hierarchy Standard

    http://www.pathname.com/fhs/


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=588756&group_id=5470


From noreply@sourceforge.net  Fri Aug 30 21:51:11 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 30 Aug 2002 13:51:11 -0700
Subject: [Python-bugs-list] [ python-Bugs-602627 ] pydoc -g dumps core on Solaris 2.8
Message-ID: <E17ksjX-00023q-00@usw-sf-web4.sourceforge.net>

Bugs item #602627, was opened at 2002-08-30 20:51
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602627&group_id=5470

Category: Demos and Tools
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Koenig (arkoenig)
Assigned to: Nobody/Anonymous (nobody)
Summary: pydoc -g dumps core on Solaris 2.8

Initial Comment:
Python 2.2.1, Solaris 2.8, gcc 3.2, binutils 2.12.1

When I execute "pydoc -g", it pops up a dialog box
saying "Starting server" and "Search for", and then
dumps core before I have time to type anything.
The same problem happens on Solaris 2.7

The traceback:

Core was generated by `/usr/gnu/bin/python
/usr/gnu/bin/pydoc -g'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libsocket.so.1...done.
Loaded symbols for /usr/lib/libsocket.so.1
Reading symbols from /usr/lib/libnsl.so.1...done.
Loaded symbols for /usr/lib/libnsl.so.1
Reading symbols from /usr/lib/libdl.so.1...done.
Loaded symbols for /usr/lib/libdl.so.1
Reading symbols from /usr/lib/libpthread.so.1...done.
Loaded symbols for /usr/lib/libpthread.so.1
Reading symbols from /usr/lib/libthread.so.1...done.
Loaded symbols for /usr/lib/libthread.so.1
Reading symbols from
/usr/gnu/lib/libreadline.so.4...done.
Loaded symbols for /usr/gnu/lib/libreadline.so.4
Reading symbols from /usr/lib/libcurses.so.1...done.
Loaded symbols for /usr/lib/libcurses.so.1
Reading symbols from /usr/lib/libcrypt_i.so.1...done.
Loaded symbols for /usr/lib/libcrypt_i.so.1
Reading symbols from /usr/gnu/lib/libtk8.3.so...done.
Loaded symbols for /usr/gnu/lib/libtk8.3.so
Reading symbols from /usr/gnu/lib/libtcl8.3.so...done.
Loaded symbols for /usr/gnu/lib/libtcl8.3.so
Reading symbols from /usr/lib/libX11.so.4...done.
Loaded symbols for /usr/lib/libX11.so.4
Reading symbols from /usr/lib/libm.so.1...done.
Loaded symbols for /usr/lib/libm.so.1
Reading symbols from /usr/lib/libc.so.1...done.
Loaded symbols for /usr/lib/libc.so.1
Reading symbols from /usr/gnu/lib/libgcc_s.so.1...done.
Loaded symbols for /usr/gnu/lib/libgcc_s.so.1
Reading symbols from /usr/lib/libmp.so.2...done.
Loaded symbols for /usr/lib/libmp.so.2
Reading symbols from /usr/lib/libgen.so.1...done.
Loaded symbols for /usr/lib/libgen.so.1
Reading symbols from
/usr/openwin/lib/libXext.so.0...done.
Loaded symbols for /usr/openwin/lib/libXext.so.0
Reading symbols from
/usr/openwin/lib/libdga.so.1...done.
Loaded symbols for /usr/openwin/lib/libdga.so.1
Reading symbols from
/usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1...done.
Loaded symbols for
/usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1
Reading symbols from
/usr/gnu/lib/python2.2/lib-dynload/strop.so...done.
Loaded symbols for
/usr/gnu/lib/python2.2/lib-dynload/strop.so
Reading symbols from
/usr/lib/locale/en_US.ISO8859-1/en_US.ISO8859-1.so.2...done.
Loaded symbols for
/usr/lib/locale/en_US.ISO8859-1/en_US.ISO8859-1.so.2
Reading symbols from
/usr/openwin/lib/locale/common/xlibi18n.so.2...done.
Loaded symbols for
/usr/openwin/lib/locale/common/xlibi18n.so.2
Reading symbols from
/usr/openwin/lib/locale/common/ximlocal.so.2...done.
Loaded symbols for
/usr/openwin/lib/locale/common/ximlocal.so.2
Reading symbols from
/usr/gnu/lib/python2.2/lib-dynload/time.so...done.
Loaded symbols for
/usr/gnu/lib/python2.2/lib-dynload/time.so
Reading symbols from
/usr/gnu/lib/python2.2/lib-dynload/errno.so...done.
Loaded symbols for
/usr/gnu/lib/python2.2/lib-dynload/errno.so
Reading symbols from
/usr/gnu/lib/python2.2/lib-dynload/_socket.so...done.
Loaded symbols for
/usr/gnu/lib/python2.2/lib-dynload/_socket.so
Reading symbols from
/usr/gnu/lib/python2.2/lib-dynload/select.so...done.
Loaded symbols for
/usr/gnu/lib/python2.2/lib-dynload/select.so
#0  0xff0b2be0 in Tk_FreeGC () from
/usr/gnu/lib/libtk8.3.so
(gdb) bt
#0  0xff0b2be0 in Tk_FreeGC () from
/usr/gnu/lib/libtk8.3.so
#1  0xff0da71c in TkButtonWorldChanged () from
/usr/gnu/lib/libtk8.3.so
#2  0xff0da66c in ConfigureButton () from
/usr/gnu/lib/libtk8.3.so
#3  0xff0d9dc8 in ButtonWidgetObjCmd () from
/usr/gnu/lib/libtk8.3.so
#4  0xfefe0b50 in EvalObjv () from
/usr/gnu/lib/libtcl8.3.so
#5  0xfefe0c80 in Tcl_EvalObjv () from
/usr/gnu/lib/libtcl8.3.so
#6  0x0008deb8 in Tkapp_Call (self=0x159c88,
args=0x2c60d8) at Modules/_tkinter.c:619
#7  0x00049e28 in fast_cfunction (func=0x159c88,
pp_stack=0xfe908780, na=1089160)
    at Python/ceval.c:3131
#8  0x00047ea0 in eval_frame (f=0x1cc7c0) at
Python/ceval.c:2007
#9  0x00048b30 in PyEval_EvalCodeEx (co=0x220340,
globals=0x1cc7c0, locals=0x0, args=0x8, 
    argcount=1, kws=0x1c1dd8, kwcount=1, defs=0x1d76ec,
defcount=1, closure=0x0)
    at Python/ceval.c:2585
#10 0x00049f20 in fast_function (func=0x1,
pp_stack=0x8, n=1842656, na=1, nk=1)
    at Python/ceval.c:3161
#11 0x00047de0 in eval_frame (f=0x1c1c80) at
Python/ceval.c:2024
#12 0x00048b30 in PyEval_EvalCodeEx (co=0x1983a8,
globals=0x1c1c80, locals=0x0, args=0x30fd50, 
    argcount=2, kws=0x30fd58, kwcount=0, defs=0x0,
defcount=0, closure=0x0) at Python/ceval.c:2585
#13 0x00049f20 in fast_function (func=0x0,
pp_stack=0x30fd50, n=3210584, na=2, nk=0)
    at Python/ceval.c:3161
#14 0x00047de0 in eval_frame (f=0x30fc00) at
Python/ceval.c:2024
#15 0x00048b30 in PyEval_EvalCodeEx (co=0x12f788,
globals=0x30fc00, locals=0x0, args=0x1c0bc8, 
    argcount=1, kws=0x1c0bcc, kwcount=0, defs=0x0,
defcount=0, closure=0x0) at Python/ceval.c:2585
#16 0x00049f20 in fast_function (func=0x0,
pp_stack=0x1c0bc8, n=1838028, na=1, nk=0)
    at Python/ceval.c:3161
#17 0x00047de0 in eval_frame (f=0x1c0a70) at
Python/ceval.c:2024
#18 0x00048b30 in PyEval_EvalCodeEx (co=0x300058,
globals=0x1c0a70, locals=0x0, args=0x301a6c, 
    argcount=3, kws=0x0, kwcount=0, defs=0x0,
defcount=0, closure=0x0) at Python/ceval.c:2585
#19 0x000aaa9c in function_call (func=0x2fc3c0,
arg=0x301a60, kw=0x0) at Objects/funcobject.c:374
#20 0x00095d00 in PyObject_Call (func=0x2fc3c0,
arg=0x301a60, kw=0x0) at Objects/abstract.c:1684
#21 0x0009e644 in instancemethod_call (func=0x2fc3c0,
arg=0x301a60, kw=0x0)
    at Objects/classobject.c:2276
#22 0x00095d00 in PyObject_Call (func=0x2fc3c0,
arg=0x301a60, kw=0x0) at Objects/abstract.c:1684
#23 0x00049fe4 in do_call (func=0x2c5718,
pp_stack=0xfe908fd8, na=3, nk=3152480)
    at Python/ceval.c:3262
#24 0x00047d28 in eval_frame (f=0x1cc5f8) at
Python/ceval.c:2027
#25 0x00048b30 in PyEval_EvalCodeEx (co=0x12f398,
globals=0x1cc5f8, locals=0x0, args=0x2cba54, 
    argcount=3, kws=0x0, kwcount=0, defs=0x0,
defcount=0, closure=0x0) at Python/ceval.c:2585
#26 0x000aaa9c in function_call (func=0x301bf0,
arg=0x2cba48, kw=0x0) at Objects/funcobject.c:374
#27 0x00095d00 in PyObject_Call (func=0x301bf0,
arg=0x2cba48, kw=0x0) at Objects/abstract.c:1684
#28 0x0009e644 in instancemethod_call (func=0x301bf0,
arg=0x2cba48, kw=0x0)
    at Objects/classobject.c:2276
#29 0x00095d00 in PyObject_Call (func=0x301bf0,
arg=0x2e3bb0, kw=0x0) at Objects/abstract.c:1684
#30 0x00049c94 in PyEval_CallObjectWithKeywords
(func=0x2da810, arg=0x2e3bb0, kw=0x0)
    at Python/ceval.c:3049
#31 0x00097d9c in PyInstance_New (klass=0x2da810,
arg=0x2e3bb0, kw=0x0) at Objects/classobject.c:557
#32 0x00095d00 in PyObject_Call (func=0x2da810,
arg=0x2e3bb0, kw=0x0) at Objects/abstract.c:1684
#33 0x00049fe4 in do_call (func=0x316828,
pp_stack=0xfe9094a0, na=2, nk=3029936)
    at Python/ceval.c:3262
#34 0x00047d28 in eval_frame (f=0x1a3d20) at
Python/ceval.c:2027
#35 0x00048b30 in PyEval_EvalCodeEx (co=0x12fab0,
globals=0x1a3d20, locals=0x0, args=0x186414, 
    argcount=3, kws=0x2b1228, kwcount=0, defs=0x1cd87c,
defcount=2, closure=0x0)
    at Python/ceval.c:2585
#36 0x000aaa9c in function_call (func=0x1d1dc8,
arg=0x186408, kw=0x2d6238)
    at Objects/funcobject.c:374
#37 0x00095d00 in PyObject_Call (func=0x1d1dc8,
arg=0x186408, kw=0x2d6238)
    at Objects/abstract.c:1684
#38 0x00049c94 in PyEval_CallObjectWithKeywords
(func=0x1d1dc8, arg=0x186408, kw=0x2d6238)
    at Python/ceval.c:3049

#39 0x000bcb3c in builtin_apply (self=0x0,
args=0x1d1dc8) at Python/bltinmodule.c:95
#40 0x000ba398 in PyCFunction_Call (func=0x101d18,
arg=0x1c4910, kw=0x0)
    at Objects/methodobject.c:69
#41 0x00047ec8 in eval_frame (f=0x1a4078) at
Python/ceval.c:2004
#42 0x00048b30 in PyEval_EvalCodeEx (co=0x2c86c8,
globals=0x1a4078, locals=0x0, args=0x1612d4, 
    argcount=1, kws=0x1612d8, kwcount=0, defs=0x0,
defcount=0, closure=0x0) at Python/ceval.c:2585
#43 0x00049f20 in fast_function (func=0x0,
pp_stack=0x1612d4, n=1446616, na=1, nk=0)
    at Python/ceval.c:3161
#44 0x00047de0 in eval_frame (f=0x161180) at
Python/ceval.c:2024
#45 0x00048b30 in PyEval_EvalCodeEx (co=0x2c8cd0,
globals=0x161180, locals=0x0, args=0x265e4c, 
    argcount=1, kws=0x0, kwcount=0, defs=0x0,
defcount=0, closure=0x0) at Python/ceval.c:2585
#46 0x000aaa9c in function_call (func=0x2d6518,
arg=0x265e40, kw=0x0) at Objects/funcobject.c:374
#47 0x00095d00 in PyObject_Call (func=0x2d6518,
arg=0x265e40, kw=0x0) at Objects/abstract.c:1684
#48 0x0009e644 in instancemethod_call (func=0x2d6518,
arg=0x265e40, kw=0x0)
    at Objects/classobject.c:2276
#49 0x00095d00 in PyObject_Call (func=0x2d6518,
arg=0x100368, kw=0x0) at Objects/abstract.c:1684
#50 0x00049c94 in PyEval_CallObjectWithKeywords
(func=0x2d7350, arg=0x100368, kw=0x0)
    at Python/ceval.c:3049
#51 0x0007f508 in t_bootstrap (boot_raw=0x28bdf8) at
Modules/threadmodule.c:190


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602627&group_id=5470


From noreply@sourceforge.net  Fri Aug 30 21:51:49 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 30 Aug 2002 13:51:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-588756 ] python should obey the FHS
Message-ID: <E17ksk9-0008HY-00@usw-sf-web5.sourceforge.net>

Bugs item #588756, was opened at 2002-07-30 22:12
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=588756&group_id=5470

Category: Installation
Group: Feature Request
Status: Open
Resolution: None
Priority: 3
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: python should obey the FHS

Initial Comment:
[From: http://bugs.debian.org/134762]

FHS Compliance - .py{,c} are architecture independant
thus belong in /usr/share

The Python manual makes it clear that byte compiled
python files are
 platform independant, and thus belong in
arch-independant packages and stored in /usr/share, as
per the FHS recommendations for such things.

So the request is to store them in
<prefix>/share/pythonX.Y.


----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2002-08-30 22:51

Message:
Logged In: YES 
user_id=45365

The layouts are similar, but not the same. MacPython-OS9 uses the source tree layout, and Windows-Python too, IIRC.
MacPython-OSX in a framework build uses a normal layout, but in a very funny place, with lots of symlinks to make it behave like a framework. I would be very surprised if, say WinCE python or AS/400 python had anything resembling a unix layout. But all these layouts are similar enough that I've never come across a Python where I felt completely lost.

I think there's nothing wrong with enabling people to use their preferred layout, if they have a good reason for it, but I would be against enforcing it unless the advantages are clear and universal.

And someone has to do the work:-)


----------------------------------------------------------------------

Comment By: Gerhard Häring (ghaering)
Date: 2002-08-30 22:32

Message:
Logged In: YES 
user_id=163326

Sorry, Matthias. I was confusing the FHS with the Linux
Standard Base.

----------------------------------------------------------------------

Comment By: Gerhard Häring (ghaering)
Date: 2002-08-30 22:24

Message:
Logged In: YES 
user_id=163326

I assume that the Python directory layout is the same on all
currently supported platforms by Python. I really don't know
enough to be sure - the less that's true, the less my
following argument will be valid:

There are really two concerns:
1) make Python conform to the FHS
2) make Python behave the same cross-platform (Windows,
Unix, Mac, BeOS, OS/2, VMS, AS/400, ...)

You can't have both unless you force the FHS directory
layout onto all other platforms. I personally think that 2)
is a good thing.

I welcome the proposal of a configuration option to make
Python FHS-compliant, but I think it should not be the
default. Btw. you'd probably have to patch distutils, too.

Jack said that Pyhon include files should be cross-platform.
AFAIK they are, with one exceptions: pyconfig.h.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-08-30 14:33

Message:
Logged In: YES 
user_id=45365

Well... the usual way in which people implemented sharing between 
architectures was that the /usr/share hierarchy duplicated the other 
hierarchies (i.e. with bin, lib, etc), and it was simply mounted cross-
platform from an nfs server. That's the architecture the Python install 
was created for. I have no idea why FHS modified this test-and-tried 
layout that's been in use for at least 15 years.

But: if you really want the other layout, why not submit a fix to 
configure.in and Makefile.pre.in? Simply add, say, --fhs-prefix=/usr/
share and if that option is present override the Makefile.pre.in 
declarations for SCRIPTDIR, LIBDEST and INCLUDEDIR?

(Hmm, coming to think of it: it seems rather silly that the FHS puts 
include files into /usr/include, where they aren't shared... If there's one 
thing that can be crossplatform it's source code....)

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-08-30 14:33

Message:
Logged In: YES 
user_id=45365

Well... the usual way in which people implemented sharing between 
architectures was that the /usr/share hierarchy duplicated the other 
hierarchies (i.e. with bin, lib, etc), and it was simply mounted cross-
platform from an nfs server. That's the architecture the Python install 
was created for. I have no idea why FHS modified this test-and-tried 
layout that's been in use for at least 15 years.

But: if you really want the other layout, why not submit a fix to 
configure.in and Makefile.pre.in? Simply add, say, --fhs-prefix=/usr/
share and if that option is present override the Makefile.pre.in 
declarations for SCRIPTDIR, LIBDEST and INCLUDEDIR?

(Hmm, coming to think of it: it seems rather silly that the FHS puts 
include files into /usr/include, where they aren't shared... If there's one 
thing that can be crossplatform it's source code....)

----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2002-08-30 13:30

Message:
Logged In: YES 
user_id=60903

when configured with --prefix=/usr/share and
--exec-prefix=/usr, python installs the header files into
/usr/share/include/pythonX.Y, which is at least unusual.
According to the FHS these files should go into
/usr/include/pythonX.Y


----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2002-08-30 12:52

Message:
Logged In: YES 
user_id=60903

Not yet.

--prefix=/foo/share/pythonX.Y would lead to
/foo/share/pythonX.Y/lib/pythonX.Y.

The SCRIPTDIR is somewhat hardcoded in getpath.c. So it's
not possible
to install into /foo/share/pythonX.Y, only
/foo/share/lib/pythonX.Y is supported.

The FHS doesn't specify where to put files inside
/usr/share, but most distributions put application specific
files directly in /usr/share.


----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-08-30 10:35

Message:
Logged In: YES 
user_id=45365

I'm confused. If you configure with --exec-prefix=/foo --prefix=/foo/share/pythonX.Y isn't that good enough?

If it's good enough (i.e. if it allows you to build a Python that adheres to the FHS if you are so inclined) that I agree with ghaering: there's no reason to force people to adhere to the Filesystem Hierarchy Standard, so let's close the bug.

If it is impossible to make an FHS-compliant distribution with the current setup: please explain.

----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2002-08-30 08:57

Message:
Logged In: YES 
user_id=60903

The reason given to close the report seems to be invalid.
The FHS has nothing to with Debian (except that we follow
the FHS). The FHS is targeted at Unix distributions, so it's
neither limited to a single distribution nor to Linux
distributions in general.

----------------------------------------------------------------------

Comment By: Gerhard Häring (ghaering)
Date: 2002-08-25 14:41

Message:
Logged In: YES 
user_id=163326

Python runs on dozens of platforms besides Debian Linux.
Thus the Linux FHS shouldn't concern Python at all. I'd
propose to close this bug as "Invalid".

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-03 13:13

Message:
Logged In: YES 
user_id=21627

I think this requires a PEP. A Python package can consist of
byte code modules and extension modules; arranging the
package loader to find those in different directories is a
challenge.

----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2002-07-30 22:15

Message:
Logged In: YES 
user_id=60903

FHS: Filesystem Hierarchy Standard

    http://www.pathname.com/fhs/


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=588756&group_id=5470


From noreply@sourceforge.net  Sat Aug 31 06:28:04 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 30 Aug 2002 22:28:04 -0700
Subject: [Python-bugs-list] [ python-Bugs-567892 ] Various Playstation 2 Linux Test Errors
Message-ID: <E17l0nk-0002p7-00@usw-sf-web1.sourceforge.net>

Bugs item #567892, was opened at 2002-06-12 02:21
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=567892&group_id=5470

Category: Installation
Group: Platform-specific
>Status: Deleted
Resolution: None
Priority: 1
Submitted By: Keith Thomson (kazriko)
Assigned to: Nobody/Anonymous (nobody)
Summary: Various Playstation 2 Linux Test Errors

Initial Comment:
I recently downloaded Python 2.2.1 onto my Playstation 
2 with a linux kit installed. It uses a mipsel architecture, 
(mips endian-little) with a Linux 2.2.1 kernel (retrofitted 
with many backported stuff from later versions) and a 
glibc 2.2.2 i believe, also custom modified by SCEI.

Python compiled perfectly the first time, and installed 
flawlessly. On a whim, I decided to run python's testing 
suite. (make test)

The first pass crashed with this error. 

test_re
make: *** [test] Segmentation fault

i moved this test out of the folder to see if there were 
any other errors, and got the same one for test_sre.

After moving these two tests, i got the following results, 
including the lines from the failing tests.

test test_descr failed -- x=2, y=1
test test_linuxaudiodev failed -- (16, 'Device or resource 
busy', '/dev/dsp')
test test_userdict failed -- test failed
3 tests failed:
    test_descr test_linuxaudiodev test_userdict
18 tests skipped:
    test_al test_cd test_cl test_curses test_dl test_gl 
test_imgfile
    test_largefile test_minidom test_nis test_ntpath 
test_pyexpat
    test_sax test_socket_ssl test_socketserver 
test_sunaudiodev
    test_winreg test_winsound
3 skips unexpected on linux2:
    test_minidom test_pyexpat test_sax

The linuxaudiodev actually gave me two different errors, 
no other audio programs were running at the time, so i'm 
suspecting a ps2sd bug on that one. but the other four 
tests I have not tried to isolate yet.

I'll keep at it, Would welcome any recommendations on 
places to look to diagnose these problems. 

This is probably a very-low priority thing, as PS2Linux is 
still a bit of a beta test thing, it would be nice if i could 
isolate this down to some bugs in ps2linux's libraries, so 
that we could fix them without mucking up the python 
code with ps2 stuff.

----------------------------------------------------------------------

Comment By: Keith Thomson (kazriko)
Date: 2002-06-12 23:11

Message:
Logged In: YES 
user_id=346680

I attempted to use the ulimit command and change the stack 
size maximum, but it still failed when doing the full test suite. 
(even tried several different stack sizes) however, running the 
test individually with this line 
./python Lib/test/regrtest.py -g test_re.py
worked perfectly, as did the sre version.

I ran test_descr outside of the testing framework, and it 
crashed on the following test..
Testing classic comparisons...
        (base = __main__.classic)
Traceback (most recent call last):
  File "./Lib/test/test_descr.py", line 2906, in ?
    test_main()
  File "./Lib/test/test_descr.py", line 2884, in test_main
    classic_comparisons()
  File "./Lib/test/test_descr.py", line 2193, in 
classic_comparisons
    verify(cmp(x, c[y]) == cmp(x, y), "x=%d, y=%d" % (x, y))
  File "./Lib/test/test_support.py", line 118, in verify
    raise TestFailed(reason)
test_support.TestFailed: x=2, y=1

similarly, test_userdict gave this traceback when it crashed.
./python ./Lib/test/test_userdict.py
Traceback (most recent call last):
  File "./Lib/test/test_userdict.py", line 33, in ?
    verify(cmp(a, b) == cmp(len(a), len(b)))
  File "./Lib/test/test_support.py", line 118, in verify
    raise TestFailed(reason)

These might be failing for the same reason?

For information's sake, here's the linuxaudio traceback.

[kazrikna@rikku Python-2.2.1]
$ ./python ./Lib/test/test_linuxaudiodev.py
Traceback (most recent call last):
  File "./Lib/test/test_linuxaudiodev.py", line 89, in ?
    test()
  File "./Lib/test/test_linuxaudiodev.py", line 86, in test
    play_sound_file(findfile('audiotest.au'))
  File "./Lib/test/test_linuxaudiodev.py", line 42, in 
play_sound_file
    a.bufsize()
linuxaudiodev.error: (22, 'Invalid argument')

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-06-12 03:31

Message:
Logged In: YES 
user_id=6656

Some tips:

(1) don't worry about test_linuxaudiodev. I'm not sure it's
a lost cause, but...

(2) the test_re stuff is probably the consequence of a small
stack size.  try running ulimit -s 8192 before running the
test suite.

(3) the other test failures are a bit odd.  do you feel like
digging some more? "test_userdict failed -- test failed"
isn't terribly informative...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=567892&group_id=5470


From noreply@sourceforge.net  Sat Aug 31 09:59:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 31 Aug 2002 01:59:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-588756 ] python should obey the FHS
Message-ID: <E17l46O-0008TS-00@usw-sf-web2.sourceforge.net>

Bugs item #588756, was opened at 2002-07-30 20:12
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=588756&group_id=5470

Category: Installation
Group: Feature Request
Status: Open
Resolution: None
Priority: 3
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: python should obey the FHS

Initial Comment:
[From: http://bugs.debian.org/134762]

FHS Compliance - .py{,c} are architecture independant
thus belong in /usr/share

The Python manual makes it clear that byte compiled
python files are
 platform independant, and thus belong in
arch-independant packages and stored in /usr/share, as
per the FHS recommendations for such things.

So the request is to store them in
<prefix>/share/pythonX.Y.


----------------------------------------------------------------------

>Comment By: Matthias Klose (doko)
Date: 2002-08-31 08:59

Message:
Logged In: YES 
user_id=60903

Ok, I'll give --fhs-prefix a try. some questions:

- the lib_python in getpath.c hardcodes lib/pythonX.Y to 
search for the libraries. Is it enouogh to set PYTHONPATH to 
pythonX.Y?

- who to ask for distutils? are there concerns if a 
module/library is splitted over two directories? Or should there 
symlinks from /usr/lib/pythonX.Y to /usr/share/pythonX.Y?

- currently there is only one site-packages directory. how 
should two site-packages be supported (lib and share)?

- speaking of etc: this is a configuration file and should belong 
into the etc hierarchy. should etc be searched before or after 
the library directories?

Python's include files: not all packages separate platform 
specific headers from generic headers, probably therefore the 
FHS puts them in /usr/include.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-08-30 20:51

Message:
Logged In: YES 
user_id=45365

The layouts are similar, but not the same. MacPython-OS9 uses the source tree layout, and Windows-Python too, IIRC.
MacPython-OSX in a framework build uses a normal layout, but in a very funny place, with lots of symlinks to make it behave like a framework. I would be very surprised if, say WinCE python or AS/400 python had anything resembling a unix layout. But all these layouts are similar enough that I've never come across a Python where I felt completely lost.

I think there's nothing wrong with enabling people to use their preferred layout, if they have a good reason for it, but I would be against enforcing it unless the advantages are clear and universal.

And someone has to do the work:-)


----------------------------------------------------------------------

Comment By: Gerhard Häring (ghaering)
Date: 2002-08-30 20:32

Message:
Logged In: YES 
user_id=163326

Sorry, Matthias. I was confusing the FHS with the Linux
Standard Base.

----------------------------------------------------------------------

Comment By: Gerhard Häring (ghaering)
Date: 2002-08-30 20:24

Message:
Logged In: YES 
user_id=163326

I assume that the Python directory layout is the same on all
currently supported platforms by Python. I really don't know
enough to be sure - the less that's true, the less my
following argument will be valid:

There are really two concerns:
1) make Python conform to the FHS
2) make Python behave the same cross-platform (Windows,
Unix, Mac, BeOS, OS/2, VMS, AS/400, ...)

You can't have both unless you force the FHS directory
layout onto all other platforms. I personally think that 2)
is a good thing.

I welcome the proposal of a configuration option to make
Python FHS-compliant, but I think it should not be the
default. Btw. you'd probably have to patch distutils, too.

Jack said that Pyhon include files should be cross-platform.
AFAIK they are, with one exceptions: pyconfig.h.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-08-30 12:33

Message:
Logged In: YES 
user_id=45365

Well... the usual way in which people implemented sharing between 
architectures was that the /usr/share hierarchy duplicated the other 
hierarchies (i.e. with bin, lib, etc), and it was simply mounted cross-
platform from an nfs server. That's the architecture the Python install 
was created for. I have no idea why FHS modified this test-and-tried 
layout that's been in use for at least 15 years.

But: if you really want the other layout, why not submit a fix to 
configure.in and Makefile.pre.in? Simply add, say, --fhs-prefix=/usr/
share and if that option is present override the Makefile.pre.in 
declarations for SCRIPTDIR, LIBDEST and INCLUDEDIR?

(Hmm, coming to think of it: it seems rather silly that the FHS puts 
include files into /usr/include, where they aren't shared... If there's one 
thing that can be crossplatform it's source code....)

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-08-30 12:33

Message:
Logged In: YES 
user_id=45365

Well... the usual way in which people implemented sharing between 
architectures was that the /usr/share hierarchy duplicated the other 
hierarchies (i.e. with bin, lib, etc), and it was simply mounted cross-
platform from an nfs server. That's the architecture the Python install 
was created for. I have no idea why FHS modified this test-and-tried 
layout that's been in use for at least 15 years.

But: if you really want the other layout, why not submit a fix to 
configure.in and Makefile.pre.in? Simply add, say, --fhs-prefix=/usr/
share and if that option is present override the Makefile.pre.in 
declarations for SCRIPTDIR, LIBDEST and INCLUDEDIR?

(Hmm, coming to think of it: it seems rather silly that the FHS puts 
include files into /usr/include, where they aren't shared... If there's one 
thing that can be crossplatform it's source code....)

----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2002-08-30 11:30

Message:
Logged In: YES 
user_id=60903

when configured with --prefix=/usr/share and
--exec-prefix=/usr, python installs the header files into
/usr/share/include/pythonX.Y, which is at least unusual.
According to the FHS these files should go into
/usr/include/pythonX.Y


----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2002-08-30 10:52

Message:
Logged In: YES 
user_id=60903

Not yet.

--prefix=/foo/share/pythonX.Y would lead to
/foo/share/pythonX.Y/lib/pythonX.Y.

The SCRIPTDIR is somewhat hardcoded in getpath.c. So it's
not possible
to install into /foo/share/pythonX.Y, only
/foo/share/lib/pythonX.Y is supported.

The FHS doesn't specify where to put files inside
/usr/share, but most distributions put application specific
files directly in /usr/share.


----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-08-30 08:35

Message:
Logged In: YES 
user_id=45365

I'm confused. If you configure with --exec-prefix=/foo --prefix=/foo/share/pythonX.Y isn't that good enough?

If it's good enough (i.e. if it allows you to build a Python that adheres to the FHS if you are so inclined) that I agree with ghaering: there's no reason to force people to adhere to the Filesystem Hierarchy Standard, so let's close the bug.

If it is impossible to make an FHS-compliant distribution with the current setup: please explain.

----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2002-08-30 06:57

Message:
Logged In: YES 
user_id=60903

The reason given to close the report seems to be invalid.
The FHS has nothing to with Debian (except that we follow
the FHS). The FHS is targeted at Unix distributions, so it's
neither limited to a single distribution nor to Linux
distributions in general.

----------------------------------------------------------------------

Comment By: Gerhard Häring (ghaering)
Date: 2002-08-25 12:41

Message:
Logged In: YES 
user_id=163326

Python runs on dozens of platforms besides Debian Linux.
Thus the Linux FHS shouldn't concern Python at all. I'd
propose to close this bug as "Invalid".

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-03 11:13

Message:
Logged In: YES 
user_id=21627

I think this requires a PEP. A Python package can consist of
byte code modules and extension modules; arranging the
package loader to find those in different directories is a
challenge.

----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2002-07-30 20:15

Message:
Logged In: YES 
user_id=60903

FHS: Filesystem Hierarchy Standard

    http://www.pathname.com/fhs/


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=588756&group_id=5470


From noreply@sourceforge.net  Sat Aug 31 15:26:08 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 31 Aug 2002 07:26:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-602029 ] smtplib mishandles empty sender
Message-ID: <E17l9CS-0000mD-00@usw-sf-web4.sourceforge.net>

Bugs item #602029, was opened at 2002-08-29 13:53
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602029&group_id=5470

Category: Python Library
>Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Ward (gward)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: smtplib mishandles empty sender

Initial Comment:
If you pass a non-empty string to SMTP.mail(), it gets it 
right, ie.
  smtp.mail("gward@python.net")
becomes
  MAIL FROM:<gward@python.net>

But if you pass the empty string, things go badly:
  smtp.mail("")
becomes
  MAIL FROM:
which most SMTP servers should reject.  (I only tried 
one.)

The culprit appears to be the "if not m" branch in 
quoteaddr().  One possible fix:

--- smtplib.py  8 Aug 2002 20:19:18 -0000       1.61
+++ smtplib.py  29 Aug 2002 18:52:42 -0000
@@ -173,11 +173,7 @@
         m=rfc822.parseaddr(addr)[1]
     except AttributeError:
         pass
-    if not m:
-        #something weird here.. punt -ddm
-        return addr
-    else:
-        return "<%s>" % m
+    return "<%s>" % m
 
 def quotedata(data):
     """Quote data for email.

Another possible fix:
--- smtplib.py  8 Aug 2002 20:19:18 -0000       1.61
+++ smtplib.py  29 Aug 2002 18:53:28 -0000
@@ -168,6 +168,8 @@
 
     Should be able to handle anything rfc822.parseaddr 
can handle.
     """
+    if addr == "":
+        return "<>"
     m=None
     try:
         m=rfc822.parseaddr(addr)[1]


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602029&group_id=5470


From noreply@sourceforge.net  Sat Aug 31 16:19:31 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 31 Aug 2002 08:19:31 -0700
Subject: [Python-bugs-list] [ python-Bugs-602232 ] dict-proxy lacks iter* methods.
Message-ID: <E17lA27-0001fh-00@usw-sf-web4.sourceforge.net>

Bugs item #602232, was opened at 2002-08-30 00:40
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602232&group_id=5470

Category: None
Group: None
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Jeremy Fincher (jemfinch)
Assigned to: Nobody/Anonymous (nobody)
Summary: dict-proxy lacks iter* methods.

Initial Comment:
One would think that, as long as the point of dict-proxy 
is to simply be a read-only dictionary, it should replicate 
all methods that make sense for a read-only dictionary.  
As such, it should have iteritems, iterkeys, and 
itervalues methods.

I don't know any C wizardry, so I can't offer any 
patches, just the suggestion.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-08-31 10:19

Message:
Logged In: YES 
user_id=80475

Already fixed in Py2.3.
Closing bug.

>>> dir(A.__dict__)
['__class__', '__contains__', '__delattr__', '__doc__', '__getat
tribute__', '__getitem__', '__hash__', '__init__', '__iter__', '__l
en__', '__new__', '__reduce__', '__repr__', '__setattr__', '__st
r__', 'copy', 'get', 'has_key', 'items', 'iteritems', 'iterkeys', 'ite
rvalues', 'keys', 'values']


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602232&group_id=5470


From noreply@sourceforge.net  Sat Aug 31 16:33:18 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 31 Aug 2002 08:33:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-597919 ] compiler package and SET_LINENO
Message-ID: <E17lAFS-0005HV-00@usw-sf-web1.sourceforge.net>

Bugs item #597919, was opened at 2002-08-20 19:51
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=597919&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Jeremy Hylton (jhylton)
Summary: compiler package and SET_LINENO

Initial Comment:
The compiler package should not issue SET_LINENO
instructions any more.  Running the Zope 2.7 test suite
produces this traceback:

Traceback (most recent call last):
  File "test.py", line 433, in ?
    process_args()
  File "test.py", line 397, in process_args
    bad = main(module_filter, test_filter)
  File "test.py", line 308, in main
    runner(files, test_filter, debug)
  File "test.py", line 275, in runner
    s = get_suite(file)
  File "test.py", line 230, in get_suite
    mod = package_import(modname)
  File "test.py", line 211, in package_import
    mod = __import__(modname)
  File
"/home/fdrake/projects/Zope/Zope2.7/lib/python/RestrictedPython/tests/testRestrictions.py",
line 64, in ?
    create_rmodule()
  File
"/home/fdrake/projects/Zope/Zope2.7/lib/python/RestrictedPython/tests/testRestrictions.py",
line 55, in create_rmodule
    code = compile_restricted(source, fn, 'exec')
  File
"/home/fdrake/projects/Zope/Zope2.7/lib/python/RestrictedPython/RCompile.py",
line 147, in compile_restricted
    gen.compile()
  File
"/usr/local/lib/python2.3/compiler/pycodegen.py", line
123, in compile
    self.code = gen.getCode()
  File
"/usr/local/lib/python2.3/compiler/pycodegen.py", line
252, in getCode
    return self.graph.getCode()
  File "/usr/local/lib/python2.3/compiler/pyassem.py",
line 378, in getCode
    self.convertArgs()
  File "/usr/local/lib/python2.3/compiler/pyassem.py",
line 484, in convertArgs
    self.insts[i] = opname, conv(self, oparg)
  File "/usr/local/lib/python2.3/compiler/pyassem.py",
line 520, in _convert_LOAD_CONST
    arg = arg.getCode()
  File
"/usr/local/lib/python2.3/compiler/pycodegen.py", line
252, in getCode
    return self.graph.getCode()
  File "/usr/local/lib/python2.3/compiler/pyassem.py",
line 380, in getCode
    self.makeByteCode()
  File "/usr/local/lib/python2.3/compiler/pyassem.py",
line 585, in makeByteCode   
lnotab.addCode(self.opnum[opname], lo, hi)
KeyError: SET_LINENO


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-08-31 15:33

Message:
Logged In: YES 
user_id=6656

I'm about to go away for a week, so if you want my help
you'll probably have to wait until I get back.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-08-23 09:39

Message:
Logged In: YES 
user_id=6656

Believe it or not, I'd actually got that far myself <wink>.

If it'd been that easy, the changes would have been part of
my original SET_LINENO removal patch.

I guess the first question to answer is where does the
lnotab live during compilation?  In the CodeGenerator?  Then
logic has to move from PyFlowGraph.makeByteCode to
CodeGenerator.set_lineno.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-08-22 16:39

Message:
Logged In: YES 
user_id=31392

A grep for SET_LINENO in the compiler package source will be
somewhat helpful.  There are very few places that actually
emit the instructions.  I thought they could just be
removed, but the lnotab is generated *from* the SET_LINENO
instructions.  So we need to come up with a different way to
generate the lnotab.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-08-21 09:08

Message:
Logged In: YES 
user_id=6656

This is my fault, obviously.

I'm prepared to do some legwork to fix this problem, but don't really understand the code well enough to judge the best approach.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=597919&group_id=5470


From noreply@sourceforge.net  Sat Aug 31 19:02:51 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 31 Aug 2002 11:02:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-602893 ] cgitb tracebacks not accessible
Message-ID: <E17lCaB-0004jT-00@usw-sf-web5.sourceforge.net>

Bugs item #602893, was opened at 2002-08-31 18:02
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602893&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Silas S. Brown (ssb22)
Assigned to: Nobody/Anonymous (nobody)
Summary: cgitb tracebacks not accessible

Initial Comment:
The cgitb tracebacks use colour ALONE to highlight
which line caused the exception.  This doesn't show up
on text-only browsers such as Lynx, and it is not
helpful to blind people or those with similar special
needs.  These people have to count the lines, or set
"context" to 1, or look at the HTML source to see the
real traceback in the comments.

It would be most helpful if there were at least an
option to indicate the line that caused the error in
some additional way (as well as the colour), such as by
highlighting it with some punctuation character to the
left of the line number.

(Python 2.2.1 under Debian Woody)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602893&group_id=5470


From noreply@sourceforge.net  Sat Aug 31 20:10:52 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 31 Aug 2002 12:10:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-601077 ] bug in new execvpe
Message-ID: <E17lDe0-0001hJ-00@usw-sf-web3.sourceforge.net>

Bugs item #601077, was opened at 2002-08-27 18:03
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=601077&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Nobody/Anonymous (nobody)
Summary: bug in new execvpe

Initial Comment:
From: "Steve M. Robbins" <steven.robbins@videotron.ca>


I think the patch associated with this thread has an
unintended
consequence.

In
http://mail.python.org/pipermail/python-dev/2002-August/027229.html
Zack pointed out three flaws in the original code:

    [...]
    Third, if an error other than the expected one
comes back, the
    loop clobbers the saved exception info and keeps
going.  Consider
    the situation where PATH=/bin:/usr/bin, /bin/foobar
exists but is
    not executable by the invoking user, and
/usr/bin/foobar does not
    exist.  The exception thrown will be 'No such file
or directory',
    not the expected 'Permission denied'.

The patch, as I understand it, changes the behaviour so
as to raise
the exception "Permission denied" in this case.

Consider a similar situation in which both /bin/foobar
(not executable
by the user) and /usr/bin/foobar (executable by the
user) exist.
Given the command "foobar", the shell will execute
/usr/bin/foobar.
If I understand the patch correctly, python will give
up when it
encounters /bin/foobar and raise the "Permission
denied" exception.

I believe this just happened to me today.  I had a
shell script named
"gcc" in ~/bin (first on my path) some months back. 
When I was
finished with it, I just did "chmod -x ~/bin/gcc" and
forgot about it.
Today was the first time since this patch went in that
I ran gcc via
python (using scipy's weave).  Boy was I surprised at
the message
"unable to execute gcc: Permission denied"!

I guess the fix is to save the EPERM exception and keep
going
in case there is an executable later in the path.


----------------------------------------------------------------------

Comment By: Zack Weinberg (zackw)
Date: 2002-08-31 12:10

Message:
Logged In: YES 
user_id=580015

I've created a patch for this bug.  I would like to attach it,
but Sourceforge doesn't want to let me do that, so I'll just
insert it inline here:

===================================================================
Index: Lib/os.py
--- Lib/os.py	5 Aug 2002 16:13:24 -0000	1.59
+++ Lib/os.py	31 Aug 2002 19:08:34 -0000
@@ -309,7 +309,7 @@ def execvp(file, args):
     _execvpe(file, args)
 
 def execvpe(file, args, env):
-    """execv(file, args, env)
+    """execvpe(file, args, env)
 
     Execute the executable file (which is searched for
along $PATH)
     with argument list args and environment env , replacing the
@@ -339,14 +339,21 @@ def _execvpe(file, args, env=None):
     else:
         envpath = defpath
     PATH = envpath.split(pathsep)
+    saved_exc = None
+    saved_tb = None
     for dir in PATH:
         fullname = path.join(dir, file)
         try:
             apply(func, (fullname,) + argrest)
-        except error, (errno, msg):
-            if errno != ENOENT and errno != ENOTDIR:
-                raise
-    raise error, (errno, msg)
+        except error, e:
+            tb = sys.exc_info()[2]
+            if (e.errno != ENOENT and e.errno != ENOTDIR
+                and saved_exc is None):
+                saved_exc = e
+                saved_tb = tb
+    if saved_exc:
+        raise error, saved_exc, saved_tb
+    raise error, e, tb
 
 # Change environ to automatically call putenv() if it exists
 try:


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-27 18:06

Message:
Logged In: YES 
user_id=6380

Since I applied Zack's patch to the trunk as well as to the
2.2 maintenance branch, this needs to be fixed in both places.

This worked correctly in 2.1 and 2.2 (and in 2.2.1, but I
haven't tested that).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=601077&group_id=5470


From noreply@sourceforge.net  Sat Aug 31 21:22:10 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 31 Aug 2002 13:22:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-601077 ] bug in new execvpe
Message-ID: <E17lEl0-0005ya-00@usw-sf-web4.sourceforge.net>

Bugs item #601077, was opened at 2002-08-27 21:03
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=601077&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: bug in new execvpe

Initial Comment:
From: "Steve M. Robbins" <steven.robbins@videotron.ca>


I think the patch associated with this thread has an
unintended
consequence.

In
http://mail.python.org/pipermail/python-dev/2002-August/027229.html
Zack pointed out three flaws in the original code:

    [...]
    Third, if an error other than the expected one
comes back, the
    loop clobbers the saved exception info and keeps
going.  Consider
    the situation where PATH=/bin:/usr/bin, /bin/foobar
exists but is
    not executable by the invoking user, and
/usr/bin/foobar does not
    exist.  The exception thrown will be 'No such file
or directory',
    not the expected 'Permission denied'.

The patch, as I understand it, changes the behaviour so
as to raise
the exception "Permission denied" in this case.

Consider a similar situation in which both /bin/foobar
(not executable
by the user) and /usr/bin/foobar (executable by the
user) exist.
Given the command "foobar", the shell will execute
/usr/bin/foobar.
If I understand the patch correctly, python will give
up when it
encounters /bin/foobar and raise the "Permission
denied" exception.

I believe this just happened to me today.  I had a
shell script named
"gcc" in ~/bin (first on my path) some months back. 
When I was
finished with it, I just did "chmod -x ~/bin/gcc" and
forgot about it.
Today was the first time since this patch went in that
I ran gcc via
python (using scipy's weave).  Boy was I surprised at
the message
"unable to execute gcc: Permission denied"!

I guess the fix is to save the EPERM exception and keep
going
in case there is an executable later in the path.


----------------------------------------------------------------------

Comment By: Zack Weinberg (zackw)
Date: 2002-08-31 15:10

Message:
Logged In: YES 
user_id=580015

I've created a patch for this bug.  I would like to attach it,
but Sourceforge doesn't want to let me do that, so I'll just
insert it inline here:

===================================================================
Index: Lib/os.py
--- Lib/os.py	5 Aug 2002 16:13:24 -0000	1.59
+++ Lib/os.py	31 Aug 2002 19:08:34 -0000
@@ -309,7 +309,7 @@ def execvp(file, args):
     _execvpe(file, args)
 
 def execvpe(file, args, env):
-    """execv(file, args, env)
+    """execvpe(file, args, env)
 
     Execute the executable file (which is searched for
along $PATH)
     with argument list args and environment env , replacing the
@@ -339,14 +339,21 @@ def _execvpe(file, args, env=None):
     else:
         envpath = defpath
     PATH = envpath.split(pathsep)
+    saved_exc = None
+    saved_tb = None
     for dir in PATH:
         fullname = path.join(dir, file)
         try:
             apply(func, (fullname,) + argrest)
-        except error, (errno, msg):
-            if errno != ENOENT and errno != ENOTDIR:
-                raise
-    raise error, (errno, msg)
+        except error, e:
+            tb = sys.exc_info()[2]
+            if (e.errno != ENOENT and e.errno != ENOTDIR
+                and saved_exc is None):
+                saved_exc = e
+                saved_tb = tb
+    if saved_exc:
+        raise error, saved_exc, saved_tb
+    raise error, e, tb
 
 # Change environ to automatically call putenv() if it exists
 try:


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-27 21:06

Message:
Logged In: YES 
user_id=6380

Since I applied Zack's patch to the trunk as well as to the
2.2 maintenance branch, this needs to be fixed in both places.

This worked correctly in 2.1 and 2.2 (and in 2.2.1, but I
haven't tested that).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=601077&group_id=5470