From noreply@sourceforge.net  Wed Nov  1 04:38:17 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 31 Oct 2000 20:38:17 -0800
Subject: [Python-bugs-list] [Bug #119862] Memory leak in python 2.0 and below
Message-ID: <200011010438.UAA09341@sf-web1.i.sourceforge.net>

Bug #119862, was updated on 2000-Oct-31 04:22
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Memory leak in python 2.0 and below

Details: The reference count of the item returned by the PyMapping_GetItemString function in call inside the function vgetargskeywords is not decremented. This can result in a memory leak.

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


From noreply@sourceforge.net  Wed Nov  1 04:40:36 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 31 Oct 2000 20:40:36 -0800
Subject: [Python-bugs-list] [Bug #119822] urllib doesn't like unicode
Message-ID: <200011010440.UAA10675@sf-web3.vaspecialprojects.com>

Bug #119822, was updated on 2000-Oct-30 17:12
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: urllib doesn't like unicode

Details: 
getting a file via urllib.urlopen(u"http://foobar/blahblah")
produces undesirable results.

Something like:

  File "/usr/local/lib/python2.0/urllib.py", line 61, in urlopen
    return _urlopener.open(url)
  File "/usr/local/lib/python2.0/urllib.py", line 166, in open
    return getattr(self, name)(url)
  File "/usr/local/lib/python2.0/urllib.py", line 248, in open_http
    host, selector = url
ValueError: unpack sequence of wrong size


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


From noreply@sourceforge.net  Wed Nov  1 09:17:38 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 1 Nov 2000 01:17:38 -0800
Subject: [Python-bugs-list] [Bug #120983] python2.0 dumps core in gc_list_remove
Message-ID: <200011010917.BAA13320@sf-web3.vaspecialprojects.com>

Bug #120983, was updated on 2000-Nov-01 01:17
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: python2.0 dumps core in gc_list_remove

Details: Source: downloaded from http://www.python.org
OS: freebsd 4.1
Compilation options: default
  (does not occur when compiled with --without-cycle-gc)
Observed while: running Zope2-cvs.

I have not tested this on other operating systems, but it seems reproducible, if intermittent on freebsd. I will keep the binary and the corefile in case further information is needed.

some information extracted with gdb:

#0  0x80a8ffb in gc_list_remove (node=0x89eab40) at ./gcmodule.c:88
---Type <return> to continue, or q <return> to quit---
88              node->gc_next->gc_prev = node->gc_prev;
(gdb) p node
$1 = (struct _gc_head *) 0x89eab40
(gdb) p node->gc_next
$2 = (struct _gc_head *) 0x0
#0  0x80a8ffb in gc_list_remove (node=0x89eab40) at ./gcmodule.c:88
#1  0x80a9ac3 in _PyGC_Remove (op=0x89eab40) at ./gcmodule.c:523
#2  0x807e01d in instance_dealloc (inst=0x89eab4c) at classobject.c:552
#3  0x808ea46 in insertdict (mp=0x89f004c, key=0x89e3ba8, hash=134733596, 
    value=0x8064d13) at dictobject.c:343
#4  0x808ee01 in PyDict_SetItem (op=0x89f004c, key=0x89e3ba8, value=0x807df1c)
    at dictobject.c:477
#5  0x2836e33c in subclass_simple_setattro (self=0x89ea900, name=0x8835760, 
    v=0x89ead6c) at ./../Components/ExtensionClass/ExtensionClass.c:2174
#6  0x283914cc in _setattro (self=0x89ea900, oname=0x8835760, v=0x89ead6c, 
    setattrf=0x2836e2cc <subclass_simple_setattro>) at ./cPersistence.c:661
#7  0x283915d0 in Per_setattro (self=0x89ea900, oname=0x8835760, v=0x89ead6c)
    at ./cPersistence.c:701
#8  0x80926c5 in PyObject_SetAttr (v=0x89eab40, name=0x89e3ba8, 
    value=0x807df1c) at object.c:767
#9  0x283ae5df in Wrapper_setattro (self=0x8856f70, oname=0x8835760, 
    v=0x89ead6c) at ./../Components/ExtensionClass/Acquisition.c:600

...

(gdb) up
#1  0x80a9ac3 in _PyGC_Remove (op=0x89eab40) at ./gcmodule.c:523
523             gc_list_remove(g);
(gdb) p *g
$4 = {gc_next = 0xc, gc_prev = 0x80db600, gc_refs = 7}
(gdb) up
#2  0x807e01d in instance_dealloc (inst=0x89eab4c) at classobject.c:552
552             PyObject_GC_Fini(inst);
(gdb) p *inst
$6 = {ob_refcnt = 0, ob_type = 0x80d89e0, in_class = 0x88a790c, 
  in_dict = 0x89eeccc}
(gdb) p *inst->ob_type
$7 = {ob_refcnt = 10, ob_type = 0x80db740, ob_size = 0, 
  tp_name = 0x80cb646 "instance", tp_basicsize = 28, tp_itemsize = 0, 
  tp_dealloc = 0x807df1c <instance_dealloc>, tp_print = 0, tp_getattr = 0, 
  tp_setattr = 0, tp_compare = 0x807e860 <instance_compare>, 
  tp_repr = 0x807e690 <instance_repr>, tp_as_number = 0x80d8940, 
  tp_as_sequence = 0x80d8900, tp_as_mapping = 0x80d88ec, 
  tp_hash = 0x807e93c <instance_hash>, tp_call = 0, tp_str = 0, 
  tp_getattro = 0x807e278 <instance_getattr>, 
  tp_setattro = 0x807e388 <instance_setattr>, tp_as_buffer = 0x0, 
  tp_flags = 15, tp_doc = 0x0, tp_traverse = 0x807ead4 <instance_traverse>, 
  tp_clear = 0, tp_xxx7 = 0, tp_xxx8 = 0}
(gdb) p *inst->in_class
$8 = {ob_refcnt = 4, ob_type = 0x80d8880, cl_bases = 0x80fbcac, 
  cl_dict = 0x88a794c, cl_name = 0x88a54c0, cl_getattr = 0x0, 
  cl_setattr = 0x0, cl_delattr = 0x0}



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


From noreply@sourceforge.net  Wed Nov  1 13:41:14 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 1 Nov 2000 05:41:14 -0800
Subject: [Python-bugs-list] [Bug #120993] Installation flaky with multiple installers, old versions
Message-ID: <200011011341.FAA23369@sf-web2.i.sourceforge.net>

Bug #120993, was updated on 2000-Nov-01 05:41
Here is a current snapshot of the bug.

Project: Python
Category: Distutils
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Installation flaky with multiple installers, old versions

Details: Installation tends to have problems when there are old installations present, especially when a different user is doing the new installation.

In particular, it appears that the chmod() done in 'copy_file()' (as a result of the "install" command attempting to preserve the mode of files from the build tree) fails, because you can't chmod() a file owned by somebody else.

Paul Dubois suggests that simply unlinking the target file before doing the copy should work.  I think he's right, but need to think about it and test it a bit first.


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


From noreply@sourceforge.net  Wed Nov  1 13:43:59 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 1 Nov 2000 05:43:59 -0800
Subject: [Python-bugs-list] [Bug #120994] Traceback with DISTUTILS_DEBUG set
Message-ID: <200011011343.FAA23421@sf-web2.i.sourceforge.net>

Bug #120994, was updated on 2000-Nov-01 05:43
Here is a current snapshot of the bug.

Project: Python
Category: Distutils
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Traceback with DISTUTILS_DEBUG set

Details: Something is wrong in the 'dump_dirs()' method of the "install" command: it bombs with an AttributeError:

$ DISTUTILS_DEBUG=1 python setup.py install
[...]
running install
Distribution.get_command_obj(): creating 'install' command object
pre-finalize_{unix,other}:
  prefix: None
  exec_prefix: None
  home: None
  install_base: None
  install_platbase: None
  root: None
  install_purelib: None
  install_platlib: None
  install_lib: None
  install_headers: None
  install_scripts: None
  install_data: None
  compile: None
Traceback (most recent call last):
  File "setup.py", line 28, in ?
    packages = ['distutils', 'distutils.command'],
  File "distutils/core.py", line 138, in setup
    dist.run_commands()
  File "distutils/dist.py", line 829, in run_commands
    self.run_command(cmd)
  File "distutils/dist.py", line 848, in run_command
    cmd_obj.ensure_finalized()
  File "distutils/cmd.py", line 112, in ensure_finalized
    self.finalize_options()
  File "distutils/command/install.py", line 240, in finalize_options
    self.dump_dirs("pre-finalize_{unix,other}")
  File "distutils/command/install.py", line 338, in dump_dirs
    val = getattr(self, opt_name)
  File "distutils/cmd.py", line 107, in __getattr__
    raise AttributeError, attr
AttributeError: no_compile

Not sure what's going on here...


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


From noreply@sourceforge.net  Wed Nov  1 13:44:12 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 1 Nov 2000 05:44:12 -0800
Subject: [Python-bugs-list] [Bug #120994] Traceback with DISTUTILS_DEBUG set
Message-ID: <200011011344.FAA23427@sf-web2.i.sourceforge.net>

Bug #120994, was updated on 2000-Nov-01 05:43
Here is a current snapshot of the bug.

Project: Python
Category: Distutils
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Traceback with DISTUTILS_DEBUG set

Details: Something is wrong in the 'dump_dirs()' method of the "install" command: it bombs with an AttributeError:

$ DISTUTILS_DEBUG=1 python setup.py install
[...]
running install
Distribution.get_command_obj(): creating 'install' command object
pre-finalize_{unix,other}:
  prefix: None
  exec_prefix: None
  home: None
  install_base: None
  install_platbase: None
  root: None
  install_purelib: None
  install_platlib: None
  install_lib: None
  install_headers: None
  install_scripts: None
  install_data: None
  compile: None
Traceback (most recent call last):
  File "setup.py", line 28, in ?
    packages = ['distutils', 'distutils.command'],
  File "distutils/core.py", line 138, in setup
    dist.run_commands()
  File "distutils/dist.py", line 829, in run_commands
    self.run_command(cmd)
  File "distutils/dist.py", line 848, in run_command
    cmd_obj.ensure_finalized()
  File "distutils/cmd.py", line 112, in ensure_finalized
    self.finalize_options()
  File "distutils/command/install.py", line 240, in finalize_options
    self.dump_dirs("pre-finalize_{unix,other}")
  File "distutils/command/install.py", line 338, in dump_dirs
    val = getattr(self, opt_name)
  File "distutils/cmd.py", line 107, in __getattr__
    raise AttributeError, attr
AttributeError: no_compile

Not sure what's going on here...


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


From noreply@sourceforge.net  Wed Nov  1 15:46:49 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 1 Nov 2000 07:46:49 -0800
Subject: [Python-bugs-list] [Bug #120082] making vars() more useful
Message-ID: <200011011546.HAA18975@sf-web3.vaspecialprojects.com>

Bug #120082, was updated on 2000-Oct-31 14:20
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 4
Summary: making vars() more useful

Details: It might make sense to change built-in vars() with no arguments.  Instead of being equivalent to locals(), it should be equivalent to the following Python code:

d = globals().copy()
d.update(locals())


Follow-Ups:

Date: 2000-Nov-01 07:46
By: jhylton

Comment:
Is this a feature request (PEP 42) or a bug report?

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

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


From noreply@sourceforge.net  Wed Nov  1 15:57:16 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 1 Nov 2000 07:57:16 -0800
Subject: [Python-bugs-list] [Bug #120983] python2.0 dumps core in gc_list_remove
Message-ID: <200011011557.HAA26515@sf-web2.i.sourceforge.net>

Bug #120983, was updated on 2000-Nov-01 01:17
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: python2.0 dumps core in gc_list_remove

Details: Source: downloaded from http://www.python.org
OS: freebsd 4.1
Compilation options: default
  (does not occur when compiled with --without-cycle-gc)
Observed while: running Zope2-cvs.

I have not tested this on other operating systems, but it seems reproducible, if intermittent on freebsd. I will keep the binary and the corefile in case further information is needed.

some information extracted with gdb:

#0  0x80a8ffb in gc_list_remove (node=0x89eab40) at ./gcmodule.c:88
---Type <return> to continue, or q <return> to quit---
88              node->gc_next->gc_prev = node->gc_prev;
(gdb) p node
$1 = (struct _gc_head *) 0x89eab40
(gdb) p node->gc_next
$2 = (struct _gc_head *) 0x0
#0  0x80a8ffb in gc_list_remove (node=0x89eab40) at ./gcmodule.c:88
#1  0x80a9ac3 in _PyGC_Remove (op=0x89eab40) at ./gcmodule.c:523
#2  0x807e01d in instance_dealloc (inst=0x89eab4c) at classobject.c:552
#3  0x808ea46 in insertdict (mp=0x89f004c, key=0x89e3ba8, hash=134733596, 
    value=0x8064d13) at dictobject.c:343
#4  0x808ee01 in PyDict_SetItem (op=0x89f004c, key=0x89e3ba8, value=0x807df1c)
    at dictobject.c:477
#5  0x2836e33c in subclass_simple_setattro (self=0x89ea900, name=0x8835760, 
    v=0x89ead6c) at ./../Components/ExtensionClass/ExtensionClass.c:2174
#6  0x283914cc in _setattro (self=0x89ea900, oname=0x8835760, v=0x89ead6c, 
    setattrf=0x2836e2cc <subclass_simple_setattro>) at ./cPersistence.c:661
#7  0x283915d0 in Per_setattro (self=0x89ea900, oname=0x8835760, v=0x89ead6c)
    at ./cPersistence.c:701
#8  0x80926c5 in PyObject_SetAttr (v=0x89eab40, name=0x89e3ba8, 
    value=0x807df1c) at object.c:767
#9  0x283ae5df in Wrapper_setattro (self=0x8856f70, oname=0x8835760, 
    v=0x89ead6c) at ./../Components/ExtensionClass/Acquisition.c:600

...

(gdb) up
#1  0x80a9ac3 in _PyGC_Remove (op=0x89eab40) at ./gcmodule.c:523
523             gc_list_remove(g);
(gdb) p *g
$4 = {gc_next = 0xc, gc_prev = 0x80db600, gc_refs = 7}
(gdb) up
#2  0x807e01d in instance_dealloc (inst=0x89eab4c) at classobject.c:552
552             PyObject_GC_Fini(inst);
(gdb) p *inst
$6 = {ob_refcnt = 0, ob_type = 0x80d89e0, in_class = 0x88a790c, 
  in_dict = 0x89eeccc}
(gdb) p *inst->ob_type
$7 = {ob_refcnt = 10, ob_type = 0x80db740, ob_size = 0, 
  tp_name = 0x80cb646 "instance", tp_basicsize = 28, tp_itemsize = 0, 
  tp_dealloc = 0x807df1c <instance_dealloc>, tp_print = 0, tp_getattr = 0, 
  tp_setattr = 0, tp_compare = 0x807e860 <instance_compare>, 
  tp_repr = 0x807e690 <instance_repr>, tp_as_number = 0x80d8940, 
  tp_as_sequence = 0x80d8900, tp_as_mapping = 0x80d88ec, 
  tp_hash = 0x807e93c <instance_hash>, tp_call = 0, tp_str = 0, 
  tp_getattro = 0x807e278 <instance_getattr>, 
  tp_setattro = 0x807e388 <instance_setattr>, tp_as_buffer = 0x0, 
  tp_flags = 15, tp_doc = 0x0, tp_traverse = 0x807ead4 <instance_traverse>, 
  tp_clear = 0, tp_xxx7 = 0, tp_xxx8 = 0}
(gdb) p *inst->in_class
$8 = {ob_refcnt = 4, ob_type = 0x80d8880, cl_bases = 0x80fbcac, 
  cl_dict = 0x88a794c, cl_name = 0x88a54c0, cl_getattr = 0x0, 
  cl_setattr = 0x0, cl_delattr = 0x0}



Follow-Ups:

Date: 2000-Nov-01 07:57
By: jhylton

Comment:
From a cursory glance, I would guess this is a problem with the extension classes used by Zope, not with the garbage collector.  
-------------------------------------------------------

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


From noreply@sourceforge.net  Wed Nov  1 16:00:44 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 1 Nov 2000 08:00:44 -0800
Subject: [Python-bugs-list] [Bug #119960] Encoding bugs.
Message-ID: <200011011600.IAA19193@sf-web3.vaspecialprojects.com>

Bug #119960, was updated on 2000-Oct-31 13:38
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Encoding bugs.

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

Follow-Ups:

Date: 2000-Nov-01 08:00
By: jhylton

Comment:
I am not entirely sure what the bug is, though I agree that it can be confusing to deal with Unicode strings.

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

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


From noreply@sourceforge.net  Wed Nov  1 16:00:55 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 1 Nov 2000 08:00:55 -0800
Subject: [Python-bugs-list] [Bug #119860] Exception "TypeError: not enough arguments" without details
Message-ID: <200011011600.IAA26655@sf-web2.i.sourceforge.net>

Bug #119860, was updated on 2000-Oct-31 03:50
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: 3rd Party
Priority: 5
Summary: Exception "TypeError: not enough arguments" without details

Details: It is possible to create a TypeError without a stack trace thus creating an exception without any hints what is wrong. You will need a third party module (I'll use PyGTK) to reproduce this:

------- test.py ---------------------
from gtk import *

def test (x, y):
    print x, y
    mainquit ()

timeout_add (1.0, test)

mainloop ()
-------- test.py ----------

Run this and you will get this message:

--- output ------------------------
TypeError: not enough parameters; expected 2, got 0
--- output ------------------------

The problem is of course that when Python has to evaluate the code, there is no "calling" instance (and thus Python has no idea what to print). As I see it, there are only two possible solutions:

- Users who want to use this API (to run Python code) must submit a "position" object (which will make python print "test.py:7 timeout_add..." when an exception happens in the C code which tries to call test()). For this, there must be an API to query the current position in a source script (should already be there because the code which prints stack traces must do something very similar).
- The code which prints the exception is in Python/ceval.c in ceval2(). The first object passed it a CodeObject. If we would pass the function object instead, we could at least print the name of the function. But ceval2() is also used in other circumstances, therefore, this might be impossible.

A quick solution and/or workaround would be most welcome !

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


From noreply@sourceforge.net  Wed Nov  1 16:01:43 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 1 Nov 2000 08:01:43 -0800
Subject: [Python-bugs-list] [Bug #119806] cgi.py uses too much memory on large file uploads
Message-ID: <200011011601.IAA17077@sf-web1.i.sourceforge.net>

Bug #119806, was updated on 2000-Oct-30 13:35
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: cgi.py uses too much memory on large file uploads

Details: When uploading files through a web form and parsing the form using cgi.py - the entire fil(s are read into memory, which is intolerable with very large (I'm thinking multiple 10's of megabyte) files.

The culprit seems to be in the FieldStorage class, basically the three calls to:

   self.lines.append(line)

in the read_lines_to_eof, read_lines_to_outerboundary, and skip_lines methods.  

Commenting those calls out seems to fix the problem, as long as you don't care to access the 'lines' member of the FieldStorage instance.  A real fix would possibly be to add a "keep_lines=1" keyword parameter to FieldStorage.__init__(), save that value in the instance, and check it before accumulating form lines.

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


From noreply@sourceforge.net  Wed Nov  1 16:02:29 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 1 Nov 2000 08:02:29 -0800
Subject: [Python-bugs-list] [Bug #119755] sys.getdefaultencoding undocumented
Message-ID: <200011011602.IAA26676@sf-web2.i.sourceforge.net>

Bug #119755, was updated on 2000-Oct-30 06:05
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: sys.getdefaultencoding undocumented

Details: I can't find any documentation of the getdefaultencoding function of module sys (though I can guess what it does...), nor any explanation about how to set/change the default encoding (or assertion that it cannot be changed).


Follow-Ups:

Date: 2000-Oct-30 06:44
By: lemburg

Comment:
Since the default encoding is 'ascii' unless one edits site.py or
sitecustomize.py to use something else, there is not much to document
here ;-)

Anyway, documentation was already written and will show up with
the next documentation release, I guess.... Fred ?

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

Date: 2000-Nov-01 08:02
By: jhylton

Comment:
If there is nothing to document, can we close this bug report?

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

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


From noreply@sourceforge.net  Wed Nov  1 16:04:20 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 1 Nov 2000 08:04:20 -0800
Subject: [Python-bugs-list] [Bug #119123] Use of ftplib or urllib causes page fault on exit
Message-ID: <200011011604.IAA17109@sf-web1.i.sourceforge.net>

Bug #119123, was updated on 2000-Oct-25 18:30
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Summary: Use of ftplib or urllib causes page fault on exit

Details: I work at a government office and have been using Python for over a year. Our office upgraded all the PC with the latest version of Netscape, IE Explorer, and security patches to Windows. After this upgrade, all scripts that use either ftplib or urllib cause a page fault in KERNEL32.DLL whenever Python exits. This page fault happens on every machine (Win95 & Win98) using Python, Pythonw, IDLE, or scripts; with version 1.5.2 and 2.0. The fault does not pop up until the script exits or interactive Python exits.

Because of this development, all Python work has stopped and my supervisors are re-evaluating the use Python for production work. I have been an avid promoter of Python, but now I am completely stuck. Other programs on the machines still work, only Python seems to be affected. Please help!

Below is the page fault message:
PYTHONW caused an invalid page fault in
module KERNEL32.DLL at 0167:bff7b9a6.
Registers:
EAX=00000000 CS=0167 EIP=bff7b9a6 EFLGS=00000246
EBX=0087b650 SS=016f ESP=0062fbdc EBP=0084d73c
ECX=00000000 DS=016f ESI=020325f0 FS=4207
EDX=00000000 ES=016f EDI=00671d68 GS=0000
Bytes at CS:EIP:
ff 76 04 e8 13 89 ff ff 5e c2 04 00 56 8b 74 24
Stack dump:
0087b650 02020b13 020325f0 0062fbf8 76003481
0062fbf8 0084d730 0087b650 7600265e 00000000
0084d730 0084d6d0 0084d6dc 76003283 0084d6d0 7600e420

Please contact mike.callahan@noaa.gov or call 800-292-5588 if you have any answers. I want to keep Python in our office, but right now, I am fighting a losing battle.

Mike Callahan
National Weather Service
Louisville KY



Follow-Ups:

Date: 2000-Nov-01 08:04
By: jhylton

Comment:
This is a pretty strange bug report.  Many, many people use Python on Windows and do not experience any such problem.
-------------------------------------------------------

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


From noreply@sourceforge.net  Wed Nov  1 16:06:45 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 1 Nov 2000 08:06:45 -0800
Subject: [Python-bugs-list] [Bug #120081] PyDict_Update() missing from C API
Message-ID: <200011011606.IAA19277@sf-web3.vaspecialprojects.com>

Bug #120081, was updated on 2000-Oct-31 14:18
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 4
Summary: PyDict_Update() missing from C API

Details: The C API should include a PyDict_Update() function which takes a dictionary as its first argument, and an arbitrary mapping as its second.  Similarly there should probably be a PyMapping_Update() in the abstract API (and several other dictionary methods in there too).

Follow-Ups:

Date: 2000-Nov-01 08:06
By: jhylton

Comment:
PEP 42 or bug report?

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

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


From noreply@sourceforge.net  Wed Nov  1 16:26:12 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 1 Nov 2000 08:26:12 -0800
Subject: [Python-bugs-list] [Bug #119755] sys.getdefaultencoding undocumented
Message-ID: <200011011626.IAA19596@sf-web3.vaspecialprojects.com>

Bug #119755, was updated on 2000-Oct-30 06:05
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Closed
Resolution: None
Bug Group: None
Priority: 5
Summary: sys.getdefaultencoding undocumented

Details: I can't find any documentation of the getdefaultencoding function of module sys (though I can guess what it does...), nor any explanation about how to set/change the default encoding (or assertion that it cannot be changed).


Follow-Ups:

Date: 2000-Oct-30 06:44
By: lemburg

Comment:
Since the default encoding is 'ascii' unless one edits site.py or
sitecustomize.py to use something else, there is not much to document
here ;-)

Anyway, documentation was already written and will show up with
the next documentation release, I guess.... Fred ?

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

Date: 2000-Nov-01 08:02
By: jhylton

Comment:
If there is nothing to document, can we close this bug report?

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

Date: 2000-Nov-01 08:26
By: lemburg

Comment:
I already sent the docs to Fred, so I think that we can close the
"bug"... done.
-------------------------------------------------------

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


From noreply@sourceforge.net  Wed Nov  1 17:18:21 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 1 Nov 2000 09:18:21 -0800
Subject: [Python-bugs-list] [Bug #110665] Compiling python on hpux 11.00 with threads (PR#360)
Message-ID: <200011011718.JAA18108@sf-web1.i.sourceforge.net>

Bug #110665, was updated on 2000-Jul-31 14:12
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: None
Bug Group: Platform-specific
Priority: 3
Summary: Compiling python on hpux 11.00 with threads (PR#360)

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


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

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

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

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

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

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

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

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



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

Follow-Ups:

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-22 02:56
By: gvanrossum

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

Date: 2000-Sep-25 06:10
By: gvanrossum

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

Date: 2000-Oct-06 10:40
By: gvanrossum

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

Date: 2000-Oct-10 04:55
By: edg

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

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

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

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

and if not, fall back on the other tests ?

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

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

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

Date: 2000-Oct-30 09:48
By: gvanrossum

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

Date: 2000-Nov-01 09:18
By: none

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

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

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

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

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

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


From noreply@sourceforge.net  Wed Nov  1 18:17:18 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 1 Nov 2000 10:17:18 -0800
Subject: [Python-bugs-list] [Bug #121013] codecs.StreamReadWriter.writelines method accesses null ptr
Message-ID: <200011011817.KAA29769@sf-web2.i.sourceforge.net>

Bug #121013, was updated on 2000-Nov-01 10:17
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: codecs.StreamReadWriter.writelines method accesses null ptr

Details: Python 2.0 (#8, Oct 16 2000, 17:27:58) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
IDLE 0.6 -- press F1 for help
>>> import codecs
>>> f = codecs.open("c:\\temp\\junk.txt", "w", "UTF-8")
>>> msg = u"this is a test"
>>> f.writelines(msg)

result:
The instruction at "0x002925a6 referenced memory at "0x00000000".  The memory could not be "read".

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


From noreply@sourceforge.net  Wed Nov  1 18:30:36 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 1 Nov 2000 10:30:36 -0800
Subject: [Python-bugs-list] [Bug #116172] 2.0b2 curses module fails to build on SGI
Message-ID: <200011011830.KAA30127@sf-web2.i.sourceforge.net>

Bug #116172, was updated on 2000-Oct-05 12:40
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 3
Summary: 2.0b2 curses module fails to build on SGI

Details: I didn't see this in the database.

Trying to build 2.0b2 here on SGI IRIX 6.5.  I have this
line in Setup:

     _curses _cursesmodule.c -lcurses -ltermcap

This used to work on 1.5.2 on IRIX 6.5, but it doesn't with 2.0b2.

Here is a digested version of the errors:

cc -n32  -O -KPIC -I./../Include -I.. -DHAVE_CONFIG_H -c ./_cursesmodule.c
...
  The identifier "attr_t" is undefined.
  The identifier "ACS_S3" is undefined.
  The identifier "ACS_LEQUAL" is undefined.
  The identifier "ACS_GEQUAL" is undefined.
  The identifier "ACS_PI" is undefined.
  The identifier "ACS_NEQUAL" is undefined.
  The identifier "ACS_STERLING" is undefined.
  A value of type "int" cannot be assigned to an entity of type "char *".
        capname = tigetstr( capname );
                ^
  The identifier "A_HORIZONTAL" is undefined.
  The identifier "A_LEFT" is undefined.
  The identifier "A_LOW" is undefined.
  The identifier "A_RIGHT" is undefined.
  The identifier "A_TOP" is undefined.
  The identifier "A_VERTICAL" is undefined.


Follow-Ups:

Date: 2000-Oct-06 07:50
By: gvanrossum

Comment:
I don't know, but I think this may be caused by IRIX having an old, incompatible version of curses. So it probably won't work. Too bad. You may be able to get a different curses implementation (there must be a free one that comes with Linux???).
-------------------------------------------------------

Date: 2000-Oct-06 08:42
By: jhylton

Comment:
Eric, can you look at this today?
-------------------------------------------------------

Date: 2000-Oct-06 11:26
By: VizNut

Comment:
A quick grep reveals Sun Solaris 7 doesn't have them either.

If the intent is to break with standard curses, to avoid confusion it might be best to rename the module from curses to "linux_curses" or "ncurses" (if that's the appropriate curses variety).

Thanks,

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

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

Comment:
This appears to be simply a matter of the platform's curses library being *reeeeeeeally* old. So I'm lowering the priority.

The ncurses API is actually quite old, and vendors have no excuse for not providing it. That's why it's not a good idea to call the module linuxcurses or ncurses.

However, it's quite possible that your vendor provides both the old curses API and the ncurses API, under those names. In that case it shouldn't be hard to change the source code to include "ncurses.h" and the Makefile to link with -lncurses. If you get this working, I'd be glad to accept a patch via the SourceForge Patch manager! This can't be done in 2.0 though (we're in a code freeze stage right now where only critical bugfixes may be checked in).
-------------------------------------------------------

Date: 2000-Oct-20 10:45
By: akuchling

Comment:
Clarification: ncurses implements the SYSV curses API,
which adds a lot of features on top of the old BSD curses API.  For example, Solaris doesn't use ncurses, but it does 
support the SYSV API, and the module should work there.

There's a STRICT_SYSV_CURSES macro that can be defined 
in _cursesmodule.c that removes certain features that
aren't on every SYSV curses platform.  That macro should be 
defined on SGI, from the following code:

#if defined(__sgi__) || defined(__sun__)
#define STRICT_SYSV_CURSES       /* Don't use ncurses extensions */
typedef chtype attr_t;           /* No attr_t type is available */
#endif                                                                          

Does your compiler not define __sgi__?  Perhaps some different macro should be used for this feature test.

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

Date: 2000-Nov-01 10:30
By: VizNut

Comment:
Just sent this reply to "Fred L. Drake, Jr." <fdrake@acm.org>.  Logging it here for record keeping...:

Randall

--- Message Follows ---

     Hi Fred.  Thanks for the patch!  Sorry for the week delay.  I've been snowed here at work lately.

     I just tested it out; I got a bag of compiler errors when building with _curses with the patch in-place.  However, this change:

  < #if defined(__sgi__) || defined(__sun__)
  > #if defined(sgi) || defined(__sun__)

gets the number of errors down to one (__sgi__ isn't defined on SGI; sgi is though).  

The one error that remained was an error about tigetstr returning an int and assigned to a char * variable (missing the prototype).  This prototype is in <term.h>, but including this header #defines many common symbols
(such as "lines") which breaks the curses module in other ways.  So I just specified an explicit prototype.  This bit at the top of the file works:

> #ifdef sgi
> /*#  include <term.h>*/         /* Don't use -- it #defines common syms */
> extern char *tigetstr(char *);
> #endif

I've attached the updated patch for the curses module to this message with
the above changes.

I'll log this to the bug page here in a sec.

Thanks,

Randall

--- End Message ---
-------------------------------------------------------

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


From noreply@sourceforge.net  Wed Nov  1 18:36:48 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 1 Nov 2000 10:36:48 -0800
Subject: [Python-bugs-list] [Bug #116172] 2.0b2 curses module fails to build on SGI
Message-ID: <200011011836.KAA30226@sf-web2.i.sourceforge.net>

Bug #116172, was updated on 2000-Oct-05 12:40
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 3
Summary: 2.0b2 curses module fails to build on SGI

Details: I didn't see this in the database.

Trying to build 2.0b2 here on SGI IRIX 6.5.  I have this
line in Setup:

     _curses _cursesmodule.c -lcurses -ltermcap

This used to work on 1.5.2 on IRIX 6.5, but it doesn't with 2.0b2.

Here is a digested version of the errors:

cc -n32  -O -KPIC -I./../Include -I.. -DHAVE_CONFIG_H -c ./_cursesmodule.c
...
  The identifier "attr_t" is undefined.
  The identifier "ACS_S3" is undefined.
  The identifier "ACS_LEQUAL" is undefined.
  The identifier "ACS_GEQUAL" is undefined.
  The identifier "ACS_PI" is undefined.
  The identifier "ACS_NEQUAL" is undefined.
  The identifier "ACS_STERLING" is undefined.
  A value of type "int" cannot be assigned to an entity of type "char *".
        capname = tigetstr( capname );
                ^
  The identifier "A_HORIZONTAL" is undefined.
  The identifier "A_LEFT" is undefined.
  The identifier "A_LOW" is undefined.
  The identifier "A_RIGHT" is undefined.
  The identifier "A_TOP" is undefined.
  The identifier "A_VERTICAL" is undefined.


Follow-Ups:

Date: 2000-Oct-06 07:50
By: gvanrossum

Comment:
I don't know, but I think this may be caused by IRIX having an old, incompatible version of curses. So it probably won't work. Too bad. You may be able to get a different curses implementation (there must be a free one that comes with Linux???).
-------------------------------------------------------

Date: 2000-Oct-06 08:42
By: jhylton

Comment:
Eric, can you look at this today?
-------------------------------------------------------

Date: 2000-Oct-06 11:26
By: VizNut

Comment:
A quick grep reveals Sun Solaris 7 doesn't have them either.

If the intent is to break with standard curses, to avoid confusion it might be best to rename the module from curses to "linux_curses" or "ncurses" (if that's the appropriate curses variety).

Thanks,

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

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

Comment:
This appears to be simply a matter of the platform's curses library being *reeeeeeeally* old. So I'm lowering the priority.

The ncurses API is actually quite old, and vendors have no excuse for not providing it. That's why it's not a good idea to call the module linuxcurses or ncurses.

However, it's quite possible that your vendor provides both the old curses API and the ncurses API, under those names. In that case it shouldn't be hard to change the source code to include "ncurses.h" and the Makefile to link with -lncurses. If you get this working, I'd be glad to accept a patch via the SourceForge Patch manager! This can't be done in 2.0 though (we're in a code freeze stage right now where only critical bugfixes may be checked in).
-------------------------------------------------------

Date: 2000-Oct-20 10:45
By: akuchling

Comment:
Clarification: ncurses implements the SYSV curses API,
which adds a lot of features on top of the old BSD curses API.  For example, Solaris doesn't use ncurses, but it does 
support the SYSV API, and the module should work there.

There's a STRICT_SYSV_CURSES macro that can be defined 
in _cursesmodule.c that removes certain features that
aren't on every SYSV curses platform.  That macro should be 
defined on SGI, from the following code:

#if defined(__sgi__) || defined(__sun__)
#define STRICT_SYSV_CURSES       /* Don't use ncurses extensions */
typedef chtype attr_t;           /* No attr_t type is available */
#endif                                                                          

Does your compiler not define __sgi__?  Perhaps some different macro should be used for this feature test.

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

Date: 2000-Nov-01 10:30
By: VizNut

Comment:
Just sent this reply to "Fred L. Drake, Jr." <fdrake@acm.org>.  Logging it here for record keeping...:

Randall

--- Message Follows ---

     Hi Fred.  Thanks for the patch!  Sorry for the week delay.  I've been snowed here at work lately.

     I just tested it out; I got a bag of compiler errors when building with _curses with the patch in-place.  However, this change:

  < #if defined(__sgi__) || defined(__sun__)
  > #if defined(sgi) || defined(__sun__)

gets the number of errors down to one (__sgi__ isn't defined on SGI; sgi is though).  

The one error that remained was an error about tigetstr returning an int and assigned to a char * variable (missing the prototype).  This prototype is in <term.h>, but including this header #defines many common symbols
(such as "lines") which breaks the curses module in other ways.  So I just specified an explicit prototype.  This bit at the top of the file works:

> #ifdef sgi
> /*#  include <term.h>*/         /* Don't use -- it #defines common syms */
> extern char *tigetstr(char *);
> #endif

I've attached the updated patch for the curses module to this message with
the above changes.

I'll log this to the bug page here in a sec.

Thanks,

Randall

--- End Message ---
-------------------------------------------------------

Date: 2000-Nov-01 10:36
By: VizNut

Comment:
2000-Oct-20 17:45 by akuchling:
 | Does your compiler not define __sgi__? Perhaps some
 | different macro should be used for this feature test.

Thanks Andrew.  Just noted this in my reply to Fred (Cc bug history) that "__sgi__" isn't defined on IRIX, but "sgi" is.  That gets past all but one of the compilation errors.  That error is described in my follow-up (2000-Nov-01 18:30 VizNut).

Randall

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

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


From noreply@sourceforge.net  Wed Nov  1 18:50:34 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 1 Nov 2000 10:50:34 -0800
Subject: [Python-bugs-list] [Bug #121027] regex.compile("***").match("") malfunction
Message-ID: <200011011850.KAA30616@sf-web2.i.sourceforge.net>

Bug #121027, was updated on 2000-Nov-01 10:50
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: regex.compile("***").match("") malfunction

Details: Hi,
I've found it by mistake, but regex.compile/match methods seems to have a bug handling weird regex expressions as "***".
See below, this happens inside NT/cygwin but also happens inside python 1.6/solaris SunOS 5.5.1.
Hoping this could help.
Claudio Ortega
cortega@sinfomed.org.ar
cortega@nortelnetworks.com

----------------------------------------------------
bash-2.02$ python
Python 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit (Intel)] on win32
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import regex
>>> regex.compile("*").match("")
-1
>>> regex.compile("*").match("")
-1
>>> regex.compile("**").match("")
0
>>> regex.compile("***").match("")
(prompt doesn't return here anymore, memory consumption begins to grow until memory is exhausted)
----------------------------------------------------



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


From noreply@sourceforge.net  Wed Nov  1 19:06:35 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 1 Nov 2000 11:06:35 -0800
Subject: [Python-bugs-list] [Bug #121013] codecs.StreamReadWriter.writelines method accesses null ptr
Message-ID: <200011011906.LAA30930@sf-web2.i.sourceforge.net>

Bug #121013, was updated on 2000-Nov-01 10:17
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: codecs.StreamReadWriter.writelines method accesses null ptr

Details: Python 2.0 (#8, Oct 16 2000, 17:27:58) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
IDLE 0.6 -- press F1 for help
>>> import codecs
>>> f = codecs.open("c:\\temp\\junk.txt", "w", "UTF-8")
>>> msg = u"this is a test"
>>> f.writelines(msg)

result:
The instruction at "0x002925a6 referenced memory at "0x00000000".  The memory could not be "read".

Follow-Ups:

Date: 2000-Nov-01 11:06
By: lemburg

Comment:
The bug headline is misleading: the bug boils down to

""..join(u"this is a test")

causing a segfault. (Note that you should pass a list to .join()... not
a string.

The cause is the PySequence_Fast_GET_ITEM() macro:

#define PySequence_Fast_GET_ITEM(o, i)\
     (PyList_Check(o) ? PyList_GET_ITEM(o, i) : PyTuple_GET_ITEM(o, i))

... this only works for lists and tuples and not arbitrary sequences like
the name implies.

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

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


From noreply@sourceforge.net  Wed Nov  1 20:00:35 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 1 Nov 2000 12:00:35 -0800
Subject: [Python-bugs-list] [Bug #116172] 2.0b2 curses module fails to build on SGI
Message-ID: <200011012000.MAA32413@sf-web2.i.sourceforge.net>

Bug #116172, was updated on 2000-Oct-05 12:40
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: Fixed
Bug Group: Platform-specific
Priority: 3
Summary: 2.0b2 curses module fails to build on SGI

Details: I didn't see this in the database.

Trying to build 2.0b2 here on SGI IRIX 6.5.  I have this
line in Setup:

     _curses _cursesmodule.c -lcurses -ltermcap

This used to work on 1.5.2 on IRIX 6.5, but it doesn't with 2.0b2.

Here is a digested version of the errors:

cc -n32  -O -KPIC -I./../Include -I.. -DHAVE_CONFIG_H -c ./_cursesmodule.c
...
  The identifier "attr_t" is undefined.
  The identifier "ACS_S3" is undefined.
  The identifier "ACS_LEQUAL" is undefined.
  The identifier "ACS_GEQUAL" is undefined.
  The identifier "ACS_PI" is undefined.
  The identifier "ACS_NEQUAL" is undefined.
  The identifier "ACS_STERLING" is undefined.
  A value of type "int" cannot be assigned to an entity of type "char *".
        capname = tigetstr( capname );
                ^
  The identifier "A_HORIZONTAL" is undefined.
  The identifier "A_LEFT" is undefined.
  The identifier "A_LOW" is undefined.
  The identifier "A_RIGHT" is undefined.
  The identifier "A_TOP" is undefined.
  The identifier "A_VERTICAL" is undefined.


Follow-Ups:

Date: 2000-Oct-06 07:50
By: gvanrossum

Comment:
I don't know, but I think this may be caused by IRIX having an old, incompatible version of curses. So it probably won't work. Too bad. You may be able to get a different curses implementation (there must be a free one that comes with Linux???).
-------------------------------------------------------

Date: 2000-Oct-06 08:42
By: jhylton

Comment:
Eric, can you look at this today?
-------------------------------------------------------

Date: 2000-Oct-06 11:26
By: VizNut

Comment:
A quick grep reveals Sun Solaris 7 doesn't have them either.

If the intent is to break with standard curses, to avoid confusion it might be best to rename the module from curses to "linux_curses" or "ncurses" (if that's the appropriate curses variety).

Thanks,

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

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

Comment:
This appears to be simply a matter of the platform's curses library being *reeeeeeeally* old. So I'm lowering the priority.

The ncurses API is actually quite old, and vendors have no excuse for not providing it. That's why it's not a good idea to call the module linuxcurses or ncurses.

However, it's quite possible that your vendor provides both the old curses API and the ncurses API, under those names. In that case it shouldn't be hard to change the source code to include "ncurses.h" and the Makefile to link with -lncurses. If you get this working, I'd be glad to accept a patch via the SourceForge Patch manager! This can't be done in 2.0 though (we're in a code freeze stage right now where only critical bugfixes may be checked in).
-------------------------------------------------------

Date: 2000-Oct-20 10:45
By: akuchling

Comment:
Clarification: ncurses implements the SYSV curses API,
which adds a lot of features on top of the old BSD curses API.  For example, Solaris doesn't use ncurses, but it does 
support the SYSV API, and the module should work there.

There's a STRICT_SYSV_CURSES macro that can be defined 
in _cursesmodule.c that removes certain features that
aren't on every SYSV curses platform.  That macro should be 
defined on SGI, from the following code:

#if defined(__sgi__) || defined(__sun__)
#define STRICT_SYSV_CURSES       /* Don't use ncurses extensions */
typedef chtype attr_t;           /* No attr_t type is available */
#endif                                                                          

Does your compiler not define __sgi__?  Perhaps some different macro should be used for this feature test.

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

Date: 2000-Nov-01 10:30
By: VizNut

Comment:
Just sent this reply to "Fred L. Drake, Jr." <fdrake@acm.org>.  Logging it here for record keeping...:

Randall

--- Message Follows ---

     Hi Fred.  Thanks for the patch!  Sorry for the week delay.  I've been snowed here at work lately.

     I just tested it out; I got a bag of compiler errors when building with _curses with the patch in-place.  However, this change:

  < #if defined(__sgi__) || defined(__sun__)
  > #if defined(sgi) || defined(__sun__)

gets the number of errors down to one (__sgi__ isn't defined on SGI; sgi is though).  

The one error that remained was an error about tigetstr returning an int and assigned to a char * variable (missing the prototype).  This prototype is in <term.h>, but including this header #defines many common symbols
(such as "lines") which breaks the curses module in other ways.  So I just specified an explicit prototype.  This bit at the top of the file works:

> #ifdef sgi
> /*#  include <term.h>*/         /* Don't use -- it #defines common syms */
> extern char *tigetstr(char *);
> #endif

I've attached the updated patch for the curses module to this message with
the above changes.

I'll log this to the bug page here in a sec.

Thanks,

Randall

--- End Message ---
-------------------------------------------------------

Date: 2000-Nov-01 10:36
By: VizNut

Comment:
2000-Oct-20 17:45 by akuchling:
 | Does your compiler not define __sgi__? Perhaps some
 | different macro should be used for this feature test.

Thanks Andrew.  Just noted this in my reply to Fred (Cc bug history) that "__sgi__" isn't defined on IRIX, but "sgi" is.  That gets past all but one of the compilation errors.  That error is described in my follow-up (2000-Nov-01 18:30 VizNut).

Randall

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

Date: 2000-Nov-01 12:00
By: akuchling

Comment:
Patch applied, with added explanatory comment.
-------------------------------------------------------

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


From noreply@sourceforge.net  Wed Nov  1 20:47:26 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 1 Nov 2000 12:47:26 -0800
Subject: [Python-bugs-list] [Bug #119960] Encoding bugs.
Message-ID: <200011012047.MAA23489@sf-web3.vaspecialprojects.com>

Bug #119960, was updated on 2000-Oct-31 13:38
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Encoding bugs.

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

Follow-Ups:

Date: 2000-Nov-01 08:00
By: jhylton

Comment:
I am not entirely sure what the bug is, though I agree that it can be confusing to deal with Unicode strings.

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

Date: 2000-Nov-01 12:47
By: lemburg

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

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


From noreply@sourceforge.net  Wed Nov  1 21:16:22 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 1 Nov 2000 13:16:22 -0800
Subject: [Python-bugs-list] [Bug #119960] Encoding bugs.
Message-ID: <200011012116.NAA01807@sf-web2.i.sourceforge.net>

Bug #119960, was updated on 2000-Oct-31 13:38
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Encoding bugs.

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

Follow-Ups:

Date: 2000-Nov-01 08:00
By: jhylton

Comment:
I am not entirely sure what the bug is, though I agree that it can be confusing to deal with Unicode strings.

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

Date: 2000-Nov-01 12:47
By: lemburg

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

Date: 2000-Nov-01 13:16
By: kirill_simonov

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

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


From noreply@sourceforge.net  Wed Nov  1 22:29:03 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 1 Nov 2000 14:29:03 -0800
Subject: [Python-bugs-list] [Bug #120081] PyDict_Update() missing from C API
Message-ID: <200011012229.OAA03630@sf-web2.i.sourceforge.net>

Bug #120081, was updated on 2000-Oct-31 14:18
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Later
Bug Group: Feature Request
Priority: 4
Summary: PyDict_Update() missing from C API

Details: The C API should include a PyDict_Update() function which takes a dictionary as its first argument, and an arbitrary mapping as its second.  Similarly there should probably be a PyMapping_Update() in the abstract API (and several other dictionary methods in there too).

Follow-Ups:

Date: 2000-Nov-01 08:06
By: jhylton

Comment:
PEP 42 or bug report?

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

Date: 2000-Nov-01 14:29
By: twouters

Comment:
At Moshe's request, who conferred with Barry apparently, marked closed. A feature request has been added to PEP 42.

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

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


From noreply@sourceforge.net  Wed Nov  1 22:30:42 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 1 Nov 2000 14:30:42 -0800
Subject: [Python-bugs-list] [Bug #120082] making vars() more useful
Message-ID: <200011012230.OAA03741@sf-web2.i.sourceforge.net>

Bug #120082, was updated on 2000-Oct-31 14:20
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Later
Bug Group: Feature Request
Priority: 4
Summary: making vars() more useful

Details: It might make sense to change built-in vars() with no arguments.  Instead of being equivalent to locals(), it should be equivalent to the following Python code:

d = globals().copy()
d.update(locals())


Follow-Ups:

Date: 2000-Nov-01 07:46
By: jhylton

Comment:
Is this a feature request (PEP 42) or a bug report?

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

Date: 2000-Nov-01 14:30
By: twouters

Comment:
At Moshe's request, who apparently conferred with Barry, marked closed. A feature request for this has been added to PEP 42.

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

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


From noreply@sourceforge.net  Wed Nov  1 22:34:30 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 1 Nov 2000 14:34:30 -0800
Subject: [Python-bugs-list] [Bug #121027] regex.compile("***").match("") malfunction
Message-ID: <200011012234.OAA25061@sf-web3.vaspecialprojects.com>

Bug #121027, was updated on 2000-Nov-01 10:50
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: regex.compile("***").match("") malfunction

Details: Hi,
I've found it by mistake, but regex.compile/match methods seems to have a bug handling weird regex expressions as "***".
See below, this happens inside NT/cygwin but also happens inside python 1.6/solaris SunOS 5.5.1.
Hoping this could help.
Claudio Ortega
cortega@sinfomed.org.ar
cortega@nortelnetworks.com

----------------------------------------------------
bash-2.02$ python
Python 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit (Intel)] on win32
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import regex
>>> regex.compile("*").match("")
-1
>>> regex.compile("*").match("")
-1
>>> regex.compile("**").match("")
0
>>> regex.compile("***").match("")
(prompt doesn't return here anymore, memory consumption begins to grow until memory is exhausted)
----------------------------------------------------



Follow-Ups:

Date: 2000-Nov-01 14:34
By: jhylton

Comment:
I don't know if we are still supporting regex.  Is there a reason not to use re?

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

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


From noreply@sourceforge.net  Wed Nov  1 22:39:17 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 1 Nov 2000 14:39:17 -0800
Subject: [Python-bugs-list] [Bug #121013] codecs.StreamReadWriter.writelines method accesses null ptr
Message-ID: <200011012239.OAA25113@sf-web3.vaspecialprojects.com>

Bug #121013, was updated on 2000-Nov-01 10:17
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Summary: codecs.StreamReadWriter.writelines method accesses null ptr

Details: Python 2.0 (#8, Oct 16 2000, 17:27:58) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
IDLE 0.6 -- press F1 for help
>>> import codecs
>>> f = codecs.open("c:\\temp\\junk.txt", "w", "UTF-8")
>>> msg = u"this is a test"
>>> f.writelines(msg)

result:
The instruction at "0x002925a6 referenced memory at "0x00000000".  The memory could not be "read".

Follow-Ups:

Date: 2000-Nov-01 11:06
By: lemburg

Comment:
The bug headline is misleading: the bug boils down to

""..join(u"this is a test")

causing a segfault. (Note that you should pass a list to .join()... not
a string.

The cause is the PySequence_Fast_GET_ITEM() macro:

#define PySequence_Fast_GET_ITEM(o, i)\
     (PyList_Check(o) ? PyList_GET_ITEM(o, i) : PyTuple_GET_ITEM(o, i))

... this only works for lists and tuples and not arbitrary sequences like
the name implies.

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

Date: 2000-Nov-01 14:39
By: jhylton

Comment:
I think the cause is whatever uses the PySequence_Fast_GET_ITEM macro (which may have a misleading name).

It looks like it might also be useful to raise an exception when join is passed a string.  I think it's more likely to be an error than deliberate.

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

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


From noreply@sourceforge.net  Thu Nov  2 01:01:23 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 1 Nov 2000 17:01:23 -0800
Subject: [Python-bugs-list] [Bug #121060] memory leak in python 2.0
Message-ID: <200011020101.RAA06980@sf-web2.i.sourceforge.net>

Bug #121060, was updated on 2000-Nov-01 17:01
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: memory leak in python 2.0

Details: I seem to have stumbled on a memory leak that only seems to occur in Python 2.0, it doesn't happen in Python 1.5.2, and I've been told (but haven't verified) that it doesn't happen in 1.6 either.

It seems to happen when what I'd call a 'second order' import occurs, a really simple test case that leaks memory pretty fast -

------

in a directory called Shared, I have a file called test.py, with contents -

---
import time
---

and an __init__.py so that I can import it.

in the directory a level up I have a file called atest.py with contents -

---
from Shared import test

pass
---

and finally I have a file called tester.py with contents -

---
while 1:
    execfile('atest.py')
---

------

running tester.py with python 2.0 leaks memory, running it with python 1.5.2 remains at a constant usage.

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


From noreply@sourceforge.net  Thu Nov  2 04:47:40 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 1 Nov 2000 20:47:40 -0800
Subject: [Python-bugs-list] [Bug #119123] Use of ftplib or urllib causes page fault on exit
Message-ID: <200011020447.UAA29860@sf-web3.vaspecialprojects.com>

Bug #119123, was updated on 2000-Oct-25 18:30
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Use of ftplib or urllib causes page fault on exit

Details: I work at a government office and have been using Python for over a year. Our office upgraded all the PC with the latest version of Netscape, IE Explorer, and security patches to Windows. After this upgrade, all scripts that use either ftplib or urllib cause a page fault in KERNEL32.DLL whenever Python exits. This page fault happens on every machine (Win95 & Win98) using Python, Pythonw, IDLE, or scripts; with version 1.5.2 and 2.0. The fault does not pop up until the script exits or interactive Python exits.

Because of this development, all Python work has stopped and my supervisors are re-evaluating the use Python for production work. I have been an avid promoter of Python, but now I am completely stuck. Other programs on the machines still work, only Python seems to be affected. Please help!

Below is the page fault message:
PYTHONW caused an invalid page fault in
module KERNEL32.DLL at 0167:bff7b9a6.
Registers:
EAX=00000000 CS=0167 EIP=bff7b9a6 EFLGS=00000246
EBX=0087b650 SS=016f ESP=0062fbdc EBP=0084d73c
ECX=00000000 DS=016f ESI=020325f0 FS=4207
EDX=00000000 ES=016f EDI=00671d68 GS=0000
Bytes at CS:EIP:
ff 76 04 e8 13 89 ff ff 5e c2 04 00 56 8b 74 24
Stack dump:
0087b650 02020b13 020325f0 0062fbf8 76003481
0062fbf8 0084d730 0087b650 7600265e 00000000
0084d730 0084d6d0 0084d6dc 76003283 0084d6d0 7600e420

Please contact mike.callahan@noaa.gov or call 800-292-5588 if you have any answers. I want to keep Python in our office, but right now, I am fighting a losing battle.

Mike Callahan
National Weather Service
Louisville KY



Follow-Ups:

Date: 2000-Nov-01 08:04
By: jhylton

Comment:
This is a pretty strange bug report.  Many, many people use Python on Windows and do not experience any such problem.
-------------------------------------------------------

Date: 2000-Nov-01 20:47
By: tim_one

Comment:
Reduced priority; mailed this msg to Mike:

Hi, Mike.  This is about the Python bug you reported at:

http://sourceforge.net/bugs/?func=detailbug&bug_id=119123&group_id=5470

I don't see that we can do much about this:

1. Tens of thousands of people use Python on Windows, and yours is the only report of this.

2. There's no evidence of a Python bug.  KERNEL32.DLL, where the error happens, is a core Microsoft DLL, and its source code is an MS secret -- i.e., the error is in MS's code, and you'd probably have to pay Microsoft support staff to find out exactly what's going wrong in their code.

That said, at least post a small and self-contained program that exhibits the problem so others can *try* it.  Since you have no idea what's going wrong either, saying "all scripts that use either ftplib or urllib" gives us no information.  There may well be something your site's particular scripts have in common that's important!  It's certainly *not* the case that other people using ftplib or urllib on Windows are having troubles.

Since your uses of ftplib and urllib presumably access info across a network, a likely cause of errors in KERNEL32.DLL is a misconfigured network, or non-MS "security programs" that poke around where they shouldn't (incl. virus checkers, which are a notorious source of problems -- have you tried running your scripts w/ virus checkers disabled?  with all background tasks other than Explorer and Systray killed off?  that's just basic Windows debugging procedure, but can't tell whether you've done any of it).

About "I want to keep Python in our office, but right now, I am fighting a losing battle", ask them to *think* a little.  In the old days, people used to take canaries into coal mines, because (or so the story goes ...) if there was a potentially fatal buildup of gases, the canaries would pass out before people noticed.  Throwing out Python because your sysadmins changed your setup in such a way that Microsoft's software blows up is a lot like saying the canary keeps passing out, so let's ignore it <0.5 wink>.  Python didn't cause this problem -- indeed, you said there was no problem before they "upgraded" your systems!

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

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


From noreply@sourceforge.net  Thu Nov  2 15:25:39 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 2 Nov 2000 07:25:39 -0800
Subject: [Python-bugs-list] [Bug #110665] Compiling python on hpux 11.00 with threads (PR#360)
Message-ID: <200011021525.HAA05567@sf-web3.vaspecialprojects.com>

Bug #110665, was updated on 2000-Jul-31 14:12
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: None
Bug Group: Platform-specific
Priority: 3
Summary: Compiling python on hpux 11.00 with threads (PR#360)

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


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

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

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

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

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

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

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

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



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

Follow-Ups:

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-22 02:56
By: gvanrossum

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

Date: 2000-Sep-25 06:10
By: gvanrossum

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

Date: 2000-Oct-06 10:40
By: gvanrossum

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

Date: 2000-Oct-10 04:55
By: edg

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

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

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

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

and if not, fall back on the other tests ?

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

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

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

Date: 2000-Oct-30 09:48
By: gvanrossum

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

Date: 2000-Nov-01 09:18
By: none

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

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

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

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

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

Date: 2000-Nov-02 07:25
By: none

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

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

-- 
albert chin (china@thewrittenword.com)
-------------------------------------------------------

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


From noreply@sourceforge.net  Thu Nov  2 15:42:55 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 2 Nov 2000 07:42:55 -0800
Subject: [Python-bugs-list] [Bug #121060] memory leak in python 2.0
Message-ID: <200011021542.HAA25574@sf-web2.i.sourceforge.net>

Bug #121060, was updated on 2000-Nov-01 17:01
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: memory leak in python 2.0

Details: I seem to have stumbled on a memory leak that only seems to occur in Python 2.0, it doesn't happen in Python 1.5.2, and I've been told (but haven't verified) that it doesn't happen in 1.6 either.

It seems to happen when what I'd call a 'second order' import occurs, a really simple test case that leaks memory pretty fast -

------

in a directory called Shared, I have a file called test.py, with contents -

---
import time
---

and an __init__.py so that I can import it.

in the directory a level up I have a file called atest.py with contents -

---
from Shared import test

pass
---

and finally I have a file called tester.py with contents -

---
while 1:
    execfile('atest.py')
---

------

running tester.py with python 2.0 leaks memory, running it with python 1.5.2 remains at a constant usage.

Follow-Ups:

Date: 2000-Nov-02 07:42
By: gvanrossum

Comment:
For Barry. I can indeed reproduce this!
-------------------------------------------------------

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


From noreply@sourceforge.net  Thu Nov  2 15:51:51 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 2 Nov 2000 07:51:51 -0800
Subject: [Python-bugs-list] [Bug #121115] Kill threads from main thread
Message-ID: <200011021551.HAA05987@sf-web3.vaspecialprojects.com>

Bug #121115, was updated on 2000-Nov-02 07:51
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: Kill threads from main thread

Details: It still isn't possible to kill a thread from another thread. This is an important feature for long running processes as multithreaded application servers. It should be possible for the main thread (or another thread) to kill a non responding thread after a timeout.

As I read in a discussion forum "pthreads" support somewhat like thread_cancel() for Windows I don't know.

If this feature became implemented it would be nice if an ThreadObject from the module "threading" could be killed by deleting the object.

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


From noreply@sourceforge.net  Thu Nov  2 16:20:12 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 2 Nov 2000 08:20:12 -0800
Subject: [Python-bugs-list] [Bug #121027] regex.compile("***").match("") malfunction
Message-ID: <200011021620.IAA06416@sf-web3.vaspecialprojects.com>

Bug #121027, was updated on 2000-Nov-01 10:50
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: regex.compile("***").match("") malfunction

Details: Hi,
I've found it by mistake, but regex.compile/match methods seems to have a bug handling weird regex expressions as "***".
See below, this happens inside NT/cygwin but also happens inside python 1.6/solaris SunOS 5.5.1.
Hoping this could help.
Claudio Ortega
cortega@sinfomed.org.ar
cortega@nortelnetworks.com

----------------------------------------------------
bash-2.02$ python
Python 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit (Intel)] on win32
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import regex
>>> regex.compile("*").match("")
-1
>>> regex.compile("*").match("")
-1
>>> regex.compile("**").match("")
0
>>> regex.compile("***").match("")
(prompt doesn't return here anymore, memory consumption begins to grow until memory is exhausted)
----------------------------------------------------



Follow-Ups:

Date: 2000-Nov-01 14:34
By: jhylton

Comment:
I don't know if we are still supporting regex.  Is there a reason not to use re?

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

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


From noreply@sourceforge.net  Thu Nov  2 16:33:46 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 2 Nov 2000 08:33:46 -0800
Subject: [Python-bugs-list] [Bug #121121] Dynamic loading on Solaris does not work
Message-ID: <200011021633.IAA03660@sf-web1.i.sourceforge.net>

Bug #121121, was updated on 2000-Nov-02 08:33
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Dynamic loading on Solaris does not work

Details: Dynamic loading of shared libraries (Python/dynload_shlib) does not work under Solaris. This is due to a bug in the autoconf script. The patch at ftp://ftp.thewrittenword.com/outgoing/pub/python-2.0-solaris-dynload.patch fixes it.

The problem is that AC_CHECK_LIB(dl, dlopen) will never define HAVE_DLOPEN (AC_CHECK_FUNCS(dlopen) does that) which in turn will never define $ac_cv_func_dlopen. Anyway, using internal autoconf macros is icky. Redo the autoconf test because it will cache the results.

-- 
albert chin (china@thewrittenword.com)

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


From noreply@sourceforge.net  Thu Nov  2 16:38:58 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 2 Nov 2000 08:38:58 -0800
Subject: [Python-bugs-list] [Bug #110665] Compiling python on hpux 11.00 with threads (PR#360)
Message-ID: <200011021638.IAA03718@sf-web1.i.sourceforge.net>

Bug #110665, was updated on 2000-Jul-31 14:12
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 3
Summary: Compiling python on hpux 11.00 with threads (PR#360)

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


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

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

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

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

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

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

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

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



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

Follow-Ups:

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-22 02:56
By: gvanrossum

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

Date: 2000-Sep-25 06:10
By: gvanrossum

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

Date: 2000-Oct-06 10:40
By: gvanrossum

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

Date: 2000-Oct-10 04:55
By: edg

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

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

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

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

and if not, fall back on the other tests ?

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

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

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

Date: 2000-Oct-30 09:48
By: gvanrossum

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

Date: 2000-Nov-01 09:18
By: none

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

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

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

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

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

Date: 2000-Nov-02 07:25
By: none

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

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

-- 
albert chin (china@thewrittenword.com)
-------------------------------------------------------

Date: 2000-Nov-02 08:38
By: gvanrossum

Comment:
Reopened because there's a dissenting opinion.
-------------------------------------------------------

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


From noreply@sourceforge.net  Thu Nov  2 16:47:31 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 2 Nov 2000 08:47:31 -0800
Subject: [Python-bugs-list] [Bug #119860] Exception "TypeError: not enough arguments" without details
Message-ID: <200011021647.IAA03841@sf-web1.i.sourceforge.net>

Bug #119860, was updated on 2000-Oct-31 03:50
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Wont Fix
Bug Group: 3rd Party
Priority: 5
Summary: Exception "TypeError: not enough arguments" without details

Details: It is possible to create a TypeError without a stack trace thus creating an exception without any hints what is wrong. You will need a third party module (I'll use PyGTK) to reproduce this:

------- test.py ---------------------
from gtk import *

def test (x, y):
    print x, y
    mainquit ()

timeout_add (1.0, test)

mainloop ()
-------- test.py ----------

Run this and you will get this message:

--- output ------------------------
TypeError: not enough parameters; expected 2, got 0
--- output ------------------------

The problem is of course that when Python has to evaluate the code, there is no "calling" instance (and thus Python has no idea what to print). As I see it, there are only two possible solutions:

- Users who want to use this API (to run Python code) must submit a "position" object (which will make python print "test.py:7 timeout_add..." when an exception happens in the C code which tries to call test()). For this, there must be an API to query the current position in a source script (should already be there because the code which prints stack traces must do something very similar).
- The code which prints the exception is in Python/ceval.c in ceval2(). The first object passed it a CodeObject. If we would pass the function object instead, we could at least print the name of the function. But ceval2() is also used in other circumstances, therefore, this might be impossible.

A quick solution and/or workaround would be most welcome !

Follow-Ups:

Date: 2000-Nov-02 08:47
By: gvanrossum

Comment:
I think that the GTK bindings should fix this. There's nothing Python can do about this. I'm closing the bug report -- resubmit it to the GTK folks.
-------------------------------------------------------

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


From noreply@sourceforge.net  Thu Nov  2 16:50:56 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 2 Nov 2000 08:50:56 -0800
Subject: [Python-bugs-list] [Bug #120081] PyDict_Update() missing from C API
Message-ID: <200011021650.IAA27278@sf-web2.i.sourceforge.net>

Bug #120081, was updated on 2000-Oct-31 14:18
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Wont Fix
Bug Group: Feature Request
Priority: 4
Summary: PyDict_Update() missing from C API

Details: The C API should include a PyDict_Update() function which takes a dictionary as its first argument, and an arbitrary mapping as its second.  Similarly there should probably be a PyMapping_Update() in the abstract API (and several other dictionary methods in there too).

Follow-Ups:

Date: 2000-Nov-01 08:06
By: jhylton

Comment:
PEP 42 or bug report?

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

Date: 2000-Nov-01 14:29
By: twouters

Comment:
At Moshe's request, who conferred with Barry apparently, marked closed. A feature request has been added to PEP 42.

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

Date: 2000-Nov-02 08:50
By: gvanrossum

Comment:
This wish should not be fulfilled. I think there's no need to add C APIs for every method of dictionary objects! After all the implementation would just have to be to call the method. There are already ways to do that.
-------------------------------------------------------

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


From noreply@sourceforge.net  Thu Nov  2 16:55:58 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 2 Nov 2000 08:55:58 -0800
Subject: [Python-bugs-list] [Bug #120082] making vars() more useful
Message-ID: <200011021655.IAA06956@sf-web3.vaspecialprojects.com>

Bug #120082, was updated on 2000-Oct-31 14:20
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Wont Fix
Bug Group: Feature Request
Priority: 4
Summary: making vars() more useful

Details: It might make sense to change built-in vars() with no arguments.  Instead of being equivalent to locals(), it should be equivalent to the following Python code:

d = globals().copy()
d.update(locals())


Follow-Ups:

Date: 2000-Nov-01 07:46
By: jhylton

Comment:
Is this a feature request (PEP 42) or a bug report?

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

Date: 2000-Nov-01 14:30
By: twouters

Comment:
At Moshe's request, who apparently conferred with Barry, marked closed. A feature request for this has been added to PEP 42.

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

Date: 2000-Nov-02 08:55
By: gvanrossum

Comment:
I disagree. vars() and locals() return a dictionary that might be modified. If you implement what he says, this won't work any more. This is an ill-conceived feature request and should not be honored.
-------------------------------------------------------

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


From noreply@sourceforge.net  Thu Nov  2 17:31:44 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 2 Nov 2000 09:31:44 -0800
Subject: [Python-bugs-list] [Bug #121115] Kill threads from main thread
Message-ID: <200011021731.JAA07472@sf-web3.vaspecialprojects.com>

Bug #121115, was updated on 2000-Nov-02 07:51
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: Kill threads from main thread

Details: It still isn't possible to kill a thread from another thread. This is an important feature for long running processes as multithreaded application servers. It should be possible for the main thread (or another thread) to kill a non responding thread after a timeout.

As I read in a discussion forum "pthreads" support somewhat like thread_cancel() for Windows I don't know.

If this feature became implemented it would be nice if an ThreadObject from the module "threading" could be killed by deleting the object.

Follow-Ups:

Date: 2000-Nov-02 09:31
By: gvanrossum

Comment:
This is a very controversial feature. If a thread owns a resource (e.g. it holds a lock), what happens to the resource when the thread is killed?

The best idea I can come up with is to make it possible to send asynchronous exceptions to threads -- but this doesn't help for threads that are blocked in an I/O operation. That might be solved through sending signals, but that's a Unix-only solution, and probably isn't even consistent across different Unix thread implementations.
-------------------------------------------------------

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


From noreply@sourceforge.net  Thu Nov  2 17:32:59 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 2 Nov 2000 09:32:59 -0800
Subject: [Python-bugs-list] [Bug #119645] distutils.sysconfig.LINKFORSHARED is undefined
Message-ID: <200011021732.JAA07491@sf-web3.vaspecialprojects.com>

Bug #119645, was updated on 2000-Oct-28 17:24
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: distutils.sysconfig.LINKFORSHARED is undefined

Details: The current documentation (in http://www.python.org/doc/current/ext/link-reqs.html) says to check the value of distutils.sysconfig.LINKFORSHARED in order to get compiler options for embedding Python.  However, this value is undefined in Python 2.0, installed on a RedHat Linux system from the RPMs on www.python.org:

>>> import distutils.sysconfig
>>> distutils.sysconfig.LINKFORSHARED 
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
AttributeError: LINKFORSHARED


Follow-Ups:

Date: 2000-Oct-30 18:25
By: gward

Comment:
This is a documentation bug, but I plead partly guilty (since I changed the interface of the distutils.sysconfig module without thinking to see if it had been documented anywhere, implicitly or not).  Oops.

This patch fixes the doc bug:

--- ext.tex     2000/10/26 17:19:58     1.87
+++ ext.tex     2000/10/31 02:22:58
@@ -2138,7 +2138,7 @@
 
 \begin{verbatim}
 >>> import distutils.sysconfig
->>> distutils.sysconfig.LINKFORSHARED 
+>>> distutils.sysconfig.get_config_var("LINKFORSHARED")
 '-Xlinker -export-dynamic'
 \end{verbatim}
 \refstmodindex{distutils.sysconfig}

Fred, I can check this in if you want...
-------------------------------------------------------

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


From noreply@sourceforge.net  Thu Nov  2 17:36:18 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 2 Nov 2000 09:36:18 -0800
Subject: [Python-bugs-list] [Bug #121129] makesetup loop
Message-ID: <200011021736.JAA07540@sf-web3.vaspecialprojects.com>

Bug #121129, was updated on 2000-Nov-02 09:36
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Summary: makesetup loop

Details: My Python build directory is different from the source directory.  After the most recent changes to Setup processing, make gets stuck in an infinite loop.


(cd Modules; make -f Makefile.pre Makefile)
make[1]: Entering directory `/home/jeremy/src/python/dist/src/build-O3/Modules'
-----------------------------------------------
Modules/Setup.dist is newer than Modules/Setup;
check to make sure you have all the updates you
need in your Modules/Setup file.
-----------------------------------------------
rm -rf ../libpython2.0.a
/bin/sh ../../Modules/makesetup Setup.config Setup.local Setup
cat: Setup.local: No such file or directory
cat: Setup: No such file or directory
make[1]: Leaving directory `/home/jeremy/src/python/dist/src/build-O3/Modules'
making Makefile in subdirectory .
make[1]: Entering directory `/home/jeremy/src/python/dist/src/build-O3'
make[1]: `Makefile' is up to date.
make[1]: Leaving directory `/home/jeremy/src/python/dist/src/build-O3'
making Makefile in subdirectory Parser
make[1]: Entering directory `/home/jeremy/src/python/dist/src/build-O3/Parser'
make[1]: `Makefile' is up to date.
make[1]: Leaving directory `/home/jeremy/src/python/dist/src/build-O3/Parser'
making Makefile in subdirectory Grammar
make[1]: Entering directory `/home/jeremy/src/python/dist/src/build-O3/Grammar'
make[1]: Nothing to be done for `Makefile'.
make[1]: Leaving directory `/home/jeremy/src/python/dist/src/build-O3/Grammar'
making Makefile in subdirectory Objects
make[1]: Entering directory `/home/jeremy/src/python/dist/src/build-O3/Objects'
make[1]: `Makefile' is up to date.
make[1]: Leaving directory `/home/jeremy/src/python/dist/src/build-O3/Objects'
making Makefile in subdirectory Python
make[1]: Entering directory `/home/jeremy/src/python/dist/src/build-O3/Python'
make[1]: `Makefile' is up to date.
make[1]: Leaving directory `/home/jeremy/src/python/dist/src/build-O3/Python'
making Makefile in subdirectory Modules
make[1]: Entering directory `/home/jeremy/src/python/dist/src/build-O3/Modules'
-----------------------------------------------
Modules/Setup.dist is newer than Modules/Setup;
check to make sure you have all the updates you
need in your Modules/Setup file.
-----------------------------------------------
rm -rf ../libpython2.0.a
/bin/sh ../../Modules/makesetup Setup.config Setup.local Setup
cat: Setup.local: No such file or directory
cat: Setup: No such file or directory
make[1]: Leaving directory `/home/jeremy/src/python/dist/src/build-O3/Modules'
make[1]: Entering directory `/home/jeremy/src/python/dist/src/build-O3/Modules'
-----------------------------------------------
Modules/Setup.dist is newer than Modules/Setup;
check to make sure you have all the updates you
need in your Modules/Setup file.
-----------------------------------------------
rm -rf ../libpython2.0.a
/bin/sh ../../Modules/makesetup Setup.config Setup.local Setup
cat: Setup.local: No such file or directory
cat: Setup: No such file or directory
make[1]: Leaving directory `/home/jeremy/src/python/dist/src/build-O3/Modules'
make[1]: Entering directory `/home/jeremy/src/python/dist/src/build-O3/Modules'
-----------------------------------------------
Modules/Setup.dist is newer than Modules/Setup;
check to make sure you have all the updates you
need in your Modules/Setup file.
-----------------------------------------------
rm -rf ../libpython2.0.a
/bin/sh ../../Modules/makesetup Setup.config Setup.local Setup
cat: Setup.local: No such file or directory
cat: Setup: No such file or directory
make[1]: Leaving directory `/home/jeremy/src/python/dist/src/build-O3/Modules'
make[1]: Entering directory `/home/jeremy/src/python/dist/src/build-O3/Modules'
-----------------------------------------------
Modules/Setup.dist is newer than Modules/Setup;
check to make sure you have all the updates you
need in your Modules/Setup file.

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


From noreply@sourceforge.net  Thu Nov  2 17:54:26 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 2 Nov 2000 09:54:26 -0800
Subject: [Python-bugs-list] [Bug #121129] makesetup loop
Message-ID: <200011021754.JAA04766@sf-web1.i.sourceforge.net>

Bug #121129, was updated on 2000-Nov-02 09:36
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Summary: makesetup loop

Details: My Python build directory is different from the source directory.  After the most recent changes to Setup processing, make gets stuck in an infinite loop.


(cd Modules; make -f Makefile.pre Makefile)
make[1]: Entering directory `/home/jeremy/src/python/dist/src/build-O3/Modules'
-----------------------------------------------
Modules/Setup.dist is newer than Modules/Setup;
check to make sure you have all the updates you
need in your Modules/Setup file.
-----------------------------------------------
rm -rf ../libpython2.0.a
/bin/sh ../../Modules/makesetup Setup.config Setup.local Setup
cat: Setup.local: No such file or directory
cat: Setup: No such file or directory
make[1]: Leaving directory `/home/jeremy/src/python/dist/src/build-O3/Modules'
making Makefile in subdirectory .
make[1]: Entering directory `/home/jeremy/src/python/dist/src/build-O3'
make[1]: `Makefile' is up to date.
make[1]: Leaving directory `/home/jeremy/src/python/dist/src/build-O3'
making Makefile in subdirectory Parser
make[1]: Entering directory `/home/jeremy/src/python/dist/src/build-O3/Parser'
make[1]: `Makefile' is up to date.
make[1]: Leaving directory `/home/jeremy/src/python/dist/src/build-O3/Parser'
making Makefile in subdirectory Grammar
make[1]: Entering directory `/home/jeremy/src/python/dist/src/build-O3/Grammar'
make[1]: Nothing to be done for `Makefile'.
make[1]: Leaving directory `/home/jeremy/src/python/dist/src/build-O3/Grammar'
making Makefile in subdirectory Objects
make[1]: Entering directory `/home/jeremy/src/python/dist/src/build-O3/Objects'
make[1]: `Makefile' is up to date.
make[1]: Leaving directory `/home/jeremy/src/python/dist/src/build-O3/Objects'
making Makefile in subdirectory Python
make[1]: Entering directory `/home/jeremy/src/python/dist/src/build-O3/Python'
make[1]: `Makefile' is up to date.
make[1]: Leaving directory `/home/jeremy/src/python/dist/src/build-O3/Python'
making Makefile in subdirectory Modules
make[1]: Entering directory `/home/jeremy/src/python/dist/src/build-O3/Modules'
-----------------------------------------------
Modules/Setup.dist is newer than Modules/Setup;
check to make sure you have all the updates you
need in your Modules/Setup file.
-----------------------------------------------
rm -rf ../libpython2.0.a
/bin/sh ../../Modules/makesetup Setup.config Setup.local Setup
cat: Setup.local: No such file or directory
cat: Setup: No such file or directory
make[1]: Leaving directory `/home/jeremy/src/python/dist/src/build-O3/Modules'
make[1]: Entering directory `/home/jeremy/src/python/dist/src/build-O3/Modules'
-----------------------------------------------
Modules/Setup.dist is newer than Modules/Setup;
check to make sure you have all the updates you
need in your Modules/Setup file.
-----------------------------------------------
rm -rf ../libpython2.0.a
/bin/sh ../../Modules/makesetup Setup.config Setup.local Setup
cat: Setup.local: No such file or directory
cat: Setup: No such file or directory
make[1]: Leaving directory `/home/jeremy/src/python/dist/src/build-O3/Modules'
make[1]: Entering directory `/home/jeremy/src/python/dist/src/build-O3/Modules'
-----------------------------------------------
Modules/Setup.dist is newer than Modules/Setup;
check to make sure you have all the updates you
need in your Modules/Setup file.
-----------------------------------------------
rm -rf ../libpython2.0.a
/bin/sh ../../Modules/makesetup Setup.config Setup.local Setup
cat: Setup.local: No such file or directory
cat: Setup: No such file or directory
make[1]: Leaving directory `/home/jeremy/src/python/dist/src/build-O3/Modules'
make[1]: Entering directory `/home/jeremy/src/python/dist/src/build-O3/Modules'
-----------------------------------------------
Modules/Setup.dist is newer than Modules/Setup;
check to make sure you have all the updates you
need in your Modules/Setup file.

Follow-Ups:

Date: 2000-Nov-02 09:54
By: fdrake

Comment:
I cannot reproduce this, but hit a different bug instead.  ;)

The configure script does not *create* the Modules/ directory in time to write the Modules/Setup file on the first run, so there are failures later.  This is fixed in configure.in revision 1.176.

I'm leaving this bug open, but assigning to Jeremy for further testing.  Please make sure you're starting with a clear working directory, or document what's there when you run configure for the first time.
-------------------------------------------------------

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


From noreply@sourceforge.net  Thu Nov  2 17:56:13 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 2 Nov 2000 09:56:13 -0800
Subject: [Python-bugs-list] [Bug #121027] regex.compile("***").match("") malfunction
Message-ID: <200011021756.JAA04798@sf-web1.i.sourceforge.net>

Bug #121027, was updated on 2000-Nov-01 10:50
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Wont Fix
Bug Group: None
Priority: 5
Summary: regex.compile("***").match("") malfunction

Details: Hi,
I've found it by mistake, but regex.compile/match methods seems to have a bug handling weird regex expressions as "***".
See below, this happens inside NT/cygwin but also happens inside python 1.6/solaris SunOS 5.5.1.
Hoping this could help.
Claudio Ortega
cortega@sinfomed.org.ar
cortega@nortelnetworks.com

----------------------------------------------------
bash-2.02$ python
Python 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit (Intel)] on win32
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import regex
>>> regex.compile("*").match("")
-1
>>> regex.compile("*").match("")
-1
>>> regex.compile("**").match("")
0
>>> regex.compile("***").match("")
(prompt doesn't return here anymore, memory consumption begins to grow until memory is exhausted)
----------------------------------------------------



Follow-Ups:

Date: 2000-Nov-01 14:34
By: jhylton

Comment:
I don't know if we are still supporting regex.  Is there a reason not to use re?

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

Date: 2000-Nov-02 09:56
By: gvanrossum

Comment:
Since this is about an obsolete module (regex, not re), we won't fix this. I'm closing the bug report now.
-------------------------------------------------------

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


From noreply@sourceforge.net  Thu Nov  2 18:08:11 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 2 Nov 2000 10:08:11 -0800
Subject: [Python-bugs-list] [Bug #121121] Dynamic loading on Solaris does not work
Message-ID: <200011021808.KAA07990@sf-web3.vaspecialprojects.com>

Bug #121121, was updated on 2000-Nov-02 08:33
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Dynamic loading on Solaris does not work

Details: Dynamic loading of shared libraries (Python/dynload_shlib) does not work under Solaris. This is due to a bug in the autoconf script. The patch at ftp://ftp.thewrittenword.com/outgoing/pub/python-2.0-solaris-dynload.patch fixes it.

The problem is that AC_CHECK_LIB(dl, dlopen) will never define HAVE_DLOPEN (AC_CHECK_FUNCS(dlopen) does that) which in turn will never define $ac_cv_func_dlopen. Anyway, using internal autoconf macros is icky. Redo the autoconf test because it will cache the results.

-- 
albert chin (china@thewrittenword.com)

Follow-Ups:

Date: 2000-Nov-02 10:08
By: gvanrossum

Comment:
Thanks for the patch; but would you be so kind to submit the patch to the SourceForge patch manager?
See http://sourceforge.net/patch/?group_id=5470
-------------------------------------------------------

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


From noreply@sourceforge.net  Thu Nov  2 18:14:25 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 2 Nov 2000 10:14:25 -0800
Subject: [Python-bugs-list] [Bug #121121] Dynamic loading on Solaris does not work
Message-ID: <200011021814.KAA05078@sf-web1.i.sourceforge.net>

Bug #121121, was updated on 2000-Nov-02 08:33
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Dynamic loading on Solaris does not work

Details: Dynamic loading of shared libraries (Python/dynload_shlib) does not work under Solaris. This is due to a bug in the autoconf script. The patch at ftp://ftp.thewrittenword.com/outgoing/pub/python-2.0-solaris-dynload.patch fixes it.

The problem is that AC_CHECK_LIB(dl, dlopen) will never define HAVE_DLOPEN (AC_CHECK_FUNCS(dlopen) does that) which in turn will never define $ac_cv_func_dlopen. Anyway, using internal autoconf macros is icky. Redo the autoconf test because it will cache the results.

-- 
albert chin (china@thewrittenword.com)

Follow-Ups:

Date: 2000-Nov-02 10:08
By: gvanrossum

Comment:
Thanks for the patch; but would you be so kind to submit the patch to the SourceForge patch manager?
See http://sourceforge.net/patch/?group_id=5470
-------------------------------------------------------

Date: 2000-Nov-02 10:14
By: tww-account

Comment:
Ok, patch uploaded to the SourceForge patch manager.
-------------------------------------------------------

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


From noreply@sourceforge.net  Thu Nov  2 18:49:43 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 2 Nov 2000 10:49:43 -0800
Subject: [Python-bugs-list] [Bug #121115] Kill threads from main thread
Message-ID: <200011021849.KAA08617@sf-web3.vaspecialprojects.com>

Bug #121115, was updated on 2000-Nov-02 07:51
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: Kill threads from main thread

Details: It still isn't possible to kill a thread from another thread. This is an important feature for long running processes as multithreaded application servers. It should be possible for the main thread (or another thread) to kill a non responding thread after a timeout.

As I read in a discussion forum "pthreads" support somewhat like thread_cancel() for Windows I don't know.

If this feature became implemented it would be nice if an ThreadObject from the module "threading" could be killed by deleting the object.

Follow-Ups:

Date: 2000-Nov-02 09:31
By: gvanrossum

Comment:
This is a very controversial feature. If a thread owns a resource (e.g. it holds a lock), what happens to the resource when the thread is killed?

The best idea I can come up with is to make it possible to send asynchronous exceptions to threads -- but this doesn't help for threads that are blocked in an I/O operation. That might be solved through sending signals, but that's a Unix-only solution, and probably isn't even consistent across different Unix thread implementations.
-------------------------------------------------------

Date: 2000-Nov-02 10:49
By: holtwick

Comment:
Blocking I/O operations are a problem, but what about other internal problems like endless loops? An asynchronous exception would be a good way for most problems (I have with threads ;) And as far as the documentation says, signals always go to the main thread. If that is so, it doesn't help much. 

So what about connecting signals to threads. I don't know if this is possible, but a reliable way to use signals with threads would be a way to give threads a timeout.
-------------------------------------------------------

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


From noreply@sourceforge.net  Thu Nov  2 20:04:06 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 2 Nov 2000 12:04:06 -0800
Subject: [Python-bugs-list] [Bug #121115] Kill threads from main thread
Message-ID: <200011022004.MAA06765@sf-web1.i.sourceforge.net>

Bug #121115, was updated on 2000-Nov-02 07:51
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: Kill threads from main thread

Details: It still isn't possible to kill a thread from another thread. This is an important feature for long running processes as multithreaded application servers. It should be possible for the main thread (or another thread) to kill a non responding thread after a timeout.

As I read in a discussion forum "pthreads" support somewhat like thread_cancel() for Windows I don't know.

If this feature became implemented it would be nice if an ThreadObject from the module "threading" could be killed by deleting the object.

Follow-Ups:

Date: 2000-Nov-02 09:31
By: gvanrossum

Comment:
This is a very controversial feature. If a thread owns a resource (e.g. it holds a lock), what happens to the resource when the thread is killed?

The best idea I can come up with is to make it possible to send asynchronous exceptions to threads -- but this doesn't help for threads that are blocked in an I/O operation. That might be solved through sending signals, but that's a Unix-only solution, and probably isn't even consistent across different Unix thread implementations.
-------------------------------------------------------

Date: 2000-Nov-02 10:49
By: holtwick

Comment:
Blocking I/O operations are a problem, but what about other internal problems like endless loops? An asynchronous exception would be a good way for most problems (I have with threads ;) And as far as the documentation says, signals always go to the main thread. If that is so, it doesn't help much. 

So what about connecting signals to threads. I don't know if this is possible, but a reliable way to use signals with threads would be a way to give threads a timeout.
-------------------------------------------------------

Date: 2000-Nov-02 12:04
By: gvanrossum

Comment:
As I said, signals are a Unix-only solution.

And blocked I/O is a common reason to *want* to kill a thread -- e.g. the common problem of webservers that simply never reply.
-------------------------------------------------------

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


From noreply@sourceforge.net  Thu Nov  2 20:56:27 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 2 Nov 2000 12:56:27 -0800
Subject: [Python-bugs-list] [Bug #121129] makesetup loop
Message-ID: <200011022056.MAA07544@sf-web1.i.sourceforge.net>

Bug #121129, was updated on 2000-Nov-02 09:36
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: Wont Fix
Bug Group: None
Priority: 7
Summary: makesetup loop

Details: My Python build directory is different from the source directory.  After the most recent changes to Setup processing, make gets stuck in an infinite loop.


(cd Modules; make -f Makefile.pre Makefile)
make[1]: Entering directory `/home/jeremy/src/python/dist/src/build-O3/Modules'
-----------------------------------------------
Modules/Setup.dist is newer than Modules/Setup;
check to make sure you have all the updates you
need in your Modules/Setup file.
-----------------------------------------------
rm -rf ../libpython2.0.a
/bin/sh ../../Modules/makesetup Setup.config Setup.local Setup
cat: Setup.local: No such file or directory
cat: Setup: No such file or directory
make[1]: Leaving directory `/home/jeremy/src/python/dist/src/build-O3/Modules'
making Makefile in subdirectory .
make[1]: Entering directory `/home/jeremy/src/python/dist/src/build-O3'
make[1]: `Makefile' is up to date.
make[1]: Leaving directory `/home/jeremy/src/python/dist/src/build-O3'
making Makefile in subdirectory Parser
make[1]: Entering directory `/home/jeremy/src/python/dist/src/build-O3/Parser'
make[1]: `Makefile' is up to date.
make[1]: Leaving directory `/home/jeremy/src/python/dist/src/build-O3/Parser'
making Makefile in subdirectory Grammar
make[1]: Entering directory `/home/jeremy/src/python/dist/src/build-O3/Grammar'
make[1]: Nothing to be done for `Makefile'.
make[1]: Leaving directory `/home/jeremy/src/python/dist/src/build-O3/Grammar'
making Makefile in subdirectory Objects
make[1]: Entering directory `/home/jeremy/src/python/dist/src/build-O3/Objects'
make[1]: `Makefile' is up to date.
make[1]: Leaving directory `/home/jeremy/src/python/dist/src/build-O3/Objects'
making Makefile in subdirectory Python
make[1]: Entering directory `/home/jeremy/src/python/dist/src/build-O3/Python'
make[1]: `Makefile' is up to date.
make[1]: Leaving directory `/home/jeremy/src/python/dist/src/build-O3/Python'
making Makefile in subdirectory Modules
make[1]: Entering directory `/home/jeremy/src/python/dist/src/build-O3/Modules'
-----------------------------------------------
Modules/Setup.dist is newer than Modules/Setup;
check to make sure you have all the updates you
need in your Modules/Setup file.
-----------------------------------------------
rm -rf ../libpython2.0.a
/bin/sh ../../Modules/makesetup Setup.config Setup.local Setup
cat: Setup.local: No such file or directory
cat: Setup: No such file or directory
make[1]: Leaving directory `/home/jeremy/src/python/dist/src/build-O3/Modules'
make[1]: Entering directory `/home/jeremy/src/python/dist/src/build-O3/Modules'
-----------------------------------------------
Modules/Setup.dist is newer than Modules/Setup;
check to make sure you have all the updates you
need in your Modules/Setup file.
-----------------------------------------------
rm -rf ../libpython2.0.a
/bin/sh ../../Modules/makesetup Setup.config Setup.local Setup
cat: Setup.local: No such file or directory
cat: Setup: No such file or directory
make[1]: Leaving directory `/home/jeremy/src/python/dist/src/build-O3/Modules'
make[1]: Entering directory `/home/jeremy/src/python/dist/src/build-O3/Modules'
-----------------------------------------------
Modules/Setup.dist is newer than Modules/Setup;
check to make sure you have all the updates you
need in your Modules/Setup file.
-----------------------------------------------
rm -rf ../libpython2.0.a
/bin/sh ../../Modules/makesetup Setup.config Setup.local Setup
cat: Setup.local: No such file or directory
cat: Setup: No such file or directory
make[1]: Leaving directory `/home/jeremy/src/python/dist/src/build-O3/Modules'
make[1]: Entering directory `/home/jeremy/src/python/dist/src/build-O3/Modules'
-----------------------------------------------
Modules/Setup.dist is newer than Modules/Setup;
check to make sure you have all the updates you
need in your Modules/Setup file.

Follow-Ups:

Date: 2000-Nov-02 09:54
By: fdrake

Comment:
I cannot reproduce this, but hit a different bug instead.  ;)

The configure script does not *create* the Modules/ directory in time to write the Modules/Setup file on the first run, so there are failures later.  This is fixed in configure.in revision 1.176.

I'm leaving this bug open, but assigning to Jeremy for further testing.  Please make sure you're starting with a clear working directory, or document what's there when you run configure for the first time.
-------------------------------------------------------

Date: 2000-Nov-02 12:56
By: jhylton

Comment:
This happens if you have a Setup.local in your source tree.  It's a limitation of VPATH support.  You can't build in the source tree and in other directories.

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

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


From noreply@sourceforge.net  Thu Nov  2 21:52:08 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 2 Nov 2000 13:52:08 -0800
Subject: [Python-bugs-list] [Bug #119645] distutils.sysconfig.LINKFORSHARED is undefined
Message-ID: <200011022152.NAA11383@sf-web3.vaspecialprojects.com>

Bug #119645, was updated on 2000-Oct-28 17:24
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: distutils.sysconfig.LINKFORSHARED is undefined

Details: The current documentation (in http://www.python.org/doc/current/ext/link-reqs.html) says to check the value of distutils.sysconfig.LINKFORSHARED in order to get compiler options for embedding Python.  However, this value is undefined in Python 2.0, installed on a RedHat Linux system from the RPMs on www.python.org:

>>> import distutils.sysconfig
>>> distutils.sysconfig.LINKFORSHARED 
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
AttributeError: LINKFORSHARED


Follow-Ups:

Date: 2000-Oct-30 18:25
By: gward

Comment:
This is a documentation bug, but I plead partly guilty (since I changed the interface of the distutils.sysconfig module without thinking to see if it had been documented anywhere, implicitly or not).  Oops.

This patch fixes the doc bug:

--- ext.tex     2000/10/26 17:19:58     1.87
+++ ext.tex     2000/10/31 02:22:58
@@ -2138,7 +2138,7 @@
 
 \begin{verbatim}
 >>> import distutils.sysconfig
->>> distutils.sysconfig.LINKFORSHARED 
+>>> distutils.sysconfig.get_config_var("LINKFORSHARED")
 '-Xlinker -export-dynamic'
 \end{verbatim}
 \refstmodindex{distutils.sysconfig}

Fred, I can check this in if you want...
-------------------------------------------------------

Date: 2000-Nov-02 13:52
By: fdrake

Comment:
Fixed in Doc/ext/ext.tex revision 1.88.
-------------------------------------------------------

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


From noreply@sourceforge.net  Thu Nov  2 21:50:49 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 2 Nov 2000 13:50:49 -0800
Subject: [Python-bugs-list] [Bug #119729] copy/past error in Extending&Embedding
Message-ID: <200011022150.NAA08302@sf-web1.i.sourceforge.net>

Bug #119729, was updated on 2000-Oct-29 23:04
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: copy/past error in Extending&Embedding

Details: On page 9 of "extending and embedding" release 2.0,
I found a copy/past error for item 'es':

\item[\samp{es} (string, Unicode object or character buffer
compatible object) {[const char *encoding, char **buffer]}]
=> 2 parameters

But :
The variant [...] and the third one a pointer to an integer
(\var{*buffer_length}, the buffer length).



Follow-Ups:

Date: 2000-Nov-02 13:50
By: fdrake

Comment:
Fixed in Doc/ext/ext.tex revision 1.88.
-------------------------------------------------------

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


From noreply@sourceforge.net  Thu Nov  2 22:57:32 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 2 Nov 2000 14:57:32 -0800
Subject: [Python-bugs-list] [Bug #117524] The unicodedata db does not know about the special ranges.
Message-ID: <200011022257.OAA09192@sf-web1.i.sourceforge.net>

Bug #117524, was updated on 2000-Oct-23 13:06
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 6
Summary: The unicodedata db does not know about the special ranges.

Details: There seems to a bug in the unicodedata. The special ranges described under "Field Formats" are not handled correctly.

   ftp://ftp.unicode.org/Public/3.0-Update/UnicodeData-3.0.0.html

The two characters should have identical properties:

Python 2.0 (#8, Oct 16 2000, 17:27:58) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> import unicodedata
>>> unicodedata.category(u"\u3400")
'Lo'
>>> unicodedata.category(u"\u3401")
'Cn'
>>> u"\u3400".isalpha()
1
>>> u"\u3401".isalpha()
0
>>>

Follow-Ups:

Date: 2000-Oct-26 09:02
By: lemburg

Comment:
Looks like we'll have to add a few special if()s to the various APIs.

I hadn't realized that the Unicode database defines properties for
char points which do not appear in the listed UnicodeData.txt file...
one little sentence in the webpage you mention makes the difference - sigh.

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

Date: 2000-Nov-02 14:57
By: none

Comment:
Forget about the if statements -- the compression
method used for the unicode tables doesn't really
care if you have lots of undefined character entries,
or lots of character entries all having the same data.

Or to put it another way, I just added 38642 new chars
to the database, and it's still exactly the same size
as in 2.0.

Patch coming later.

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

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


From noreply@sourceforge.net  Fri Nov  3 01:28:31 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 2 Nov 2000 17:28:31 -0800
Subject: [Python-bugs-list] [Bug #119851] inline C++ keyword in config.h
Message-ID: <200011030128.RAA07107@sf-web2.i.sourceforge.net>

Bug #119851, was updated on 2000-Oct-31 01:47
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: inline C++ keyword in config.h

Details: Hi,

I have built Python 2.0 on Solaris 7 using the Sun C compiler.

Now I see the following piece of code in config.h:

/* Define as __inline if that's what the C compiler calls it.  */
#define inline

This is a problem when writing Python modules in C++
and should probably be removed. What was the intent
in the first place?

Thanks,
Dimitri


Follow-Ups:

Date: 2000-Nov-02 17:28
By: fdrake

Comment:
This does appear to be unnecessary.  Removing AC_C_INLINE from configure.in seems to be sufficient and doesn't seem to break anything.  If no one can explain why it should remain, I'll check in the changes this weekend.
-------------------------------------------------------

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


From noreply@sourceforge.net  Fri Nov  3 02:34:27 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 2 Nov 2000 18:34:27 -0800
Subject: [Python-bugs-list] [Bug #121121] Dynamic loading on Solaris does not work
Message-ID: <200011030234.SAA14865@sf-web3.vaspecialprojects.com>

Bug #121121, was updated on 2000-Nov-02 08:33
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Dynamic loading on Solaris does not work

Details: Dynamic loading of shared libraries (Python/dynload_shlib) does not work under Solaris. This is due to a bug in the autoconf script. The patch at ftp://ftp.thewrittenword.com/outgoing/pub/python-2.0-solaris-dynload.patch fixes it.

The problem is that AC_CHECK_LIB(dl, dlopen) will never define HAVE_DLOPEN (AC_CHECK_FUNCS(dlopen) does that) which in turn will never define $ac_cv_func_dlopen. Anyway, using internal autoconf macros is icky. Redo the autoconf test because it will cache the results.

-- 
albert chin (china@thewrittenword.com)

Follow-Ups:

Date: 2000-Nov-02 10:08
By: gvanrossum

Comment:
Thanks for the patch; but would you be so kind to submit the patch to the SourceForge patch manager?
See http://sourceforge.net/patch/?group_id=5470
-------------------------------------------------------

Date: 2000-Nov-02 10:14
By: tww-account

Comment:
Ok, patch uploaded to the SourceForge patch manager.
-------------------------------------------------------

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


From noreply@sourceforge.net  Fri Nov  3 04:16:01 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 2 Nov 2000 20:16:01 -0800
Subject: [Python-bugs-list] [Bug #119709] A make error
Message-ID: <200011030416.UAA12768@sf-web1.i.sourceforge.net>

Bug #119709, was updated on 2000-Oct-29 16:20
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: A make error

Details: I use:

Slackware96
Linux 2.0.0
gcc 2.7.2
glibc2
PC/i486

And I try to install Python-2.0.tar.gz package.
I use default Modules/Setup.

When run:

#./configure
#make

gcc tells me in Modules/selectmodule.c, begins from the 345 line,

POLLIN undeclared,...

Every POLL* name follows are all undeclared.

Which header file lost? poll.h? Or something wrong?

Thanks.


Follow-Ups:

Date: 2000-Nov-02 20:16
By: fdrake

Comment:
I think this has been fixed post-2.0, but I'm not sure.  Assigned to Andrew since he'll know and, if it's not fixed, will be the one to do so.   ;-)
-------------------------------------------------------

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


From noreply@sourceforge.net  Fri Nov  3 08:11:28 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 3 Nov 2000 00:11:28 -0800
Subject: [Python-bugs-list] [Bug #110631] Debugger (win and idle) (PR#283)
Message-ID: <200011030811.AAA18393@sf-web3.vaspecialprojects.com>

Bug #110631, was updated on 2000-Jul-31 14:09
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 3
Summary: Debugger (win and idle) (PR#283)

Details: Jitterbug-Id: 283
Submitted-By: musingattheruins@yahoo.com
Date: Mon, 10 Apr 2000 12:30:44 -0400 (EDT)
Version: 1.5.2
OS: Win32


The python debugger (both Idle and PythonWin) does not undertand packages.  Can
run scripts from the command line that cannot be run in the debugger...

Create package 'Test' in the directory "My Modules", add an __init__.py (empty)
to the directory "My modules\Test", create file testfile.py with the
contents...

class TheTest:
   def __init__(self):
      self.i = 1

   def go(self):
      return self.i

Add the path to the Python path with the following file (test.reg)...

REGEDIT4

[HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\1.5\PythonPath\TheTest]
@="C:\\My modules"

then try the following at the python prompt:

import Test.testfile
j = Test.testfile.TheTest() 
k = j.go

runs fine right? Yes it does, now step through it in the debugger and you
get...

import Test.testfile
j = Test.testfile.TheTest() #exception: attribute 'TheTest'
k = j.go

Does not appear to be realted to the class (you can change it to a 'function in
a module' instead of a 'method in a class in a module' and you get the a similar
result.)

Debugger does not understand packages.



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

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


From noreply@sourceforge.net  Fri Nov  3 12:51:46 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 3 Nov 2000 04:51:46 -0800
Subject: [Python-bugs-list] [Bug #121207] % operator on strings not documented
Message-ID: <200011031251.EAA21780@sf-web3.vaspecialprojects.com>

Bug #121207, was updated on 2000-Nov-03 04:51
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: % operator on strings not documented

Details: Python string substitution with % is not documented --
the closest the doc gets is at
<http://www.python.org/doc/current/lib/typesseq-strings.html>
which says the string is "interpreted as a C sprintf()
format string", but doesn't say what that means or how
the substitution is done.

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


From noreply@sourceforge.net  Fri Nov  3 13:01:11 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 3 Nov 2000 05:01:11 -0800
Subject: [Python-bugs-list] [Bug #121115] Kill threads from main thread
Message-ID: <200011031301.FAA21890@sf-web3.vaspecialprojects.com>

Bug #121115, was updated on 2000-Nov-02 07:51
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: Kill threads from main thread

Details: It still isn't possible to kill a thread from another thread. This is an important feature for long running processes as multithreaded application servers. It should be possible for the main thread (or another thread) to kill a non responding thread after a timeout.

As I read in a discussion forum "pthreads" support somewhat like thread_cancel() for Windows I don't know.

If this feature became implemented it would be nice if an ThreadObject from the module "threading" could be killed by deleting the object.

Follow-Ups:

Date: 2000-Nov-02 09:31
By: gvanrossum

Comment:
This is a very controversial feature. If a thread owns a resource (e.g. it holds a lock), what happens to the resource when the thread is killed?

The best idea I can come up with is to make it possible to send asynchronous exceptions to threads -- but this doesn't help for threads that are blocked in an I/O operation. That might be solved through sending signals, but that's a Unix-only solution, and probably isn't even consistent across different Unix thread implementations.
-------------------------------------------------------

Date: 2000-Nov-02 10:49
By: holtwick

Comment:
Blocking I/O operations are a problem, but what about other internal problems like endless loops? An asynchronous exception would be a good way for most problems (I have with threads ;) And as far as the documentation says, signals always go to the main thread. If that is so, it doesn't help much. 

So what about connecting signals to threads. I don't know if this is possible, but a reliable way to use signals with threads would be a way to give threads a timeout.
-------------------------------------------------------

Date: 2000-Nov-02 12:04
By: gvanrossum

Comment:
As I said, signals are a Unix-only solution.

And blocked I/O is a common reason to *want* to kill a thread -- e.g. the common problem of webservers that simply never reply.
-------------------------------------------------------

Date: 2000-Nov-03 05:01
By: holtwick

Comment:
I think then it would be the best to send the asynchronous exceptions even if they don't work for blocking I/O operations. The need of killing threads from outside is obvious I think. And there will be for sure some scenarios where the killing doesn't work properly, but to avoid these situations should be a task for the programmer of the code. There are always situations where the design of a programming language will not save the programmer of writing stupid code, e.g. while 1: pass

If there is no way of implementing the killing how should one write an multithreaded long running programm that keeps itself clean for several days or months or years. The advantage of threads are the shared informations and forking is often more difficult to use.

How does Java solve these problems?
-------------------------------------------------------

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


From noreply@sourceforge.net  Fri Nov  3 13:04:14 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 3 Nov 2000 05:04:14 -0800
Subject: [Python-bugs-list] [Bug #121208] Advanced email module
Message-ID: <200011031304.FAA22131@sf-web2.i.sourceforge.net>

Bug #121208, was updated on 2000-Nov-03 05:04
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: Advanced email module

Details: A nice new module to have would be a mime enabled email composer. I posted a sample to SourceForge that is still very basic:

http://sourceforge.net/snippet/detail.php?type=snippet&id=100444

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


From noreply@sourceforge.net  Fri Nov  3 13:15:07 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 3 Nov 2000 05:15:07 -0800
Subject: [Python-bugs-list] [Bug #121207] % operator on strings not documented
Message-ID: <200011031315.FAA22062@sf-web3.vaspecialprojects.com>

Bug #121207, was updated on 2000-Nov-03 04:51
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: % operator on strings not documented

Details: Python string substitution with % is not documented --
the closest the doc gets is at
<http://www.python.org/doc/current/lib/typesseq-strings.html>
which says the string is "interpreted as a C sprintf()
format string", but doesn't say what that means or how
the substitution is done.

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


From noreply@sourceforge.net  Fri Nov  3 13:18:23 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 3 Nov 2000 05:18:23 -0800
Subject: [Python-bugs-list] [Bug #121115] Kill threads from main thread
Message-ID: <200011031318.FAA22366@sf-web2.i.sourceforge.net>

Bug #121115, was updated on 2000-Nov-02 07:51
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: Kill threads from main thread

Details: It still isn't possible to kill a thread from another thread. This is an important feature for long running processes as multithreaded application servers. It should be possible for the main thread (or another thread) to kill a non responding thread after a timeout.

As I read in a discussion forum "pthreads" support somewhat like thread_cancel() for Windows I don't know.

If this feature became implemented it would be nice if an ThreadObject from the module "threading" could be killed by deleting the object.

Follow-Ups:

Date: 2000-Nov-02 09:31
By: gvanrossum

Comment:
This is a very controversial feature. If a thread owns a resource (e.g. it holds a lock), what happens to the resource when the thread is killed?

The best idea I can come up with is to make it possible to send asynchronous exceptions to threads -- but this doesn't help for threads that are blocked in an I/O operation. That might be solved through sending signals, but that's a Unix-only solution, and probably isn't even consistent across different Unix thread implementations.
-------------------------------------------------------

Date: 2000-Nov-02 10:49
By: holtwick

Comment:
Blocking I/O operations are a problem, but what about other internal problems like endless loops? An asynchronous exception would be a good way for most problems (I have with threads ;) And as far as the documentation says, signals always go to the main thread. If that is so, it doesn't help much. 

So what about connecting signals to threads. I don't know if this is possible, but a reliable way to use signals with threads would be a way to give threads a timeout.
-------------------------------------------------------

Date: 2000-Nov-02 12:04
By: gvanrossum

Comment:
As I said, signals are a Unix-only solution.

And blocked I/O is a common reason to *want* to kill a thread -- e.g. the common problem of webservers that simply never reply.
-------------------------------------------------------

Date: 2000-Nov-03 05:01
By: holtwick

Comment:
I think then it would be the best to send the asynchronous exceptions even if they don't work for blocking I/O operations. The need of killing threads from outside is obvious I think. And there will be for sure some scenarios where the killing doesn't work properly, but to avoid these situations should be a task for the programmer of the code. There are always situations where the design of a programming language will not save the programmer of writing stupid code, e.g. while 1: pass

If there is no way of implementing the killing how should one write an multithreaded long running programm that keeps itself clean for several days or months or years. The advantage of threads are the shared informations and forking is often more difficult to use.

How does Java solve these problems?
-------------------------------------------------------

Date: 2000-Nov-03 05:18
By: gvanrossum

Comment:
The common solution for things like this is to have a simple app-specific protocol involving. The thread watches a specific variable that means "please exit"; when there's a need to kill the thread this variable is set. The thread just has to be careful to check this variable in each unbounded loop. This requires a bit of discipline; but (as you say) there are too many things a programmer can do to break the program to try and prevent them all.
-------------------------------------------------------

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


From noreply@sourceforge.net  Fri Nov  3 14:30:05 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 3 Nov 2000 06:30:05 -0800
Subject: [Python-bugs-list] [Bug #117606] *.so creation in solaris+GCC
Message-ID: <200011031430.GAA19736@sf-web1.i.sourceforge.net>

Bug #117606, was updated on 2000-Oct-24 08:15
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Summary: *.so creation in solaris+GCC

Details: Python 2.0 (dinamic modules)
Mod_Python 2.6.2 (dinamic module)
GCC 2.95.2
Apache 1.3.14 (dinamic modules)
SunOS5 (Solaris 2.x)

I send the email also to "mod_python" mailing list since I detect the problem using this package. Other developers could see the very same problem!.


Mod_python runs smoothly until I do a "import zlib", for example, in a handler. In this case, the request is aborted with the following log:

>>>>>
[Tue Oct 24 16:27:40 2000] [error] PythonHandler cache: Traceback (most recent call last):
[Tue Oct 24 16:27:40 2000] [error] PythonHandler cache:   File "/usr/local/lib/python2.0/site-packages/mod_python/apache.py", line 185, in Dispatch
    result = object(self.req)
[Tue Oct 24 16:27:40 2000] [error] PythonHandler cache:   File "/export/home/webmaster/www.argo.es/servicios/cache.py", line 47, in handler
    exec(cache[f][1])
[Tue Oct 24 16:27:40 2000] [error] PythonHandler cache:   File "/export/home/webmaster/www.argo.es/servicios/borra_email", line 183, in ?
    req2=wrap(req)
[Tue Oct 24 16:27:40 2000] [error] PythonHandler cache:   File "/export/home/webmaster/www.argo.es/servicios/borra_email", line 159, in __init__
    import zlib
[Tue Oct 24 16:27:40 2000] [error] PythonHandler cache: ImportError: ld.so.1: /opt/local/apache/bin/httpd: fatal: relocation error: file /usr/local/lib/python2.0/lib-dynload/zlibmodule.so: symbol main: referenced symbol not found
<<<<<

That is, "zlibmodule.so" tries to link to a function called "main".

Doing a "nm object|grep main", I see the unresolved reference in "zlibmodule.so", but not in "zlibmodule.o". So, the problem seems to be the creation of the shared library.

I tracked down the problem to the "configure" script: "cc -G" is (I think) the right thing to do to create a shared library if you are using the Sun compiler, but if you are using GCC (like me), the right command is "gcc -shared".

Patch for Python 2.0:

>>>>>
Index: configure
===================================================================
RCS file: /opt/src/cvsroot/python/configure,v
retrieving revision 1.1.1.2
retrieving revision 1.1.1.2.2.1
diff -c -r1.1.1.2 -r1.1.1.2.2.1
*** configure   2000/10/18 19:06:44     1.1.1.2
--- configure   2000/10/24 14:19:01     1.1.1.2.2.1
***************
*** 2650,2656 ****
        SunOS/4*) LDSHARED="ld";;
        SunOS/5*) 
                if test "$GCC" = "yes"
!               then LDSHARED='$(CC) -G'
                else LDSHARED="ld -G";
                fi ;;
        hp*|HP*) LDSHARED="ld -b";;
--- 2650,2656 ----
        SunOS/4*) LDSHARED="ld";;
        SunOS/5*) 
                if test "$GCC" = "yes"
!               then LDSHARED='$(CC) -shared'
                else LDSHARED="ld -G";
                fi ;;
        hp*|HP*) LDSHARED="ld -b";;
Index: configure.in
===================================================================
RCS file: /opt/src/cvsroot/python/configure.in,v
retrieving revision 1.1.1.2
retrieving revision 1.1.1.2.2.1
diff -c -r1.1.1.2 -r1.1.1.2.2.1
*** configure.in        2000/10/18 19:06:45     1.1.1.2
--- configure.in        2000/10/24 14:19:03     1.1.1.2.2.1
***************
*** 564,570 ****
        SunOS/4*) LDSHARED="ld";;
        SunOS/5*) 
                if test "$GCC" = "yes"
!               then LDSHARED='$(CC) -G'
                else LDSHARED="ld -G";
                fi ;;
        hp*|HP*) LDSHARED="ld -b";;
--- 564,570 ----
        SunOS/4*) LDSHARED="ld";;
        SunOS/5*) 
                if test "$GCC" = "yes"
!               then LDSHARED='$(CC) -shared'
                else LDSHARED="ld -G";
                fi ;;
        hp*|HP*) LDSHARED="ld -b";;
<<<<<


Follow-Ups:

Date: 2000-Nov-03 06:30
By: gward

Comment:
I don't think "gcc -shared" is the right answer; at least on Solaris 2.6, with GCC 2.95.2 and Python2.0+ (CVS as of 2000/11/03), compiling extensions dies horribly.  The very first extension, arraymodule.c, compiles fine to arraymodule.o.  But then linking to arraymodule.so fails with hundreds of symbol relocation errors.  About half are "Py" or "_Py" symbols, there are many "<unknown>" (?) symbols, and a handful of errors for 'malloc', 'sprintf', and the like.

I have no idea what's going on here, but "gcc -shared" definitely makes things *worse* for a vanilla (non-embedded) build of Python 2.0+ on Solaris 2.6 with GCC 2.95.2.

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

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


From noreply@sourceforge.net  Fri Nov  3 14:32:48 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 3 Nov 2000 06:32:48 -0800
Subject: [Python-bugs-list] [Bug #117606] *.so creation in solaris+GCC
Message-ID: <200011031432.GAA19773@sf-web1.i.sourceforge.net>

Bug #117606, was updated on 2000-Oct-24 08:15
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Summary: *.so creation in solaris+GCC

Details: Python 2.0 (dinamic modules)
Mod_Python 2.6.2 (dinamic module)
GCC 2.95.2
Apache 1.3.14 (dinamic modules)
SunOS5 (Solaris 2.x)

I send the email also to "mod_python" mailing list since I detect the problem using this package. Other developers could see the very same problem!.


Mod_python runs smoothly until I do a "import zlib", for example, in a handler. In this case, the request is aborted with the following log:

>>>>>
[Tue Oct 24 16:27:40 2000] [error] PythonHandler cache: Traceback (most recent call last):
[Tue Oct 24 16:27:40 2000] [error] PythonHandler cache:   File "/usr/local/lib/python2.0/site-packages/mod_python/apache.py", line 185, in Dispatch
    result = object(self.req)
[Tue Oct 24 16:27:40 2000] [error] PythonHandler cache:   File "/export/home/webmaster/www.argo.es/servicios/cache.py", line 47, in handler
    exec(cache[f][1])
[Tue Oct 24 16:27:40 2000] [error] PythonHandler cache:   File "/export/home/webmaster/www.argo.es/servicios/borra_email", line 183, in ?
    req2=wrap(req)
[Tue Oct 24 16:27:40 2000] [error] PythonHandler cache:   File "/export/home/webmaster/www.argo.es/servicios/borra_email", line 159, in __init__
    import zlib
[Tue Oct 24 16:27:40 2000] [error] PythonHandler cache: ImportError: ld.so.1: /opt/local/apache/bin/httpd: fatal: relocation error: file /usr/local/lib/python2.0/lib-dynload/zlibmodule.so: symbol main: referenced symbol not found
<<<<<

That is, "zlibmodule.so" tries to link to a function called "main".

Doing a "nm object|grep main", I see the unresolved reference in "zlibmodule.so", but not in "zlibmodule.o". So, the problem seems to be the creation of the shared library.

I tracked down the problem to the "configure" script: "cc -G" is (I think) the right thing to do to create a shared library if you are using the Sun compiler, but if you are using GCC (like me), the right command is "gcc -shared".

Patch for Python 2.0:

>>>>>
Index: configure
===================================================================
RCS file: /opt/src/cvsroot/python/configure,v
retrieving revision 1.1.1.2
retrieving revision 1.1.1.2.2.1
diff -c -r1.1.1.2 -r1.1.1.2.2.1
*** configure   2000/10/18 19:06:44     1.1.1.2
--- configure   2000/10/24 14:19:01     1.1.1.2.2.1
***************
*** 2650,2656 ****
        SunOS/4*) LDSHARED="ld";;
        SunOS/5*) 
                if test "$GCC" = "yes"
!               then LDSHARED='$(CC) -G'
                else LDSHARED="ld -G";
                fi ;;
        hp*|HP*) LDSHARED="ld -b";;
--- 2650,2656 ----
        SunOS/4*) LDSHARED="ld";;
        SunOS/5*) 
                if test "$GCC" = "yes"
!               then LDSHARED='$(CC) -shared'
                else LDSHARED="ld -G";
                fi ;;
        hp*|HP*) LDSHARED="ld -b";;
Index: configure.in
===================================================================
RCS file: /opt/src/cvsroot/python/configure.in,v
retrieving revision 1.1.1.2
retrieving revision 1.1.1.2.2.1
diff -c -r1.1.1.2 -r1.1.1.2.2.1
*** configure.in        2000/10/18 19:06:45     1.1.1.2
--- configure.in        2000/10/24 14:19:03     1.1.1.2.2.1
***************
*** 564,570 ****
        SunOS/4*) LDSHARED="ld";;
        SunOS/5*) 
                if test "$GCC" = "yes"
!               then LDSHARED='$(CC) -G'
                else LDSHARED="ld -G";
                fi ;;
        hp*|HP*) LDSHARED="ld -b";;
--- 564,570 ----
        SunOS/4*) LDSHARED="ld";;
        SunOS/5*) 
                if test "$GCC" = "yes"
!               then LDSHARED='$(CC) -shared'
                else LDSHARED="ld -G";
                fi ;;
        hp*|HP*) LDSHARED="ld -b";;
<<<<<


Follow-Ups:

Date: 2000-Nov-03 06:30
By: gward

Comment:
I don't think "gcc -shared" is the right answer; at least on Solaris 2.6, with GCC 2.95.2 and Python2.0+ (CVS as of 2000/11/03), compiling extensions dies horribly.  The very first extension, arraymodule.c, compiles fine to arraymodule.o.  But then linking to arraymodule.so fails with hundreds of symbol relocation errors.  About half are "Py" or "_Py" symbols, there are many "<unknown>" (?) symbols, and a handful of errors for 'malloc', 'sprintf', and the like.

I have no idea what's going on here, but "gcc -shared" definitely makes things *worse* for a vanilla (non-embedded) build of Python 2.0+ on Solaris 2.6 with GCC 2.95.2.

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

Date: 2000-Nov-03 06:32
By: gward

Comment:
Oops, forgot to mention: the original bug report didn't specify which version of Solaris.  Could be 2.6, 2.7, 2.8, maybe even 2.5, ... 

I have access to 2.6 and 2.7 machines for testing, if it helps.  Have only tried it on 2.6 so far, and that's where it died horribly.

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

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


From noreply@sourceforge.net  Fri Nov  3 20:24:12 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 3 Nov 2000 12:24:12 -0800
Subject: [Python-bugs-list] [Bug #117524] The unicodedata db does not know about the special ranges.
Message-ID: <200011032024.MAA00784@sf-web2.i.sourceforge.net>

Bug #117524, was updated on 2000-Oct-23 13:06
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 6
Summary: The unicodedata db does not know about the special ranges.

Details: There seems to a bug in the unicodedata. The special ranges described under "Field Formats" are not handled correctly.

   ftp://ftp.unicode.org/Public/3.0-Update/UnicodeData-3.0.0.html

The two characters should have identical properties:

Python 2.0 (#8, Oct 16 2000, 17:27:58) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> import unicodedata
>>> unicodedata.category(u"\u3400")
'Lo'
>>> unicodedata.category(u"\u3401")
'Cn'
>>> u"\u3400".isalpha()
1
>>> u"\u3401".isalpha()
0
>>>

Follow-Ups:

Date: 2000-Oct-26 09:02
By: lemburg

Comment:
Looks like we'll have to add a few special if()s to the various APIs.

I hadn't realized that the Unicode database defines properties for
char points which do not appear in the listed UnicodeData.txt file...
one little sentence in the webpage you mention makes the difference - sigh.

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

Date: 2000-Nov-02 14:57
By: none

Comment:
Forget about the if statements -- the compression
method used for the unicode tables doesn't really
care if you have lots of undefined character entries,
or lots of character entries all having the same data.

Or to put it another way, I just added 38642 new chars
to the database, and it's still exactly the same size
as in 2.0.

Patch coming later.

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

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


From noreply@sourceforge.net  Fri Nov  3 20:31:21 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 3 Nov 2000 12:31:21 -0800
Subject: [Python-bugs-list] [Bug #121327] threads within an embedded python interpreter
Message-ID: <200011032031.MAA00986@sf-web2.i.sourceforge.net>

Bug #121327, was updated on 2000-Nov-03 12:31
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: threads within an embedded python interpreter

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





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


From noreply@sourceforge.net  Fri Nov  3 20:44:28 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 3 Nov 2000 12:44:28 -0800
Subject: [Python-bugs-list] [Bug #121327] threads within an embedded python interpreter
Message-ID: <200011032044.MAA26193@sf-web1.i.sourceforge.net>

Bug #121327, was updated on 2000-Nov-03 12:31
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 3
Summary: threads within an embedded python interpreter

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





Follow-Ups:

Date: 2000-Nov-03 12:44
By: gvanrossum

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

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


From noreply@sourceforge.net  Fri Nov  3 20:49:18 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 3 Nov 2000 12:49:18 -0800
Subject: [Python-bugs-list] [Bug #121208] Advanced email module
Message-ID: <200011032049.MAA01457@sf-web2.i.sourceforge.net>

Bug #121208, was updated on 2000-Nov-03 05:04
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 1
Summary: Advanced email module

Details: A nice new module to have would be a mime enabled email composer. I posted a sample to SourceForge that is still very basic:

http://sourceforge.net/snippet/detail.php?type=snippet&id=100444

Follow-Ups:

Date: 2000-Nov-03 12:49
By: gvanrossum

Comment:
Hey, I didn't know about the SD "Snippet" feature! Cool!

But I'm not sure that this should be a standard library -- it's pretty application specific. Any other opinions?
-------------------------------------------------------

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


From noreply@sourceforge.net  Fri Nov  3 22:48:09 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 3 Nov 2000 14:48:09 -0800
Subject: [Python-bugs-list] [Bug #117606] *.so creation in solaris+GCC
Message-ID: <200011032248.OAA28599@sf-web1.i.sourceforge.net>

Bug #117606, was updated on 2000-Oct-24 08:15
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Summary: *.so creation in solaris+GCC

Details: Python 2.0 (dinamic modules)
Mod_Python 2.6.2 (dinamic module)
GCC 2.95.2
Apache 1.3.14 (dinamic modules)
SunOS5 (Solaris 2.x)

I send the email also to "mod_python" mailing list since I detect the problem using this package. Other developers could see the very same problem!.


Mod_python runs smoothly until I do a "import zlib", for example, in a handler. In this case, the request is aborted with the following log:

>>>>>
[Tue Oct 24 16:27:40 2000] [error] PythonHandler cache: Traceback (most recent call last):
[Tue Oct 24 16:27:40 2000] [error] PythonHandler cache:   File "/usr/local/lib/python2.0/site-packages/mod_python/apache.py", line 185, in Dispatch
    result = object(self.req)
[Tue Oct 24 16:27:40 2000] [error] PythonHandler cache:   File "/export/home/webmaster/www.argo.es/servicios/cache.py", line 47, in handler
    exec(cache[f][1])
[Tue Oct 24 16:27:40 2000] [error] PythonHandler cache:   File "/export/home/webmaster/www.argo.es/servicios/borra_email", line 183, in ?
    req2=wrap(req)
[Tue Oct 24 16:27:40 2000] [error] PythonHandler cache:   File "/export/home/webmaster/www.argo.es/servicios/borra_email", line 159, in __init__
    import zlib
[Tue Oct 24 16:27:40 2000] [error] PythonHandler cache: ImportError: ld.so.1: /opt/local/apache/bin/httpd: fatal: relocation error: file /usr/local/lib/python2.0/lib-dynload/zlibmodule.so: symbol main: referenced symbol not found
<<<<<

That is, "zlibmodule.so" tries to link to a function called "main".

Doing a "nm object|grep main", I see the unresolved reference in "zlibmodule.so", but not in "zlibmodule.o". So, the problem seems to be the creation of the shared library.

I tracked down the problem to the "configure" script: "cc -G" is (I think) the right thing to do to create a shared library if you are using the Sun compiler, but if you are using GCC (like me), the right command is "gcc -shared".

Patch for Python 2.0:

>>>>>
Index: configure
===================================================================
RCS file: /opt/src/cvsroot/python/configure,v
retrieving revision 1.1.1.2
retrieving revision 1.1.1.2.2.1
diff -c -r1.1.1.2 -r1.1.1.2.2.1
*** configure   2000/10/18 19:06:44     1.1.1.2
--- configure   2000/10/24 14:19:01     1.1.1.2.2.1
***************
*** 2650,2656 ****
        SunOS/4*) LDSHARED="ld";;
        SunOS/5*) 
                if test "$GCC" = "yes"
!               then LDSHARED='$(CC) -G'
                else LDSHARED="ld -G";
                fi ;;
        hp*|HP*) LDSHARED="ld -b";;
--- 2650,2656 ----
        SunOS/4*) LDSHARED="ld";;
        SunOS/5*) 
                if test "$GCC" = "yes"
!               then LDSHARED='$(CC) -shared'
                else LDSHARED="ld -G";
                fi ;;
        hp*|HP*) LDSHARED="ld -b";;
Index: configure.in
===================================================================
RCS file: /opt/src/cvsroot/python/configure.in,v
retrieving revision 1.1.1.2
retrieving revision 1.1.1.2.2.1
diff -c -r1.1.1.2 -r1.1.1.2.2.1
*** configure.in        2000/10/18 19:06:45     1.1.1.2
--- configure.in        2000/10/24 14:19:03     1.1.1.2.2.1
***************
*** 564,570 ****
        SunOS/4*) LDSHARED="ld";;
        SunOS/5*) 
                if test "$GCC" = "yes"
!               then LDSHARED='$(CC) -G'
                else LDSHARED="ld -G";
                fi ;;
        hp*|HP*) LDSHARED="ld -b";;
--- 564,570 ----
        SunOS/4*) LDSHARED="ld";;
        SunOS/5*) 
                if test "$GCC" = "yes"
!               then LDSHARED='$(CC) -shared'
                else LDSHARED="ld -G";
                fi ;;
        hp*|HP*) LDSHARED="ld -b";;
<<<<<


Follow-Ups:

Date: 2000-Nov-03 06:30
By: gward

Comment:
I don't think "gcc -shared" is the right answer; at least on Solaris 2.6, with GCC 2.95.2 and Python2.0+ (CVS as of 2000/11/03), compiling extensions dies horribly.  The very first extension, arraymodule.c, compiles fine to arraymodule.o.  But then linking to arraymodule.so fails with hundreds of symbol relocation errors.  About half are "Py" or "_Py" symbols, there are many "<unknown>" (?) symbols, and a handful of errors for 'malloc', 'sprintf', and the like.

I have no idea what's going on here, but "gcc -shared" definitely makes things *worse* for a vanilla (non-embedded) build of Python 2.0+ on Solaris 2.6 with GCC 2.95.2.

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

Date: 2000-Nov-03 06:32
By: gward

Comment:
Oops, forgot to mention: the original bug report didn't specify which version of Solaris.  Could be 2.6, 2.7, 2.8, maybe even 2.5, ... 

I have access to 2.6 and 2.7 machines for testing, if it helps.  Have only tried it on 2.6 so far, and that's where it died horribly.

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

Date: 2000-Nov-03 14:48
By: gward

Comment:
Martin von Loewis suggested compiling with -fPIC; I did so and everything worked out fine.  I have a revised patch for configure.in, which adds -fPIC to OPT for GCC on *all* platforms, and sets LDSHARED to "$(CC) -shared" for GCC on Solaris.  It works for me -- I can check it in any time.
-------------------------------------------------------

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


From noreply@sourceforge.net  Fri Nov  3 22:53:04 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 3 Nov 2000 14:53:04 -0800
Subject: [Python-bugs-list] [Bug #121479] Compiler warnings on Solaris
Message-ID: <200011032253.OAA28686@sf-web1.i.sourceforge.net>

Bug #121479, was updated on 2000-Nov-03 14:53
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Compiler warnings on Solaris

Details: GCC 2.95.2 on Solaris 2.6 reports a bunch of warnings building the latest CVS source.  Here's the complete list:

intrcheck.c:151: warning: function declaration isn't a prototype
intrcheck.c: In function `PyOS_InitInterrupts':
intrcheck.c:156: warning: function declaration isn't a prototype
intrcheck.c:156: warning: function declaration isn't a prototype
floatobject.c:35: warning: function declaration isn't a prototype
intobject.c: In function `PyInt_FromString':
intobject.c:185: warning: subscript has type `char'
bltinmodule.c: In function `builtin_ord':
bltinmodule.c:1507: warning: `ord' might be used uninitialized in this function
errors.c: In function `PyErr_Format':
errors.c:405: warning: subscript has type `char'
errors.c:460: warning: subscript has type `char'
errors.c:465: warning: subscript has type `char'
errors.c:468: warning: subscript has type `char'
pythonrun.c: In function `initsigs':
pythonrun.c:1134: warning: function declaration isn't a prototype
./posixmodule.c: In function `posix_confstr':
./posixmodule.c:4471: warning: implicit declaration of function `confstr'
./signalmodule.c:88: warning: function declaration isn't a prototype
./signalmodule.c: In function `signal_signal':
./signalmodule.c:212: warning: function declaration isn't a prototype
./signalmodule.c:214: warning: function declaration isn't a prototype
./signalmodule.c:225: warning: function declaration isn't a prototype
./signalmodule.c: In function `initsignal':
./signalmodule.c:332: warning: function declaration isn't a prototype
./signalmodule.c:336: warning: function declaration isn't a prototype
./signalmodule.c:355: warning: function declaration isn't a prototype
./signalmodule.c:357: warning: function declaration isn't a prototype
./signalmodule.c: In function `finisignal':
./signalmodule.c:556: warning: function declaration isn't a prototype
./signalmodule.c:564: warning: function declaration isn't a prototype
make[1]: [add2lib] Error 2 (ignored)
./stropmodule.c: In function `strop_atoi':
./stropmodule.c:752: warning: subscript has type `char'
./timemodule.c: In function `time_strptime':
./timemodule.c:385: warning: subscript has type `char'
./socketmodule.c: In function `PySocket_socket':
./socketmodule.c:1768: warning: function declaration isn't a prototype
./socketmodule.c: In function `PySocket_fromfd':
./socketmodule.c:1806: warning: function declaration isn't a prototype

I'll look into these one at a time and see how many I can fix.

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


From noreply@sourceforge.net  Fri Nov  3 22:53:25 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 3 Nov 2000 14:53:25 -0800
Subject: [Python-bugs-list] [Bug #121479] Compiler warnings on Solaris
Message-ID: <200011032253.OAA28689@sf-web1.i.sourceforge.net>

Bug #121479, was updated on 2000-Nov-03 14:53
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Compiler warnings on Solaris

Details: GCC 2.95.2 on Solaris 2.6 reports a bunch of warnings building the latest CVS source.  Here's the complete list:

intrcheck.c:151: warning: function declaration isn't a prototype
intrcheck.c: In function `PyOS_InitInterrupts':
intrcheck.c:156: warning: function declaration isn't a prototype
intrcheck.c:156: warning: function declaration isn't a prototype
floatobject.c:35: warning: function declaration isn't a prototype
intobject.c: In function `PyInt_FromString':
intobject.c:185: warning: subscript has type `char'
bltinmodule.c: In function `builtin_ord':
bltinmodule.c:1507: warning: `ord' might be used uninitialized in this function
errors.c: In function `PyErr_Format':
errors.c:405: warning: subscript has type `char'
errors.c:460: warning: subscript has type `char'
errors.c:465: warning: subscript has type `char'
errors.c:468: warning: subscript has type `char'
pythonrun.c: In function `initsigs':
pythonrun.c:1134: warning: function declaration isn't a prototype
./posixmodule.c: In function `posix_confstr':
./posixmodule.c:4471: warning: implicit declaration of function `confstr'
./signalmodule.c:88: warning: function declaration isn't a prototype
./signalmodule.c: In function `signal_signal':
./signalmodule.c:212: warning: function declaration isn't a prototype
./signalmodule.c:214: warning: function declaration isn't a prototype
./signalmodule.c:225: warning: function declaration isn't a prototype
./signalmodule.c: In function `initsignal':
./signalmodule.c:332: warning: function declaration isn't a prototype
./signalmodule.c:336: warning: function declaration isn't a prototype
./signalmodule.c:355: warning: function declaration isn't a prototype
./signalmodule.c:357: warning: function declaration isn't a prototype
./signalmodule.c: In function `finisignal':
./signalmodule.c:556: warning: function declaration isn't a prototype
./signalmodule.c:564: warning: function declaration isn't a prototype
make[1]: [add2lib] Error 2 (ignored)
./stropmodule.c: In function `strop_atoi':
./stropmodule.c:752: warning: subscript has type `char'
./timemodule.c: In function `time_strptime':
./timemodule.c:385: warning: subscript has type `char'
./socketmodule.c: In function `PySocket_socket':
./socketmodule.c:1768: warning: function declaration isn't a prototype
./socketmodule.c: In function `PySocket_fromfd':
./socketmodule.c:1806: warning: function declaration isn't a prototype

I'll look into these one at a time and see how many I can fix.

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


From noreply@sourceforge.net  Sat Nov  4 16:40:58 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 4 Nov 2000 08:40:58 -0800
Subject: [Python-bugs-list] [Bug #121208] Advanced email module
Message-ID: <200011041640.IAA27103@sf-web2.i.sourceforge.net>

Bug #121208, was updated on 2000-Nov-03 05:04
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: Advanced email module

Details: A nice new module to have would be a mime enabled email composer. I posted a sample to SourceForge that is still very basic:

http://sourceforge.net/snippet/detail.php?type=snippet&id=100444

Follow-Ups:

Date: 2000-Nov-03 12:49
By: gvanrossum

Comment:
Hey, I didn't know about the SD "Snippet" feature! Cool!

But I'm not sure that this should be a standard library -- it's pretty application specific. Any other opinions?
-------------------------------------------------------

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


From noreply@sourceforge.net  Sun Nov  5 00:41:23 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 4 Nov 2000 16:41:23 -0800
Subject: [Python-bugs-list] [Bug #117556] Python 2.0 regression fails on test_pyexpat.
Message-ID: <200011050041.QAA13785@sf-web1.i.sourceforge.net>

Bug #117556, was updated on 2000-Oct-23 18:18
Here is a current snapshot of the bug.

Project: Python
Category: XML
Status: Closed
Resolution: Works For Me
Bug Group: None
Priority: 5
Summary: Python 2.0 regression fails on test_pyexpat.

Details: Regression fails on test_pyexpat with the following message:

test test_pyexpat failed -- Writing: "('xml=http://www.w3.org/XML/1998/namespace\\014external_entity', None, 'entity.file', None)", expected: "('http://www.python.org/namespace=http://www.w3.org/XML/1998/namespace\\014external_entity'"

This is on Python 2.0 final with expat 1.2 both compiled on Solaris 7 x86 with SunPro 4.2.

Follow-Ups:

Date: 2000-Oct-24 10:25
By: garthc

Comment:
Submitted by garthc (was not registered at the time).
-------------------------------------------------------

Date: 2000-Oct-28 17:49
By: loewis

Comment:
This appears to be an incompatibility between expat 1.1 and expat 1.2. I don't know which one is correct, though.
-------------------------------------------------------

Date: 2000-Nov-04 16:41
By: prescod

Comment:
Python 2.0 just works with Expat 1.1. Expat 1.2 is not 100% backwards compatible. I don't think version skews count as bugs.
-------------------------------------------------------

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


From noreply@sourceforge.net  Sun Nov  5 02:38:58 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 4 Nov 2000 18:38:58 -0800
Subject: [Python-bugs-list] [Bug #114598] Blue Screen crash, popen, Win98, Norton Antivirus 2000
Message-ID: <200011050238.SAA14983@sf-web1.i.sourceforge.net>

Bug #114598, was updated on 2000-Sep-16 13:24
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Open
Resolution: None
Bug Group: 3rd Party
Priority: 3
Summary: Blue Screen crash, popen, Win98, Norton Antivirus 2000

Details: On Windows 98, all of the os.popen*() functions cause a hard "blue screen" crash requiring a reboot, when Nortin Antivirus 2000 is installed and enabled. (Not with Norton Antivirus version 5, not on Windows 2000.)

While this is probably a bug in Norton Antivirus 2000, and we're already warning for this on the download page, that's not enough (we've seen at least one report in the newsgroup), and it would be good if we could somehow prevent it. Even a call to Py_FatalError is better than the blue screen, and raising os.error would be a *lot* better.

Follow-Ups:

Date: 2000-Sep-16 14:26
By: tim_one

Comment:
I don't know how to stop this.  Pissed away an hour trying to get help on the Symantec site, and eventually found a support board to which I posted this msg:

Product: Norton AntiVirus 2000 6.0 for Windows 95/98/NT
Supported operating system: Windows 98
Action: Run Another Program
Error Message: 
Summary: Blue screen crash

I develop the Windows version of the core Python language. Several reports of blue-screen death on Win98 have been traced to NAV2000.  Here's the exact msg from one such:

An exception 0E has occurred at 0028:C02AD9D0 in VxD IFSMGR(04) + 000050E4. This was called from 0028:C000B511 in VxD VMM(01) + 0000A511. It may be possible to continue normally.

This occurs whenever a user executes a member of the popen family of functions from within Python; for example, this Python program:

import os
p = os.popen("dir")

popen is a std C library function, poorly implemented by Microsoft, but not *that* poorly <wink>.

You can get our latest installer here:

http://www.pythonlabs.com/tech/python2.0/download.html

As the warning there says:

-----------------
Incompatibility warning: Norton Antivirus 2000 can cause blue screen crashes on Windows 98 when a function in the os.popen*() family is invoked. To prevent this problem, disable Norton Antivirus when using Python. (Confirmed on Windows 98 Second Edition with Norton Antivirus version 6.10.20. The same Norton Antivirus version doesn't have this
problem on Windows 2000. Norton Antivirus version 5 on Windows 98SE doesn't have this problem either.) 
-----------------

ActiveState is seeing the same problem with their derivative work ActivePython, as is PythonWare with their derivative work PythonWorks. So this affects a lot of people. A recent change to the implementation of a popular library module has made it acutely visible recently (didn't use to use popen, but does now).

A workaround would be nice. More importantly, how can I *detect* whether an affected version of NAV is in use, so that we can shut down Python gracefully with an appropriate message before executing any of the popen functions that throw NAV into blue-screen territory? We try to be a very user-friendly language, and we'll do anything to prevent a crash. Alas, right now I don't know how to stop it.

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

Date: 2000-Sep-19 02:21
By: tim_one

Comment:
1. Sent Guido a small self-contained C program in the hope that it's enough to provoke the problem by itself.  Reassigned this bug to Guido since he has to tell me what happens with that next (then assign back to me).

2. That's because Symantec is being no help at all.  They suggest upgrading to NAV 2001(!).  If I can post a tiny C program, maybe it will embarrass then into doing something.  You can follow this soap opera at:

http://servicenews.symantec.com/cgi-bin/displayArticle.cgi?group=symantec.support.win9x.nortonantivirus2000.general&article=57765

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

Date: 2000-Sep-19 09:06
By: gvanrossum

Comment:
Tim's little C program crashes in the same way as Python when NAV2000 is enabled. back to Tim...
-------------------------------------------------------

Date: 2000-Sep-21 11:32
By: tim_one

Comment:
I cranked up my obnoxiousness level on the Symantec board (URL two comments down), and they may be on the edge of taking this seriously now.
-------------------------------------------------------

Date: 2000-Sep-22 20:46
By: tim_one

Comment:
Reduced the priority a notch.  The biggest trigger here was IDLE's use of os.popen (indirectly via webbrowser.py) to launch the Python HTML docs.  I put in a new Windows function (os.startfile) that uses Win32 ShellExecute instead, and changed webbrowser.py to use that.  IDLE now lives peacefully with NAV 6.10.20.

This was all Guido's idea, and he suggested that the priority of this bug should be dropped now.
-------------------------------------------------------

Date: 2000-Oct-06 12:23
By: gvanrossum

Comment:
Reduced priority even more. There's not much else we can do about this, it seems, except yell at Norton. :-(
-------------------------------------------------------

Date: 2000-Oct-06 16:23
By: tim_one

Comment:
Indeed, I can detect whether AutoProtect is loaded at system startup, but not whether it's currently running.  Just left another nag on the Symantec board but don't expect a useful response.
-------------------------------------------------------

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


From noreply@sourceforge.net  Sun Nov  5 08:17:13 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 5 Nov 2000 00:17:13 -0800
Subject: [Python-bugs-list] [Bug #121654] sre regex () groups have strong memory
Message-ID: <200011050817.AAA15545@sf-web2.i.sourceforge.net>

Bug #121654, was updated on 2000-Nov-05 00:17
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: sre regex () groups have strong memory

Details: The new re module (sre) has a problem with () grouping.
It seems () groups sometimes "remember" the previous
match.  Try the following:


#!/usr/bin/python

"""
	This module parses a CSV string and produces a list whose
	elements are the Comma-Seperated Values.  myCSV uses Python's
	regular expression matching.  The search pattern uses three
	groups of ().  findall() returns a list of tuples containing
	three elements--the results of the search groups.  The lambda
	function returns the correct element of the three.

        For more info on regular expressions see:
            Mastering Regular Expressions
            Jeffrey E. F. Friedl
            O'Reilly Press

######################################################################
        Created:            23-Mar-2000
        Author:             David S. Alessio
        Last Modified:      $Modtime:$
        Last Modified by:   $Author:$
        Revision:           $Revision:$

	Revision History:
        $Log:$
######################################################################
"""

import re


class myCSV:
    def __init__(self):
        self.srchPat = '"([^"\\\\]*(\\\\.[^"\\\\]*)*)",?|([^,]+),?|,'
        self.srchProg = re.compile(self.srchPat)
    
    def __str2num(self, str):
        try:
            num = int(str)
        except:
            try:
                num = long(str)
            except:
                try:
                    num = float(str)
                except:
                    num = str
        return num

    def __pick_best_value(self, t):
        value = t[0] or t[2]
        return self.__str2num(value)
        
    def csv2list(self, str):
#       print self.srchProg.findall(str)
        return map(lambda t: t[0] or t[2], self.srchProg.findall(str))
        
    def csv2numlist(self, str):
        return map(self.__pick_best_value, self.srchProg.findall(str))

    def test(self):
        str = '1,2,3,"ab\\"c","de,f",name,"123",,,"xyz","","zzz"'
        tstnumlst = [1,2,3,'ab\\"c','de,f','name',123,'','','xyz','','zzz']
        list = self.csv2list(str)
        numlst = self.csv2numlist(str)
        print str
        print list
        print numlst
        print tstnumlst
#"""
        if tstnumlst != numlst:
            print "\nERROR:"
            if len(numlst) > len(tstnumlst):
                print 'NumList Too Long!!!'
            elif len(numlst) < len(tstnumlst):
                print 'NumList Too Short!!!'
            else:
                print '            Expected      Got'
                for i in xrange(len(tstnumlst)):
                    mark = ''
                    if tstnumlst[i] != numlst[i]:
                        mark = ' <==='
                    print 'L[%2d]: %10s %10s %s' % (i, tstnumlst[i], numlst[i], mark)
                    
        else:
            print 'OK'
#"""

if __name__ == '__main__':
    from sys import argv
    if len(argv) == 1:
        print 'Compiling CSV'
        x = myCSV();
        print 'Testing...'
        x.test()
    elif len(argv) == 2:
        fin = open(argv[1])
        x = myCSV();
        while 1:
            str = fin.readline()
            if not str: break
            csv = x.csv2numlist(str[:-1])
            print csv
    else:
        print 'Usage: %s [file.csv]' % argv[0]
		


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


From noreply@sourceforge.net  Sun Nov  5 16:16:35 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 5 Nov 2000 08:16:35 -0800
Subject: [Python-bugs-list] [Bug #121671] bad link David Ascher's compile.py script
Message-ID: <200011051616.IAA25864@sf-web1.i.sourceforge.net>

Bug #121671, was updated on 2000-Nov-05 08:16
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: bad link David Ascher's compile.py script 

Details: The document "Extending and Embedding the Python Interpreter, October 16, 2000, Release 2.0", at

http://www.python.org/doc/current/ext/win-cookbook.html

contains a bad link to bad link David Ascher's compile.py script; the link is to http://starship.python.net/crew/da/compile/ 
but this URL doesn't work (it redirects to one that
refuses connections).

It'd be great if someone could put compile.py someplace
accessible and fix this link!

--Mark


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


From noreply@sourceforge.net  Sun Nov  5 16:27:45 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 5 Nov 2000 08:27:45 -0800
Subject: [Python-bugs-list] [Bug #121672] Documentation which needs updating to 2.0
Message-ID: <200011051627.IAA26085@sf-web1.i.sourceforge.net>

Bug #121672, was updated on 2000-Nov-05 08:27
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Documentation which needs updating to 2.0

Details: When describing formatting strings while "%s" is described, the new "%r" is not.

Built in function int(val [, radix])  Radix may be 0 in which case it works like string.atoi used to (looks at start of string, if 0x hex, if 0 octal otherwise decimal, or something close)

long(), like int() has an optional radix parameter


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


From noreply@sourceforge.net  Sun Nov  5 23:40:55 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 5 Nov 2000 15:40:55 -0800
Subject: [Python-bugs-list] [Bug #121706] exceptions module cannot be imported in two interpreters
Message-ID: <200011052340.PAA31310@sf-web1.i.sourceforge.net>

Bug #121706, was updated on 2000-Nov-05 15:40
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: exceptions module cannot be imported in two interpreters

Details: If the exceptions module is imported in two separate interpreters within one process, the second import fails.  The program below fails when linked with Python 2.0 on RedHat Linux 6.2 with the following message:

Traceback (most recent call last):
  File "<string>", line 1, in ?
ImportError: Cannot re-init internal module exceptions

Program source:

#include <Python.h>

char *cmd = "import exceptions";

int main()
{
  Py_Initialize();
  PyEval_InitThreads();
  PyRun_SimpleString(cmd);
  Py_EndInterpreter(PyThreadState_Get());
  Py_NewInterpreter();
  PyRun_SimpleString(cmd);
  Py_Finalize();
}

If the command is changed to "import sys" or "import os" there is no error message.




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


From noreply@sourceforge.net  Mon Nov  6 16:34:07 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 6 Nov 2000 08:34:07 -0800
Subject: [Python-bugs-list] [Bug #121791] possible GCC egcs-2.91.66 bug in parsestr
Message-ID: <200011061634.IAA11772@sf-web1.i.sourceforge.net>

Bug #121791, was updated on 2000-Nov-06 08:34
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: possible GCC egcs-2.91.66 bug in parsestr

Details: Using:

GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2

I get the following 'error' message:

    from interscript.languages.interscript_languages import add_translation
  File "interscript/languages/interscript_languages.py", line 2, in ?
    from interscript.encoding.utf8 import utf8
ValueError: invalid \x escape

in known correct code (i.e. it works on Python 1.5.2).

I have examined the function 'parsestr' in
'compile.c', and added debugging prints to find out
what is going on. The function _correctly_ processes
the string 'utf8' (quotes included), and returns,
then the error is generated _without_ entering
the routine!

This almost certainly must be a bug in egcs-2.91.66. 
The code in 'parsestr' looks correct to me.

It is possible the error can be replicated by
downloading and running 'interscript' (without
any arguments). Interscript is available at

	http://interscript.sourceforge.net

[Reply to skaller@maxtal.com.au, sorry, I couldn't
figure out how to 'log on']


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


From noreply@sourceforge.net  Mon Nov  6 16:40:19 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 6 Nov 2000 08:40:19 -0800
Subject: [Python-bugs-list] [Bug #117464] clash with BSD db when building
Message-ID: <200011061640.IAA09181@sf-web2.i.sourceforge.net>

Bug #117464, was updated on 2000-Oct-23 00:29
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: clash with BSD db when building

Details: On RH7.0, beside the LONG_BIT issue, I came across a db.h missmatch. 
The preprocessor directive values used in bsddbmodule.c correspond to the /usr/include/db1/db.h file, but on my system, /usr/include/db.h points to db3/db.h which does not define the same set of values, and does not compile.

Compiling with the old file works, but obviously it does not link...

configure (with no options) ran trouble free.

The system is:
RedHat 7.0
gcc version 2.96 20000731 (yes with the LONG_BIT problem) 
Python 2.0 final release

Regards,
Pascal    

Follow-Ups:

Date: 2000-Oct-23 18:13
By: fleury

Comment:
Well, I also tried at home, where I have a vanilla RH7.0 and it compiles perfectly.
The reported bug was on a RH6.2->RH7.0 upgraded machine.
-------------------------------------------------------

Date: 2000-Nov-06 08:40
By: montanaro

Comment:
This is going to require a bit of effort.  My current scheme for detecting whether bsddb can be built/linked or not relies on the presence or absence of db.h and/or db_185.h.  If db_185.h is present, libdb v.2 is assumed.  If only db.h is present, libdb v.1 is assumed.

Now Sleepycat has libdb v.3, and on RH7 it appears you can have all three versions installed at once.  I don't yet know if bsddbmodule.c can be built/linked with v.3 (seems likely, since db_185.h still existts), but even if it can, configure will have to grovel around in db.h looking for DB_VERSION_MAJOR.  If it doesn't exist, we have v.1.  If it does exist, its value will determine what version > 1 we have.

I imagine for an autoconf whiz this will be a simple task, but it's more of a challenge than I have time for at the moment.  Anyone want to take this on?

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

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


From noreply@sourceforge.net  Mon Nov  6 17:04:53 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 6 Nov 2000 09:04:53 -0800
Subject: [Python-bugs-list] [Bug #121791] Error for bad \x escape doesn't mention filename
Message-ID: <200011061704.JAA09514@sf-web2.i.sourceforge.net>

Bug #121791, was updated on 2000-Nov-06 08:34
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Error for bad \x escape doesn't mention filename

Details: Using:

GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2

I get the following 'error' message:

    from interscript.languages.interscript_languages import add_translation
  File "interscript/languages/interscript_languages.py", line 2, in ?
    from interscript.encoding.utf8 import utf8
ValueError: invalid \x escape

in known correct code (i.e. it works on Python 1.5.2).

I have examined the function 'parsestr' in
'compile.c', and added debugging prints to find out
what is going on. The function _correctly_ processes
the string 'utf8' (quotes included), and returns,
then the error is generated _without_ entering
the routine!

This almost certainly must be a bug in egcs-2.91.66. 
The code in 'parsestr' looks correct to me.

It is possible the error can be replicated by
downloading and running 'interscript' (without
any arguments). Interscript is available at

	http://interscript.sourceforge.net

[Reply to skaller@maxtal.com.au, sorry, I couldn't
figure out how to 'log on']


Follow-Ups:

Date: 2000-Nov-06 09:04
By: gvanrossum

Comment:
The error message is legitimate: in Python 2.0, \x escapes must have exactly two hex characters following, and he uses \x0\x0 in his __init__.py module, which generates the error message.

But his bug report is also legitimate: the ValueError doesn't mention the file where this is occurring! I'm changing the bug subject to reflect this -- it has nothing to do with egcs 2.91.66.

I'm randomly assigning this to Tim.
-------------------------------------------------------

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


From noreply@sourceforge.net  Mon Nov  6 18:36:03 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 6 Nov 2000 10:36:03 -0800
Subject: [Python-bugs-list] [Bug #119806] cgi.py uses too much memory on large file uploads
Message-ID: <200011061836.KAA10839@sf-web2.i.sourceforge.net>

Bug #119806, was updated on 2000-Oct-30 13:35
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Fixed
Bug Group: Feature Request
Priority: 5
Summary: cgi.py uses too much memory on large file uploads

Details: When uploading files through a web form and parsing the form using cgi.py - the entire fil(s are read into memory, which is intolerable with very large (I'm thinking multiple 10's of megabyte) files.

The culprit seems to be in the FieldStorage class, basically the three calls to:

   self.lines.append(line)

in the read_lines_to_eof, read_lines_to_outerboundary, and skip_lines methods.  

Commenting those calls out seems to fix the problem, as long as you don't care to access the 'lines' member of the FieldStorage instance.  A real fix would possibly be to add a "keep_lines=1" keyword parameter to FieldStorage.__init__(), save that value in the instance, and check it before accumulating form lines.

Follow-Ups:

Date: 2000-Nov-06 10:36
By: bwarsaw

Comment:
This is identical to bug 110674 which was closed prior to Python 2.0 after added it to PEP 42.

For Python 2.1, we will remove the self.lines attribute and see if anybody complains.  Nobody can remember why those were added in the first place.

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

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


From noreply@sourceforge.net  Mon Nov  6 18:39:03 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 6 Nov 2000 10:39:03 -0800
Subject: [Python-bugs-list] [Bug #110674] memory bloat in binary file upload (PR#381)
Message-ID: <200011061839.KAA10908@sf-web2.i.sourceforge.net>

Bug #110674, was updated on 2000-Jul-31 14:13
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Fixed
Bug Group: Feature Request
Priority: 5
Summary: memory bloat in binary file upload (PR#381)

Details: Jitterbug-Id: 381
Submitted-By: naris@ensim.com
Date: Mon,  3 Jul 2000 21:29:25 -0400 (EDT)
Version: 1.5.2
OS: RedHat 6.1


read_lines_to_outerboundary chews up memory.
there's a while (1) loop that does a readline(), which
is probably not good, as you could have a binary file that
doesn't have an endline til the end, and thus readline would
read the entire file into memory.  i did the following:
dd'd a 100MB /dev/zero file and used zope to upload it.
it chewed up a large amount of memory.

there seems to be bug reports about text files and windows
systems (and needing to use python -u), but this problem
is unrelated.  i am using a unix browser -> unix web server.



====================================================================
Audit trail:
Tue Jul 11 08:24:22 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-24 12:38
By: naris

Comment:
there's a bug i submitted to zope that deals with a second problem
with read_lines_to_outerboundary, which will also cause a memory
leak.

the read_lines_to_outerboundary has an unnecessary line 
self.lines.append(line).  removing will fix it this second problem.
-------------------------------------------------------

Date: 2000-Sep-25 15:06
By: bwarsaw

Comment:
Agreed that readlines() isn't the best thing to use in the face of large binary uploads.  I've added this feature request to PEP 42 (and am closing this bug report).

Removing self.lines might be more problematic, since although it's not documented as part of the public interface for FieldStorage, it is possible that existing code is using it, and that code would break.
-------------------------------------------------------

Date: 2000-Sep-27 03:38
By: naris

Comment:
i feel the self.lines.append() is is a pretty serious problem...have you got any
second opinions on how to proceed?

if its not part of the public interface for FieldStorage, then wouldn't it be somewhat safe to remove it (you might anger some people, but they could always stick to using the old cgi.py)?

my argument is that if they changed the socket connect/bind functions to reject connect(host,port) in favor of connect((host,port)), then we should certainly be able to remove this self.lines.append() :-)

what do you think?

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

Date: 2000-Nov-06 10:39
By: bwarsaw

Comment:
We've decided to remove the self.lines attribute for Python 2.1.  This part of the bug report is identical to 119806.  No one can remember why self.lines was there in the first place, so we'll remove it and see who complains.
-------------------------------------------------------

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


From noreply@sourceforge.net  Mon Nov  6 22:32:14 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 6 Nov 2000 14:32:14 -0800
Subject: [Python-bugs-list] [Bug #119123] Use of ftplib or urllib causes page fault on exit
Message-ID: <200011062232.OAA18558@sf-web3.vaspecialprojects.com>

Bug #119123, was updated on 2000-Oct-25 18:30
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Invalid
Bug Group: 3rd Party
Priority: 5
Summary: Use of ftplib or urllib causes page fault on exit

Details: I work at a government office and have been using Python for over a year. Our office upgraded all the PC with the latest version of Netscape, IE Explorer, and security patches to Windows. After this upgrade, all scripts that use either ftplib or urllib cause a page fault in KERNEL32.DLL whenever Python exits. This page fault happens on every machine (Win95 & Win98) using Python, Pythonw, IDLE, or scripts; with version 1.5.2 and 2.0. The fault does not pop up until the script exits or interactive Python exits.

Because of this development, all Python work has stopped and my supervisors are re-evaluating the use Python for production work. I have been an avid promoter of Python, but now I am completely stuck. Other programs on the machines still work, only Python seems to be affected. Please help!

Below is the page fault message:
PYTHONW caused an invalid page fault in
module KERNEL32.DLL at 0167:bff7b9a6.
Registers:
EAX=00000000 CS=0167 EIP=bff7b9a6 EFLGS=00000246
EBX=0087b650 SS=016f ESP=0062fbdc EBP=0084d73c
ECX=00000000 DS=016f ESI=020325f0 FS=4207
EDX=00000000 ES=016f EDI=00671d68 GS=0000
Bytes at CS:EIP:
ff 76 04 e8 13 89 ff ff 5e c2 04 00 56 8b 74 24
Stack dump:
0087b650 02020b13 020325f0 0062fbf8 76003481
0062fbf8 0084d730 0087b650 7600265e 00000000
0084d730 0084d6d0 0084d6dc 76003283 0084d6d0 7600e420

Please contact mike.callahan@noaa.gov or call 800-292-5588 if you have any answers. I want to keep Python in our office, but right now, I am fighting a losing battle.

Mike Callahan
National Weather Service
Louisville KY



Follow-Ups:

Date: 2000-Nov-01 08:04
By: jhylton

Comment:
This is a pretty strange bug report.  Many, many people use Python on Windows and do not experience any such problem.
-------------------------------------------------------

Date: 2000-Nov-01 20:47
By: tim_one

Comment:
Reduced priority; mailed this msg to Mike:

Hi, Mike.  This is about the Python bug you reported at:

http://sourceforge.net/bugs/?func=detailbug&bug_id=119123&group_id=5470

I don't see that we can do much about this:

1. Tens of thousands of people use Python on Windows, and yours is the only report of this.

2. There's no evidence of a Python bug.  KERNEL32.DLL, where the error happens, is a core Microsoft DLL, and its source code is an MS secret -- i.e., the error is in MS's code, and you'd probably have to pay Microsoft support staff to find out exactly what's going wrong in their code.

That said, at least post a small and self-contained program that exhibits the problem so others can *try* it.  Since you have no idea what's going wrong either, saying "all scripts that use either ftplib or urllib" gives us no information.  There may well be something your site's particular scripts have in common that's important!  It's certainly *not* the case that other people using ftplib or urllib on Windows are having troubles.

Since your uses of ftplib and urllib presumably access info across a network, a likely cause of errors in KERNEL32.DLL is a misconfigured network, or non-MS "security programs" that poke around where they shouldn't (incl. virus checkers, which are a notorious source of problems -- have you tried running your scripts w/ virus checkers disabled?  with all background tasks other than Explorer and Systray killed off?  that's just basic Windows debugging procedure, but can't tell whether you've done any of it).

About "I want to keep Python in our office, but right now, I am fighting a losing battle", ask them to *think* a little.  In the old days, people used to take canaries into coal mines, because (or so the story goes ...) if there was a potentially fatal buildup of gases, the canaries would pass out before people noticed.  Throwing out Python because your sysadmins changed your setup in such a way that Microsoft's software blows up is a lot like saying the canary keeps passing out, so let's ignore it <0.5 wink>.  Python didn't cause this problem -- indeed, you said there was no problem before they "upgraded" your systems!

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

Date: 2000-Nov-06 14:32
By: tim_one

Comment:
Closed, changed Group to 3rd-party and Resolution to Invalid.  Mike reports:

"""
We found the problem. It was a program which I did not know about called CyberSitter which was on all the network PCs. We turned it off and all is well again with Python. Thanks for your help. 
"""

CyberSitter sure qualifies as a "non-MS 'security program' that pokes around where it shouldn't"!  I pointed him to news://news.cybersitter.com, which has many reports of CyberSitter crashing all sorts of things.
-------------------------------------------------------

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


From noreply@sourceforge.net  Tue Nov  7 07:28:11 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 6 Nov 2000 23:28:11 -0800
Subject: [Python-bugs-list] [Bug #119729] copy/past error in Extending&Embedding
Message-ID: <200011070728.XAA24543@sf-web1.i.sourceforge.net>

Bug #119729, was updated on 2000-Oct-29 23:04
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: copy/past error in Extending&Embedding

Details: On page 9 of "extending and embedding" release 2.0,
I found a copy/past error for item 'es':

\item[\samp{es} (string, Unicode object or character buffer
compatible object) {[const char *encoding, char **buffer]}]
=> 2 parameters

But :
The variant [...] and the third one a pointer to an integer
(\var{*buffer_length}, the buffer length).



Follow-Ups:

Date: 2000-Nov-02 13:50
By: fdrake

Comment:
Fixed in Doc/ext/ext.tex revision 1.88.
-------------------------------------------------------

Date: 2000-Nov-06 23:28
By: gcivario

Comment:
Hello.

Still on page 9, for \item{es#}, the "two C variables"
should become "three C variables" I guess.

Regards.

Gilles.
-------------------------------------------------------

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


From noreply@sourceforge.net  Tue Nov  7 10:05:38 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 7 Nov 2000 02:05:38 -0800
Subject: [Python-bugs-list] [Bug #120994] Traceback with DISTUTILS_DEBUG set
Message-ID: <200011071005.CAA23493@sf-web2.i.sourceforge.net>

Bug #120994, was updated on 2000-Nov-01 05:43
Here is a current snapshot of the bug.

Project: Python
Category: Distutils
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Traceback with DISTUTILS_DEBUG set

Details: Something is wrong in the 'dump_dirs()' method of the "install" command: it bombs with an AttributeError:

$ DISTUTILS_DEBUG=1 python setup.py install
[...]
running install
Distribution.get_command_obj(): creating 'install' command object
pre-finalize_{unix,other}:
  prefix: None
  exec_prefix: None
  home: None
  install_base: None
  install_platbase: None
  root: None
  install_purelib: None
  install_platlib: None
  install_lib: None
  install_headers: None
  install_scripts: None
  install_data: None
  compile: None
Traceback (most recent call last):
  File "setup.py", line 28, in ?
    packages = ['distutils', 'distutils.command'],
  File "distutils/core.py", line 138, in setup
    dist.run_commands()
  File "distutils/dist.py", line 829, in run_commands
    self.run_command(cmd)
  File "distutils/dist.py", line 848, in run_command
    cmd_obj.ensure_finalized()
  File "distutils/cmd.py", line 112, in ensure_finalized
    self.finalize_options()
  File "distutils/command/install.py", line 240, in finalize_options
    self.dump_dirs("pre-finalize_{unix,other}")
  File "distutils/command/install.py", line 338, in dump_dirs
    val = getattr(self, opt_name)
  File "distutils/cmd.py", line 107, in __getattr__
    raise AttributeError, attr
AttributeError: no_compile

Not sure what's going on here...


Follow-Ups:

Date: 2000-Nov-07 02:05
By: calvin

Comment:
I submitted a patch for this on the mailling list.
-------------------------------------------------------

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


From noreply@sourceforge.net  Tue Nov  7 12:46:08 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 7 Nov 2000 04:46:08 -0800
Subject: [Python-bugs-list] [Bug #120994] Traceback with DISTUTILS_DEBUG set
Message-ID: <200011071246.EAA25411@sf-web2.i.sourceforge.net>

Bug #120994, was updated on 2000-Nov-01 05:43
Here is a current snapshot of the bug.

Project: Python
Category: Distutils
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Traceback with DISTUTILS_DEBUG set

Details: Something is wrong in the 'dump_dirs()' method of the "install" command: it bombs with an AttributeError:

$ DISTUTILS_DEBUG=1 python setup.py install
[...]
running install
Distribution.get_command_obj(): creating 'install' command object
pre-finalize_{unix,other}:
  prefix: None
  exec_prefix: None
  home: None
  install_base: None
  install_platbase: None
  root: None
  install_purelib: None
  install_platlib: None
  install_lib: None
  install_headers: None
  install_scripts: None
  install_data: None
  compile: None
Traceback (most recent call last):
  File "setup.py", line 28, in ?
    packages = ['distutils', 'distutils.command'],
  File "distutils/core.py", line 138, in setup
    dist.run_commands()
  File "distutils/dist.py", line 829, in run_commands
    self.run_command(cmd)
  File "distutils/dist.py", line 848, in run_command
    cmd_obj.ensure_finalized()
  File "distutils/cmd.py", line 112, in ensure_finalized
    self.finalize_options()
  File "distutils/command/install.py", line 240, in finalize_options
    self.dump_dirs("pre-finalize_{unix,other}")
  File "distutils/command/install.py", line 338, in dump_dirs
    val = getattr(self, opt_name)
  File "distutils/cmd.py", line 107, in __getattr__
    raise AttributeError, attr
AttributeError: no_compile

Not sure what's going on here...


Follow-Ups:

Date: 2000-Nov-07 02:05
By: calvin

Comment:
I submitted a patch for this on the mailling list.
-------------------------------------------------------

Date: 2000-Nov-07 04:46
By: none

Comment:
Please put the patch in the Patch Manager instead!

--Guido
-------------------------------------------------------

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


From noreply@sourceforge.net  Tue Nov  7 15:20:12 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 7 Nov 2000 07:20:12 -0800
Subject: [Python-bugs-list] [Bug #121887] new.function, 3rd arg: can it be None or not?
Message-ID: <200011071520.HAA27684@sf-web2.i.sourceforge.net>

Bug #121887, was updated on 2000-Nov-07 07:20
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: new.function, 3rd arg: can it be None or not?

Details: According to the docs, new.function's 3rd argument can be None (then the name from the codeobject will be used).

Trying to call new.function with None as the third argument raises an exception saying that this argument must be a string. Documentation error, or bug in module new?


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


From noreply@sourceforge.net  Tue Nov  7 15:48:01 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 7 Nov 2000 07:48:01 -0800
Subject: [Python-bugs-list] [Bug #117606] *.so creation in solaris+GCC
Message-ID: <200011071548.HAA31708@sf-web3.vaspecialprojects.com>

Bug #117606, was updated on 2000-Oct-24 08:15
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: Fixed
Bug Group: Platform-specific
Priority: 6
Summary: *.so creation in solaris+GCC

Details: Python 2.0 (dinamic modules)
Mod_Python 2.6.2 (dinamic module)
GCC 2.95.2
Apache 1.3.14 (dinamic modules)
SunOS5 (Solaris 2.x)

I send the email also to "mod_python" mailing list since I detect the problem using this package. Other developers could see the very same problem!.


Mod_python runs smoothly until I do a "import zlib", for example, in a handler. In this case, the request is aborted with the following log:

>>>>>
[Tue Oct 24 16:27:40 2000] [error] PythonHandler cache: Traceback (most recent call last):
[Tue Oct 24 16:27:40 2000] [error] PythonHandler cache:   File "/usr/local/lib/python2.0/site-packages/mod_python/apache.py", line 185, in Dispatch
    result = object(self.req)
[Tue Oct 24 16:27:40 2000] [error] PythonHandler cache:   File "/export/home/webmaster/www.argo.es/servicios/cache.py", line 47, in handler
    exec(cache[f][1])
[Tue Oct 24 16:27:40 2000] [error] PythonHandler cache:   File "/export/home/webmaster/www.argo.es/servicios/borra_email", line 183, in ?
    req2=wrap(req)
[Tue Oct 24 16:27:40 2000] [error] PythonHandler cache:   File "/export/home/webmaster/www.argo.es/servicios/borra_email", line 159, in __init__
    import zlib
[Tue Oct 24 16:27:40 2000] [error] PythonHandler cache: ImportError: ld.so.1: /opt/local/apache/bin/httpd: fatal: relocation error: file /usr/local/lib/python2.0/lib-dynload/zlibmodule.so: symbol main: referenced symbol not found
<<<<<

That is, "zlibmodule.so" tries to link to a function called "main".

Doing a "nm object|grep main", I see the unresolved reference in "zlibmodule.so", but not in "zlibmodule.o". So, the problem seems to be the creation of the shared library.

I tracked down the problem to the "configure" script: "cc -G" is (I think) the right thing to do to create a shared library if you are using the Sun compiler, but if you are using GCC (like me), the right command is "gcc -shared".

Patch for Python 2.0:

>>>>>
Index: configure
===================================================================
RCS file: /opt/src/cvsroot/python/configure,v
retrieving revision 1.1.1.2
retrieving revision 1.1.1.2.2.1
diff -c -r1.1.1.2 -r1.1.1.2.2.1
*** configure   2000/10/18 19:06:44     1.1.1.2
--- configure   2000/10/24 14:19:01     1.1.1.2.2.1
***************
*** 2650,2656 ****
        SunOS/4*) LDSHARED="ld";;
        SunOS/5*) 
                if test "$GCC" = "yes"
!               then LDSHARED='$(CC) -G'
                else LDSHARED="ld -G";
                fi ;;
        hp*|HP*) LDSHARED="ld -b";;
--- 2650,2656 ----
        SunOS/4*) LDSHARED="ld";;
        SunOS/5*) 
                if test "$GCC" = "yes"
!               then LDSHARED='$(CC) -shared'
                else LDSHARED="ld -G";
                fi ;;
        hp*|HP*) LDSHARED="ld -b";;
Index: configure.in
===================================================================
RCS file: /opt/src/cvsroot/python/configure.in,v
retrieving revision 1.1.1.2
retrieving revision 1.1.1.2.2.1
diff -c -r1.1.1.2 -r1.1.1.2.2.1
*** configure.in        2000/10/18 19:06:45     1.1.1.2
--- configure.in        2000/10/24 14:19:03     1.1.1.2.2.1
***************
*** 564,570 ****
        SunOS/4*) LDSHARED="ld";;
        SunOS/5*) 
                if test "$GCC" = "yes"
!               then LDSHARED='$(CC) -G'
                else LDSHARED="ld -G";
                fi ;;
        hp*|HP*) LDSHARED="ld -b";;
--- 564,570 ----
        SunOS/4*) LDSHARED="ld";;
        SunOS/5*) 
                if test "$GCC" = "yes"
!               then LDSHARED='$(CC) -shared'
                else LDSHARED="ld -G";
                fi ;;
        hp*|HP*) LDSHARED="ld -b";;
<<<<<


Follow-Ups:

Date: 2000-Nov-03 06:30
By: gward

Comment:
I don't think "gcc -shared" is the right answer; at least on Solaris 2.6, with GCC 2.95.2 and Python2.0+ (CVS as of 2000/11/03), compiling extensions dies horribly.  The very first extension, arraymodule.c, compiles fine to arraymodule.o.  But then linking to arraymodule.so fails with hundreds of symbol relocation errors.  About half are "Py" or "_Py" symbols, there are many "<unknown>" (?) symbols, and a handful of errors for 'malloc', 'sprintf', and the like.

I have no idea what's going on here, but "gcc -shared" definitely makes things *worse* for a vanilla (non-embedded) build of Python 2.0+ on Solaris 2.6 with GCC 2.95.2.

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

Date: 2000-Nov-03 06:32
By: gward

Comment:
Oops, forgot to mention: the original bug report didn't specify which version of Solaris.  Could be 2.6, 2.7, 2.8, maybe even 2.5, ... 

I have access to 2.6 and 2.7 machines for testing, if it helps.  Have only tried it on 2.6 so far, and that's where it died horribly.

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

Date: 2000-Nov-03 14:48
By: gward

Comment:
Martin von Loewis suggested compiling with -fPIC; I did so and everything worked out fine.  I have a revised patch for configure.in, which adds -fPIC to OPT for GCC on *all* platforms, and sets LDSHARED to "$(CC) -shared" for GCC on Solaris.  It works for me -- I can check it in any time.
-------------------------------------------------------

Date: 2000-Nov-07 07:48
By: gward

Comment:
Fixed with rev 1.178 of configure.in and rev 1.170 of configure.
-------------------------------------------------------

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


From noreply@sourceforge.net  Wed Nov  8 02:14:57 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 7 Nov 2000 18:14:57 -0800
Subject: [Python-bugs-list] [Bug #121930] Parameter mismatch exception tracebacks could be more helpfu
Message-ID: <200011080214.SAA08542@sf-web3.vaspecialprojects.com>

Bug #121930, was updated on 2000-Nov-07 18:14
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Parameter mismatch exception tracebacks could be more helpfu

Details: Here's an example of the problem:

def foo(a,b,c,d,e,f,g,h,i,j): pass
a=foo
#10,00 lines of code
#10,00 lines of code
...
j=a
# 10,000 lines of code
def bar(): j()
bar()
 
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File "<stdin>", line 1, in bar
TypeError: not enough arguments; expected 10, got 0
 
Notice that there is *no indication* of the real source-location of the
thing that I attempted to call (foo). As soon as there is a layer or two
of indirection between function pointers and the code that calls them,
it can get really confusing to try and figure out what code is being
called. When the callee is Python it would be nice if there were some
indication in the error message or traceback of the thing's real name
and real source location.

Guido says:

> This could be fixed with special purpose code for this exception
> (probably by setting up a dummy frame and using that).


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


From noreply@sourceforge.net  Wed Nov  8 02:16:02 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 7 Nov 2000 18:16:02 -0800
Subject: [Python-bugs-list] [Bug #121930] Parameter mismatch exception tracebacks could be more helpfu
Message-ID: <200011080216.SAA08565@sf-web3.vaspecialprojects.com>

Bug #121930, was updated on 2000-Nov-07 18:14
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Parameter mismatch exception tracebacks could be more helpfu

Details: Here's an example of the problem:

def foo(a,b,c,d,e,f,g,h,i,j): pass
a=foo
#10,00 lines of code
#10,00 lines of code
...
j=a
# 10,000 lines of code
def bar(): j()
bar()
 
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File "<stdin>", line 1, in bar
TypeError: not enough arguments; expected 10, got 0
 
Notice that there is *no indication* of the real source-location of the
thing that I attempted to call (foo). As soon as there is a layer or two
of indirection between function pointers and the code that calls them,
it can get really confusing to try and figure out what code is being
called. When the callee is Python it would be nice if there were some
indication in the error message or traceback of the thing's real name
and real source location.

Guido says:

> This could be fixed with special purpose code for this exception
> (probably by setting up a dummy frame and using that).


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


From noreply@sourceforge.net  Wed Nov  8 11:11:44 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 8 Nov 2000 03:11:44 -0800
Subject: [Python-bugs-list] [Bug #121951] webbrowser.open() generates AttributeError on Mac
Message-ID: <200011081111.DAA10445@sf-web2.i.sourceforge.net>

Bug #121951, was updated on 2000-Nov-08 03:11
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: webbrowser.open() generates AttributeError on Mac

Details: A typo in webbrowser.py.  This context diff fixes this problem:

Index: webbrowser.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/webbrowser.py,v
retrieving revision 1.4
diff -c -r1.4 webbrowser.py
*** webbrowser.py	2000/10/02 03:40:51	1.4
--- webbrowser.py	2000/11/08 10:24:39
***************
*** 215,221 ****
  else:
      class InternetConfig:
          def open(self, url, new=0):
!             ic.launcurl(url)
  
          def open_new(self, url):
              self.open(url)
--- 215,221 ----
  else:
      class InternetConfig:
          def open(self, url, new=0):
!             ic.launchurl(url)
  
          def open_new(self, url):
              self.open(url)



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


From noreply@sourceforge.net  Wed Nov  8 13:52:30 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 8 Nov 2000 05:52:30 -0800
Subject: [Python-bugs-list] [Bug #121963] IDLE hangs on Threads
Message-ID: <200011081352.FAA15362@sf-web1.i.sourceforge.net>

Bug #121963, was updated on 2000-Nov-08 05:52
Here is a current snapshot of the bug.

Project: Python
Category: IDLE
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: IDLE hangs on Threads

Details: everytime my python- program starts a thread under IDLE it crashes. i use Windows 2000 and Python 2.0

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


From noreply@sourceforge.net  Wed Nov  8 14:11:58 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 8 Nov 2000 06:11:58 -0800
Subject: [Python-bugs-list] [Bug #121965] 10 in xrange(10) returns 1
Message-ID: <200011081411.GAA12836@sf-web2.i.sourceforge.net>

Bug #121965, was updated on 2000-Nov-08 06:11
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: 10 in xrange(10) returns 1

Details: C:\Python20>python.exe
Python 2.0 (#8, Oct 24 2000, 15:02:23) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> 10 in xrange(10)
1
>>> 10 in range(10)
0
>>>

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


From noreply@sourceforge.net  Wed Nov  8 14:27:03 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 8 Nov 2000 06:27:03 -0800
Subject: [Python-bugs-list] [Bug #121965] 10 in xrange(10) returns 1
Message-ID: <200011081427.GAA15987@sf-web1.i.sourceforge.net>

Bug #121965, was updated on 2000-Nov-08 06:11
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Summary: 10 in xrange(10) returns 1

Details: C:\Python20>python.exe
Python 2.0 (#8, Oct 24 2000, 15:02:23) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> 10 in xrange(10)
1
>>> 10 in range(10)
0
>>>

Follow-Ups:

Date: 2000-Nov-08 06:27
By: gvanrossum

Comment:
Simple end case bug in range_contains().
Another bug: it doesn't work right for negative strides.

Better add some test cases too!

Assigned to Fred since he checked the code in (so maybe he even wrote it :-).
-------------------------------------------------------

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


From noreply@sourceforge.net  Wed Nov  8 18:39:30 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 8 Nov 2000 10:39:30 -0800
Subject: [Python-bugs-list] [Bug #121965] 10 in xrange(10) returns 1
Message-ID: <200011081839.KAA17254@sf-web2.i.sourceforge.net>

Bug #121965, was updated on 2000-Nov-08 06:11
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 9
Summary: 10 in xrange(10) returns 1

Details: C:\Python20>python.exe
Python 2.0 (#8, Oct 24 2000, 15:02:23) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> 10 in xrange(10)
1
>>> 10 in range(10)
0
>>>

Follow-Ups:

Date: 2000-Nov-08 06:27
By: gvanrossum

Comment:
Simple end case bug in range_contains().
Another bug: it doesn't work right for negative strides.

Better add some test cases too!

Assigned to Fred since he checked the code in (so maybe he even wrote it :-).
-------------------------------------------------------

Date: 2000-Nov-08 10:39
By: fdrake

Comment:
">" was used where ">=" should have been used; fixed in Objects/rangeobject.c revision 2.21.
-------------------------------------------------------

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


From noreply@sourceforge.net  Wed Nov  8 19:55:43 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 8 Nov 2000 11:55:43 -0800
Subject: [Python-bugs-list] [Bug #121965] 10 in xrange(10) returns 1
Message-ID: <200011081955.LAA22293@sf-web3.vaspecialprojects.com>

Bug #121965, was updated on 2000-Nov-08 06:11
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 9
Summary: 10 in xrange(10) returns 1

Details: C:\Python20>python.exe
Python 2.0 (#8, Oct 24 2000, 15:02:23) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> 10 in xrange(10)
1
>>> 10 in range(10)
0
>>>

Follow-Ups:

Date: 2000-Nov-08 06:27
By: gvanrossum

Comment:
Simple end case bug in range_contains().
Another bug: it doesn't work right for negative strides.

Better add some test cases too!

Assigned to Fred since he checked the code in (so maybe he even wrote it :-).
-------------------------------------------------------

Date: 2000-Nov-08 10:39
By: fdrake

Comment:
">" was used where ">=" should have been used; fixed in Objects/rangeobject.c revision 2.21.
-------------------------------------------------------

Date: 2000-Nov-08 11:55
By: fdrake

Comment:
Fixed containment test for negative steps in Objects/rangeobject.c revision 2.22.

Regression tests for containment test for both positive and negative step added in Lib/test/test_b2.py revision 1.20.
-------------------------------------------------------

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


From noreply@sourceforge.net  Wed Nov  8 20:24:01 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 8 Nov 2000 12:24:01 -0800
Subject: [Python-bugs-list] [Bug #119851] inline C++ keyword in config.h
Message-ID: <200011082024.MAA18759@sf-web2.i.sourceforge.net>

Bug #119851, was updated on 2000-Oct-31 01:47
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: inline C++ keyword in config.h

Details: Hi,

I have built Python 2.0 on Solaris 7 using the Sun C compiler.

Now I see the following piece of code in config.h:

/* Define as __inline if that's what the C compiler calls it.  */
#define inline

This is a problem when writing Python modules in C++
and should probably be removed. What was the intent
in the first place?

Thanks,
Dimitri


Follow-Ups:

Date: 2000-Nov-02 17:28
By: fdrake

Comment:
This does appear to be unnecessary.  Removing AC_C_INLINE from configure.in seems to be sufficient and doesn't seem to break anything.  If no one can explain why it should remain, I'll check in the changes this weekend.
-------------------------------------------------------

Date: 2000-Nov-08 12:24
By: fdrake

Comment:
I've removed the test in configure.in revision 1.179 and the symbol definition from config.h.in revision 2.79.
-------------------------------------------------------

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


From noreply@sourceforge.net  Wed Nov  8 20:29:08 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 8 Nov 2000 12:29:08 -0800
Subject: [Python-bugs-list] [Bug #119883] smtplib.py can leak file descriptors
Message-ID: <200011082029.MAA18837@sf-web2.i.sourceforge.net>

Bug #119883, was updated on 2000-Oct-31 08:35
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: smtplib.py can leak file descriptors

Details: If the socket.connect() fails in SMTP.connect() in smtplib.py, file descriptors are leaked.  Patch #102185 fixes this.

Follow-Ups:

Date: 2000-Nov-08 12:29
By: fdrake

Comment:
I accepted the patch last week; please check it in and close this bug.
-------------------------------------------------------

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


From noreply@sourceforge.net  Wed Nov  8 22:21:30 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 8 Nov 2000 14:21:30 -0800
Subject: [Python-bugs-list] [Bug #119883] smtplib.py can leak file descriptors
Message-ID: <200011082221.OAA24454@sf-web3.vaspecialprojects.com>

Bug #119883, was updated on 2000-Oct-31 08:35
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: smtplib.py can leak file descriptors

Details: If the socket.connect() fails in SMTP.connect() in smtplib.py, file descriptors are leaked.  Patch #102185 fixes this.

Follow-Ups:

Date: 2000-Nov-08 12:29
By: fdrake

Comment:
I accepted the patch last week; please check it in and close this bug.
-------------------------------------------------------

Date: 2000-Nov-08 14:21
By: bwarsaw

Comment:
Fixed by application of patch #102185 in smtplib.py 1.30
-------------------------------------------------------

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


From noreply@sourceforge.net  Thu Nov  9 06:34:44 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 8 Nov 2000 22:34:44 -0800
Subject: [Python-bugs-list] [Bug #117178] Documentation missing for __iadd__, __isub__, etc.
Message-ID: <200011090634.WAA30457@sf-web3.vaspecialprojects.com>

Bug #117178, was updated on 2000-Oct-18 06:48
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Documentation missing for __iadd__, __isub__, etc.

Details: I understand that __iadd__, __isub__, etc. are the
functions you have to implement in a class for it to
support augmented assignment, but there is no documentation
for them under the 3.3 Special Method Names section. I
searched under the Doc directory for __isub__ and found
nothing at all.


Follow-Ups:

Date: 2000-Oct-30 05:03
By: twouters

Comment:
Sorry, my fault. I wasn't thorough enough in my attempts to write documentation and finding the right place to add it in the current layout. I've submitted a patch, #110216, to fix this.

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

Date: 2000-Nov-08 22:34
By: fdrake

Comment:
The right patch number is #102169.

I've sent the patch back to Thomas for revision, but there's been no activity on it.  I'm adding this note so I don't lose track of this.
-------------------------------------------------------

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


From noreply@sourceforge.net  Thu Nov  9 06:35:43 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 8 Nov 2000 22:35:43 -0800
Subject: [Python-bugs-list] [Bug #121672] Documentation which needs updating to 2.0
Message-ID: <200011090635.WAA30468@sf-web3.vaspecialprojects.com>

Bug #121672, was updated on 2000-Nov-05 08:27
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Documentation which needs updating to 2.0

Details: When describing formatting strings while "%s" is described, the new "%r" is not.

Built in function int(val [, radix])  Radix may be 0 in which case it works like string.atoi used to (looks at start of string, if 0x hex, if 0 octal otherwise decimal, or something close)

long(), like int() has an optional radix parameter


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


From noreply@sourceforge.net  Thu Nov  9 06:38:35 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 8 Nov 2000 22:38:35 -0800
Subject: [Python-bugs-list] [Bug #121671] bad link David Ascher's compile.py script
Message-ID: <200011090638.WAA30505@sf-web3.vaspecialprojects.com>

Bug #121671, was updated on 2000-Nov-05 08:16
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: bad link David Ascher's compile.py script 

Details: The document "Extending and Embedding the Python Interpreter, October 16, 2000, Release 2.0", at

http://www.python.org/doc/current/ext/win-cookbook.html

contains a bad link to bad link David Ascher's compile.py script; the link is to http://starship.python.net/crew/da/compile/ 
but this URL doesn't work (it redirects to one that
refuses connections).

It'd be great if someone could put compile.py someplace
accessible and fix this link!

--Mark


Follow-Ups:

Date: 2000-Nov-08 22:38
By: fdrake

Comment:
This is a known problem.  I have a copy of the script, but I need someone to test it to make sure it works with Python 2.0.  Another possibility is to push the Distutils tools; that may be a better option at this point.
-------------------------------------------------------

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


From noreply@sourceforge.net  Thu Nov  9 10:00:43 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 9 Nov 2000 02:00:43 -0800
Subject: [Python-bugs-list] [Bug #119960] Encoding bugs.
Message-ID: <200011091000.CAA31384@sf-web1.i.sourceforge.net>

Bug #119960, was updated on 2000-Oct-31 13:38
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Open
Resolution: None
Bug Group: None
Priority: 3
Summary: Encoding bugs.

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

Follow-Ups:

Date: 2000-Nov-01 08:00
By: jhylton

Comment:
I am not entirely sure what the bug is, though I agree that it can be confusing to deal with Unicode strings.

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

Date: 2000-Nov-01 12:47
By: lemburg

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

Date: 2000-Nov-01 13:16
By: kirill_simonov

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

Date: 2000-Nov-03 12:49
By: gvanrossum

Comment:
Assigned to Marc-Andre, since I have no idea what to do about this... :-(
-------------------------------------------------------

Date: 2000-Nov-09 02:00
By: lemburg

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

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

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


From noreply@sourceforge.net  Thu Nov  9 17:50:24 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 9 Nov 2000 09:50:24 -0800
Subject: [Python-bugs-list] [Bug #122070] rfc822.py unprotected call to tell() fails in Win32
Message-ID: <200011091750.JAA06543@sf-web3.vaspecialprojects.com>

Bug #122070, was updated on 2000-Nov-09 09:50
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: rfc822.py unprotected call to tell() fails in Win32

Details: In the Python 2.0 rfc822.py module, there are 4 calls to tell() methods. 3 of the calls are protected inside try/except statements (as if someone expected there might be problems), 1 isn't.  

When running under Win32 Apache 1.3.14, with the environment variable PYTHONUNBUFFERED set to 1 (so cgi.py can read forms properly), cgi.py calls rfc822.py, which succeeds in calling the first tell() to see if teh file is seekable, and the 2nd tell to fetch self.startofbody, it then calls the readheaders() method, which successfully calls tell() one time, reads the line, and dies on the next call to tell() with an IOError exception.

I've tried to reproduce this outside of the Apache/cgi environment, but haven't succeded yet.  I'm assuming this is a problem in the C runtime, and the easiest fix might be to just wrap up the bare call to tell() in a try/except wrapper like the other three.

So my suggestion is to replace the line in rfc822.py:
  
   startofline = tell()

with:

    try:
        startofline = tell()
    except IOError:
        startofline = tell = None
        self.seekable = 0

which seems to work ok, and is consistent with the other usages of tell() in that particular module.

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


From noreply@sourceforge.net  Thu Nov  9 18:05:50 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 9 Nov 2000 10:05:50 -0800
Subject: [Python-bugs-list] [Bug #122070] rfc822.py unprotected call to tell() fails in Win32
Message-ID: <200011091805.KAA05670@sf-web1.i.sourceforge.net>

Bug #122070, was updated on 2000-Nov-09 09:50
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: rfc822.py unprotected call to tell() fails in Win32

Details: In the Python 2.0 rfc822.py module, there are 4 calls to tell() methods. 3 of the calls are protected inside try/except statements (as if someone expected there might be problems), 1 isn't.  

When running under Win32 Apache 1.3.14, with the environment variable PYTHONUNBUFFERED set to 1 (so cgi.py can read forms properly), cgi.py calls rfc822.py, which succeeds in calling the first tell() to see if teh file is seekable, and the 2nd tell to fetch self.startofbody, it then calls the readheaders() method, which successfully calls tell() one time, reads the line, and dies on the next call to tell() with an IOError exception.

I've tried to reproduce this outside of the Apache/cgi environment, but haven't succeded yet.  I'm assuming this is a problem in the C runtime, and the easiest fix might be to just wrap up the bare call to tell() in a try/except wrapper like the other three.

So my suggestion is to replace the line in rfc822.py:
  
   startofline = tell()

with:

    try:
        startofline = tell()
    except IOError:
        startofline = tell = None
        self.seekable = 0

which seems to work ok, and is consistent with the other usages of tell() in that particular module.

Follow-Ups:

Date: 2000-Nov-09 10:05
By: gvanrossum

Comment:
Agreed with your analysis.  Checked in the change into the CVS tree.  Case closed.
-------------------------------------------------------

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


From noreply@sourceforge.net  Thu Nov  9 19:54:24 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 9 Nov 2000 11:54:24 -0800
Subject: [Python-bugs-list] [Bug #121654] sre regex () groups have strong memory
Message-ID: <200011091954.LAA08349@sf-web3.vaspecialprojects.com>

Bug #121654, was updated on 2000-Nov-05 00:17
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: sre regex () groups have strong memory

Details: The new re module (sre) has a problem with () grouping.
It seems () groups sometimes "remember" the previous
match.  Try the following:


#!/usr/bin/python

"""
	This module parses a CSV string and produces a list whose
	elements are the Comma-Seperated Values.  myCSV uses Python's
	regular expression matching.  The search pattern uses three
	groups of ().  findall() returns a list of tuples containing
	three elements--the results of the search groups.  The lambda
	function returns the correct element of the three.

        For more info on regular expressions see:
            Mastering Regular Expressions
            Jeffrey E. F. Friedl
            O'Reilly Press

######################################################################
        Created:            23-Mar-2000
        Author:             David S. Alessio
        Last Modified:      $Modtime:$
        Last Modified by:   $Author:$
        Revision:           $Revision:$

	Revision History:
        $Log:$
######################################################################
"""

import re


class myCSV:
    def __init__(self):
        self.srchPat = '"([^"\\\\]*(\\\\.[^"\\\\]*)*)",?|([^,]+),?|,'
        self.srchProg = re.compile(self.srchPat)
    
    def __str2num(self, str):
        try:
            num = int(str)
        except:
            try:
                num = long(str)
            except:
                try:
                    num = float(str)
                except:
                    num = str
        return num

    def __pick_best_value(self, t):
        value = t[0] or t[2]
        return self.__str2num(value)
        
    def csv2list(self, str):
#       print self.srchProg.findall(str)
        return map(lambda t: t[0] or t[2], self.srchProg.findall(str))
        
    def csv2numlist(self, str):
        return map(self.__pick_best_value, self.srchProg.findall(str))

    def test(self):
        str = '1,2,3,"ab\\"c","de,f",name,"123",,,"xyz","","zzz"'
        tstnumlst = [1,2,3,'ab\\"c','de,f','name',123,'','','xyz','','zzz']
        list = self.csv2list(str)
        numlst = self.csv2numlist(str)
        print str
        print list
        print numlst
        print tstnumlst
#"""
        if tstnumlst != numlst:
            print "\nERROR:"
            if len(numlst) > len(tstnumlst):
                print 'NumList Too Long!!!'
            elif len(numlst) < len(tstnumlst):
                print 'NumList Too Short!!!'
            else:
                print '            Expected      Got'
                for i in xrange(len(tstnumlst)):
                    mark = ''
                    if tstnumlst[i] != numlst[i]:
                        mark = ' <==='
                    print 'L[%2d]: %10s %10s %s' % (i, tstnumlst[i], numlst[i], mark)
                    
        else:
            print 'OK'
#"""

if __name__ == '__main__':
    from sys import argv
    if len(argv) == 1:
        print 'Compiling CSV'
        x = myCSV();
        print 'Testing...'
        x.test()
    elif len(argv) == 2:
        fin = open(argv[1])
        x = myCSV();
        while 1:
            str = fin.readline()
            if not str: break
            csv = x.csv2numlist(str[:-1])
            print csv
    else:
        print 'Usage: %s [file.csv]' % argv[0]
		


Follow-Ups:

Date: 2000-Nov-09 11:54
By: effbot

Comment:
same as #117612
-------------------------------------------------------

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


From noreply@sourceforge.net  Fri Nov 10 10:43:08 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 Nov 2000 02:43:08 -0800
Subject: [Python-bugs-list] [Bug #122113] Mathematic operations fail on maximum negative integer
Message-ID: <200011101043.CAA15128@sf-web2.i.sourceforge.net>

Bug #122113, was updated on 2000-Nov-10 02:43
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Mathematic operations fail on maximum negative integer

Details: Python documentation states -2147483648 is the largest maximum negative integer value. When attempting mathematical comparisons on this value an overflow error is encountered. The following line will fail:
    if -2147483648 < 50:
        print 'broken'

However assigning this value to a variable and using the variable in the comparison will succeed as will the following:
    maximum = -2147483648
    int(maximum)
This was originally found in 1.5.2 but I have tested it in 2.0 and the problem is still present.

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


From noreply@sourceforge.net  Fri Nov 10 12:41:46 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 Nov 2000 04:41:46 -0800
Subject: [Python-bugs-list] [Bug #116547] test_poll.py fails on SPARCstation LX under Red Hat 5.2
Message-ID: <200011101241.EAA16570@sf-web2.i.sourceforge.net>

Bug #116547, was updated on 2000-Oct-10 15:02
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: test_poll.py fails on SPARCstation LX under Red Hat 5.2

Details: Attached is a traceback from running the test manually.

Running poll test 1
 This is a test.
 This is a test.
 This is a test.
 This is a test.
 This is a test.
 This is a test.
 This is a test.
 This is a test.
 This is a test.
 This is a test.
 This is a test.
 This is a test.
Traceback (most recent call last):
  File "./Lib/test/test_poll.py", line 171, in ?
    test_poll1()
  File "./Lib/test/test_poll.py", line 65, in test_poll1
    poll_unit_tests()
  File "./Lib/test/test_poll.py", line 77, in poll_unit_tests
    r = p.poll()
select.error: (9, 'Bad file descriptor')

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


From noreply@sourceforge.net  Fri Nov 10 13:14:11 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 Nov 2000 05:14:11 -0800
Subject: [Python-bugs-list] [Bug #122113] Mathematic operations fail on maximum negative integer
Message-ID: <200011101314.FAA17054@sf-web2.i.sourceforge.net>

Bug #122113, was updated on 2000-Nov-10 02:43
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 3
Summary: Mathematic operations fail on maximum negative integer

Details: Python documentation states -2147483648 is the largest maximum negative integer value. When attempting mathematical comparisons on this value an overflow error is encountered. The following line will fail:
    if -2147483648 < 50:
        print 'broken'

However assigning this value to a variable and using the variable in the comparison will succeed as will the following:
    maximum = -2147483648
    int(maximum)
This was originally found in 1.5.2 but I have tested it in 2.0 and the problem is still present.

Follow-Ups:

Date: 2000-Nov-10 05:14
By: gvanrossum

Comment:
Any expression involving -2147483648 (via a variable or otherwise) immediately raises OverflowError for me, as it should and as it explicitly is coded.

Are there other operations on integers that fail for you?

What platform are you using?  How many bits is a long int in C on that platform?

Does the test suite ("make test") complete without errors?

Did you build Python yourself or did you download a binary from somewhere?

Did you get any errors or warnings during building?

Assigned to Tim Peters, our expert on numerical conundrums.

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

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


From noreply@sourceforge.net  Fri Nov 10 13:41:51 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 Nov 2000 05:41:51 -0800
Subject: [Python-bugs-list] [Bug #122113] Mathematic operations fail on maximum negative integer
Message-ID: <200011101341.FAA19534@sf-web1.i.sourceforge.net>

Bug #122113, was updated on 2000-Nov-10 02:43
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 3
Summary: Mathematic operations fail on maximum negative integer

Details: Python documentation states -2147483648 is the largest maximum negative integer value. When attempting mathematical comparisons on this value an overflow error is encountered. The following line will fail:
    if -2147483648 < 50:
        print 'broken'

However assigning this value to a variable and using the variable in the comparison will succeed as will the following:
    maximum = -2147483648
    int(maximum)
This was originally found in 1.5.2 but I have tested it in 2.0 and the problem is still present.

Follow-Ups:

Date: 2000-Nov-10 05:14
By: gvanrossum

Comment:
Any expression involving -2147483648 (via a variable or otherwise) immediately raises OverflowError for me, as it should and as it explicitly is coded.

Are there other operations on integers that fail for you?

What platform are you using?  How many bits is a long int in C on that platform?

Does the test suite ("make test") complete without errors?

Did you build Python yourself or did you download a binary from somewhere?

Did you get any errors or warnings during building?

Assigned to Tim Peters, our expert on numerical conundrums.

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

Date: 2000-Nov-10 05:41
By: rhathaway

Comment:
Its just a guess but I think I should have added slightly more information on the bug -> I'll remember for the future ;-)

The heart of the problem is that the int() function works with -2147483648 but mathematical operations do not. Should the maximum number be -2147483648 or -2147483647 -> Python appears to be unsure atm. Basically I receive a value in a string and I need to convert it into an appropriate Python type to work with it. To do this I am currently issuing an int(stringValue) and trapping on Value error at which point I attempt to convert it to a long. Now the int works with 
-2147483648 so the value is converted to an int type but the subsequent less than check fails.

The problem only occurs with this single value at the very bottom of the integer range. I have not come across any other values that cause similar problems.

I have tested this problem in both 1.5.2 and 2.0 (Python on both Windows 98 and on Solaris 2.7. The windows Python installation was from the self installing exe downloaded from the python website. The solaris install was built from the tar file downloaded from the python website. No installation problems were encountered in any of the installs and the test suite make works fine.

Hopefully this should help to clarify the issue I have raised

Kind regards

Rob
-------------------------------------------------------

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


From noreply@sourceforge.net  Fri Nov 10 18:17:37 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 Nov 2000 10:17:37 -0800
Subject: [Python-bugs-list] [Bug #122113] Mathematic operations fail on maximum negative integer
Message-ID: <200011101817.KAA25240@sf-web3.vaspecialprojects.com>

Bug #122113, was updated on 2000-Nov-10 02:43
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 3
Summary: Mathematic operations fail on maximum negative integer

Details: Python documentation states -2147483648 is the largest maximum negative integer value. When attempting mathematical comparisons on this value an overflow error is encountered. The following line will fail:
    if -2147483648 < 50:
        print 'broken'

However assigning this value to a variable and using the variable in the comparison will succeed as will the following:
    maximum = -2147483648
    int(maximum)
This was originally found in 1.5.2 but I have tested it in 2.0 and the problem is still present.

Follow-Ups:

Date: 2000-Nov-10 05:14
By: gvanrossum

Comment:
Any expression involving -2147483648 (via a variable or otherwise) immediately raises OverflowError for me, as it should and as it explicitly is coded.

Are there other operations on integers that fail for you?

What platform are you using?  How many bits is a long int in C on that platform?

Does the test suite ("make test") complete without errors?

Did you build Python yourself or did you download a binary from somewhere?

Did you get any errors or warnings during building?

Assigned to Tim Peters, our expert on numerical conundrums.

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

Date: 2000-Nov-10 05:41
By: rhathaway

Comment:
Its just a guess but I think I should have added slightly more information on the bug -> I'll remember for the future ;-)

The heart of the problem is that the int() function works with -2147483648 but mathematical operations do not. Should the maximum number be -2147483648 or -2147483647 -> Python appears to be unsure atm. Basically I receive a value in a string and I need to convert it into an appropriate Python type to work with it. To do this I am currently issuing an int(stringValue) and trapping on Value error at which point I attempt to convert it to a long. Now the int works with 
-2147483648 so the value is converted to an int type but the subsequent less than check fails.

The problem only occurs with this single value at the very bottom of the integer range. I have not come across any other values that cause similar problems.

I have tested this problem in both 1.5.2 and 2.0 (Python on both Windows 98 and on Solaris 2.7. The windows Python installation was from the self installing exe downloaded from the python website. The solaris install was built from the tar file downloaded from the python website. No installation problems were encountered in any of the installs and the test suite make works fine.

Hopefully this should help to clarify the issue I have raised

Kind regards

Rob
-------------------------------------------------------

Date: 2000-Nov-10 10:17
By: tim_one

Comment:
Rob, please post a specific line of actual Python code that fails for you, self-contained and without trying to explain it to us <wink>.

The literal -2147483648 in a Python program on a 32-bit machine *should* raise OverflowError at compile-time.  Here's an actual screen dump (from IDLE) showing this:

>>> x = -2147483648
OverflowError: integer literal too large
>>>

For that reason, none of your examples make sense:  if we try *any* of them, they simply die with the same kind of OverflowError.

Note however that this does *not* fail:

>>> x = int("-2147483648")
>>> x
-2147483648
>>>

The difference in behavior here is unfortunate, but is a fact of life:  in the case of a literal appearing within Python program text, Python's grammar does not consider the leading "-" to be part of the literal.  -4 is actually read by Python as applying the unary negation operator to the positive integer 4.  That's why -2147483648 *as a literal* blows up:  the 2147483648 part alone is too large.  In the case of int(string), the string is parsed as a whole by a C library routine, which knows what to do with "-2147483648".

As to your test case:

if -2147483648 < 50: print 'broken' 

First, let's actually run it:

>>> if -2147483648 < 50: print 'broken'
OverflowError: integer literal too large
>>>

As explained above, that's exactly what's expected.  Second, let's try it via int(string) instead:

>>> if int("-2147483648") < 50: print 'broken'

broken
>>>

Yes, it prints "broken", but that's what it SHOULD print:  if you agree that 0 < 50, and that -1 < 50, then certainly you must agree that -2147483648 < 50 is correct too.

In short, I don't see any bug here, and suspect you're wrestling with illusions.  Unless you can give us a specific piece of runnable self-contained Python code that shows a bug, I'll just close this report as a Not-a-Bug.

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

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


From noreply@sourceforge.net  Fri Nov 10 18:53:40 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 Nov 2000 10:53:40 -0800
Subject: [Python-bugs-list] [Bug #119960] Encoding bugs.
Message-ID: <200011101853.KAA25795@sf-web3.vaspecialprojects.com>

Bug #119960, was updated on 2000-Oct-31 13:38
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Open
Resolution: None
Bug Group: None
Priority: 3
Summary: Encoding bugs.

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

Follow-Ups:

Date: 2000-Nov-01 08:00
By: jhylton

Comment:
I am not entirely sure what the bug is, though I agree that it can be confusing to deal with Unicode strings.

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

Date: 2000-Nov-01 12:47
By: lemburg

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

Date: 2000-Nov-01 13:16
By: kirill_simonov

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

Date: 2000-Nov-03 12:49
By: gvanrossum

Comment:
Assigned to Marc-Andre, since I have no idea what to do about this... :-(
-------------------------------------------------------

Date: 2000-Nov-09 02:00
By: lemburg

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

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

Date: 2000-Nov-10 10:53
By: kirill_simonov

Comment:
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"
[...]

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

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


From noreply@sourceforge.net  Fri Nov 10 18:56:02 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 Nov 2000 10:56:02 -0800
Subject: [Python-bugs-list] [Bug #119483] OpenBSD can't dynamically load modules
Message-ID: <200011101856.KAA22368@sf-web2.i.sourceforge.net>

Bug #119483, was updated on 2000-Oct-26 14:11
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Duplicate
Bug Group: Platform-specific
Priority: 5
Summary: OpenBSD can't dynamically load modules

Details: 
On OpenBSD, one always gets a traceback trying to import a '.so' module (replacing blahblahblah with module name):

ImportError: dynamic module does not define init function (initblahblahblah)

The problem is that dynload_shlib.c doesn't prepend an underscore to the symbol name (the C standard for naming function exports). Some OS's will try both the name with and without the underscore, some try only the literal symbol name when calling dlsym. OpenBSD requires the literal symbol. Hence, the following patch is in order:

--- dynload_shlib.c    Thu Oct 26 11:10:36 2000
+++ dynload_shlib.c     Thu Oct 26 11:10:51 2000
@@ -55,7 +55,7 @@
        }
 
        /* ### should there be a leading underscore for some platforms? */
-       sprintf(funcname, "init%.200s", shortname);
+       sprintf(funcname, "_init%.200s", shortname);
 
        if (fp != NULL) {
                int i;


Follow-Ups:

Date: 2000-Oct-26 14:15
By: gvanrossum

Comment:
This was reported before. I just fixed this 1-2 days ago in the CvS tree.
-------------------------------------------------------

Date: 2000-Nov-10 10:56
By: none

Comment:
This is a problem with a.out versions of NetBSD also.
However, the ELF versions of NetBSD can use the __ELF__
define to manage the problem. here is a patchfile which handles both a.out and ELF versions of NetBSD:

--- dynload_shlib.c.org Wed Nov  8 20:01:21 2000
+++ dynload_shlib.c     Wed Nov  8 20:38:49 2000
@@ -55,7 +55,11 @@
        }
 
        /* ### should there be a leading underscore for some platforms? */
-       sprintf(funcname, "init%.200s", shortname);
+#ifndef __ELF__
+       sprintf(funcname, "_init%.200s", shortname);
+#else
+        sprintf(funcname, "init%.200s", shortname);
+#endif
 
        if (fp != NULL) {
                int i;

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

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


From noreply@sourceforge.net  Fri Nov 10 19:05:23 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 Nov 2000 11:05:23 -0800
Subject: [Python-bugs-list] [Bug #117402] Interpreter crashes when str or repr called with an array
Message-ID: <200011101905.LAA22497@sf-web2.i.sourceforge.net>

Bug #117402, was updated on 2000-Oct-22 02:16
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 7
Summary: Interpreter crashes when str or repr called with an array

Details: With Python 2.0 Final Release,


>>> from array import array
>>> z=array('c','hello world')
>>> `z`  #Note that these are back-quotes

It returns a nice "python20.dll" error with a page fault
, whereas run on python 1.6, it returns what we expect,
the string form of the array. (On Unix System V, it
produced a segmentation fault)




Follow-Ups:

Date: 2000-Nov-10 11:05
By: tim_one

Comment:
Fixed and Closed.  Checkin comment for arraymodule.c (new rev 2.59):

Fix for SF bug 117402, crashes on str(array) and repr(array).  This was an unfortunate consequence of somebody switching from PyArg_Parse to PyArg_ParseTuple but without changing the argument from a NULL to a tuple.
-------------------------------------------------------

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


From noreply@sourceforge.net  Fri Nov 10 19:10:44 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 Nov 2000 11:10:44 -0800
Subject: [Python-bugs-list] [Bug #119483] OpenBSD can't dynamically load modules
Message-ID: <200011101910.LAA26033@sf-web3.vaspecialprojects.com>

Bug #119483, was updated on 2000-Oct-26 14:11
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: Duplicate
Bug Group: Platform-specific
Priority: 5
Summary: OpenBSD can't dynamically load modules

Details: 
On OpenBSD, one always gets a traceback trying to import a '.so' module (replacing blahblahblah with module name):

ImportError: dynamic module does not define init function (initblahblahblah)

The problem is that dynload_shlib.c doesn't prepend an underscore to the symbol name (the C standard for naming function exports). Some OS's will try both the name with and without the underscore, some try only the literal symbol name when calling dlsym. OpenBSD requires the literal symbol. Hence, the following patch is in order:

--- dynload_shlib.c    Thu Oct 26 11:10:36 2000
+++ dynload_shlib.c     Thu Oct 26 11:10:51 2000
@@ -55,7 +55,7 @@
        }
 
        /* ### should there be a leading underscore for some platforms? */
-       sprintf(funcname, "init%.200s", shortname);
+       sprintf(funcname, "_init%.200s", shortname);
 
        if (fp != NULL) {
                int i;


Follow-Ups:

Date: 2000-Oct-26 14:15
By: gvanrossum

Comment:
This was reported before. I just fixed this 1-2 days ago in the CvS tree.
-------------------------------------------------------

Date: 2000-Nov-10 10:56
By: none

Comment:
This is a problem with a.out versions of NetBSD also.
However, the ELF versions of NetBSD can use the __ELF__
define to manage the problem. here is a patchfile which handles both a.out and ELF versions of NetBSD:

--- dynload_shlib.c.org Wed Nov  8 20:01:21 2000
+++ dynload_shlib.c     Wed Nov  8 20:38:49 2000
@@ -55,7 +55,11 @@
        }
 
        /* ### should there be a leading underscore for some platforms? */
-       sprintf(funcname, "init%.200s", shortname);
+#ifndef __ELF__
+       sprintf(funcname, "_init%.200s", shortname);
+#else
+        sprintf(funcname, "init%.200s", shortname);
+#endif
 
        if (fp != NULL) {
                int i;

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

Date: 2000-Nov-10 11:10
By: gvanrossum

Comment:
Could someone check that this patch also works for OpenBSD?
Then I could remove the current OpenBSD specific hack.

Of course there are other considerations too: are there systems that don't use __ELF__ but that also don't need the leading underscore? If so, the patch would break those platforms...
-------------------------------------------------------

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


From noreply@sourceforge.net  Fri Nov 10 19:17:28 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 Nov 2000 11:17:28 -0800
Subject: [Python-bugs-list] [Bug #117092] Testsuite dumps core on Win2000 / IDLE
Message-ID: <200011101917.LAA22678@sf-web2.i.sourceforge.net>

Bug #117092, was updated on 2000-Oct-17 08:59
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: Fixed
Bug Group: Platform-specific
Priority: 7
Summary: Testsuite dumps core on Win2000 / IDLE

Details: On a fresh installation of Python2.0 under Win2k, when running test.testall I get an "ApplicationError". The last test output is:

test_array
*****************************
array after append: <--[ApplicationError dialog appears]


Follow-Ups:

Date: 2000-Nov-10 11:17
By: tim_one

Comment:
Fixed and Closed.  This was due to a bug in the array module (see SF bug 117402).

However, note that the test suite was not meant to be run from within IDLE, and in particular when you get to the thread test IDLE will hang.

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

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


From noreply@sourceforge.net  Fri Nov 10 20:51:30 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 Nov 2000 12:51:30 -0800
Subject: [Python-bugs-list] [Bug #110843] Low FD_SETSIZE limit on Win32 (PR#41)
Message-ID: <200011102051.MAA24140@sf-web2.i.sourceforge.net>

Bug #110843, was updated on 2000-Aug-01 14:15
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 3
Summary: Low FD_SETSIZE limit on Win32 (PR#41)

Details: Jitterbug-Id: 41
Submitted-By: brian@digicool.com
Date: Fri, 30 Jul 1999 10:10:49 -0400 (EDT)
Version: 1.5.2
OS: NT


It appears that win32 has a default limit of 64 descriptors that 
can be handed to the select() function. This is pretty low for
any serious async servers, and causes them to raise lots of errors
under very moderate loads.

We at DC ran into this using Medusa as a basis for ZServer, which
serves Zope sites. It turns out that you can actually add a define
when compiling the python15.dll for windows to bump the default
fd limit to a more reasonable level.

The approach _I_ took was to add the define: FD_SETSIZE=1024
to the preprocessor options in the MSVC project settings for
python15.dll, though I imagine you could also roll the define
into config.h or something (so long as it's defined before
windows.h or any of the select / socket include files are
referenced). It would make life much easier for win32 server
developers if this define could find its way into the next
official python release :^)

Thanks!


Brian Lloyd        brian@digicool.com
Software Engineer  540.371.6909              
Digital Creations  http://www.digicool.com 




====================================================================
Audit trail:
Fri Jul 30 10:43:41 1999	guido	moved from incoming to request

Follow-Ups:

Date: 2000-Aug-30 23:19
By: mhammond

Comment:
I am a little worried that adding it to config.h may have side-effects when Python is embedded in other projects with their own socket config (eg, Mozilla :-)

Now that socket and select are external .pyd modules, will it be sufficient to only add it to these extension modules?
-------------------------------------------------------

Date: 2000-Sep-21 21:16
By: tim_one

Comment:
Changed summary to say "Win32" instead of "NT", as this is a general Win32 issue.

Mark, did you email your question directly to Brian?  (This bug got moved over from Jitterbug, so he didn't see your note otherwise.)

I certainly agree Python can't go changing the MS default value in any way visible from Python.h (which #includes config.h).
-------------------------------------------------------

Date: 2000-Oct-05 21:11
By: mhammond

Comment:
Brian has agreed to help with a specific patch that will remain local to the Python build.  Dropping priority to reflect that it wont affect most users, and wont make 2.0.
-------------------------------------------------------

Date: 2000-Nov-10 12:51
By: tim_one

Comment:
Mark, Guido is agreeable to Python adding its own

#ifndef FD_SETSIZE
#define FD_SETSIZE ???
#endif

block.  If other people are doing the define-this-thing-on-the-cmdline trick, fine, such a block won't interfere with their beliefs.

So the primary remaining question is what "???" should be.  Is 1024 enough?  Someone else just bumped into the 64 limit (Python-Help), but didn't commit to a specific amount.
-------------------------------------------------------

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


From noreply@sourceforge.net  Fri Nov 10 22:22:36 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 Nov 2000 14:22:36 -0800
Subject: [Python-bugs-list] [Bug #122162] split is broken for unicode strings
Message-ID: <200011102222.OAA25532@sf-web2.i.sourceforge.net>

Bug #122162, was updated on 2000-Nov-10 14:22
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: split is broken for unicode strings

Details: Calling the split method on a unicode string or with a unicode string is broken if the substring being split on is at the end of the source string. 

Example:

Python 2.0 (#8, Oct 16 2000, 17:27:58) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
IDLE 0.6 -- press F1 for help
>>> a = 'border case test'
>>> a.split('test')
['border case ', '']
>>> a.split(u'test')
[u'border case test']
>>> u = u'border case test'
>>> u.split('test')
[u'border case test']
>>> u.split(u'test')
[u'border case test']

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


From noreply@sourceforge.net  Fri Nov 10 23:03:18 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 Nov 2000 15:03:18 -0800
Subject: [Python-bugs-list] [Bug #122162] split is broken for unicode strings
Message-ID: <200011102303.PAA26109@sf-web2.i.sourceforge.net>

Bug #122162, was updated on 2000-Nov-10 14:22
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: split is broken for unicode strings

Details: Calling the split method on a unicode string or with a unicode string is broken if the substring being split on is at the end of the source string. 

Example:

Python 2.0 (#8, Oct 16 2000, 17:27:58) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
IDLE 0.6 -- press F1 for help
>>> a = 'border case test'
>>> a.split('test')
['border case ', '']
>>> a.split(u'test')
[u'border case test']
>>> u = u'border case test'
>>> u.split('test')
[u'border case test']
>>> u.split(u'test')
[u'border case test']

Follow-Ups:

Date: 2000-Nov-10 15:03
By: gvanrossum

Comment:
Indeed.  This only seems to be a problem if

1) the split arg is longer than 1 char
2) the split arg doesn't occur at all

Probably a boundary case in the Unicode split. Assigned to Marc-Andre.
-------------------------------------------------------

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


From noreply@sourceforge.net  Fri Nov 10 23:27:09 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 Nov 2000 15:27:09 -0800
Subject: [Python-bugs-list] [Bug #110843] Low FD_SETSIZE limit on Win32 (PR#41)
Message-ID: <200011102327.PAA28439@sf-web1.i.sourceforge.net>

Bug #110843, was updated on 2000-Aug-01 14:15
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 3
Summary: Low FD_SETSIZE limit on Win32 (PR#41)

Details: Jitterbug-Id: 41
Submitted-By: brian@digicool.com
Date: Fri, 30 Jul 1999 10:10:49 -0400 (EDT)
Version: 1.5.2
OS: NT


It appears that win32 has a default limit of 64 descriptors that 
can be handed to the select() function. This is pretty low for
any serious async servers, and causes them to raise lots of errors
under very moderate loads.

We at DC ran into this using Medusa as a basis for ZServer, which
serves Zope sites. It turns out that you can actually add a define
when compiling the python15.dll for windows to bump the default
fd limit to a more reasonable level.

The approach _I_ took was to add the define: FD_SETSIZE=1024
to the preprocessor options in the MSVC project settings for
python15.dll, though I imagine you could also roll the define
into config.h or something (so long as it's defined before
windows.h or any of the select / socket include files are
referenced). It would make life much easier for win32 server
developers if this define could find its way into the next
official python release :^)

Thanks!


Brian Lloyd        brian@digicool.com
Software Engineer  540.371.6909              
Digital Creations  http://www.digicool.com 




====================================================================
Audit trail:
Fri Jul 30 10:43:41 1999	guido	moved from incoming to request

Follow-Ups:

Date: 2000-Aug-30 23:19
By: mhammond

Comment:
I am a little worried that adding it to config.h may have side-effects when Python is embedded in other projects with their own socket config (eg, Mozilla :-)

Now that socket and select are external .pyd modules, will it be sufficient to only add it to these extension modules?
-------------------------------------------------------

Date: 2000-Sep-21 21:16
By: tim_one

Comment:
Changed summary to say "Win32" instead of "NT", as this is a general Win32 issue.

Mark, did you email your question directly to Brian?  (This bug got moved over from Jitterbug, so he didn't see your note otherwise.)

I certainly agree Python can't go changing the MS default value in any way visible from Python.h (which #includes config.h).
-------------------------------------------------------

Date: 2000-Oct-05 21:11
By: mhammond

Comment:
Brian has agreed to help with a specific patch that will remain local to the Python build.  Dropping priority to reflect that it wont affect most users, and wont make 2.0.
-------------------------------------------------------

Date: 2000-Nov-10 12:51
By: tim_one

Comment:
Mark, Guido is agreeable to Python adding its own

#ifndef FD_SETSIZE
#define FD_SETSIZE ???
#endif

block.  If other people are doing the define-this-thing-on-the-cmdline trick, fine, such a block won't interfere with their beliefs.

So the primary remaining question is what "???" should be.  Is 1024 enough?  Someone else just bumped into the 64 limit (Python-Help), but didn't commit to a specific amount.
-------------------------------------------------------

Date: 2000-Nov-10 15:27
By: none

Comment:
I recently raised this in the help desk for python. 
I am running into this in the WInsock arena and I really want to get over this hump. Can I get a Python dll with 1024 sockets in 1.5.2? I would be happy to test this in the Win2k arena for you (like that is a major gold star).

Really even 256 would be ok for me .. but 1024 is a spot more attractive (as I wouldn't have to keep watch on this all the time). Many thanks to Martin von Loewis and Tim Peters for thier help.


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

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


From noreply@sourceforge.net  Sat Nov 11 01:40:06 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 Nov 2000 17:40:06 -0800
Subject: [Python-bugs-list] [Bug #122168] Does not compile on RH 7.0
Message-ID: <200011110140.RAA29893@sf-web1.i.sourceforge.net>

Bug #122168, was updated on 2000-Nov-10 17:40
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Does not compile on RH 7.0

Details: Just another program which seems not to compile under RH7.0. The following output occurs:

cd Parser ; make OPT="-g -O2 -Wall -Wstrict-prototypes" VERSION="2.0" \
		prefix="/usr/local" exec_prefix="/usr/local" all
make[1]: Wechsel in das Verzeichnis Verzeichnis »/usr/src/redhat/BUILD/Python-2.0/Parser«
gcc -g -O2 -Wall -Wstrict-prototypes -I./../Include -I.. -DHAVE_CONFIG_H   -c -o pgenmain.o pgenmain.c
gcc -g -O2 -Wall -Wstrict-prototypes -I./../Include -I.. -DHAVE_CONFIG_H   -c -o acceler.o acceler.c
gcc -g -O2 -Wall -Wstrict-prototypes -I./../Include -I.. -DHAVE_CONFIG_H   -c -o grammar1.o grammar1.c
gcc -g -O2 -Wall -Wstrict-prototypes -I./../Include -I.. -DHAVE_CONFIG_H   -c -o listnode.o listnode.c
gcc -g -O2 -Wall -Wstrict-prototypes -I./../Include -I.. -DHAVE_CONFIG_H   -c -o node.o node.c
In file included from ../Include/Python.h:54,
                 from node.c:3:
../Include/pyport.h:390:2: #error "LONG_BIT definition appears wrong for platform (bad gcc config?)."
make[1]: *** [node.o] Fehler 1
make[1]: Verlassen des Verzeichnisses Verzeichnis »/usr/src/redhat/BUILD/Python-2.0/Parser«
make: *** [Parser] Fehler 2


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


From noreply@sourceforge.net  Sat Nov 11 11:00:54 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 11 Nov 2000 03:00:54 -0800
Subject: [Python-bugs-list] [Bug #122176] Error in rotor module documentation
Message-ID: <200011111100.DAA03759@sf-web3.vaspecialprojects.com>

Bug #122176, was updated on 2000-Nov-11 03:00
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Error in rotor module documentation

Details: A minor error in the description of the "decrypt" and "decryptmore" methods in the rotor module documentation :

decrypt (ciphertext) 
     Reset the rotor object to its initial state and decrypt ciphertext, returning a string containing the ciphertext. The plaintext string will always be the same length as the ciphertext. 

decryptmore (ciphertext) 
     Decrypt ciphertext without resetting the rotor object, and return a string containing the ciphertext. 

In both cases the returned string is the *clear text*, not the *ciphertext* (fortunately enough :-)

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


From noreply@sourceforge.net  Sat Nov 11 18:06:01 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 11 Nov 2000 10:06:01 -0800
Subject: [Python-bugs-list] [Bug #122176] Error in rotor module documentation
Message-ID: <200011111806.KAA09003@sf-web3.vaspecialprojects.com>

Bug #122176, was updated on 2000-Nov-11 03:00
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Error in rotor module documentation

Details: A minor error in the description of the "decrypt" and "decryptmore" methods in the rotor module documentation :

decrypt (ciphertext) 
     Reset the rotor object to its initial state and decrypt ciphertext, returning a string containing the ciphertext. The plaintext string will always be the same length as the ciphertext. 

decryptmore (ciphertext) 
     Decrypt ciphertext without resetting the rotor object, and return a string containing the ciphertext. 

In both cases the returned string is the *clear text*, not the *ciphertext* (fortunately enough :-)

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


From noreply@sourceforge.net  Sat Nov 11 18:09:55 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 11 Nov 2000 10:09:55 -0800
Subject: [Python-bugs-list] [Bug #122168] Does not compile on RH 7.0
Message-ID: <200011111809.KAA09050@sf-web3.vaspecialprojects.com>

Bug #122168, was updated on 2000-Nov-10 17:40
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Invalid
Bug Group: Platform-specific
Priority: 5
Summary: Does not compile on RH 7.0

Details: Just another program which seems not to compile under RH7.0. The following output occurs:

cd Parser ; make OPT="-g -O2 -Wall -Wstrict-prototypes" VERSION="2.0" \
		prefix="/usr/local" exec_prefix="/usr/local" all
make[1]: Wechsel in das Verzeichnis Verzeichnis »/usr/src/redhat/BUILD/Python-2.0/Parser«
gcc -g -O2 -Wall -Wstrict-prototypes -I./../Include -I.. -DHAVE_CONFIG_H   -c -o pgenmain.o pgenmain.c
gcc -g -O2 -Wall -Wstrict-prototypes -I./../Include -I.. -DHAVE_CONFIG_H   -c -o acceler.o acceler.c
gcc -g -O2 -Wall -Wstrict-prototypes -I./../Include -I.. -DHAVE_CONFIG_H   -c -o grammar1.o grammar1.c
gcc -g -O2 -Wall -Wstrict-prototypes -I./../Include -I.. -DHAVE_CONFIG_H   -c -o listnode.o listnode.c
gcc -g -O2 -Wall -Wstrict-prototypes -I./../Include -I.. -DHAVE_CONFIG_H   -c -o node.o node.c
In file included from ../Include/Python.h:54,
                 from node.c:3:
../Include/pyport.h:390:2: #error "LONG_BIT definition appears wrong for platform (bad gcc config?)."
make[1]: *** [node.o] Fehler 1
make[1]: Verlassen des Verzeichnisses Verzeichnis »/usr/src/redhat/BUILD/Python-2.0/Parser«
make: *** [Parser] Fehler 2


Follow-Ups:

Date: 2000-Nov-11 10:09
By: gvanrossum

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

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

The solution is to download a valid version of GCC.

--Guido van Rossum
-------------------------------------------------------

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


From noreply@sourceforge.net  Sat Nov 11 21:52:24 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 11 Nov 2000 13:52:24 -0800
Subject: [Python-bugs-list] [Bug #116682] 2.0 stalls Mac on external drive
Message-ID: <200011112152.NAA08448@sf-web2.i.sourceforge.net>

Bug #116682, was updated on 2000-Oct-11 22:05
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Closed
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: 2.0 stalls Mac on external drive

Details: Both 2.0 and 1.52 cause problems when they are on an external drive. The machine boots fine on a cold boot, but on restart the alias in the extensions folder to Python core can't find the original file as the drive is not yet mounted and so the machine doesn't get past the Happy Mac. (This is on system 8.1). Perhaps it would work better if the original was in the system folder and the alias was in the Python folder?

Follow-Ups:

Date: 2000-Oct-13 16:46
By: jackjansen

Comment:
Various SIG users have tried to repeat this bug, but without success. However, as there are other problems with having the alias for PythonCore pointing to a different partition than the system disk (people have reported their applets not working, or working intermittently) the installer now detects this situation and offers to copy PythonCore in stead of aliasing it. That solution should fix this problem too.
-------------------------------------------------------

Date: 2000-Nov-11 13:52
By: jackjansen

Comment:
Never heard anything back from the original submittor, so I'll assume the copying of PythonCore has indeed
fixed the bug.
-------------------------------------------------------

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


From noreply@sourceforge.net  Sat Nov 11 22:16:35 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 11 Nov 2000 14:16:35 -0800
Subject: [Python-bugs-list] [Bug #115641] Dynamic Loading Fails on Mac OS X
Message-ID: <200011112216.OAA08725@sf-web2.i.sourceforge.net>

Bug #115641, was updated on 2000-Sep-29 00:20
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Dynamic Loading Fails on Mac OS X

Details: Martin v. Loewis asked me to report that dynamic loading fails on Mac OS X.  I was able to successfully build the CVS version of Python following the directions posted by Dan Wolfe to Python-Dev:

http://www.python.org/pipermail/python-dev/2000-September/016289.html

However, I had some problems compiling the CVS version of Python/XML and reported them as a bug to Source Forge:

https://sourceforge.net/bugs/?func=detailbug&group_id=6473&bug_id=115544

Martin pointed out "how distutils comes up with the linker line: They read the configure-generated Makefile and scan for LDSHARED. So anything that was in the Python Makefile will be used when linking a distutils module."  He aksed me to try to build Python a few different ways, but they all failed.

When configured with:

./configure -with-threads -with-dyld --with-next-framework -with-suffix=.exe

Building Python produced the following:

cd Modules ; make OPT="-g -O2 -fno-common" VERSION="2.0" \
                prefix="/usr/local" exec_prefix="/usr/local" all
make[2]: Nothing to be done for `all'.
libtool -o libpython2.0.dylib -dynamic  libpython2.0.a -framework System  
ld: for architecture ppc
ld: Undefined symbols:
restFP
saveFP
___eprintf
_environ
libtool: internal link edit command failed
make[1]: *** [libpython2.0.dylib] Error 1
make: *** [python.exe] Error 2

When line 579 in "configure" is modified to the following:

then LDSHARED='$(CC) $(LDFLAGS) -bundle -undefined suppress'

building Python results in the following:

for i in Parser Grammar Objects Python Modules; do \
                (cd $i; make VERSION="2.0" add2lib); done
make[2]: `add2lib' is up to date.
make[2]: Nothing to be done for `add2lib'.
make[2]: `add2lib' is up to date.
make[2]: `add2lib' is up to date.
make[2]: `add2lib' is up to date.
libtool -o libpython2.0.dylib -dynamic  libpython2.0.a -framework System  
ld: for architecture ppc
ld: Undefined symbols:
___eprintf
_environ
libtool: internal link edit command failed
make[1]: *** [libpython2.0.dylib] Error 1
make: *** [python.exe] Error 2

I have only been using Mac OS X for a few days (and the development tools even less), so this could definitely be due to user error, but I will help out however I can.



Follow-Ups:

Date: 2000-Nov-11 14:16
By: jackjansen

Comment:
Lots of work has been done (not by me:-) on MacOSX Python, and the problems in this
bug report appear to have been addressed in 2.0 final.
-------------------------------------------------------

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


From noreply@sourceforge.net  Sun Nov 12 04:26:23 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 11 Nov 2000 20:26:23 -0800
Subject: [Python-bugs-list] [Bug #122215] python will not build without --with-suffix on case insensitive filesystem
Message-ID: <200011120426.UAA12732@sf-web2.i.sourceforge.net>

Bug #122215, was updated on 2000-Nov-11 20:26
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: python will not build without --with-suffix on case insensitive filesystem

Details: Mac OSX as the option of being installed in HFS+, a case insensitive filesystem.

Under OSX on HFS+, one *must* use the --with-suffix to change the name of the compiled executable or the build fails.

However, it would be desirable to have the 'make install' still instal the binary as just plain 'python' without requiring manual step.

Maybe the top level Python directory could be renamed PyCore or something?

(Yes, this is an annoyance-- but case insensitive files systems are a reality)


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


From noreply@sourceforge.net  Sun Nov 12 11:07:24 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 12 Nov 2000 03:07:24 -0800
Subject: [Python-bugs-list] [Bug #119822] urllib doesn't like unicode
Message-ID: <200011121107.DAA17435@sf-web1.i.sourceforge.net>

Bug #119822, was updated on 2000-Oct-30 17:12
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: urllib doesn't like unicode

Details: 
getting a file via urllib.urlopen(u"http://foobar/blahblah")
produces undesirable results.

Something like:

  File "/usr/local/lib/python2.0/urllib.py", line 61, in urlopen
    return _urlopener.open(url)
  File "/usr/local/lib/python2.0/urllib.py", line 166, in open
    return getattr(self, name)(url)
  File "/usr/local/lib/python2.0/urllib.py", line 248, in open_http
    host, selector = url
ValueError: unpack sequence of wrong size


Follow-Ups:

Date: 2000-Nov-12 03:07
By: loewis

Comment:
A patch for that bug is in http://sourceforge.net/patch/?func=detailpatch&patch_id=102364&group_id=5470
-------------------------------------------------------

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


From noreply@sourceforge.net  Sun Nov 12 11:30:37 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 12 Nov 2000 03:30:37 -0800
Subject: [Python-bugs-list] [Bug #119960] Encoding bugs.
Message-ID: <200011121130.DAA17670@sf-web1.i.sourceforge.net>

Bug #119960, was updated on 2000-Oct-31 13:38
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Open
Resolution: None
Bug Group: None
Priority: 3
Summary: Encoding bugs.

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

Follow-Ups:

Date: 2000-Nov-01 08:00
By: jhylton

Comment:
I am not entirely sure what the bug is, though I agree that it can be confusing to deal with Unicode strings.

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

Date: 2000-Nov-01 12:47
By: lemburg

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

Date: 2000-Nov-01 13:16
By: kirill_simonov

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

Date: 2000-Nov-03 12:49
By: gvanrossum

Comment:
Assigned to Marc-Andre, since I have no idea what to do about this... :-(
-------------------------------------------------------

Date: 2000-Nov-09 02:00
By: lemburg

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

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

Date: 2000-Nov-10 10:53
By: kirill_simonov

Comment:
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"
[...]

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

Date: 2000-Nov-12 03:30
By: loewis

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

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


From noreply@sourceforge.net  Sun Nov 12 12:17:01 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 12 Nov 2000 04:17:01 -0800
Subject: [Python-bugs-list] [Bug #119960] Encoding bugs.
Message-ID: <200011121217.EAA16895@sf-web2.i.sourceforge.net>

Bug #119960, was updated on 2000-Oct-31 13:38
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Open
Resolution: None
Bug Group: None
Priority: 3
Summary: Encoding bugs.

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

Follow-Ups:

Date: 2000-Nov-01 08:00
By: jhylton

Comment:
I am not entirely sure what the bug is, though I agree that it can be confusing to deal with Unicode strings.

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

Date: 2000-Nov-01 12:47
By: lemburg

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

Date: 2000-Nov-01 13:16
By: kirill_simonov

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

Date: 2000-Nov-03 12:49
By: gvanrossum

Comment:
Assigned to Marc-Andre, since I have no idea what to do about this... :-(
-------------------------------------------------------

Date: 2000-Nov-09 02:00
By: lemburg

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

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

Date: 2000-Nov-10 10:53
By: kirill_simonov

Comment:
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"
[...]

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

Date: 2000-Nov-12 03:30
By: loewis

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

Date: 2000-Nov-12 04:17
By: kirill_simonov

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

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

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


From noreply@sourceforge.net  Sun Nov 12 16:00:22 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 12 Nov 2000 08:00:22 -0800
Subject: [Python-bugs-list] [Bug #122236] 11.4.2 Example 2 contains typos and one bug
Message-ID: <200011121600.IAA26249@sf-web3.vaspecialprojects.com>

Bug #122236, was updated on 2000-Nov-12 08:00
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: 11.4.2 Example 2 contains typos and one bug

Details: 
In 11.4.2 Example 2:

Two typos:

h.send(paramstring) -> h.send(params)

print errorcode -> print result

One bug:

For it to work (for example, with an Apache 1.3.14 server and php 4.0), you need this line just after the POST line:

h.putheader("Content-type", "application/x-www-form-urlencoded")

Scott Schram
http://schram.net




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


From noreply@sourceforge.net  Sun Nov 12 16:26:10 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 12 Nov 2000 08:26:10 -0800
Subject: [Python-bugs-list] [Bug #122236] 11.4.2 Example 2 contains typos and one bug
Message-ID: <200011121626.IAA26663@sf-web3.vaspecialprojects.com>

Bug #122236, was updated on 2000-Nov-12 08:00
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: 11.4.2 Example 2 contains typos and one bug

Details: 
In 11.4.2 Example 2:

Two typos:

h.send(paramstring) -> h.send(params)

print errorcode -> print result

One bug:

For it to work (for example, with an Apache 1.3.14 server and php 4.0), you need this line just after the POST line:

h.putheader("Content-type", "application/x-www-form-urlencoded")

Scott Schram
http://schram.net




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


From noreply@sourceforge.net  Mon Nov 13 03:53:24 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 12 Nov 2000 19:53:24 -0800
Subject: [Python-bugs-list] [Bug #122273] sunau readframes() docs should mention ULAW conversion
Message-ID: <200011130353.TAA02629@sf-web3.vaspecialprojects.com>

Bug #122273, was updated on 2000-Nov-12 19:53
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: sunau readframes() docs should mention ULAW conversion

Details: the docs for the sunau module should have something like the 
following in the readframes() function:

If the data is in ULAW format, readframes() will convert it to
linear format automatically.

thanks,
Anthony

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


From noreply@sourceforge.net  Mon Nov 13 20:21:46 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 13 Nov 2000 12:21:46 -0800
Subject: [Python-bugs-list] [Bug #122273] sunau readframes() docs should mention ULAW conversion
Message-ID: <200011132021.MAA13133@sf-web2.i.sourceforge.net>

Bug #122273, was updated on 2000-Nov-12 19:53
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: sunau readframes() docs should mention ULAW conversion

Details: the docs for the sunau module should have something like the 
following in the readframes() function:

If the data is in ULAW format, readframes() will convert it to
linear format automatically.

thanks,
Anthony

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


From noreply@sourceforge.net  Mon Nov 13 20:21:15 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 13 Nov 2000 12:21:15 -0800
Subject: [Python-bugs-list] [Bug #122215] python will not build without --with-suffix on case insensitive filesystem
Message-ID: <200011132021.MAA13123@sf-web2.i.sourceforge.net>

Bug #122215, was updated on 2000-Nov-11 20:26
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: python will not build without --with-suffix on case insensitive filesystem

Details: Mac OSX as the option of being installed in HFS+, a case insensitive filesystem.

Under OSX on HFS+, one *must* use the --with-suffix to change the name of the compiled executable or the build fails.

However, it would be desirable to have the 'make install' still instal the binary as just plain 'python' without requiring manual step.

Maybe the top level Python directory could be renamed PyCore or something?

(Yes, this is an annoyance-- but case insensitive files systems are a reality)


Follow-Ups:

Date: 2000-Nov-13 12:21
By: gvanrossum

Comment:
I've added this feature request to PEP 42.
-------------------------------------------------------

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


From noreply@sourceforge.net  Mon Nov 13 20:21:27 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 13 Nov 2000 12:21:27 -0800
Subject: [Python-bugs-list] [Bug #121115] Kill threads from main thread
Message-ID: <200011132021.MAA13126@sf-web2.i.sourceforge.net>

Bug #121115, was updated on 2000-Nov-02 07:51
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: Kill threads from main thread

Details: It still isn't possible to kill a thread from another thread. This is an important feature for long running processes as multithreaded application servers. It should be possible for the main thread (or another thread) to kill a non responding thread after a timeout.

As I read in a discussion forum "pthreads" support somewhat like thread_cancel() for Windows I don't know.

If this feature became implemented it would be nice if an ThreadObject from the module "threading" could be killed by deleting the object.

Follow-Ups:

Date: 2000-Nov-02 09:31
By: gvanrossum

Comment:
This is a very controversial feature. If a thread owns a resource (e.g. it holds a lock), what happens to the resource when the thread is killed?

The best idea I can come up with is to make it possible to send asynchronous exceptions to threads -- but this doesn't help for threads that are blocked in an I/O operation. That might be solved through sending signals, but that's a Unix-only solution, and probably isn't even consistent across different Unix thread implementations.
-------------------------------------------------------

Date: 2000-Nov-02 10:49
By: holtwick

Comment:
Blocking I/O operations are a problem, but what about other internal problems like endless loops? An asynchronous exception would be a good way for most problems (I have with threads ;) And as far as the documentation says, signals always go to the main thread. If that is so, it doesn't help much. 

So what about connecting signals to threads. I don't know if this is possible, but a reliable way to use signals with threads would be a way to give threads a timeout.
-------------------------------------------------------

Date: 2000-Nov-02 12:04
By: gvanrossum

Comment:
As I said, signals are a Unix-only solution.

And blocked I/O is a common reason to *want* to kill a thread -- e.g. the common problem of webservers that simply never reply.
-------------------------------------------------------

Date: 2000-Nov-03 05:01
By: holtwick

Comment:
I think then it would be the best to send the asynchronous exceptions even if they don't work for blocking I/O operations. The need of killing threads from outside is obvious I think. And there will be for sure some scenarios where the killing doesn't work properly, but to avoid these situations should be a task for the programmer of the code. There are always situations where the design of a programming language will not save the programmer of writing stupid code, e.g. while 1: pass

If there is no way of implementing the killing how should one write an multithreaded long running programm that keeps itself clean for several days or months or years. The advantage of threads are the shared informations and forking is often more difficult to use.

How does Java solve these problems?
-------------------------------------------------------

Date: 2000-Nov-03 05:18
By: gvanrossum

Comment:
The common solution for things like this is to have a simple app-specific protocol involving. The thread watches a specific variable that means "please exit"; when there's a need to kill the thread this variable is set. The thread just has to be careful to check this variable in each unbounded loop. This requires a bit of discipline; but (as you say) there are too many things a programmer can do to break the program to try and prevent them all.
-------------------------------------------------------

Date: 2000-Nov-13 12:21
By: gvanrossum

Comment:
I've added this feature request to PEP 42.
-------------------------------------------------------

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


From noreply@sourceforge.net  Mon Nov 13 20:29:35 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 13 Nov 2000 12:29:35 -0800
Subject: [Python-bugs-list] [Bug #121887] new.function, 3rd arg: can it be None or not?
Message-ID: <200011132029.MAA13243@sf-web2.i.sourceforge.net>

Bug #121887, was updated on 2000-Nov-07 07:20
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Closed
Resolution: None
Bug Group: None
Priority: 5
Summary: new.function, 3rd arg: can it be None or not?

Details: According to the docs, new.function's 3rd argument can be None (then the name from the codeobject will be used).

Trying to call new.function with None as the third argument raises an exception saying that this argument must be a string. Documentation error, or bug in module new?


Follow-Ups:

Date: 2000-Nov-13 12:29
By: gvanrossum

Comment:
I have fixed the code in CVS. Closed.
-------------------------------------------------------

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


From noreply@sourceforge.net  Mon Nov 13 20:31:19 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 13 Nov 2000 12:31:19 -0800
Subject: [Python-bugs-list] [Bug #121951] webbrowser.open() generates AttributeError on Mac
Message-ID: <200011132031.MAA13272@sf-web2.i.sourceforge.net>

Bug #121951, was updated on 2000-Nov-08 03:11
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: None
Bug Group: None
Priority: 5
Summary: webbrowser.open() generates AttributeError on Mac

Details: A typo in webbrowser.py.  This context diff fixes this problem:

Index: webbrowser.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/webbrowser.py,v
retrieving revision 1.4
diff -c -r1.4 webbrowser.py
*** webbrowser.py	2000/10/02 03:40:51	1.4
--- webbrowser.py	2000/11/08 10:24:39
***************
*** 215,221 ****
  else:
      class InternetConfig:
          def open(self, url, new=0):
!             ic.launcurl(url)
  
          def open_new(self, url):
              self.open(url)
--- 215,221 ----
  else:
      class InternetConfig:
          def open(self, url, new=0):
!             ic.launchurl(url)
  
          def open_new(self, url):
              self.open(url)



Follow-Ups:

Date: 2000-Nov-13 12:31
By: gvanrossum

Comment:
Fixed, thanks!

(NB for patches, it's best to use the patch manager.)
-------------------------------------------------------

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


From noreply@sourceforge.net  Mon Nov 13 20:34:03 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 13 Nov 2000 12:34:03 -0800
Subject: [Python-bugs-list] [Bug #122327] 0.1 + 0.1 =  0.20000000000000001
Message-ID: <200011132034.MAA13319@sf-web2.i.sourceforge.net>

Bug #122327, was updated on 2000-Nov-13 09:28
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: None
Bug Group: None
Priority: 5
Summary: 0.1 + 0.1 =  0.20000000000000001

Details: I am running Python 2.0 on solaris 8 and I am getting this bug.  I thought that this was fixed.

>>> 0.1 + 0.1
0.20000000000000001
>>> a = 0.1 + 0.1
>>> print a
0.2
>>> a
0.20000000000000001
>>>


Follow-Ups:

Date: 2000-Nov-13 12:34
By: gvanrossum

Comment:
This is not  bug.

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

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

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

>>> print 0.1+0.1
0.2
>>>
-------------------------------------------------------

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


From noreply@sourceforge.net  Mon Nov 13 20:35:42 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 13 Nov 2000 12:35:42 -0800
Subject: [Python-bugs-list] [Bug #121963] IDLE hangs on Threads
Message-ID: <200011132035.MAA13352@sf-web2.i.sourceforge.net>

Bug #121963, was updated on 2000-Nov-08 05:52
Here is a current snapshot of the bug.

Project: Python
Category: IDLE
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: IDLE hangs on Threads

Details: everytime my python- program starts a thread under IDLE it crashes. i use Windows 2000 and Python 2.0

Follow-Ups:

Date: 2000-Nov-13 12:35
By: gvanrossum

Comment:
Please provide more detail. What code do you use to start a thread? Does that code run correctly when using the command line interpreter (python.exe)? What kind of message do you get from the crash?
-------------------------------------------------------

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


From noreply@sourceforge.net  Mon Nov 13 20:35:53 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 13 Nov 2000 12:35:53 -0800
Subject: [Python-bugs-list] [Bug #121963] IDLE hangs on Threads
Message-ID: <200011132035.MAA13355@sf-web2.i.sourceforge.net>

Bug #121963, was updated on 2000-Nov-08 05:52
Here is a current snapshot of the bug.

Project: Python
Category: IDLE
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: IDLE hangs on Threads

Details: everytime my python- program starts a thread under IDLE it crashes. i use Windows 2000 and Python 2.0

Follow-Ups:

Date: 2000-Nov-13 12:35
By: gvanrossum

Comment:
Please provide more detail. What code do you use to start a thread? Does that code run correctly when using the command line interpreter (python.exe)? What kind of message do you get from the crash?
-------------------------------------------------------

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


From noreply@sourceforge.net  Mon Nov 13 20:36:35 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 13 Nov 2000 12:36:35 -0800
Subject: [Python-bugs-list] [Bug #114923] ToolTip not showing text on AIX 4.3
Message-ID: <200011132036.MAA13367@sf-web2.i.sourceforge.net>

Bug #114923, was updated on 2000-Sep-20 14:27
Here is a current snapshot of the bug.

Project: Python
Category: IDLE
Status: Closed
Resolution: None
Bug Group: Platform-specific
Priority: 1
Summary: ToolTip not showing text on AIX 4.3

Details: IDLE0.6 runs nicely on AIX except that the tip text itself does not show when the pop up box appears. The box seems to be sized properly but is blank.

-Robin Friedrich

Follow-Ups:

Date: 2000-Sep-20 16:54
By: gvanrossum

Comment:
Could it be a Tcl version problem? It's hard to debug this... :-(
-------------------------------------------------------

Date: 2000-Sep-21 14:17
By: none

Comment:
Yes I imagine it will be hard to debug. The tclTk version is 8.3.2. I am unaware of problems with that on the X windows platforms. Has this been noticed on other unices with 2.0b1?  --Robin F.
-------------------------------------------------------

Date: 2000-Sep-21 14:23
By: gvanrossum

Comment:
BTW, where do you expect to see tooltips? The only place I can think of is when you type a function name followed by a left paren. Is that it? What function name did you use?

(And yes, this works fine for me on Linux.)

Could it have to do with font? color? Perhaps your window manager?
Source is in CallTipWindow.py if you want to play.
-------------------------------------------------------

Date: 2000-Sep-25 11:39
By: none

Comment:
The open paren binding yes. Any function like those in the string module.
OK I've played with CallTipWindow.py and the main() test routine exhibits the bug nicely. The code looks dead simple and should work. I can only blame Tk 8.3.2. I tried linking in our old Tk 8.0 libraries/headers (hoping Tkinter was still compatible with it) and the tooltip call now raises the following. We are using X/Motif with the CDE window manager.

>>> idle.CallTipWindow.main()
>>> Exception in Tkinter callback
Traceback (most recent call last):
  File "./Lib/lib-tk/Tkinter.py", line 1283, in __call__
    args = apply(self.subst, args)
  File "./Lib/lib-tk/Tkinter.py", line 1053, in _substitute
    e.delta = getint(D)
ValueError: invalid literal for int(): D




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

Date: 2000-Sep-25 12:41
By: gvanrossum

Comment:
The getint(D) problem is because earlier versions of Tkinter don't support the mousewheel delta value.

Try again with the current CVS version (or wait 1.5 days for Python 2.0b2 to be released). The getint(D) problem should be solved in the CVS version (a try/except is put around it).
-------------------------------------------------------

Date: 2000-Sep-25 13:37
By: none

Comment:
I tried to trap the error and go on but then the test still fails to show text in the tooltip window with 8.0 Tk. I'm kinda stumped at this point.   Do you know of any other AIX users which I could pester instead of you?

-Robin F.
-------------------------------------------------------

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

Comment:
Hi Robin, I don't know of any other AIX users -- Vladimir Marangozov is in the middle of a move and hasn't resurfaced yet. (You can always try python-list@python.org of course.)

You could try to upgrade to Tcl/tk 8.3 -- I'm suspecting a Tcl or Tk error at this point and AIX is a minority platform for them too...

Also, try the CVS version of _tkinter.c (or wait for 2.0final) -- yesterday I checked in a change that avoids using interp->result, which is deprecated and caused (different) problems on Windows. Who knows. Just a lark.
-------------------------------------------------------

Date: 2000-Oct-25 07:28
By: gpk

Comment:
I see the same problem on Solaris 2.6, python 1.6 final,
TCL  8.3 .
-------------------------------------------------------

Date: 2000-Nov-13 12:36
By: gvanrossum

Comment:
Closing this for lack of interest.
-------------------------------------------------------

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


From noreply@sourceforge.net  Mon Nov 13 20:40:24 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 13 Nov 2000 12:40:24 -0800
Subject: [Python-bugs-list] [Bug #117329] Compile Python 2.0 on BSDI BSD/OS 4.0.1 fails
Message-ID: <200011132040.MAA13426@sf-web2.i.sourceforge.net>

Bug #117329, was updated on 2000-Oct-20 10:08
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: None
Bug Group: Platform-specific
Priority: 3
Summary: Compile Python 2.0 on BSDI BSD/OS 4.0.1 fails

Details: When compiling Python 2.0. on BSDI BSD/OS 4.0.1

Configure
     ./configure --prefix=/usr/home/sud2000/python --with-                  threads=no
     no problem

make

     After a lot of warnings like :

        .........
   /usr/include/math.h:177: warning: function declaration
             isn't a prototype
   /usr/include/math.h:257: warning: function declaration
             isn't a prototype
        ........

The compile failed with this message :

   /usr/home/......./Python-2.0/Objects/fileobject.c:274:
                      undefined reference to `TELL64'
   *** Error code 1

        Stop.
   *** Error code 1


Follow-Ups:

Date: 2000-Oct-24 13:00
By: dkwolfe

Comment:
The warnings also appear under Darwin as the BSD header files have issues with prototypes.
-------------------------------------------------------

Date: 2000-Oct-25 14:11
By: gvanrossum

Comment:
If you search for TELL64 in fileobject.c, you'll notice some code bracketed with #elif defined(__NetBSD__) || defined(__OpenBSD__). Try adding || defined(_HAVE_BSDI) to that line to see if that fixes it. If so, please let me know so we can apply the patch!
-------------------------------------------------------

Date: 2000-Nov-13 12:40
By: gvanrossum

Comment:
I believe this is fixed now. A patch is also present on

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

(TELL64 problems on BSDI and Mac OSX)
-------------------------------------------------------

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


From noreply@sourceforge.net  Mon Nov 13 20:44:01 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 13 Nov 2000 12:44:01 -0800
Subject: [Python-bugs-list] [Bug #119483] OpenBSD can't dynamically load modules
Message-ID: <200011132044.MAA13464@sf-web2.i.sourceforge.net>

Bug #119483, was updated on 2000-Oct-26 14:11
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Duplicate
Bug Group: Platform-specific
Priority: 5
Summary: OpenBSD can't dynamically load modules

Details: 
On OpenBSD, one always gets a traceback trying to import a '.so' module (replacing blahblahblah with module name):

ImportError: dynamic module does not define init function (initblahblahblah)

The problem is that dynload_shlib.c doesn't prepend an underscore to the symbol name (the C standard for naming function exports). Some OS's will try both the name with and without the underscore, some try only the literal symbol name when calling dlsym. OpenBSD requires the literal symbol. Hence, the following patch is in order:

--- dynload_shlib.c    Thu Oct 26 11:10:36 2000
+++ dynload_shlib.c     Thu Oct 26 11:10:51 2000
@@ -55,7 +55,7 @@
        }
 
        /* ### should there be a leading underscore for some platforms? */
-       sprintf(funcname, "init%.200s", shortname);
+       sprintf(funcname, "_init%.200s", shortname);
 
        if (fp != NULL) {
                int i;


Follow-Ups:

Date: 2000-Oct-26 14:15
By: gvanrossum

Comment:
This was reported before. I just fixed this 1-2 days ago in the CvS tree.
-------------------------------------------------------

Date: 2000-Nov-10 10:56
By: none

Comment:
This is a problem with a.out versions of NetBSD also.
However, the ELF versions of NetBSD can use the __ELF__
define to manage the problem. here is a patchfile which handles both a.out and ELF versions of NetBSD:

--- dynload_shlib.c.org Wed Nov  8 20:01:21 2000
+++ dynload_shlib.c     Wed Nov  8 20:38:49 2000
@@ -55,7 +55,11 @@
        }
 
        /* ### should there be a leading underscore for some platforms? */
-       sprintf(funcname, "init%.200s", shortname);
+#ifndef __ELF__
+       sprintf(funcname, "_init%.200s", shortname);
+#else
+        sprintf(funcname, "init%.200s", shortname);
+#endif
 
        if (fp != NULL) {
                int i;

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

Date: 2000-Nov-10 11:10
By: gvanrossum

Comment:
Could someone check that this patch also works for OpenBSD?
Then I could remove the current OpenBSD specific hack.

Of course there are other considerations too: are there systems that don't use __ELF__ but that also don't need the leading underscore? If so, the patch would break those platforms...
-------------------------------------------------------

Date: 2000-Nov-13 12:44
By: gvanrossum

Comment:
This should be fixed now.  A patch is also available from:

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

"Shared library problems on OpenBSD"
-------------------------------------------------------

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


From noreply@sourceforge.net  Mon Nov 13 20:54:01 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 13 Nov 2000 12:54:01 -0800
Subject: [Python-bugs-list] [Bug #121121] Dynamic loading on Solaris does not work
Message-ID: <200011132054.MAA13624@sf-web2.i.sourceforge.net>

Bug #121121, was updated on 2000-Nov-02 08:33
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 4
Summary: Dynamic loading on Solaris does not work

Details: Dynamic loading of shared libraries (Python/dynload_shlib) does not work under Solaris. This is due to a bug in the autoconf script. The patch at ftp://ftp.thewrittenword.com/outgoing/pub/python-2.0-solaris-dynload.patch fixes it.

The problem is that AC_CHECK_LIB(dl, dlopen) will never define HAVE_DLOPEN (AC_CHECK_FUNCS(dlopen) does that) which in turn will never define $ac_cv_func_dlopen. Anyway, using internal autoconf macros is icky. Redo the autoconf test because it will cache the results.

-- 
albert chin (china@thewrittenword.com)

Follow-Ups:

Date: 2000-Nov-02 10:08
By: gvanrossum

Comment:
Thanks for the patch; but would you be so kind to submit the patch to the SourceForge patch manager?
See http://sourceforge.net/patch/?group_id=5470
-------------------------------------------------------

Date: 2000-Nov-02 10:14
By: tww-account

Comment:
Ok, patch uploaded to the SourceForge patch manager.
-------------------------------------------------------

Date: 2000-Nov-13 12:54
By: gvanrossum

Comment:
Albert, would you be so kind to try again with the CVS version?

We didn't follow your suggestions (I can't find your patch on SF -- what's the patch id?) but we did change a few things. According to Greg Ward it now should work on Solaris. I can't test that beucase I have no acccess to a Solaris machine.
-------------------------------------------------------

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


From noreply@sourceforge.net  Mon Nov 13 22:24:57 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 13 Nov 2000 14:24:57 -0800
Subject: [Python-bugs-list] [Bug #122113] Mathematic operations fail on maximum negative integer
Message-ID: <200011132224.OAA14973@sf-web2.i.sourceforge.net>

Bug #122113, was updated on 2000-Nov-10 02:43
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 3
Summary: Mathematic operations fail on maximum negative integer

Details: Python documentation states -2147483648 is the largest maximum negative integer value. When attempting mathematical comparisons on this value an overflow error is encountered. The following line will fail:
    if -2147483648 < 50:
        print 'broken'

However assigning this value to a variable and using the variable in the comparison will succeed as will the following:
    maximum = -2147483648
    int(maximum)
This was originally found in 1.5.2 but I have tested it in 2.0 and the problem is still present.

Follow-Ups:

Date: 2000-Nov-10 05:14
By: gvanrossum

Comment:
Any expression involving -2147483648 (via a variable or otherwise) immediately raises OverflowError for me, as it should and as it explicitly is coded.

Are there other operations on integers that fail for you?

What platform are you using?  How many bits is a long int in C on that platform?

Does the test suite ("make test") complete without errors?

Did you build Python yourself or did you download a binary from somewhere?

Did you get any errors or warnings during building?

Assigned to Tim Peters, our expert on numerical conundrums.

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

Date: 2000-Nov-10 05:41
By: rhathaway

Comment:
Its just a guess but I think I should have added slightly more information on the bug -> I'll remember for the future ;-)

The heart of the problem is that the int() function works with -2147483648 but mathematical operations do not. Should the maximum number be -2147483648 or -2147483647 -> Python appears to be unsure atm. Basically I receive a value in a string and I need to convert it into an appropriate Python type to work with it. To do this I am currently issuing an int(stringValue) and trapping on Value error at which point I attempt to convert it to a long. Now the int works with 
-2147483648 so the value is converted to an int type but the subsequent less than check fails.

The problem only occurs with this single value at the very bottom of the integer range. I have not come across any other values that cause similar problems.

I have tested this problem in both 1.5.2 and 2.0 (Python on both Windows 98 and on Solaris 2.7. The windows Python installation was from the self installing exe downloaded from the python website. The solaris install was built from the tar file downloaded from the python website. No installation problems were encountered in any of the installs and the test suite make works fine.

Hopefully this should help to clarify the issue I have raised

Kind regards

Rob
-------------------------------------------------------

Date: 2000-Nov-10 10:17
By: tim_one

Comment:
Rob, please post a specific line of actual Python code that fails for you, self-contained and without trying to explain it to us <wink>.

The literal -2147483648 in a Python program on a 32-bit machine *should* raise OverflowError at compile-time.  Here's an actual screen dump (from IDLE) showing this:

>>> x = -2147483648
OverflowError: integer literal too large
>>>

For that reason, none of your examples make sense:  if we try *any* of them, they simply die with the same kind of OverflowError.

Note however that this does *not* fail:

>>> x = int("-2147483648")
>>> x
-2147483648
>>>

The difference in behavior here is unfortunate, but is a fact of life:  in the case of a literal appearing within Python program text, Python's grammar does not consider the leading "-" to be part of the literal.  -4 is actually read by Python as applying the unary negation operator to the positive integer 4.  That's why -2147483648 *as a literal* blows up:  the 2147483648 part alone is too large.  In the case of int(string), the string is parsed as a whole by a C library routine, which knows what to do with "-2147483648".

As to your test case:

if -2147483648 < 50: print 'broken' 

First, let's actually run it:

>>> if -2147483648 < 50: print 'broken'
OverflowError: integer literal too large
>>>

As explained above, that's exactly what's expected.  Second, let's try it via int(string) instead:

>>> if int("-2147483648") < 50: print 'broken'

broken
>>>

Yes, it prints "broken", but that's what it SHOULD print:  if you agree that 0 < 50, and that -1 < 50, then certainly you must agree that -2147483648 < 50 is correct too.

In short, I don't see any bug here, and suspect you're wrestling with illusions.  Unless you can give us a specific piece of runnable self-contained Python code that shows a bug, I'll just close this report as a Not-a-Bug.

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

Date: 2000-Nov-13 02:57
By: rhathaway

Comment:
Tim,
    It is true that having different parts of Python treat the value of -2147483648 differently can make writing programs difficult. I guess it would be fair to say that it is the way the the int() function (and therefore underlying C library routine) deals with the value. If you send the function the literal of -2147483648 it errors out (as expected) however if you send it the string value of '-2147483648' it will succeed. It is this behaviour that is at the root of the problem. Unfortunately I only have a string representation of the value and the routine I have written attempts to figure out which of the Python types it should be converted to in order to perform some calculations on it.
    I'm willing to accept suggestions as how to convert from a string into the correct Python type in order to perform the relevant calculations.

Many thanks for your help

rob
-------------------------------------------------------

Date: 2000-Nov-13 14:24
By: tim_one

Comment:
Rob, as far as I can tell, conversion from string to int already works exactly the way you want it to.

If you're still having a problem, please include an actual, self-contained, executable Python example.

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

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


From noreply@sourceforge.net  Mon Nov 13 22:51:54 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 13 Nov 2000 14:51:54 -0800
Subject: [Python-bugs-list] [Bug #121791] Error for bad \x escape doesn't mention filename
Message-ID: <200011132251.OAA15404@sf-web2.i.sourceforge.net>

Bug #121791, was updated on 2000-Nov-06 08:34
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Error for bad \x escape doesn't mention filename

Details: Using:

GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2

I get the following 'error' message:

    from interscript.languages.interscript_languages import add_translation
  File "interscript/languages/interscript_languages.py", line 2, in ?
    from interscript.encoding.utf8 import utf8
ValueError: invalid \x escape

in known correct code (i.e. it works on Python 1.5.2).

I have examined the function 'parsestr' in
'compile.c', and added debugging prints to find out
what is going on. The function _correctly_ processes
the string 'utf8' (quotes included), and returns,
then the error is generated _without_ entering
the routine!

This almost certainly must be a bug in egcs-2.91.66. 
The code in 'parsestr' looks correct to me.

It is possible the error can be replicated by
downloading and running 'interscript' (without
any arguments). Interscript is available at

	http://interscript.sourceforge.net

[Reply to skaller@maxtal.com.au, sorry, I couldn't
figure out how to 'log on']


Follow-Ups:

Date: 2000-Nov-06 09:04
By: gvanrossum

Comment:
The error message is legitimate: in Python 2.0, \x escapes must have exactly two hex characters following, and he uses \x0\x0 in his __init__.py module, which generates the error message.

But his bug report is also legitimate: the ValueError doesn't mention the file where this is occurring! I'm changing the bug subject to reflect this -- it has nothing to do with egcs 2.91.66.

I'm randomly assigning this to Tim.
-------------------------------------------------------

Date: 2000-Nov-13 14:51
By: tim_one

Comment:
Just noting that this is a bit of a mess to repair:  no "2nd phase" compile-time errors report file names or line numbers unless they're SyntaxErrors.  The bad \x escape here is one path thru that code; bad \x escapes in Unicode strings are another; likewise for OverflowError due to "too large" integer literal.  A fix is in progress.
-------------------------------------------------------

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


From noreply@sourceforge.net  Tue Nov 14 05:25:09 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 13 Nov 2000 21:25:09 -0800
Subject: [Python-bugs-list] [Bug #117484] Float operations/assignments in Python 2.0
Message-ID: <200011140525.VAA09004@sf-web3.vaspecialprojects.com>

Bug #117484, was updated on 2000-Oct-23 03:55
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Wont Fix
Bug Group: Not a Bug
Priority: 5
Summary: Float operations/assignments in Python 2.0

Details: Platform : WinNT 4.0 SP 5

go the interpreter window 
>>> x = 5.14
>>> x
5.139998

Could u please explain whats happening?
Wanted to use Python2.0 for test drivers for a financial package?
What do I do?

Thanks,
Kalyan.


Follow-Ups:

Date: 2000-Oct-23 06:34
By: jhylton

Comment:
This isn't a bug; it's the way floating point numbers work in nearly every language and on nearly every platform.

http://www.deja.com/=dnc/[ST_rn=ps]/getdoc.xp?AN=607818947

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

Date: 2000-Nov-13 21:25
By: tim_one

Comment:
Actually, if the bug report is accurate, it *is* a bug:  5.139998 isn't close enough to 5.14.  When I try it I get:

>>> x = 5.14
>>> x
5.1399999999999997
>>>

which is reasonable.  In the absence of more info, though, I assume the bug report is wrong -- leaving it closed.

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

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


From noreply@sourceforge.net  Tue Nov 14 13:37:26 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 14 Nov 2000 05:37:26 -0800
Subject: [Python-bugs-list] [Bug #122395] readline() of codecs.StreamReader doesn't work for"utf-16le"
Message-ID: <200011141337.FAA15812@sf-web3.vaspecialprojects.com>

Bug #122395, was updated on 2000-Nov-14 05:37
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: readline() of codecs.StreamReader doesn't work for"utf-16le"

Details: I tried that in
BOTH Python 1.6 and Python 2.0
(operating system: Windows NT)

I wrote :

import codecs

fileName1 = "d:\\sveta\\unicode\\try.txt"
(UTF16LE_encode, UTF16LE_decode,
 UTF16LE_streamreader, UTF16LE_streamwriter) = codecs.lookup('UTF-16LE')

output = UTF16LE_streamwriter( open(fileName1, 'wb') )
output.write(unicode('abc\n'))
output.write(unicode('def\n'))
output.close()

input = UTF16LE_streamreader( open(fileName1, 'rb') )
rl = input.readline()
print rl
input.close()

After I run it I got:

Traceback (most recent call last):
  File "d:\\sveta\\unicode\\unicodecheck.py", line 13, in ?
    rl = input.readline()
  File "D:\Program Files\Python16\lib\codecs.py", line 250, in readline
    return self.decode(line)[0]
UnicodeError: UTF-16 decoding error: truncated data

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


From noreply@sourceforge.net  Tue Nov 14 14:02:53 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 14 Nov 2000 06:02:53 -0800
Subject: [Python-bugs-list] [Bug #122395] readline() of codecs.StreamReader doesn't work for"utf-16le"
Message-ID: <200011141402.GAA28225@sf-web2.i.sourceforge.net>

Bug #122395, was updated on 2000-Nov-14 05:37
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: readline() of codecs.StreamReader doesn't work for"utf-16le"

Details: I tried that in
BOTH Python 1.6 and Python 2.0
(operating system: Windows NT)

I wrote :

import codecs

fileName1 = "d:\\sveta\\unicode\\try.txt"
(UTF16LE_encode, UTF16LE_decode,
 UTF16LE_streamreader, UTF16LE_streamwriter) = codecs.lookup('UTF-16LE')

output = UTF16LE_streamwriter( open(fileName1, 'wb') )
output.write(unicode('abc\n'))
output.write(unicode('def\n'))
output.close()

input = UTF16LE_streamreader( open(fileName1, 'rb') )
rl = input.readline()
print rl
input.close()

After I run it I got:

Traceback (most recent call last):
  File "d:\\sveta\\unicode\\unicodecheck.py", line 13, in ?
    rl = input.readline()
  File "D:\Program Files\Python16\lib\codecs.py", line 250, in readline
    return self.decode(line)[0]
UnicodeError: UTF-16 decoding error: truncated data

Follow-Ups:

Date: 2000-Nov-14 06:02
By: gvanrossum

Comment:
One for Marc-Andre. (Unfortunately he's announced he'll be too busy to look at bugs this year, so if someone else has a smart idea, feel free to butt in!)

This was originally classified as a Windows bug, but it's platform independent (I can reproduce it on Linux as well).
-------------------------------------------------------

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


From noreply@sourceforge.net  Tue Nov 14 14:09:12 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 14 Nov 2000 06:09:12 -0800
Subject: [Python-bugs-list] [Bug #122395] readline() of codecs.StreamReader doesn't work for"utf-16le"
Message-ID: <200011141409.GAA28329@sf-web2.i.sourceforge.net>

Bug #122395, was updated on 2000-Nov-14 05:37
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: readline() of codecs.StreamReader doesn't work for"utf-16le"

Details: I tried that in
BOTH Python 1.6 and Python 2.0
(operating system: Windows NT)

I wrote :

import codecs

fileName1 = "d:\\sveta\\unicode\\try.txt"
(UTF16LE_encode, UTF16LE_decode,
 UTF16LE_streamreader, UTF16LE_streamwriter) = codecs.lookup('UTF-16LE')

output = UTF16LE_streamwriter( open(fileName1, 'wb') )
output.write(unicode('abc\n'))
output.write(unicode('def\n'))
output.close()

input = UTF16LE_streamreader( open(fileName1, 'rb') )
rl = input.readline()
print rl
input.close()

After I run it I got:

Traceback (most recent call last):
  File "d:\\sveta\\unicode\\unicodecheck.py", line 13, in ?
    rl = input.readline()
  File "D:\Program Files\Python16\lib\codecs.py", line 250, in readline
    return self.decode(line)[0]
UnicodeError: UTF-16 decoding error: truncated data

Follow-Ups:

Date: 2000-Nov-14 06:02
By: gvanrossum

Comment:
One for Marc-Andre. (Unfortunately he's announced he'll be too busy to look at bugs this year, so if someone else has a smart idea, feel free to butt in!)

This was originally classified as a Windows bug, but it's platform independent (I can reproduce it on Linux as well).
-------------------------------------------------------

Date: 2000-Nov-14 06:09
By: gvanrossum

Comment:
A little bit of debugging suggests that the StreamReader.readline() method is naive: it calls the underlying stream's readline() method. Since in the example code the underlying stream is a regular 8-bit file, this will return an odd number of byte in the example. Because of the little-endian encoding; the file contains these hex bytes: 61 00 62 00 63 00 0a 00 ... (0a being '\n').

I'm not familiar enough with this class to tell whether this is simply inappropriate use of StreamReader, or that this should be fixed. Maybe Marc-Andre can answer t least that question?
-------------------------------------------------------

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


From noreply@sourceforge.net  Tue Nov 14 14:43:48 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 14 Nov 2000 06:43:48 -0800
Subject: [Python-bugs-list] [Bug #122395] readline() of codecs.StreamReader doesn't work for"utf-16le"
Message-ID: <200011141443.GAA29026@sf-web2.i.sourceforge.net>

Bug #122395, was updated on 2000-Nov-14 05:37
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: readline() of codecs.StreamReader doesn't work for"utf-16le"

Details: I tried that in
BOTH Python 1.6 and Python 2.0
(operating system: Windows NT)

I wrote :

import codecs

fileName1 = "d:\\sveta\\unicode\\try.txt"
(UTF16LE_encode, UTF16LE_decode,
 UTF16LE_streamreader, UTF16LE_streamwriter) = codecs.lookup('UTF-16LE')

output = UTF16LE_streamwriter( open(fileName1, 'wb') )
output.write(unicode('abc\n'))
output.write(unicode('def\n'))
output.close()

input = UTF16LE_streamreader( open(fileName1, 'rb') )
rl = input.readline()
print rl
input.close()

After I run it I got:

Traceback (most recent call last):
  File "d:\\sveta\\unicode\\unicodecheck.py", line 13, in ?
    rl = input.readline()
  File "D:\Program Files\Python16\lib\codecs.py", line 250, in readline
    return self.decode(line)[0]
UnicodeError: UTF-16 decoding error: truncated data

Follow-Ups:

Date: 2000-Nov-14 06:02
By: gvanrossum

Comment:
One for Marc-Andre. (Unfortunately he's announced he'll be too busy to look at bugs this year, so if someone else has a smart idea, feel free to butt in!)

This was originally classified as a Windows bug, but it's platform independent (I can reproduce it on Linux as well).
-------------------------------------------------------

Date: 2000-Nov-14 06:09
By: gvanrossum

Comment:
A little bit of debugging suggests that the StreamReader.readline() method is naive: it calls the underlying stream's readline() method. Since in the example code the underlying stream is a regular 8-bit file, this will return an odd number of byte in the example. Because of the little-endian encoding; the file contains these hex bytes: 61 00 62 00 63 00 0a 00 ... (0a being '\n').

I'm not familiar enough with this class to tell whether this is simply inappropriate use of StreamReader, or that this should be fixed. Maybe Marc-Andre can answer t least that question?
-------------------------------------------------------

Date: 2000-Nov-14 06:43
By: lemburg

Comment:
Some background:

.readline() is implemented in the way it is because all other
techniques would require adding real buffering to the codec (AFAIK.
at least) and this is currently out of scope.

Besides, there is another problem:  line breaking in Unicode is much
more difficult to get right than for plain ASCII, since there are a lot
more line break characters to watch out for.

.readline() is currently relying on the underlying stream to do the
line breaking. Since this doesn't know anything about encodings
it will break lines at single bytes. As a result, the input data for the
codec is broken.

To correct the problem, one would have to write a true UTF-16 codec
which implements buffering. This should be doable in Python, e.g. see
how StringIO does it. The codec would then have to read the
input data in chunks of say 1024 bytes (must be even), then
pass the data through the codec and use the .splitlines() method on
the Unicode output. Data which is not on  the current line would
have to be buffered until the next call to .read() or .readline().

Unfortunately, this technique will also break .tell(), .truncate() and friends...
it's a mess.

An easy work-around is reading in the file as a whole and then
using .splitlines() to get at the lines.

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

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


From noreply@sourceforge.net  Tue Nov 14 17:13:06 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 14 Nov 2000 09:13:06 -0800
Subject: [Python-bugs-list] [Bug #121963] IDLE hangs on Threads
Message-ID: <200011141713.JAA19800@sf-web3.vaspecialprojects.com>

Bug #121963, was updated on 2000-Nov-08 05:52
Here is a current snapshot of the bug.

Project: Python
Category: IDLE
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: IDLE hangs on Threads

Details: everytime my python- program starts a thread under IDLE it crashes. i use Windows 2000 and Python 2.0

Follow-Ups:

Date: 2000-Nov-13 12:35
By: gvanrossum

Comment:
Please provide more detail. What code do you use to start a thread? Does that code run correctly when using the command line interpreter (python.exe)? What kind of message do you get from the crash?
-------------------------------------------------------

Date: 2000-Nov-13 15:11
By: tim_one

Comment:
Under Win98SE, I don't see a crash but a hang is very easy to provoke (the bug report is unclear about which is happening).  For example:

def f():
    for i in range(100): print "hi", i
import thread
thread.start_new_thread(f, ())

From within IDLE, this freezes solid after a "random" number of prints, and whether typed in directly or run from a file ("Run script" from IDLE Edit menu).  Have to kill the shell from the Task Manager.

A possibly different symptom can be provoked by typing

from test import test_thread

from the IDLE prompt.

I don't think this is anything new; I always figured that threads & IDLE don't mix, and never thought more about it.

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

Date: 2000-Nov-14 09:13
By: none

Comment:
sorry that my comment was not clear enough. my prog works when it's running under the command line interpreter. there's no error message, it just hangs. 
here's my code:

from threading import *

class MyThread(Thread):
   def __init__(self, aData):
       Thread.__init__(self)
       self.mData=Data

   def run(self):
       for i in range(10):
          print self.mData


if __name__=="__main__":
   aThread=MyThread("Test")
   bThread=MyThread("another")

   aThread.start()
   bThread.start()

   aThread.join()
   bThread.join()

   

that's it. we did this at school and my system is a Dual Pentium II with 2 x 400 Mhz and 256Mb.


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

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


From noreply@sourceforge.net  Tue Nov 14 17:31:51 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 14 Nov 2000 09:31:51 -0800
Subject: [Python-bugs-list] [Bug #121963] IDLE hangs on Threads
Message-ID: <200011141731.JAA32188@sf-web2.i.sourceforge.net>

Bug #121963, was updated on 2000-Nov-08 05:52
Here is a current snapshot of the bug.

Project: Python
Category: IDLE
Status: Closed
Resolution: Wont Fix
Bug Group: None
Priority: 5
Summary: IDLE hangs on Threads

Details: everytime my python- program starts a thread under IDLE it crashes. i use Windows 2000 and Python 2.0

Follow-Ups:

Date: 2000-Nov-13 12:35
By: gvanrossum

Comment:
Please provide more detail. What code do you use to start a thread? Does that code run correctly when using the command line interpreter (python.exe)? What kind of message do you get from the crash?
-------------------------------------------------------

Date: 2000-Nov-13 15:11
By: tim_one

Comment:
Under Win98SE, I don't see a crash but a hang is very easy to provoke (the bug report is unclear about which is happening).  For example:

def f():
    for i in range(100): print "hi", i
import thread
thread.start_new_thread(f, ())

From within IDLE, this freezes solid after a "random" number of prints, and whether typed in directly or run from a file ("Run script" from IDLE Edit menu).  Have to kill the shell from the Task Manager.

A possibly different symptom can be provoked by typing

from test import test_thread

from the IDLE prompt.

I don't think this is anything new; I always figured that threads & IDLE don't mix, and never thought more about it.

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

Date: 2000-Nov-14 09:13
By: none

Comment:
sorry that my comment was not clear enough. my prog works when it's running under the command line interpreter. there's no error message, it just hangs. 
here's my code:

from threading import *

class MyThread(Thread):
   def __init__(self, aData):
       Thread.__init__(self)
       self.mData=Data

   def run(self):
       for i in range(10):
          print self.mData


if __name__=="__main__":
   aThread=MyThread("Test")
   bThread=MyThread("another")

   aThread.start()
   bThread.start()

   aThread.join()
   bThread.join()

   

that's it. we did this at school and my system is a Dual Pentium II with 2 x 400 Mhz and 256Mb.


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

Date: 2000-Nov-14 09:31
By: gvanrossum

Comment:
Ah.  Yes, printing from threads started under IDLE doesn't work, and in general using threads under IDLE isn't safe.   This is not platform specific!

This isn't easy to fix; the best solution will be (eventually) to run the program in a subprocess instead of as a module in the IDLE process, but thta requires significant architectural changes to IDLE.

For the short term, the solution is to run your program from the command line, or to avoid threads if you want to run nder IDLE.

Sorry.
-------------------------------------------------------

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


From noreply@sourceforge.net  Tue Nov 14 20:34:42 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 14 Nov 2000 12:34:42 -0800
Subject: [Python-bugs-list] [Bug #121963] IDLE hangs on Threads
Message-ID: <200011142034.MAA23609@sf-web3.vaspecialprojects.com>

Bug #121963, was updated on 2000-Nov-08 05:52
Here is a current snapshot of the bug.

Project: Python
Category: IDLE
Status: Closed
Resolution: Later
Bug Group: Feature Request
Priority: 5
Summary: IDLE hangs on Threads

Details: everytime my python- program starts a thread under IDLE it crashes. i use Windows 2000 and Python 2.0

Follow-Ups:

Date: 2000-Nov-13 12:35
By: gvanrossum

Comment:
Please provide more detail. What code do you use to start a thread? Does that code run correctly when using the command line interpreter (python.exe)? What kind of message do you get from the crash?
-------------------------------------------------------

Date: 2000-Nov-13 15:11
By: tim_one

Comment:
Under Win98SE, I don't see a crash but a hang is very easy to provoke (the bug report is unclear about which is happening).  For example:

def f():
    for i in range(100): print "hi", i
import thread
thread.start_new_thread(f, ())

From within IDLE, this freezes solid after a "random" number of prints, and whether typed in directly or run from a file ("Run script" from IDLE Edit menu).  Have to kill the shell from the Task Manager.

A possibly different symptom can be provoked by typing

from test import test_thread

from the IDLE prompt.

I don't think this is anything new; I always figured that threads & IDLE don't mix, and never thought more about it.

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

Date: 2000-Nov-14 09:13
By: none

Comment:
sorry that my comment was not clear enough. my prog works when it's running under the command line interpreter. there's no error message, it just hangs. 
here's my code:

from threading import *

class MyThread(Thread):
   def __init__(self, aData):
       Thread.__init__(self)
       self.mData=Data

   def run(self):
       for i in range(10):
          print self.mData


if __name__=="__main__":
   aThread=MyThread("Test")
   bThread=MyThread("another")

   aThread.start()
   bThread.start()

   aThread.join()
   bThread.join()

   

that's it. we did this at school and my system is a Dual Pentium II with 2 x 400 Mhz and 256Mb.


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

Date: 2000-Nov-14 09:31
By: gvanrossum

Comment:
Ah.  Yes, printing from threads started under IDLE doesn't work, and in general using threads under IDLE isn't safe.   This is not platform specific!

This isn't easy to fix; the best solution will be (eventually) to run the program in a subprocess instead of as a module in the IDLE process, but thta requires significant architectural changes to IDLE.

For the short term, the solution is to run your program from the command line, or to avoid threads if you want to run nder IDLE.

Sorry.
-------------------------------------------------------

Date: 2000-Nov-14 12:34
By: tim_one

Comment:
Changed to Feature Request and added to PEP42.
-------------------------------------------------------

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


From noreply@sourceforge.net  Tue Nov 14 20:47:04 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 14 Nov 2000 12:47:04 -0800
Subject: [Python-bugs-list] [Bug #119622] Python 2.0 compile errors ...
Message-ID: <200011142047.MAA03345@sf-web2.i.sourceforge.net>

Bug #119622, was updated on 2000-Oct-28 04:42
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: Fixed
Bug Group: Platform-specific
Priority: 5
Summary: Python 2.0 compile errors ...

Details: 
Hi,

the modules marshal.c and compile.c causes compilation errors because of several 
'extern double atof()' declarations when Python 2.0 will be compiled with gcc or Watcom 10.6.

IMHO ... these statements are misplaced and useless because the extern declaration of atof() is allready
included in the standard header.

Regards

 

Follow-Ups:

Date: 2000-Nov-14 12:47
By: tim_one

Comment:
Fixed & Closed.  I removed the redundant decls (marshal.c rev 1.58 and compile.c rev 2.143) but am confused by two things:  (1) lots of people compile Python w/ gcc and nobody else has reported compile errors due to this; and, (2) I can't imagine what *kind* of compile errors these would be:  C allows redundant decls.  So if you're getting errors, I can only imagine that your stdlib.h is declaring atof incorrectly.
-------------------------------------------------------

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


From noreply@sourceforge.net  Tue Nov 14 21:38:11 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 14 Nov 2000 13:38:11 -0800
Subject: [Python-bugs-list] [Bug #122113] Mathematic operations fail on maximum negative integer
Message-ID: <200011142138.NAA28770@sf-web1.i.sourceforge.net>

Bug #122113, was updated on 2000-Nov-10 02:43
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Invalid
Bug Group: Not a Bug
Priority: 3
Summary: Mathematic operations fail on maximum negative integer

Details: Python documentation states -2147483648 is the largest maximum negative integer value. When attempting mathematical comparisons on this value an overflow error is encountered. The following line will fail:
    if -2147483648 < 50:
        print 'broken'

However assigning this value to a variable and using the variable in the comparison will succeed as will the following:
    maximum = -2147483648
    int(maximum)
This was originally found in 1.5.2 but I have tested it in 2.0 and the problem is still present.

Follow-Ups:

Date: 2000-Nov-10 05:14
By: gvanrossum

Comment:
Any expression involving -2147483648 (via a variable or otherwise) immediately raises OverflowError for me, as it should and as it explicitly is coded.

Are there other operations on integers that fail for you?

What platform are you using?  How many bits is a long int in C on that platform?

Does the test suite ("make test") complete without errors?

Did you build Python yourself or did you download a binary from somewhere?

Did you get any errors or warnings during building?

Assigned to Tim Peters, our expert on numerical conundrums.

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

Date: 2000-Nov-10 05:41
By: rhathaway

Comment:
Its just a guess but I think I should have added slightly more information on the bug -> I'll remember for the future ;-)

The heart of the problem is that the int() function works with -2147483648 but mathematical operations do not. Should the maximum number be -2147483648 or -2147483647 -> Python appears to be unsure atm. Basically I receive a value in a string and I need to convert it into an appropriate Python type to work with it. To do this I am currently issuing an int(stringValue) and trapping on Value error at which point I attempt to convert it to a long. Now the int works with 
-2147483648 so the value is converted to an int type but the subsequent less than check fails.

The problem only occurs with this single value at the very bottom of the integer range. I have not come across any other values that cause similar problems.

I have tested this problem in both 1.5.2 and 2.0 (Python on both Windows 98 and on Solaris 2.7. The windows Python installation was from the self installing exe downloaded from the python website. The solaris install was built from the tar file downloaded from the python website. No installation problems were encountered in any of the installs and the test suite make works fine.

Hopefully this should help to clarify the issue I have raised

Kind regards

Rob
-------------------------------------------------------

Date: 2000-Nov-10 10:17
By: tim_one

Comment:
Rob, please post a specific line of actual Python code that fails for you, self-contained and without trying to explain it to us <wink>.

The literal -2147483648 in a Python program on a 32-bit machine *should* raise OverflowError at compile-time.  Here's an actual screen dump (from IDLE) showing this:

>>> x = -2147483648
OverflowError: integer literal too large
>>>

For that reason, none of your examples make sense:  if we try *any* of them, they simply die with the same kind of OverflowError.

Note however that this does *not* fail:

>>> x = int("-2147483648")
>>> x
-2147483648
>>>

The difference in behavior here is unfortunate, but is a fact of life:  in the case of a literal appearing within Python program text, Python's grammar does not consider the leading "-" to be part of the literal.  -4 is actually read by Python as applying the unary negation operator to the positive integer 4.  That's why -2147483648 *as a literal* blows up:  the 2147483648 part alone is too large.  In the case of int(string), the string is parsed as a whole by a C library routine, which knows what to do with "-2147483648".

As to your test case:

if -2147483648 < 50: print 'broken' 

First, let's actually run it:

>>> if -2147483648 < 50: print 'broken'
OverflowError: integer literal too large
>>>

As explained above, that's exactly what's expected.  Second, let's try it via int(string) instead:

>>> if int("-2147483648") < 50: print 'broken'

broken
>>>

Yes, it prints "broken", but that's what it SHOULD print:  if you agree that 0 < 50, and that -1 < 50, then certainly you must agree that -2147483648 < 50 is correct too.

In short, I don't see any bug here, and suspect you're wrestling with illusions.  Unless you can give us a specific piece of runnable self-contained Python code that shows a bug, I'll just close this report as a Not-a-Bug.

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

Date: 2000-Nov-13 02:57
By: rhathaway

Comment:
Tim,
    It is true that having different parts of Python treat the value of -2147483648 differently can make writing programs difficult. I guess it would be fair to say that it is the way the the int() function (and therefore underlying C library routine) deals with the value. If you send the function the literal of -2147483648 it errors out (as expected) however if you send it the string value of '-2147483648' it will succeed. It is this behaviour that is at the root of the problem. Unfortunately I only have a string representation of the value and the routine I have written attempts to figure out which of the Python types it should be converted to in order to perform some calculations on it.
    I'm willing to accept suggestions as how to convert from a string into the correct Python type in order to perform the relevant calculations.

Many thanks for your help

rob
-------------------------------------------------------

Date: 2000-Nov-13 14:24
By: tim_one

Comment:
Rob, as far as I can tell, conversion from string to int already works exactly the way you want it to.

If you're still having a problem, please include an actual, self-contained, executable Python example.

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

Date: 2000-Nov-14 13:38
By: tim_one

Comment:
Closing this, as there's still no evidence of a bug (although it is irritating that int literals have different rules via int() than via Python's grammar).

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

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


From noreply@sourceforge.net  Tue Nov 14 21:48:59 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 14 Nov 2000 13:48:59 -0800
Subject: [Python-bugs-list] [Bug #122176] Error in rotor module documentation
Message-ID: <200011142148.NAA24927@sf-web3.vaspecialprojects.com>

Bug #122176, was updated on 2000-Nov-11 03:00
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: Error in rotor module documentation

Details: A minor error in the description of the "decrypt" and "decryptmore" methods in the rotor module documentation :

decrypt (ciphertext) 
     Reset the rotor object to its initial state and decrypt ciphertext, returning a string containing the ciphertext. The plaintext string will always be the same length as the ciphertext. 

decryptmore (ciphertext) 
     Decrypt ciphertext without resetting the rotor object, and return a string containing the ciphertext. 

In both cases the returned string is the *clear text*, not the *ciphertext* (fortunately enough :-)

Follow-Ups:

Date: 2000-Nov-14 13:48
By: tim_one

Comment:
Fixed and Closed, in librotor.tex rev 1.17.  Used "plaintext" instead of "clear text" for consistency with the rest of the rotor docs.
-------------------------------------------------------

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


From noreply@sourceforge.net  Wed Nov 15 02:27:40 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 14 Nov 2000 18:27:40 -0800
Subject: [Python-bugs-list] [Bug #122463] ./configure --help double trouble
Message-ID: <200011150227.SAA01042@sf-web1.i.sourceforge.net>

Bug #122463, was updated on 2000-Nov-14 18:27
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: ./configure --help double trouble

Details: When you do a ./configure --help it reports that you can use a '--program-suffix=SUFFIX' to append SUFFIX to installed program names AND '--with-suffix=.exe' to set executable suffix.  Are these the same?  If so the program-suffix doesn't work. 

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


From noreply@sourceforge.net  Wed Nov 15 18:20:13 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 15 Nov 2000 10:20:13 -0800
Subject: [Python-bugs-list] [Bug #122517] problems to compile 2.0 on IRIX 6.5
Message-ID: <200011151820.KAA11805@sf-web3.vaspecialprojects.com>

Bug #122517, was updated on 2000-Nov-15 10:20
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: problems to compile 2.0 on IRIX 6.5

Details: ./configure --prefix=/usr/local/sbin/python/ --with-threads --without-gcc --with-cxx=CC

no errors...

gmake test:

PYTHONPATH= ./python -tt ./Lib/test/regrtest.py -l
'import site' failed; use -v for traceback
Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 35, in ?
    import string
ImportError: No module named string
gmake: [test] Error 1 (ignored)
PYTHONPATH= ./python -tt ./Lib/test/regrtest.py -l
'import site' failed; use -v for traceback
Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 35, in ?
    import string
ImportError: No module named string
gmake: *** [test] Error 1


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


From noreply@sourceforge.net  Thu Nov 16 07:03:37 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 15 Nov 2000 23:03:37 -0800
Subject: [Python-bugs-list] [Bug #122562] Some typo errors in Extending & Embedding
Message-ID: <200011160703.XAA22928@sf-web3.vaspecialprojects.com>

Bug #122562, was updated on 2000-Nov-15 23:03
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Some typo errors in Extending & Embedding

Details: While translating into French this document, I found three
typo errors :
 1/ as mentioned in a former message, page 9 for item 'es#',
    "stores into two C variables" should become "stores
    into three C variables"
 2/ page 11 for item ';', "the colon is used" should
    become "the semicolon is used"
 3/ page 14, items 'u' and 'u#' are present twice

That all what I found. I finished my translation yesterday,
and it will be available very soon on :
  http://frpython.sourceforge.net

Gilles

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


From noreply@sourceforge.net  Thu Nov 16 07:06:20 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 15 Nov 2000 23:06:20 -0800
Subject: [Python-bugs-list] [Bug #122564] Some typo errors in Extending & Embedding
Message-ID: <200011160706.XAA22960@sf-web3.vaspecialprojects.com>

Bug #122564, was updated on 2000-Nov-15 23:06
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Some typo errors in Extending & Embedding

Details: While translating into French this document, I found three
typo errors :
 1/ as mentioned in a former message, page 9 for item 'es#',
    "stores into two C variables" should become "stores
    into three C variables"
 2/ page 11 for item ';', "the colon is used" should
    become "the semicolon is used"
 3/ page 14, items 'u' and 'u#' are present twice

That all what I found. I finished my translation yesterday,
and it will be available very soon on :
  http://frpython.sourceforge.net

Gilles

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


From noreply@sourceforge.net  Thu Nov 16 14:10:42 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Nov 2000 06:10:42 -0800
Subject: [Python-bugs-list] [Bug #122587] xmllib unable to parse "german scharfes ß" in UTF8 format
Message-ID: <200011161410.GAA08284@sf-web2.i.sourceforge.net>

Bug #122587, was updated on 2000-Nov-16 06:10
Here is a current snapshot of the bug.

Project: Python
Category: XML
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: xmllib unable to parse "german scharfes ß" in UTF8 format

Details: The xmllib.XMLParser seems to be unable to parse 
an XML file that contains 0xc3 0x9f (UTF8 representation
of the german ß).

Python 2.0 (Linux i386) always give me the following 
traceback:

suxlap@/tmp/xx(2)% python test.py test.xml
<?xml version="1.0" encoding="UTF-8" ?>

<test>Ã&#376;üöä</test>

Traceback (most recent call last):
  File "test.py", line 20, in ?
    pp.feed(data)
  File "/opt/python-2.0/lib/python2.0/xmllib.py", line 165, in feed
    self.goahead(0)
  File "/opt/python-2.0/lib/python2.0/xmllib.py", line 261, in goahead
    self.syntax_error('illegal character in content')
  File "/opt/python-2.0/lib/python2.0/xmllib.py", line 786, in syntax_error
    raise RuntimeError, 'Syntax error at line %d: %s' % (self.lineno, message)
RuntimeError: Syntax error at line 3: illegal character in content         



Other UTF8 characters seem to work

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


From noreply@sourceforge.net  Thu Nov 16 14:15:39 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Nov 2000 06:15:39 -0800
Subject: [Python-bugs-list] [Bug #122588] xmllib unable to parse "german scharfes ß" in UTF8 format
Message-ID: <200011161415.GAA29476@sf-web3.vaspecialprojects.com>

Bug #122588, was updated on 2000-Nov-16 06:15
Here is a current snapshot of the bug.

Project: Python
Category: XML
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: xmllib unable to parse "german scharfes ß" in UTF8 format

Details: The xmllib.XMLParser seems to be unable to parse 
an XML file that contains 0xc3 0x9f (UTF8 representation
of the german ß).

Python 2.0 (Linux i386) always give me the following 
traceback:

suxlap@/tmp/xx(2)% python test.py test.xml
<?xml version="1.0" encoding="UTF-8" ?>

<test>Ã&#376;üöä</test>

Traceback (most recent call last):
  File "test.py", line 20, in ?
    pp.feed(data)
  File "/opt/python-2.0/lib/python2.0/xmllib.py", line 165, in feed
    self.goahead(0)
  File "/opt/python-2.0/lib/python2.0/xmllib.py", line 261, in goahead
    self.syntax_error('illegal character in content')
  File "/opt/python-2.0/lib/python2.0/xmllib.py", line 786, in syntax_error
    raise RuntimeError, 'Syntax error at line %d: %s' % (self.lineno, message)
RuntimeError: Syntax error at line 3: illegal character in content         



Other UTF8 characters seem to work

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


From noreply@sourceforge.net  Thu Nov 16 14:11:41 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Nov 2000 06:11:41 -0800
Subject: [Python-bugs-list] [Bug #122589] xmllib unable to parse "german scharfes ß" in UTF8 format
Message-ID: <200011161411.GAA32737@sf-web1.i.sourceforge.net>

Bug #122589, was updated on 2000-Nov-16 06:11
Here is a current snapshot of the bug.

Project: Python
Category: XML
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: xmllib unable to parse "german scharfes ß" in UTF8 format

Details: The xmllib.XMLParser seems to be unable to parse 
an XML file that contains 0xc3 0x9f (UTF8 representation
of the german ß).

Python 2.0 (Linux i386) always give me the following 
traceback:

suxlap@/tmp/xx(2)% python test.py test.xml
<?xml version="1.0" encoding="UTF-8" ?>

<test>Ã&#376;üöä</test>

Traceback (most recent call last):
  File "test.py", line 20, in ?
    pp.feed(data)
  File "/opt/python-2.0/lib/python2.0/xmllib.py", line 165, in feed
    self.goahead(0)
  File "/opt/python-2.0/lib/python2.0/xmllib.py", line 261, in goahead
    self.syntax_error('illegal character in content')
  File "/opt/python-2.0/lib/python2.0/xmllib.py", line 786, in syntax_error
    raise RuntimeError, 'Syntax error at line %d: %s' % (self.lineno, message)
RuntimeError: Syntax error at line 3: illegal character in content         



Other UTF8 characters seem to work

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


From noreply@sourceforge.net  Thu Nov 16 14:27:14 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Nov 2000 06:27:14 -0800
Subject: [Python-bugs-list] [Bug #122588] xmllib unable to parse "german scharfes ß" in UTF8 format
Message-ID: <200011161427.GAA29814@sf-web3.vaspecialprojects.com>

Bug #122588, was updated on 2000-Nov-16 06:15
Here is a current snapshot of the bug.

Project: Python
Category: XML
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: xmllib unable to parse "german scharfes ß" in UTF8 format

Details: The xmllib.XMLParser seems to be unable to parse 
an XML file that contains 0xc3 0x9f (UTF8 representation
of the german ß).

Python 2.0 (Linux i386) always give me the following 
traceback:

suxlap@/tmp/xx(2)% python test.py test.xml
<?xml version="1.0" encoding="UTF-8" ?>

<test>Ã&#376;üöä</test>

Traceback (most recent call last):
  File "test.py", line 20, in ?
    pp.feed(data)
  File "/opt/python-2.0/lib/python2.0/xmllib.py", line 165, in feed
    self.goahead(0)
  File "/opt/python-2.0/lib/python2.0/xmllib.py", line 261, in goahead
    self.syntax_error('illegal character in content')
  File "/opt/python-2.0/lib/python2.0/xmllib.py", line 786, in syntax_error
    raise RuntimeError, 'Syntax error at line %d: %s' % (self.lineno, message)
RuntimeError: Syntax error at line 3: illegal character in content         



Other UTF8 characters seem to work

Follow-Ups:

Date: 2000-Nov-16 06:27
By: none

Comment:
Did you pass the keyword option "accept_utf8=1" to the
constructor of the parser ?
--
Marc-Andre Lemburg
-------------------------------------------------------

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


From noreply@sourceforge.net  Thu Nov 16 16:40:08 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Nov 2000 08:40:08 -0800
Subject: [Python-bugs-list] [Bug #122564] Some typo errors in Extending & Embedding
Message-ID: <200011161640.IAA32173@sf-web3.vaspecialprojects.com>

Bug #122564, was updated on 2000-Nov-15 23:06
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Some typo errors in Extending & Embedding

Details: While translating into French this document, I found three
typo errors :
 1/ as mentioned in a former message, page 9 for item 'es#',
    "stores into two C variables" should become "stores
    into three C variables"
 2/ page 11 for item ';', "the colon is used" should
    become "the semicolon is used"
 3/ page 14, items 'u' and 'u#' are present twice

That all what I found. I finished my translation yesterday,
and it will be available very soon on :
  http://frpython.sourceforge.net

Gilles

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


From noreply@sourceforge.net  Thu Nov 16 17:17:01 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Nov 2000 09:17:01 -0800
Subject: [Python-bugs-list] [Bug #122587] xmllib unable to parse "german scharfes ß" in UTF8 format
Message-ID: <200011161717.JAA03556@sf-web1.i.sourceforge.net>

Bug #122587, was updated on 2000-Nov-16 06:10
Here is a current snapshot of the bug.

Project: Python
Category: XML
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: xmllib unable to parse "german scharfes ß" in UTF8 format

Details: The xmllib.XMLParser seems to be unable to parse 
an XML file that contains 0xc3 0x9f (UTF8 representation
of the german ß).

Python 2.0 (Linux i386) always give me the following 
traceback:

suxlap@/tmp/xx(2)% python test.py test.xml
<?xml version="1.0" encoding="UTF-8" ?>

<test>Ã&#376;üöä</test>

Traceback (most recent call last):
  File "test.py", line 20, in ?
    pp.feed(data)
  File "/opt/python-2.0/lib/python2.0/xmllib.py", line 165, in feed
    self.goahead(0)
  File "/opt/python-2.0/lib/python2.0/xmllib.py", line 261, in goahead
    self.syntax_error('illegal character in content')
  File "/opt/python-2.0/lib/python2.0/xmllib.py", line 786, in syntax_error
    raise RuntimeError, 'Syntax error at line %d: %s' % (self.lineno, message)
RuntimeError: Syntax error at line 3: illegal character in content         



Other UTF8 characters seem to work

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


From noreply@sourceforge.net  Thu Nov 16 17:17:35 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Nov 2000 09:17:35 -0800
Subject: [Python-bugs-list] [Bug #122588] xmllib unable to parse "german scharfes ß" in UTF8 format
Message-ID: <200011161717.JAA11791@sf-web2.i.sourceforge.net>

Bug #122588, was updated on 2000-Nov-16 06:15
Here is a current snapshot of the bug.

Project: Python
Category: XML
Status: Closed
Resolution: Duplicate
Bug Group: None
Priority: 5
Summary: xmllib unable to parse "german scharfes ß" in UTF8 format

Details: The xmllib.XMLParser seems to be unable to parse 
an XML file that contains 0xc3 0x9f (UTF8 representation
of the german ß).

Python 2.0 (Linux i386) always give me the following 
traceback:

suxlap@/tmp/xx(2)% python test.py test.xml
<?xml version="1.0" encoding="UTF-8" ?>

<test>Ã&#376;üöä</test>

Traceback (most recent call last):
  File "test.py", line 20, in ?
    pp.feed(data)
  File "/opt/python-2.0/lib/python2.0/xmllib.py", line 165, in feed
    self.goahead(0)
  File "/opt/python-2.0/lib/python2.0/xmllib.py", line 261, in goahead
    self.syntax_error('illegal character in content')
  File "/opt/python-2.0/lib/python2.0/xmllib.py", line 786, in syntax_error
    raise RuntimeError, 'Syntax error at line %d: %s' % (self.lineno, message)
RuntimeError: Syntax error at line 3: illegal character in content         



Other UTF8 characters seem to work

Follow-Ups:

Date: 2000-Nov-16 06:27
By: Nobody

Comment:
Did you pass the keyword option "accept_utf8=1" to the
constructor of the parser ?
--
Marc-Andre Lemburg
-------------------------------------------------------

Date: 2000-Nov-16 09:17
By: jhylton

Comment:
please submit a bug report exactly once

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

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


From noreply@sourceforge.net  Thu Nov 16 17:17:35 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Nov 2000 09:17:35 -0800
Subject: [Python-bugs-list] [Bug #122588] xmllib unable to parse "german scharfes ß" in UTF8 format
Message-ID: <200011161717.JAA11788@sf-web2.i.sourceforge.net>

Bug #122588, was updated on 2000-Nov-16 06:15
Here is a current snapshot of the bug.

Project: Python
Category: XML
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: xmllib unable to parse "german scharfes ß" in UTF8 format

Details: The xmllib.XMLParser seems to be unable to parse 
an XML file that contains 0xc3 0x9f (UTF8 representation
of the german ß).

Python 2.0 (Linux i386) always give me the following 
traceback:

suxlap@/tmp/xx(2)% python test.py test.xml
<?xml version="1.0" encoding="UTF-8" ?>

<test>Ã&#376;üöä</test>

Traceback (most recent call last):
  File "test.py", line 20, in ?
    pp.feed(data)
  File "/opt/python-2.0/lib/python2.0/xmllib.py", line 165, in feed
    self.goahead(0)
  File "/opt/python-2.0/lib/python2.0/xmllib.py", line 261, in goahead
    self.syntax_error('illegal character in content')
  File "/opt/python-2.0/lib/python2.0/xmllib.py", line 786, in syntax_error
    raise RuntimeError, 'Syntax error at line %d: %s' % (self.lineno, message)
RuntimeError: Syntax error at line 3: illegal character in content         



Other UTF8 characters seem to work

Follow-Ups:

Date: 2000-Nov-16 06:27
By: Nobody

Comment:
Did you pass the keyword option "accept_utf8=1" to the
constructor of the parser ?
--
Marc-Andre Lemburg
-------------------------------------------------------

Date: 2000-Nov-16 09:17
By: jhylton

Comment:
please submit a bug report exactly once

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

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


From noreply@sourceforge.net  Thu Nov 16 17:17:49 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Nov 2000 09:17:49 -0800
Subject: [Python-bugs-list] [Bug #122589] xmllib unable to parse "german scharfes ß" in UTF8 format
Message-ID: <200011161717.JAA03570@sf-web1.i.sourceforge.net>

Bug #122589, was updated on 2000-Nov-16 06:11
Here is a current snapshot of the bug.

Project: Python
Category: XML
Status: Closed
Resolution: Duplicate
Bug Group: Platform-specific
Priority: 5
Summary: xmllib unable to parse "german scharfes ß" in UTF8 format

Details: The xmllib.XMLParser seems to be unable to parse 
an XML file that contains 0xc3 0x9f (UTF8 representation
of the german ß).

Python 2.0 (Linux i386) always give me the following 
traceback:

suxlap@/tmp/xx(2)% python test.py test.xml
<?xml version="1.0" encoding="UTF-8" ?>

<test>Ã&#376;üöä</test>

Traceback (most recent call last):
  File "test.py", line 20, in ?
    pp.feed(data)
  File "/opt/python-2.0/lib/python2.0/xmllib.py", line 165, in feed
    self.goahead(0)
  File "/opt/python-2.0/lib/python2.0/xmllib.py", line 261, in goahead
    self.syntax_error('illegal character in content')
  File "/opt/python-2.0/lib/python2.0/xmllib.py", line 786, in syntax_error
    raise RuntimeError, 'Syntax error at line %d: %s' % (self.lineno, message)
RuntimeError: Syntax error at line 3: illegal character in content         



Other UTF8 characters seem to work

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


From noreply@sourceforge.net  Thu Nov 16 17:22:43 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Nov 2000 09:22:43 -0800
Subject: [Python-bugs-list] [Bug #122562] Some typo errors in Extending & Embedding
Message-ID: <200011161722.JAA00441@sf-web3.vaspecialprojects.com>

Bug #122562, was updated on 2000-Nov-15 23:03
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Some typo errors in Extending & Embedding

Details: While translating into French this document, I found three
typo errors :
 1/ as mentioned in a former message, page 9 for item 'es#',
    "stores into two C variables" should become "stores
    into three C variables"
 2/ page 11 for item ';', "the colon is used" should
    become "the semicolon is used"
 3/ page 14, items 'u' and 'u#' are present twice

That all what I found. I finished my translation yesterday,
and it will be available very soon on :
  http://frpython.sourceforge.net

Gilles

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


From noreply@sourceforge.net  Thu Nov 16 18:58:03 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Nov 2000 10:58:03 -0800
Subject: [Python-bugs-list] [Bug #122587] xmllib unable to parse "german scharfes ß" in UTF8 format
Message-ID: <200011161858.KAA01891@sf-web3.vaspecialprojects.com>

Bug #122587, was updated on 2000-Nov-16 06:10
Here is a current snapshot of the bug.

Project: Python
Category: XML
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: xmllib unable to parse "german scharfes ß" in UTF8 format

Details: The xmllib.XMLParser seems to be unable to parse 
an XML file that contains 0xc3 0x9f (UTF8 representation
of the german ß).

Python 2.0 (Linux i386) always give me the following 
traceback:

suxlap@/tmp/xx(2)% python test.py test.xml
<?xml version="1.0" encoding="UTF-8" ?>

<test>Ã&#376;üöä</test>

Traceback (most recent call last):
  File "test.py", line 20, in ?
    pp.feed(data)
  File "/opt/python-2.0/lib/python2.0/xmllib.py", line 165, in feed
    self.goahead(0)
  File "/opt/python-2.0/lib/python2.0/xmllib.py", line 261, in goahead
    self.syntax_error('illegal character in content')
  File "/opt/python-2.0/lib/python2.0/xmllib.py", line 786, in syntax_error
    raise RuntimeError, 'Syntax error at line %d: %s' % (self.lineno, message)
RuntimeError: Syntax error at line 3: illegal character in content         



Other UTF8 characters seem to work

Follow-Ups:

Date: 2000-Nov-16 10:58
By: Nobody

Comment:
works with accept_utf=1 as additional parameter,
but using xml package instead.
 
-------------------------------------------------------

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


From noreply@sourceforge.net  Thu Nov 16 21:29:54 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Nov 2000 13:29:54 -0800
Subject: [Python-bugs-list] [Bug #122625] Using os.system() does not execute some programs
Message-ID: <200011162129.NAA04538@sf-web3.vaspecialprojects.com>

Bug #122625, was updated on 2000-Nov-16 13:29
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Using os.system() does not execute some programs

Details: I do not think I can fully explain what is happening. Here is my attempt.
I use Python as a scripting to run large programs. Sometimes the code I expect python to run in os.system(command) does not run. I cannot figure out why it does not run. 

My guess is that os.system() cannot execute large programs (sometimes?). Becuase when I run
	command = "XYZ"   # whatever long program
	print command
	os.system(command)
it sometimes works. I have not just piped it to tcsh as 
	command = "XYZ"
	print command
Take the above program | tcsh
This works all the time.

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


From noreply@sourceforge.net  Thu Nov 16 21:42:43 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Nov 2000 13:42:43 -0800
Subject: [Python-bugs-list] [Bug #122625] Using os.system() does not execute some programs
Message-ID: <200011162142.NAA08074@sf-web1.i.sourceforge.net>

Bug #122625, was updated on 2000-Nov-16 13:29
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Using os.system() does not execute some programs

Details: I do not think I can fully explain what is happening. Here is my attempt.
I use Python as a scripting to run large programs. Sometimes the code I expect python to run in os.system(command) does not run. I cannot figure out why it does not run. 

My guess is that os.system() cannot execute large programs (sometimes?). Becuase when I run
	command = "XYZ"   # whatever long program
	print command
	os.system(command)
it sometimes works. I have not just piped it to tcsh as 
	command = "XYZ"
	print command
Take the above program | tcsh
This works all the time.

Follow-Ups:

Date: 2000-Nov-16 13:42
By: gvanrossum

Comment:
We don't have enough information to go on here. What's the platform used?

It may well have to do with the exact contents of "XYZ". Can you give an example of an XYZ that doesn't work? (As a baseline, an example that *does* work for you would be helpful too.)

I'm not sure what you mean by "large program", but I'm suspecting that you mean "a large amount of sh script code". If this is the case, consider using os.popen() to pipe the script into tcsh under control of your program.

I *think* this is not a bug but a "HOWTO" question.

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

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


From noreply@sourceforge.net  Thu Nov 16 21:42:43 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Nov 2000 13:42:43 -0800
Subject: [Python-bugs-list] [Bug #122625] Using os.system() does not execute some programs
Message-ID: <200011162142.NAA08077@sf-web1.i.sourceforge.net>

Bug #122625, was updated on 2000-Nov-16 13:29
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 3
Summary: Using os.system() does not execute some programs

Details: I do not think I can fully explain what is happening. Here is my attempt.
I use Python as a scripting to run large programs. Sometimes the code I expect python to run in os.system(command) does not run. I cannot figure out why it does not run. 

My guess is that os.system() cannot execute large programs (sometimes?). Becuase when I run
	command = "XYZ"   # whatever long program
	print command
	os.system(command)
it sometimes works. I have not just piped it to tcsh as 
	command = "XYZ"
	print command
Take the above program | tcsh
This works all the time.

Follow-Ups:

Date: 2000-Nov-16 13:42
By: gvanrossum

Comment:
We don't have enough information to go on here. What's the platform used?

It may well have to do with the exact contents of "XYZ". Can you give an example of an XYZ that doesn't work? (As a baseline, an example that *does* work for you would be helpful too.)

I'm not sure what you mean by "large program", but I'm suspecting that you mean "a large amount of sh script code". If this is the case, consider using os.popen() to pipe the script into tcsh under control of your program.

I *think* this is not a bug but a "HOWTO" question.

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

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


From noreply@sourceforge.net  Fri Nov 17 12:11:44 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Nov 2000 04:11:44 -0800
Subject: [Python-bugs-list] [Bug #122680] compile python 2.0 on irix 6.5
Message-ID: <200011171211.EAA17640@sf-web3.vaspecialprojects.com>

Bug #122680, was updated on 2000-Nov-17 04:11
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: compile python 2.0 on irix 6.5

Details: tried to compile python 2.0 with irix6.5
with irix-cc and egcs

'import site' failed; use -v for traceback
Python 2.0 (#3, Nov 17 2000, 13:05:58) 
[GCC egcs-2.91.66 19990314 (egcs-1.1.2 release)] on irix6
Type "copyright", "credits" or "license" for more information.

PYTHONPATH= ./python -tt ./Lib/test/regrtest.py -l
'import site' failed; use -v for traceback
Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 35, in ?
    import string
ImportError: No module named string
gmake: [test] Error 1 (ignored)
PYTHONPATH= ./python -tt ./Lib/test/regrtest.py -l
'import site' failed; use -v for traceback
Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 35, in ?
    import string
ImportError: No module named string
gmake: *** [test] Error 1

nearly same error-message with irix-cc, 
any ideas ??



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


From noreply@sourceforge.net  Fri Nov 17 12:42:58 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Nov 2000 04:42:58 -0800
Subject: [Python-bugs-list] [Bug #122684] Memory leak creating sub-interpreters
Message-ID: <200011171242.EAA18076@sf-web3.vaspecialprojects.com>

Bug #122684, was updated on 2000-Nov-17 04:42
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Memory leak creating sub-interpreters

Details: Instantiating a sub-interpreter in Python 2.0 (compiled with Visual C++ 6 SP4) allocates memory that is never released. The problem can be reproduced using the following sample code:

/* For unmodified Python 2.0 (#8, Oct 16 2000, 17:27:58) */
#include "Python.H"

int main()
{
  Py_Initialize();
  PyEval_InitThreads();
  PyThreadState* mainThread = PyEval_SaveThread();
  for (;;)
  {
    PyEval_AcquireLock();
    Py_EndInterpreter(Py_NewInterpreter());
    PyEval_ReleaseLock();
  }
  PyEval_AcquireThread(mainThread);
  Py_Finalize();
  return 0;
}


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


From noreply@sourceforge.net  Fri Nov 17 13:54:51 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Nov 2000 05:54:51 -0800
Subject: [Python-bugs-list] [Bug #120983] python2.0 dumps core in gc_list_remove
Message-ID: <200011171354.FAA22358@sf-web1.i.sourceforge.net>

Bug #120983, was updated on 2000-Nov-01 01:17
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: python2.0 dumps core in gc_list_remove

Details: Source: downloaded from http://www.python.org
OS: freebsd 4.1
Compilation options: default
  (does not occur when compiled with --without-cycle-gc)
Observed while: running Zope2-cvs.

I have not tested this on other operating systems, but it seems reproducible, if intermittent on freebsd. I will keep the binary and the corefile in case further information is needed.

some information extracted with gdb:

#0  0x80a8ffb in gc_list_remove (node=0x89eab40) at ./gcmodule.c:88
---Type <return> to continue, or q <return> to quit---
88              node->gc_next->gc_prev = node->gc_prev;
(gdb) p node
$1 = (struct _gc_head *) 0x89eab40
(gdb) p node->gc_next
$2 = (struct _gc_head *) 0x0
#0  0x80a8ffb in gc_list_remove (node=0x89eab40) at ./gcmodule.c:88
#1  0x80a9ac3 in _PyGC_Remove (op=0x89eab40) at ./gcmodule.c:523
#2  0x807e01d in instance_dealloc (inst=0x89eab4c) at classobject.c:552
#3  0x808ea46 in insertdict (mp=0x89f004c, key=0x89e3ba8, hash=134733596, 
    value=0x8064d13) at dictobject.c:343
#4  0x808ee01 in PyDict_SetItem (op=0x89f004c, key=0x89e3ba8, value=0x807df1c)
    at dictobject.c:477
#5  0x2836e33c in subclass_simple_setattro (self=0x89ea900, name=0x8835760, 
    v=0x89ead6c) at ./../Components/ExtensionClass/ExtensionClass.c:2174
#6  0x283914cc in _setattro (self=0x89ea900, oname=0x8835760, v=0x89ead6c, 
    setattrf=0x2836e2cc <subclass_simple_setattro>) at ./cPersistence.c:661
#7  0x283915d0 in Per_setattro (self=0x89ea900, oname=0x8835760, v=0x89ead6c)
    at ./cPersistence.c:701
#8  0x80926c5 in PyObject_SetAttr (v=0x89eab40, name=0x89e3ba8, 
    value=0x807df1c) at object.c:767
#9  0x283ae5df in Wrapper_setattro (self=0x8856f70, oname=0x8835760, 
    v=0x89ead6c) at ./../Components/ExtensionClass/Acquisition.c:600

...

(gdb) up
#1  0x80a9ac3 in _PyGC_Remove (op=0x89eab40) at ./gcmodule.c:523
523             gc_list_remove(g);
(gdb) p *g
$4 = {gc_next = 0xc, gc_prev = 0x80db600, gc_refs = 7}
(gdb) up
#2  0x807e01d in instance_dealloc (inst=0x89eab4c) at classobject.c:552
552             PyObject_GC_Fini(inst);
(gdb) p *inst
$6 = {ob_refcnt = 0, ob_type = 0x80d89e0, in_class = 0x88a790c, 
  in_dict = 0x89eeccc}
(gdb) p *inst->ob_type
$7 = {ob_refcnt = 10, ob_type = 0x80db740, ob_size = 0, 
  tp_name = 0x80cb646 "instance", tp_basicsize = 28, tp_itemsize = 0, 
  tp_dealloc = 0x807df1c <instance_dealloc>, tp_print = 0, tp_getattr = 0, 
  tp_setattr = 0, tp_compare = 0x807e860 <instance_compare>, 
  tp_repr = 0x807e690 <instance_repr>, tp_as_number = 0x80d8940, 
  tp_as_sequence = 0x80d8900, tp_as_mapping = 0x80d88ec, 
  tp_hash = 0x807e93c <instance_hash>, tp_call = 0, tp_str = 0, 
  tp_getattro = 0x807e278 <instance_getattr>, 
  tp_setattro = 0x807e388 <instance_setattr>, tp_as_buffer = 0x0, 
  tp_flags = 15, tp_doc = 0x0, tp_traverse = 0x807ead4 <instance_traverse>, 
  tp_clear = 0, tp_xxx7 = 0, tp_xxx8 = 0}
(gdb) p *inst->in_class
$8 = {ob_refcnt = 4, ob_type = 0x80d8880, cl_bases = 0x80fbcac, 
  cl_dict = 0x88a794c, cl_name = 0x88a54c0, cl_getattr = 0x0, 
  cl_setattr = 0x0, cl_delattr = 0x0}



Follow-Ups:

Date: 2000-Nov-01 07:57
By: jhylton

Comment:
From a cursory glance, I would guess this is a problem with the extension classes used by Zope, not with the garbage collector.  
-------------------------------------------------------

Date: 2000-Nov-17 05:54
By: nascheme

Comment:
Tobias, is this core dump still occuring? If it is, can you
provide some details on how to reproduce it?
-------------------------------------------------------

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


From noreply@sourceforge.net  Fri Nov 17 13:54:51 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Nov 2000 05:54:51 -0800
Subject: [Python-bugs-list] [Bug #120983] python2.0 dumps core in gc_list_remove
Message-ID: <200011171354.FAA22362@sf-web1.i.sourceforge.net>

Bug #120983, was updated on 2000-Nov-01 01:17
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: python2.0 dumps core in gc_list_remove

Details: Source: downloaded from http://www.python.org
OS: freebsd 4.1
Compilation options: default
  (does not occur when compiled with --without-cycle-gc)
Observed while: running Zope2-cvs.

I have not tested this on other operating systems, but it seems reproducible, if intermittent on freebsd. I will keep the binary and the corefile in case further information is needed.

some information extracted with gdb:

#0  0x80a8ffb in gc_list_remove (node=0x89eab40) at ./gcmodule.c:88
---Type <return> to continue, or q <return> to quit---
88              node->gc_next->gc_prev = node->gc_prev;
(gdb) p node
$1 = (struct _gc_head *) 0x89eab40
(gdb) p node->gc_next
$2 = (struct _gc_head *) 0x0
#0  0x80a8ffb in gc_list_remove (node=0x89eab40) at ./gcmodule.c:88
#1  0x80a9ac3 in _PyGC_Remove (op=0x89eab40) at ./gcmodule.c:523
#2  0x807e01d in instance_dealloc (inst=0x89eab4c) at classobject.c:552
#3  0x808ea46 in insertdict (mp=0x89f004c, key=0x89e3ba8, hash=134733596, 
    value=0x8064d13) at dictobject.c:343
#4  0x808ee01 in PyDict_SetItem (op=0x89f004c, key=0x89e3ba8, value=0x807df1c)
    at dictobject.c:477
#5  0x2836e33c in subclass_simple_setattro (self=0x89ea900, name=0x8835760, 
    v=0x89ead6c) at ./../Components/ExtensionClass/ExtensionClass.c:2174
#6  0x283914cc in _setattro (self=0x89ea900, oname=0x8835760, v=0x89ead6c, 
    setattrf=0x2836e2cc <subclass_simple_setattro>) at ./cPersistence.c:661
#7  0x283915d0 in Per_setattro (self=0x89ea900, oname=0x8835760, v=0x89ead6c)
    at ./cPersistence.c:701
#8  0x80926c5 in PyObject_SetAttr (v=0x89eab40, name=0x89e3ba8, 
    value=0x807df1c) at object.c:767
#9  0x283ae5df in Wrapper_setattro (self=0x8856f70, oname=0x8835760, 
    v=0x89ead6c) at ./../Components/ExtensionClass/Acquisition.c:600

...

(gdb) up
#1  0x80a9ac3 in _PyGC_Remove (op=0x89eab40) at ./gcmodule.c:523
523             gc_list_remove(g);
(gdb) p *g
$4 = {gc_next = 0xc, gc_prev = 0x80db600, gc_refs = 7}
(gdb) up
#2  0x807e01d in instance_dealloc (inst=0x89eab4c) at classobject.c:552
552             PyObject_GC_Fini(inst);
(gdb) p *inst
$6 = {ob_refcnt = 0, ob_type = 0x80d89e0, in_class = 0x88a790c, 
  in_dict = 0x89eeccc}
(gdb) p *inst->ob_type
$7 = {ob_refcnt = 10, ob_type = 0x80db740, ob_size = 0, 
  tp_name = 0x80cb646 "instance", tp_basicsize = 28, tp_itemsize = 0, 
  tp_dealloc = 0x807df1c <instance_dealloc>, tp_print = 0, tp_getattr = 0, 
  tp_setattr = 0, tp_compare = 0x807e860 <instance_compare>, 
  tp_repr = 0x807e690 <instance_repr>, tp_as_number = 0x80d8940, 
  tp_as_sequence = 0x80d8900, tp_as_mapping = 0x80d88ec, 
  tp_hash = 0x807e93c <instance_hash>, tp_call = 0, tp_str = 0, 
  tp_getattro = 0x807e278 <instance_getattr>, 
  tp_setattro = 0x807e388 <instance_setattr>, tp_as_buffer = 0x0, 
  tp_flags = 15, tp_doc = 0x0, tp_traverse = 0x807ead4 <instance_traverse>, 
  tp_clear = 0, tp_xxx7 = 0, tp_xxx8 = 0}
(gdb) p *inst->in_class
$8 = {ob_refcnt = 4, ob_type = 0x80d8880, cl_bases = 0x80fbcac, 
  cl_dict = 0x88a794c, cl_name = 0x88a54c0, cl_getattr = 0x0, 
  cl_setattr = 0x0, cl_delattr = 0x0}



Follow-Ups:

Date: 2000-Nov-01 07:57
By: jhylton

Comment:
From a cursory glance, I would guess this is a problem with the extension classes used by Zope, not with the garbage collector.  
-------------------------------------------------------

Date: 2000-Nov-17 05:54
By: nascheme

Comment:
Tobias, is this core dump still occuring? If it is, can you
provide some details on how to reproduce it?
-------------------------------------------------------

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


From noreply@sourceforge.net  Fri Nov 17 15:35:19 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Nov 2000 07:35:19 -0800
Subject: [Python-bugs-list] [Bug #122690] invalid default module path
Message-ID: <200011171535.HAA00777@sf-web2.i.sourceforge.net>

Bug #122690, was updated on 2000-Nov-17 07:35
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: invalid default module path

Details: I have installed Python2.0 in a Linux 2.2 box under /usr/local/python/

I can define PYTHONHOME and PYTHONPATH pointing to the correct places and everything will work fine, but If I just do to include "/usr/local/python/bin/" in the PATH, python is unable to find any module from the standart module set.

Is this the correct behaviour?



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


From noreply@sourceforge.net  Fri Nov 17 16:31:56 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Nov 2000 08:31:56 -0800
Subject: [Python-bugs-list] [Bug #122684] Memory leak creating sub-interpreters
Message-ID: <200011171631.IAA01682@sf-web2.i.sourceforge.net>

Bug #122684, was updated on 2000-Nov-17 04:42
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Memory leak creating sub-interpreters

Details: Instantiating a sub-interpreter in Python 2.0 (compiled with Visual C++ 6 SP4) allocates memory that is never released. The problem can be reproduced using the following sample code:

/* For unmodified Python 2.0 (#8, Oct 16 2000, 17:27:58) */
#include "Python.H"

int main()
{
  Py_Initialize();
  PyEval_InitThreads();
  PyThreadState* mainThread = PyEval_SaveThread();
  for (;;)
  {
    PyEval_AcquireLock();
    Py_EndInterpreter(Py_NewInterpreter());
    PyEval_ReleaseLock();
  }
  PyEval_AcquireThread(mainThread);
  Py_Finalize();
  return 0;
}


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


From noreply@sourceforge.net  Fri Nov 17 18:04:24 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Nov 2000 10:04:24 -0800
Subject: [Python-bugs-list] [Bug #122236] 11.4.2 Example 2 contains typos and one bug
Message-ID: <200011171804.KAA03153@sf-web2.i.sourceforge.net>

Bug #122236, was updated on 2000-Nov-12 08:00
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: 11.4.2 Example 2 contains typos and one bug

Details: 
In 11.4.2 Example 2:

Two typos:

h.send(paramstring) -> h.send(params)

print errorcode -> print result

One bug:

For it to work (for example, with an Apache 1.3.14 server and php 4.0), you need this line just after the POST line:

h.putheader("Content-type", "application/x-www-form-urlencoded")

Scott Schram
http://schram.net




Follow-Ups:

Date: 2000-Nov-17 10:04
By: fdrake

Comment:
Fixed & checked in as Doc/lib/libhttplib.tex revision 1.22.
-------------------------------------------------------

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


From noreply@sourceforge.net  Fri Nov 17 18:04:32 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Nov 2000 10:04:32 -0800
Subject: [Python-bugs-list] [Bug #122236] 11.4.2 Example 2 contains typos and one bug
Message-ID: <200011171804.KAA03166@sf-web2.i.sourceforge.net>

Bug #122236, was updated on 2000-Nov-12 08:00
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: 11.4.2 Example 2 contains typos and one bug

Details: 
In 11.4.2 Example 2:

Two typos:

h.send(paramstring) -> h.send(params)

print errorcode -> print result

One bug:

For it to work (for example, with an Apache 1.3.14 server and php 4.0), you need this line just after the POST line:

h.putheader("Content-type", "application/x-www-form-urlencoded")

Scott Schram
http://schram.net




Follow-Ups:

Date: 2000-Nov-17 10:04
By: fdrake

Comment:
Fixed & checked in as Doc/lib/libhttplib.tex revision 1.22.
-------------------------------------------------------

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


From noreply@sourceforge.net  Fri Nov 17 18:12:58 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Nov 2000 10:12:58 -0800
Subject: [Python-bugs-list] [Bug #122564] Some typo errors in Extending & Embedding
Message-ID: <200011171812.KAA03349@sf-web2.i.sourceforge.net>

Bug #122564, was updated on 2000-Nov-15 23:06
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Closed
Resolution: Duplicate
Bug Group: None
Priority: 5
Summary: Some typo errors in Extending & Embedding

Details: While translating into French this document, I found three
typo errors :
 1/ as mentioned in a former message, page 9 for item 'es#',
    "stores into two C variables" should become "stores
    into three C variables"
 2/ page 11 for item ';', "the colon is used" should
    become "the semicolon is used"
 3/ page 14, items 'u' and 'u#' are present twice

That all what I found. I finished my translation yesterday,
and it will be available very soon on :
  http://frpython.sourceforge.net

Gilles

Follow-Ups:

Date: 2000-Nov-17 10:12
By: fdrake

Comment:
Duplicates bug #122562.
-------------------------------------------------------

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


From noreply@sourceforge.net  Fri Nov 17 18:12:57 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Nov 2000 10:12:57 -0800
Subject: [Python-bugs-list] [Bug #122564] Some typo errors in Extending & Embedding
Message-ID: <200011171812.KAA03346@sf-web2.i.sourceforge.net>

Bug #122564, was updated on 2000-Nov-15 23:06
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Some typo errors in Extending & Embedding

Details: While translating into French this document, I found three
typo errors :
 1/ as mentioned in a former message, page 9 for item 'es#',
    "stores into two C variables" should become "stores
    into three C variables"
 2/ page 11 for item ';', "the colon is used" should
    become "the semicolon is used"
 3/ page 14, items 'u' and 'u#' are present twice

That all what I found. I finished my translation yesterday,
and it will be available very soon on :
  http://frpython.sourceforge.net

Gilles

Follow-Ups:

Date: 2000-Nov-17 10:12
By: fdrake

Comment:
Duplicates bug #122562.
-------------------------------------------------------

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


From noreply@sourceforge.net  Fri Nov 17 18:21:48 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Nov 2000 10:21:48 -0800
Subject: [Python-bugs-list] [Bug #122562] Some typo errors in Extending & Embedding
Message-ID: <200011171821.KAA03504@sf-web2.i.sourceforge.net>

Bug #122562, was updated on 2000-Nov-15 23:03
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Some typo errors in Extending & Embedding

Details: While translating into French this document, I found three
typo errors :
 1/ as mentioned in a former message, page 9 for item 'es#',
    "stores into two C variables" should become "stores
    into three C variables"
 2/ page 11 for item ';', "the colon is used" should
    become "the semicolon is used"
 3/ page 14, items 'u' and 'u#' are present twice

That all what I found. I finished my translation yesterday,
and it will be available very soon on :
  http://frpython.sourceforge.net

Gilles

Follow-Ups:

Date: 2000-Nov-17 10:21
By: fdrake

Comment:
Fixed & checked in as Doc/ext/ext.tex revision 1.89.
-------------------------------------------------------

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


From noreply@sourceforge.net  Fri Nov 17 18:21:48 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Nov 2000 10:21:48 -0800
Subject: [Python-bugs-list] [Bug #122562] Some typo errors in Extending & Embedding
Message-ID: <200011171821.KAA03507@sf-web2.i.sourceforge.net>

Bug #122562, was updated on 2000-Nov-15 23:03
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: Some typo errors in Extending & Embedding

Details: While translating into French this document, I found three
typo errors :
 1/ as mentioned in a former message, page 9 for item 'es#',
    "stores into two C variables" should become "stores
    into three C variables"
 2/ page 11 for item ';', "the colon is used" should
    become "the semicolon is used"
 3/ page 14, items 'u' and 'u#' are present twice

That all what I found. I finished my translation yesterday,
and it will be available very soon on :
  http://frpython.sourceforge.net

Gilles

Follow-Ups:

Date: 2000-Nov-17 10:21
By: fdrake

Comment:
Fixed & checked in as Doc/ext/ext.tex revision 1.89.
-------------------------------------------------------

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


From noreply@sourceforge.net  Fri Nov 17 19:06:09 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Nov 2000 11:06:09 -0800
Subject: [Python-bugs-list] [Bug #122273] sunau readframes() docs should mention ULAW conversion
Message-ID: <200011171906.LAA27932@sf-web1.i.sourceforge.net>

Bug #122273, was updated on 2000-Nov-12 19:53
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: sunau readframes() docs should mention ULAW conversion

Details: the docs for the sunau module should have something like the 
following in the readframes() function:

If the data is in ULAW format, readframes() will convert it to
linear format automatically.

thanks,
Anthony

Follow-Ups:

Date: 2000-Nov-17 11:06
By: fdrake

Comment:
Added note to documentation in Doc/lib/libsunau.tex revision 1.4.
-------------------------------------------------------

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


From noreply@sourceforge.net  Fri Nov 17 19:06:09 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Nov 2000 11:06:09 -0800
Subject: [Python-bugs-list] [Bug #122273] sunau readframes() docs should mention ULAW conversion
Message-ID: <200011171906.LAA27935@sf-web1.i.sourceforge.net>

Bug #122273, was updated on 2000-Nov-12 19:53
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: sunau readframes() docs should mention ULAW conversion

Details: the docs for the sunau module should have something like the 
following in the readframes() function:

If the data is in ULAW format, readframes() will convert it to
linear format automatically.

thanks,
Anthony

Follow-Ups:

Date: 2000-Nov-17 11:06
By: fdrake

Comment:
Added note to documentation in Doc/lib/libsunau.tex revision 1.4.
-------------------------------------------------------

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


From noreply@sourceforge.net  Fri Nov 17 19:49:50 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Nov 2000 11:49:50 -0800
Subject: [Python-bugs-list] [Bug #121672] Documentation which needs updating to 2.0
Message-ID: <200011171949.LAA25407@sf-web3.vaspecialprojects.com>

Bug #121672, was updated on 2000-Nov-05 08:27
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: Documentation which needs updating to 2.0

Details: When describing formatting strings while "%s" is described, the new "%r" is not.

Built in function int(val [, radix])  Radix may be 0 in which case it works like string.atoi used to (looks at start of string, if 0x hex, if 0 octal otherwise decimal, or something close)

long(), like int() has an optional radix parameter


Follow-Ups:

Date: 2000-Nov-17 11:49
By: fdrake

Comment:
Fixed in Doc/lib/libstdtypes.tex revision 1.42 and Doc/lib/libfuncs.tex revision 1.72.
-------------------------------------------------------

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


From noreply@sourceforge.net  Fri Nov 17 19:49:50 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Nov 2000 11:49:50 -0800
Subject: [Python-bugs-list] [Bug #121672] Documentation which needs updating to 2.0
Message-ID: <200011171949.LAA25402@sf-web3.vaspecialprojects.com>

Bug #121672, was updated on 2000-Nov-05 08:27
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Documentation which needs updating to 2.0

Details: When describing formatting strings while "%s" is described, the new "%r" is not.

Built in function int(val [, radix])  Radix may be 0 in which case it works like string.atoi used to (looks at start of string, if 0x hex, if 0 octal otherwise decimal, or something close)

long(), like int() has an optional radix parameter


Follow-Ups:

Date: 2000-Nov-17 11:49
By: fdrake

Comment:
Fixed in Doc/lib/libstdtypes.tex revision 1.42 and Doc/lib/libfuncs.tex revision 1.72.
-------------------------------------------------------

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


From noreply@sourceforge.net  Fri Nov 17 19:57:47 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Nov 2000 11:57:47 -0800
Subject: [Python-bugs-list] [Bug #117178] Documentation missing for __iadd__, __isub__, etc.
Message-ID: <200011171957.LAA25531@sf-web3.vaspecialprojects.com>

Bug #117178, was updated on 2000-Oct-18 06:48
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Documentation missing for __iadd__, __isub__, etc.

Details: I understand that __iadd__, __isub__, etc. are the
functions you have to implement in a class for it to
support augmented assignment, but there is no documentation
for them under the 3.3 Special Method Names section. I
searched under the Doc directory for __isub__ and found
nothing at all.


Follow-Ups:

Date: 2000-Oct-30 05:03
By: twouters

Comment:
Sorry, my fault. I wasn't thorough enough in my attempts to write documentation and finding the right place to add it in the current layout. I've submitted a patch, #110216, to fix this.

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

Date: 2000-Nov-08 22:34
By: fdrake

Comment:
The right patch number is #102169.

I've sent the patch back to Thomas for revision, but there's been no activity on it.  I'm adding this note so I don't lose track of this.
-------------------------------------------------------

Date: 2000-Nov-17 11:57
By: fdrake

Comment:
Sent mail to Thomas asking if he expects to make progress on the patch anytime soon.
-------------------------------------------------------

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


From noreply@sourceforge.net  Fri Nov 17 19:57:47 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Nov 2000 11:57:47 -0800
Subject: [Python-bugs-list] [Bug #117178] Documentation missing for __iadd__, __isub__, etc.
Message-ID: <200011171957.LAA25534@sf-web3.vaspecialprojects.com>

Bug #117178, was updated on 2000-Oct-18 06:48
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Documentation missing for __iadd__, __isub__, etc.

Details: I understand that __iadd__, __isub__, etc. are the
functions you have to implement in a class for it to
support augmented assignment, but there is no documentation
for them under the 3.3 Special Method Names section. I
searched under the Doc directory for __isub__ and found
nothing at all.


Follow-Ups:

Date: 2000-Oct-30 05:03
By: twouters

Comment:
Sorry, my fault. I wasn't thorough enough in my attempts to write documentation and finding the right place to add it in the current layout. I've submitted a patch, #110216, to fix this.

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

Date: 2000-Nov-08 22:34
By: fdrake

Comment:
The right patch number is #102169.

I've sent the patch back to Thomas for revision, but there's been no activity on it.  I'm adding this note so I don't lose track of this.
-------------------------------------------------------

Date: 2000-Nov-17 11:57
By: fdrake

Comment:
Sent mail to Thomas asking if he expects to make progress on the patch anytime soon.
-------------------------------------------------------

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


From noreply@sourceforge.net  Fri Nov 17 20:08:22 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Nov 2000 12:08:22 -0800
Subject: [Python-bugs-list] [Bug #122715] __rcmp__() description
Message-ID: <200011172008.MAA25688@sf-web3.vaspecialprojects.com>

Bug #122715, was updated on 2000-Nov-17 12:08
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: __rcmp__() description

Details: The description of the __rcmp__() method in the Python Reference Manual is clearly wrong; can you please correct it, including information about when it is called?  I've received another request for this, and don't see it in the bug database.

[Assigned to Jeremy because Guido says he went through and figured it out at one point.]


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


From noreply@sourceforge.net  Fri Nov 17 22:59:14 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Nov 2000 14:59:14 -0800
Subject: [Python-bugs-list] [Bug #122729] writable not writeable in asyncore
Message-ID: <200011172259.OAA28663@sf-web3.vaspecialprojects.com>

Bug #122729, was updated on 2000-Nov-17 14:59
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: writable not writeable in asyncore

Details: in the asyncore docs it refers to the function as "writeable" when it is "writable"

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


From noreply@sourceforge.net  Sat Nov 18 08:14:12 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 18 Nov 2000 00:14:12 -0800
Subject: [Python-bugs-list] [Bug #122756] BaseHTTPServer subclass I/O call blocks forever
Message-ID: <200011180814.AAA15560@sf-web2.i.sourceforge.net>

Bug #122756, was updated on 2000-Nov-18 00:14
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: BaseHTTPServer subclass I/O call blocks forever

Details: The following BaseHTTPServer subclass blocks in the do_POST() method under Python 2.0, 1.5.2 (on Windows NT and Linux) and JPython 1.1+09.  It seems to block in the write() calls after the read() call.




import BaseHTTPServer 
 
 
class VASTestHTTPRequestHandler(BaseHTTPServer.BaseHTTPRequestHandler): 
 
    contentType="text/html" 
 
    htmlForm="<FORM METHOD=POST ACTION=/handler>\r\n<br>NAME:&nbsp;<INPUT TYPE=\
TEXT NAME=name></INPUT><br><INPUT TYPE=SUBMIT></INPUT><p>\r\n</FORM>\r\n" 
    rspGETContent="<HTML>\r\n<HEAD>\r\n</HEAD>\r\n<BODY>\r\n<H1>GET</H1>\r\n%s<\
/BODY>\r\n</HTML>\r\n" 
 
    rspPOSTContent="\r\n\r\n<HTML>\r\n<HEAD>\r\n</HEAD>\r\n<BODY>\r\n<H1>POST</\
H1>\r\n%s</BODY>\r\n</HTML>\r\n" 
 
    def do_GET(self): 
        self.send_head() 
        self.wfile.write(self.rspGETContent % (self.htmlForm)) 
         
    def do_HEAD(self): 
        self.send_head() 
    def do_POST(self): 
        self.log_message("%s","Processing POST  ...") 
        self.log_message("%s",self.rspPOSTContent % (self.htmlForm)) 
        self.contentLength=int(self.headers.getheader("Content-Length")) 
        self.log_message("content-length=%d",self.contentLength) 
 
        # this read blocks forever 
        self.reqContent=self.rfile.read() 
        self.log_message("%s",self.reqContent) 
 
        self.send_head() 
        self.wfile.write(self.rspPOSTContent % (self.htmlForm)) 
        self.log_message("%s","Processed POST") 
         
    def send_head(self): 
        self.send_response(200) 
        self.send_header("Content-Type",self.contentType) 
        self.send_header("Expires","0") 
        self.end_headers() 
 
    def setContentType(self,type): 
        self.contentType=type 
 
 
def test(HandlerClass = VASTestHTTPRequestHandler, 
         ServerClass = BaseHTTPServer.HTTPServer): 
    port=8888 
    serverAddress=('',port) 
    httpd = ServerClass(serverAddress, HandlerClass) 
 
    print "Serving HTTP on port", port, "..." 
    httpd.serve_forever() 
 
 
if __name__ == '__main__': 
    test() 
 

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


From noreply@sourceforge.net  Sat Nov 18 18:07:49 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 18 Nov 2000 10:07:49 -0800
Subject: [Python-bugs-list] [Bug #122780] msvcrt: locking constants aren't defined.
Message-ID: <200011181807.KAA10472@sf-web3.vaspecialprojects.com>

Bug #122780, was updated on 2000-Nov-18 10:07
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: msvcrt: locking constants aren't defined.

Details: 
msvcrt.locking(fd, mode, nbytes):

mode must be one of the following constants:
LK_UNLOCK = 0 # Unlock
LK_LOCK = 1 # Lock
LK_NBLCK = 2 # Non-blocking lock
LK_RLCK = 3 # Lock for read-only
LK_NBRLCK = 4 # Non-blocking lock for read-only

I think that constants should be defined in msvcrt
and written in the docs.


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


From noreply@sourceforge.net  Mon Nov 20 15:22:37 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 20 Nov 2000 07:22:37 -0800
Subject: [Python-bugs-list] [Bug #122977] ConfigParser.get needs a default arg
Message-ID: <200011201522.HAA24284@sf-web1.i.sourceforge.net>

Bug #122977, was updated on 2000-Nov-20 07:22
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: ConfigParser.get needs a default arg

Details: Seems to me that ConfigParser instances sort of act like dictionaries.  It's just that their keys are effectively (section, name) tuples.  Shouldn't their get methods have a default value?  That would make setting a series of options much simpler.  Instead of having to trap for NoSectionError and NoOptionError, the programmer could just indicate a default:

    cp = ConfigParser.ConfigParser()
    cp.read(somefile)
    self.spam = cp.get("food","spam",0,None,"fried")
    self.eggs = cp.get("food","eggs",0,None,"scrambled")

instead of 

    cp = ConfigParser.ConfigParser()
    cp.read(somefile)
    try:
        self.spam = cp.get("food","spam")
    except (NoSectionError,NoOptionError):
        self.spam = "fried"
    try:
        self.eggs = cp.get("food","eggs")
    except (NoSectionError,NoOptionError):
        self.eggs = "scrambled"

Here's a possible (but untested) patch.  Whether default values should be subject to interpolation is not obvious.

*** /tmp/ConfigParser.py.~1.23~	Mon Nov 20 09:18:14 2000
--- /tmp/ConfigParser.py	Mon Nov 20 09:18:14 2000
***************
*** 249,255 ****
                  filename = '<???>'
          self.__read(fp, filename)
  
!     def get(self, section, option, raw=0, vars=None):
          """Get an option value for a given section.
  
          All % interpolations are expanded in the return values, based on the
--- 249,255 ----
                  filename = '<???>'
          self.__read(fp, filename)
  
!     def get(self, section, option, raw=0, vars=None, default=None):
          """Get an option value for a given section.
  
          All % interpolations are expanded in the return values, based on the
***************
*** 266,272 ****
              if section == DEFAULTSECT:
                  sectdict = {}
              else:
!                 raise NoSectionError(section)
          d = self.__defaults.copy()
          d.update(sectdict)
          # Update with the entry specific variables
--- 266,272 ----
              if section == DEFAULTSECT:
                  sectdict = {}
              else:
!                 return default
          d = self.__defaults.copy()
          d.update(sectdict)
          # Update with the entry specific variables
***************
*** 276,282 ****
          try:
              rawval = d[option]
          except KeyError:
!             raise NoOptionError(option, section)
  
          if raw:
              return rawval
--- 276,282 ----
          try:
              rawval = d[option]
          except KeyError:
!             return default
  
          if raw:
              return rawval


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


From noreply@sourceforge.net  Mon Nov 20 15:54:21 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 20 Nov 2000 07:54:21 -0800
Subject: [Python-bugs-list] [Bug #122977] ConfigParser.get needs a default arg
Message-ID: <200011201554.HAA31869@sf-web2.i.sourceforge.net>

Bug #122977, was updated on 2000-Nov-20 07:22
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: None
Bug Group: Trash
Priority: 5
Summary: ConfigParser.get needs a default arg

Details: Seems to me that ConfigParser instances sort of act like dictionaries.  It's just that their keys are effectively (section, name) tuples.  Shouldn't their get methods have a default value?  That would make setting a series of options much simpler.  Instead of having to trap for NoSectionError and NoOptionError, the programmer could just indicate a default:

    cp = ConfigParser.ConfigParser()
    cp.read(somefile)
    self.spam = cp.get("food","spam",0,None,"fried")
    self.eggs = cp.get("food","eggs",0,None,"scrambled")

instead of 

    cp = ConfigParser.ConfigParser()
    cp.read(somefile)
    try:
        self.spam = cp.get("food","spam")
    except (NoSectionError,NoOptionError):
        self.spam = "fried"
    try:
        self.eggs = cp.get("food","eggs")
    except (NoSectionError,NoOptionError):
        self.eggs = "scrambled"

Here's a possible (but untested) patch.  Whether default values should be subject to interpolation is not obvious.

*** /tmp/ConfigParser.py.~1.23~	Mon Nov 20 09:18:14 2000
--- /tmp/ConfigParser.py	Mon Nov 20 09:18:14 2000
***************
*** 249,255 ****
                  filename = '<???>'
          self.__read(fp, filename)
  
!     def get(self, section, option, raw=0, vars=None):
          """Get an option value for a given section.
  
          All % interpolations are expanded in the return values, based on the
--- 249,255 ----
                  filename = '<???>'
          self.__read(fp, filename)
  
!     def get(self, section, option, raw=0, vars=None, default=None):
          """Get an option value for a given section.
  
          All % interpolations are expanded in the return values, based on the
***************
*** 266,272 ****
              if section == DEFAULTSECT:
                  sectdict = {}
              else:
!                 raise NoSectionError(section)
          d = self.__defaults.copy()
          d.update(sectdict)
          # Update with the entry specific variables
--- 266,272 ----
              if section == DEFAULTSECT:
                  sectdict = {}
              else:
!                 return default
          d = self.__defaults.copy()
          d.update(sectdict)
          # Update with the entry specific variables
***************
*** 276,282 ****
          try:
              rawval = d[option]
          except KeyError:
!             raise NoOptionError(option, section)
  
          if raw:
              return rawval
--- 276,282 ----
          try:
              rawval = d[option]
          except KeyError:
!             return default
  
          if raw:
              return rawval


Follow-Ups:

Date: 2000-Nov-20 07:54
By: montanaro

Comment:
I withdraw this feature request.  I realized that the proper way to set defaults is to perform a series of set() calls followed by a read() call.  The get() method then doesn't require any default arguments.

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

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


From noreply@sourceforge.net  Mon Nov 20 15:54:21 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 20 Nov 2000 07:54:21 -0800
Subject: [Python-bugs-list] [Bug #122977] ConfigParser.get needs a default arg
Message-ID: <200011201554.HAA31866@sf-web2.i.sourceforge.net>

Bug #122977, was updated on 2000-Nov-20 07:22
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: ConfigParser.get needs a default arg

Details: Seems to me that ConfigParser instances sort of act like dictionaries.  It's just that their keys are effectively (section, name) tuples.  Shouldn't their get methods have a default value?  That would make setting a series of options much simpler.  Instead of having to trap for NoSectionError and NoOptionError, the programmer could just indicate a default:

    cp = ConfigParser.ConfigParser()
    cp.read(somefile)
    self.spam = cp.get("food","spam",0,None,"fried")
    self.eggs = cp.get("food","eggs",0,None,"scrambled")

instead of 

    cp = ConfigParser.ConfigParser()
    cp.read(somefile)
    try:
        self.spam = cp.get("food","spam")
    except (NoSectionError,NoOptionError):
        self.spam = "fried"
    try:
        self.eggs = cp.get("food","eggs")
    except (NoSectionError,NoOptionError):
        self.eggs = "scrambled"

Here's a possible (but untested) patch.  Whether default values should be subject to interpolation is not obvious.

*** /tmp/ConfigParser.py.~1.23~	Mon Nov 20 09:18:14 2000
--- /tmp/ConfigParser.py	Mon Nov 20 09:18:14 2000
***************
*** 249,255 ****
                  filename = '<???>'
          self.__read(fp, filename)
  
!     def get(self, section, option, raw=0, vars=None):
          """Get an option value for a given section.
  
          All % interpolations are expanded in the return values, based on the
--- 249,255 ----
                  filename = '<???>'
          self.__read(fp, filename)
  
!     def get(self, section, option, raw=0, vars=None, default=None):
          """Get an option value for a given section.
  
          All % interpolations are expanded in the return values, based on the
***************
*** 266,272 ****
              if section == DEFAULTSECT:
                  sectdict = {}
              else:
!                 raise NoSectionError(section)
          d = self.__defaults.copy()
          d.update(sectdict)
          # Update with the entry specific variables
--- 266,272 ----
              if section == DEFAULTSECT:
                  sectdict = {}
              else:
!                 return default
          d = self.__defaults.copy()
          d.update(sectdict)
          # Update with the entry specific variables
***************
*** 276,282 ****
          try:
              rawval = d[option]
          except KeyError:
!             raise NoOptionError(option, section)
  
          if raw:
              return rawval
--- 276,282 ----
          try:
              rawval = d[option]
          except KeyError:
!             return default
  
          if raw:
              return rawval


Follow-Ups:

Date: 2000-Nov-20 07:54
By: montanaro

Comment:
I withdraw this feature request.  I realized that the proper way to set defaults is to perform a series of set() calls followed by a read() call.  The get() method then doesn't require any default arguments.

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

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


From noreply@sourceforge.net  Mon Nov 20 16:55:02 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 20 Nov 2000 08:55:02 -0800
Subject: [Python-bugs-list] [Bug #122985] threading not ok with GNU pth
Message-ID: <200011201655.IAA26102@sf-web1.i.sourceforge.net>

Bug #122985, was updated on 2000-Nov-20 08:55
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: threading not ok with GNU pth

Details: this program is buggy with GNU pth ...

------
#!/usr/bin/env python

from threading import *


def impr():
  d = 0
  while 1:
    d += 1
    print '|',
    if d % 12 == 0:
      e.set()
      f.clear()
      f.wait()


if __name__ == '__main__':
  T1 = Thread(None, impr, '1')
  e = Event()
  f = Event()
  T1.start()

  c = 0
  while 1:
    c += 1
    print '.',
    if c % 10 == 0 :
      f.set()
      e.clear()
      e.wait()

------

the program gives only :
. . . . . . . . . . | | | | | | | | | | | | . . . . . . . . . 

instead of a eternal serie of 10 dots followed by 12 pipes...

i use pth because i'm on hppa1.1-hp-hpux10.20 and there's no 
standard thread mecanism...


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


From noreply@sourceforge.net  Mon Nov 20 17:12:29 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 20 Nov 2000 09:12:29 -0800
Subject: [Python-bugs-list] [Bug #122986] threading not ok with GNU pth - bis
Message-ID: <200011201712.JAA12801@sf-web3.vaspecialprojects.com>

Bug #122986, was updated on 2000-Nov-20 09:12
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: threading not ok with GNU pth - bis

Details: this program is buggy with GNU pth ...

------
#!/usr/bin/env python

from threading import *


def impr():
..d = 0
..while 1:
....d += 1
....print '|',
....if d % 12 == 0:
......e.set()
......f.clear()
......f.wait()


if __name__ == '__main__':
..T1 = Thread(None, impr, '1')
..e = Event()
..f = Event()
..T1.start()

..c = 0
..while 1:
....c += 1
....print '.',
....if c % 10 == 0 :
......f.set()
......e.clear()
......e.wait()

------

the program gives only :
. . . . . . . . . . | | | | | | | | | | | | . . . . . . . . . 

instead of a eternal serie of 10 dots followed by 12 pipes...

i use pth because i'm on hppa1.1-hp-hpux10.20 and there's no
standard thread mecanism

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


From noreply@sourceforge.net  Mon Nov 20 19:13:27 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 20 Nov 2000 11:13:27 -0800
Subject: [Python-bugs-list] [Bug #114598] Blue Screen crash, popen, Win98, Norton Antivirus 2000
Message-ID: <200011201913.LAA15014@sf-web3.vaspecialprojects.com>

Bug #114598, was updated on 2000-Sep-16 13:24
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Open
Resolution: None
Bug Group: 3rd Party
Priority: 3
Summary: Blue Screen crash, popen, Win98, Norton Antivirus 2000

Details: On Windows 98, all of the os.popen*() functions cause a hard "blue screen" crash requiring a reboot, when Nortin Antivirus 2000 is installed and enabled. (Not with Norton Antivirus version 5, not on Windows 2000.)

While this is probably a bug in Norton Antivirus 2000, and we're already warning for this on the download page, that's not enough (we've seen at least one report in the newsgroup), and it would be good if we could somehow prevent it. Even a call to Py_FatalError is better than the blue screen, and raising os.error would be a *lot* better.

Follow-Ups:

Date: 2000-Sep-16 14:26
By: tim_one

Comment:
I don't know how to stop this.  Pissed away an hour trying to get help on the Symantec site, and eventually found a support board to which I posted this msg:

Product: Norton AntiVirus 2000 6.0 for Windows 95/98/NT
Supported operating system: Windows 98
Action: Run Another Program
Error Message: 
Summary: Blue screen crash

I develop the Windows version of the core Python language. Several reports of blue-screen death on Win98 have been traced to NAV2000.  Here's the exact msg from one such:

An exception 0E has occurred at 0028:C02AD9D0 in VxD IFSMGR(04) + 000050E4. This was called from 0028:C000B511 in VxD VMM(01) + 0000A511. It may be possible to continue normally.

This occurs whenever a user executes a member of the popen family of functions from within Python; for example, this Python program:

import os
p = os.popen("dir")

popen is a std C library function, poorly implemented by Microsoft, but not *that* poorly <wink>.

You can get our latest installer here:

http://www.pythonlabs.com/tech/python2.0/download.html

As the warning there says:

-----------------
Incompatibility warning: Norton Antivirus 2000 can cause blue screen crashes on Windows 98 when a function in the os.popen*() family is invoked. To prevent this problem, disable Norton Antivirus when using Python. (Confirmed on Windows 98 Second Edition with Norton Antivirus version 6.10.20. The same Norton Antivirus version doesn't have this
problem on Windows 2000. Norton Antivirus version 5 on Windows 98SE doesn't have this problem either.) 
-----------------

ActiveState is seeing the same problem with their derivative work ActivePython, as is PythonWare with their derivative work PythonWorks. So this affects a lot of people. A recent change to the implementation of a popular library module has made it acutely visible recently (didn't use to use popen, but does now).

A workaround would be nice. More importantly, how can I *detect* whether an affected version of NAV is in use, so that we can shut down Python gracefully with an appropriate message before executing any of the popen functions that throw NAV into blue-screen territory? We try to be a very user-friendly language, and we'll do anything to prevent a crash. Alas, right now I don't know how to stop it.

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

Date: 2000-Sep-19 02:21
By: tim_one

Comment:
1. Sent Guido a small self-contained C program in the hope that it's enough to provoke the problem by itself.  Reassigned this bug to Guido since he has to tell me what happens with that next (then assign back to me).

2. That's because Symantec is being no help at all.  They suggest upgrading to NAV 2001(!).  If I can post a tiny C program, maybe it will embarrass then into doing something.  You can follow this soap opera at:

http://servicenews.symantec.com/cgi-bin/displayArticle.cgi?group=symantec.support.win9x.nortonantivirus2000.general&article=57765

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

Date: 2000-Sep-19 09:06
By: gvanrossum

Comment:
Tim's little C program crashes in the same way as Python when NAV2000 is enabled. back to Tim...
-------------------------------------------------------

Date: 2000-Sep-21 11:32
By: tim_one

Comment:
I cranked up my obnoxiousness level on the Symantec board (URL two comments down), and they may be on the edge of taking this seriously now.
-------------------------------------------------------

Date: 2000-Sep-22 20:46
By: tim_one

Comment:
Reduced the priority a notch.  The biggest trigger here was IDLE's use of os.popen (indirectly via webbrowser.py) to launch the Python HTML docs.  I put in a new Windows function (os.startfile) that uses Win32 ShellExecute instead, and changed webbrowser.py to use that.  IDLE now lives peacefully with NAV 6.10.20.

This was all Guido's idea, and he suggested that the priority of this bug should be dropped now.
-------------------------------------------------------

Date: 2000-Oct-06 12:23
By: gvanrossum

Comment:
Reduced priority even more. There's not much else we can do about this, it seems, except yell at Norton. :-(
-------------------------------------------------------

Date: 2000-Oct-06 16:23
By: tim_one

Comment:
Indeed, I can detect whether AutoProtect is loaded at system startup, but not whether it's currently running.  Just left another nag on the Symantec board but don't expect a useful response.
-------------------------------------------------------

Date: 2000-Nov-20 11:13
By: tim_one

Comment:
Assigned to Guido cuz there's something I want him to try:

My new desktop box is running Win98SE and has NAV 2000 version 6.10.20.  But I don't have any problem running os.popen with autoprotect engaged.

Could you try using the NAV LiveUpdate facility to make sure all your NAV components are up to date, and try this again?  The virus defs on my box are dated 11/13/2000.

Perhaps also use Windows Update to make sure your OS components are up to date too.
-------------------------------------------------------

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


From noreply@sourceforge.net  Mon Nov 20 19:13:26 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 20 Nov 2000 11:13:26 -0800
Subject: [Python-bugs-list] [Bug #114598] Blue Screen crash, popen, Win98, Norton Antivirus 2000
Message-ID: <200011201913.LAA15011@sf-web3.vaspecialprojects.com>

Bug #114598, was updated on 2000-Sep-16 13:24
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Open
Resolution: None
Bug Group: 3rd Party
Priority: 3
Summary: Blue Screen crash, popen, Win98, Norton Antivirus 2000

Details: On Windows 98, all of the os.popen*() functions cause a hard "blue screen" crash requiring a reboot, when Nortin Antivirus 2000 is installed and enabled. (Not with Norton Antivirus version 5, not on Windows 2000.)

While this is probably a bug in Norton Antivirus 2000, and we're already warning for this on the download page, that's not enough (we've seen at least one report in the newsgroup), and it would be good if we could somehow prevent it. Even a call to Py_FatalError is better than the blue screen, and raising os.error would be a *lot* better.

Follow-Ups:

Date: 2000-Sep-16 14:26
By: tim_one

Comment:
I don't know how to stop this.  Pissed away an hour trying to get help on the Symantec site, and eventually found a support board to which I posted this msg:

Product: Norton AntiVirus 2000 6.0 for Windows 95/98/NT
Supported operating system: Windows 98
Action: Run Another Program
Error Message: 
Summary: Blue screen crash

I develop the Windows version of the core Python language. Several reports of blue-screen death on Win98 have been traced to NAV2000.  Here's the exact msg from one such:

An exception 0E has occurred at 0028:C02AD9D0 in VxD IFSMGR(04) + 000050E4. This was called from 0028:C000B511 in VxD VMM(01) + 0000A511. It may be possible to continue normally.

This occurs whenever a user executes a member of the popen family of functions from within Python; for example, this Python program:

import os
p = os.popen("dir")

popen is a std C library function, poorly implemented by Microsoft, but not *that* poorly <wink>.

You can get our latest installer here:

http://www.pythonlabs.com/tech/python2.0/download.html

As the warning there says:

-----------------
Incompatibility warning: Norton Antivirus 2000 can cause blue screen crashes on Windows 98 when a function in the os.popen*() family is invoked. To prevent this problem, disable Norton Antivirus when using Python. (Confirmed on Windows 98 Second Edition with Norton Antivirus version 6.10.20. The same Norton Antivirus version doesn't have this
problem on Windows 2000. Norton Antivirus version 5 on Windows 98SE doesn't have this problem either.) 
-----------------

ActiveState is seeing the same problem with their derivative work ActivePython, as is PythonWare with their derivative work PythonWorks. So this affects a lot of people. A recent change to the implementation of a popular library module has made it acutely visible recently (didn't use to use popen, but does now).

A workaround would be nice. More importantly, how can I *detect* whether an affected version of NAV is in use, so that we can shut down Python gracefully with an appropriate message before executing any of the popen functions that throw NAV into blue-screen territory? We try to be a very user-friendly language, and we'll do anything to prevent a crash. Alas, right now I don't know how to stop it.

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

Date: 2000-Sep-19 02:21
By: tim_one

Comment:
1. Sent Guido a small self-contained C program in the hope that it's enough to provoke the problem by itself.  Reassigned this bug to Guido since he has to tell me what happens with that next (then assign back to me).

2. That's because Symantec is being no help at all.  They suggest upgrading to NAV 2001(!).  If I can post a tiny C program, maybe it will embarrass then into doing something.  You can follow this soap opera at:

http://servicenews.symantec.com/cgi-bin/displayArticle.cgi?group=symantec.support.win9x.nortonantivirus2000.general&article=57765

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

Date: 2000-Sep-19 09:06
By: gvanrossum

Comment:
Tim's little C program crashes in the same way as Python when NAV2000 is enabled. back to Tim...
-------------------------------------------------------

Date: 2000-Sep-21 11:32
By: tim_one

Comment:
I cranked up my obnoxiousness level on the Symantec board (URL two comments down), and they may be on the edge of taking this seriously now.
-------------------------------------------------------

Date: 2000-Sep-22 20:46
By: tim_one

Comment:
Reduced the priority a notch.  The biggest trigger here was IDLE's use of os.popen (indirectly via webbrowser.py) to launch the Python HTML docs.  I put in a new Windows function (os.startfile) that uses Win32 ShellExecute instead, and changed webbrowser.py to use that.  IDLE now lives peacefully with NAV 6.10.20.

This was all Guido's idea, and he suggested that the priority of this bug should be dropped now.
-------------------------------------------------------

Date: 2000-Oct-06 12:23
By: gvanrossum

Comment:
Reduced priority even more. There's not much else we can do about this, it seems, except yell at Norton. :-(
-------------------------------------------------------

Date: 2000-Oct-06 16:23
By: tim_one

Comment:
Indeed, I can detect whether AutoProtect is loaded at system startup, but not whether it's currently running.  Just left another nag on the Symantec board but don't expect a useful response.
-------------------------------------------------------

Date: 2000-Nov-20 11:13
By: tim_one

Comment:
Assigned to Guido cuz there's something I want him to try:

My new desktop box is running Win98SE and has NAV 2000 version 6.10.20.  But I don't have any problem running os.popen with autoprotect engaged.

Could you try using the NAV LiveUpdate facility to make sure all your NAV components are up to date, and try this again?  The virus defs on my box are dated 11/13/2000.

Perhaps also use Windows Update to make sure your OS components are up to date too.
-------------------------------------------------------

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


From noreply@sourceforge.net  Tue Nov 21 06:41:01 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 20 Nov 2000 22:41:01 -0800
Subject: [Python-bugs-list] [Bug #123045] httplib uses a case-sensitive comparision on HTTP-Version
Message-ID: <200011210641.WAA24687@sf-web3.vaspecialprojects.com>

Bug #123045, was updated on 2000-Nov-20 22:41
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: httplib uses a case-sensitive comparision on HTTP-Version

Details: I am working with an HTTP server that uses a lower-cased "HTTP" in the status line.  The server authors have refered me to RFC 2616 2.1, 3.1, 6.1, which imply that a conforming implementation can return a lower-cased "http" in the status line.  (6.1 defines that a "Status-Line" begins with an "HTTP-Version".  3.1 defines "HTTP-Version" as begining with "HTTP".  2.1 explains that string literals in ABNF are case-insensitive, unless otherwise stated.)

httlib.HTTPResponse.begin determines that the status line is bad if the following code tests true:

    if version[:5] != 'HTTP/'

using a case-sensitive comparison routine.  Subsequent code also uses case insensitive comparison routine.

A similar bug was submitted as #119556, but the resolution did not take case differences into account.


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


From noreply@sourceforge.net  Tue Nov 21 11:24:45 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 21 Nov 2000 03:24:45 -0800
Subject: [Python-bugs-list] [Bug #122985] threading not ok with GNU pth
Message-ID: <200011211124.DAA11169@sf-web1.i.sourceforge.net>

Bug #122985, was updated on 2000-Nov-20 08:55
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: Duplicate
Bug Group: None
Priority: 5
Summary: threading not ok with GNU pth

Details: this program is buggy with GNU pth ...

------
#!/usr/bin/env python

from threading import *


def impr():
  d = 0
  while 1:
    d += 1
    print '|',
    if d % 12 == 0:
      e.set()
      f.clear()
      f.wait()


if __name__ == '__main__':
  T1 = Thread(None, impr, '1')
  e = Event()
  f = Event()
  T1.start()

  c = 0
  while 1:
    c += 1
    print '.',
    if c % 10 == 0 :
      f.set()
      e.clear()
      e.wait()

------

the program gives only :
. . . . . . . . . . | | | | | | | | | | | | . . . . . . . . . 

instead of a eternal serie of 10 dots followed by 12 pipes...

i use pth because i'm on hppa1.1-hp-hpux10.20 and there's no 
standard thread mecanism...


Follow-Ups:

Date: 2000-Nov-21 03:24
By: moshez

Comment:
Duplicate of 122985
-------------------------------------------------------

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


From noreply@sourceforge.net  Tue Nov 21 11:24:45 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 21 Nov 2000 03:24:45 -0800
Subject: [Python-bugs-list] [Bug #122985] threading not ok with GNU pth
Message-ID: <200011211124.DAA11166@sf-web1.i.sourceforge.net>

Bug #122985, was updated on 2000-Nov-20 08:55
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: threading not ok with GNU pth

Details: this program is buggy with GNU pth ...

------
#!/usr/bin/env python

from threading import *


def impr():
  d = 0
  while 1:
    d += 1
    print '|',
    if d % 12 == 0:
      e.set()
      f.clear()
      f.wait()


if __name__ == '__main__':
  T1 = Thread(None, impr, '1')
  e = Event()
  f = Event()
  T1.start()

  c = 0
  while 1:
    c += 1
    print '.',
    if c % 10 == 0 :
      f.set()
      e.clear()
      e.wait()

------

the program gives only :
. . . . . . . . . . | | | | | | | | | | | | . . . . . . . . . 

instead of a eternal serie of 10 dots followed by 12 pipes...

i use pth because i'm on hppa1.1-hp-hpux10.20 and there's no 
standard thread mecanism...


Follow-Ups:

Date: 2000-Nov-21 03:24
By: moshez

Comment:
Duplicate of 122985
-------------------------------------------------------

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


From noreply@sourceforge.net  Tue Nov 21 11:25:31 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 21 Nov 2000 03:25:31 -0800
Subject: [Python-bugs-list] [Bug #122985] threading not ok with GNU pth
Message-ID: <200011211125.DAA11203@sf-web1.i.sourceforge.net>

Bug #122985, was updated on 2000-Nov-20 08:55
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: Duplicate
Bug Group: None
Priority: 5
Summary: threading not ok with GNU pth

Details: this program is buggy with GNU pth ...

------
#!/usr/bin/env python

from threading import *


def impr():
  d = 0
  while 1:
    d += 1
    print '|',
    if d % 12 == 0:
      e.set()
      f.clear()
      f.wait()


if __name__ == '__main__':
  T1 = Thread(None, impr, '1')
  e = Event()
  f = Event()
  T1.start()

  c = 0
  while 1:
    c += 1
    print '.',
    if c % 10 == 0 :
      f.set()
      e.clear()
      e.wait()

------

the program gives only :
. . . . . . . . . . | | | | | | | | | | | | . . . . . . . . . 

instead of a eternal serie of 10 dots followed by 12 pipes...

i use pth because i'm on hppa1.1-hp-hpux10.20 and there's no 
standard thread mecanism...


Follow-Ups:

Date: 2000-Nov-21 03:24
By: moshez

Comment:
Duplicate of 122985
-------------------------------------------------------

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


From noreply@sourceforge.net  Tue Nov 21 17:25:17 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 21 Nov 2000 09:25:17 -0800
Subject: [Python-bugs-list] [Bug #122986] threading not ok with GNU pth - bis
Message-ID: <200011211725.JAA18144@sf-web1.i.sourceforge.net>

Bug #122986, was updated on 2000-Nov-20 09:12
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: threading not ok with GNU pth - bis

Details: this program is buggy with GNU pth ...

------
#!/usr/bin/env python

from threading import *


def impr():
..d = 0
..while 1:
....d += 1
....print '|',
....if d % 12 == 0:
......e.set()
......f.clear()
......f.wait()


if __name__ == '__main__':
..T1 = Thread(None, impr, '1')
..e = Event()
..f = Event()
..T1.start()

..c = 0
..while 1:
....c += 1
....print '.',
....if c % 10 == 0 :
......f.set()
......e.clear()
......e.wait()

------

the program gives only :
. . . . . . . . . . | | | | | | | | | | | | . . . . . . . . . 

instead of a eternal serie of 10 dots followed by 12 pipes...

i use pth because i'm on hppa1.1-hp-hpux10.20 and there's no
standard thread mecanism

Follow-Ups:

Date: 2000-Nov-21 09:25
By: Nobody

Comment:
i tried the same code on sparc-sun-solaris2.5.1 without pth
and i got more lines but still the (rather silly) program hangs!
-------------------------------------------------------

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


From noreply@sourceforge.net  Tue Nov 21 18:34:50 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 21 Nov 2000 10:34:50 -0800
Subject: [Python-bugs-list] [Bug #122986] threading not ok with GNU pth - bis
Message-ID: <200011211834.KAA26185@sf-web2.i.sourceforge.net>

Bug #122986, was updated on 2000-Nov-20 09:12
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: threading not ok with GNU pth - bis

Details: this program is buggy with GNU pth ...

------
#!/usr/bin/env python

from threading import *


def impr():
..d = 0
..while 1:
....d += 1
....print '|',
....if d % 12 == 0:
......e.set()
......f.clear()
......f.wait()


if __name__ == '__main__':
..T1 = Thread(None, impr, '1')
..e = Event()
..f = Event()
..T1.start()

..c = 0
..while 1:
....c += 1
....print '.',
....if c % 10 == 0 :
......f.set()
......e.clear()
......e.wait()

------

the program gives only :
. . . . . . . . . . | | | | | | | | | | | | . . . . . . . . . 

instead of a eternal serie of 10 dots followed by 12 pipes...

i use pth because i'm on hppa1.1-hp-hpux10.20 and there's no
standard thread mecanism

Follow-Ups:

Date: 2000-Nov-21 09:25
By: Nobody

Comment:
i tried the same code on sparc-sun-solaris2.5.1 without pth
and i got more lines but still the (rather silly) program hangs!
-------------------------------------------------------

Date: 2000-Nov-21 10:34
By: tim_one

Comment:
Changed to Invalid and Not-a-Bug, and Closed.

Deadlock is an expected behavior of this test case.  For example, the main thread (M) can have c%10==0 and the spawned thread (S) d%12==0 "at the same time".  Then this sequence is possible:

M executes f.set(), then loses its timeslice.
S executes e.set() and f.clear() and f.wait().
# Now S is hung, waiting for f to get set again.
M executes e.clear() and e.wait().
# Now M is also hung, waiting for e to get set again.

Deadlock.
-------------------------------------------------------

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


From noreply@sourceforge.net  Tue Nov 21 18:34:50 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 21 Nov 2000 10:34:50 -0800
Subject: [Python-bugs-list] [Bug #122986] threading not ok with GNU pth - bis
Message-ID: <200011211834.KAA26188@sf-web2.i.sourceforge.net>

Bug #122986, was updated on 2000-Nov-20 09:12
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: Invalid
Bug Group: Not a Bug
Priority: 5
Summary: threading not ok with GNU pth - bis

Details: this program is buggy with GNU pth ...

------
#!/usr/bin/env python

from threading import *


def impr():
..d = 0
..while 1:
....d += 1
....print '|',
....if d % 12 == 0:
......e.set()
......f.clear()
......f.wait()


if __name__ == '__main__':
..T1 = Thread(None, impr, '1')
..e = Event()
..f = Event()
..T1.start()

..c = 0
..while 1:
....c += 1
....print '.',
....if c % 10 == 0 :
......f.set()
......e.clear()
......e.wait()

------

the program gives only :
. . . . . . . . . . | | | | | | | | | | | | . . . . . . . . . 

instead of a eternal serie of 10 dots followed by 12 pipes...

i use pth because i'm on hppa1.1-hp-hpux10.20 and there's no
standard thread mecanism

Follow-Ups:

Date: 2000-Nov-21 09:25
By: Nobody

Comment:
i tried the same code on sparc-sun-solaris2.5.1 without pth
and i got more lines but still the (rather silly) program hangs!
-------------------------------------------------------

Date: 2000-Nov-21 10:34
By: tim_one

Comment:
Changed to Invalid and Not-a-Bug, and Closed.

Deadlock is an expected behavior of this test case.  For example, the main thread (M) can have c%10==0 and the spawned thread (S) d%12==0 "at the same time".  Then this sequence is possible:

M executes f.set(), then loses its timeslice.
S executes e.set() and f.clear() and f.wait().
# Now S is hung, waiting for f to get set again.
M executes e.clear() and e.wait().
# Now M is also hung, waiting for e to get set again.

Deadlock.
-------------------------------------------------------

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


From noreply@sourceforge.net  Tue Nov 21 18:48:06 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 21 Nov 2000 10:48:06 -0800
Subject: [Python-bugs-list] [Bug #122780] msvcrt: locking constants aren't defined.
Message-ID: <200011211848.KAA19706@sf-web1.i.sourceforge.net>

Bug #122780, was updated on 2000-Nov-18 10:07
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: msvcrt: locking constants aren't defined.

Details: 
msvcrt.locking(fd, mode, nbytes):

mode must be one of the following constants:
LK_UNLOCK = 0 # Unlock
LK_LOCK = 1 # Lock
LK_NBLCK = 2 # Non-blocking lock
LK_RLCK = 3 # Lock for read-only
LK_NBRLCK = 4 # Non-blocking lock for read-only

I think that constants should be defined in msvcrt
and written in the docs.


Follow-Ups:

Date: 2000-Nov-21 10:48
By: tim_one

Comment:
Assigned to me.
-------------------------------------------------------

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


From noreply@sourceforge.net  Tue Nov 21 18:48:06 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 21 Nov 2000 10:48:06 -0800
Subject: [Python-bugs-list] [Bug #122780] msvcrt: locking constants aren't defined.
Message-ID: <200011211848.KAA19709@sf-web1.i.sourceforge.net>

Bug #122780, was updated on 2000-Nov-18 10:07
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: msvcrt: locking constants aren't defined.

Details: 
msvcrt.locking(fd, mode, nbytes):

mode must be one of the following constants:
LK_UNLOCK = 0 # Unlock
LK_LOCK = 1 # Lock
LK_NBLCK = 2 # Non-blocking lock
LK_RLCK = 3 # Lock for read-only
LK_NBRLCK = 4 # Non-blocking lock for read-only

I think that constants should be defined in msvcrt
and written in the docs.


Follow-Ups:

Date: 2000-Nov-21 10:48
By: tim_one

Comment:
Assigned to me.
-------------------------------------------------------

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


From noreply@sourceforge.net  Tue Nov 21 22:23:13 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 21 Nov 2000 14:23:13 -0800
Subject: [Python-bugs-list] [Bug #116677] minidom:Node.appendChild() has wrong semantics
Message-ID: <200011212223.OAA06328@sf-web3.vaspecialprojects.com>

Bug #116677, was updated on 2000-Oct-11 19:24
Here is a current snapshot of the bug.

Project: Python
Category: XML
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Summary: minidom:Node.appendChild() has wrong semantics

Details: Consider this test program:

from xml.dom import minidom
doc = minidom.Document()
root = doc.createElement('root') ; doc.appendChild( root )

elem = doc.createElement('leaf')
root.appendChild( elem )
root.appendChild( elem )

print doc.toxml()
print root.childNodes

It prints:
<root><leaf/><leaf/></root>
[<DOM Element: leaf at 135586476>, <DOM Element: leaf at 135586476>]

'elem' is now linked into the DOM tree in two places, which is wrong; according to the DOM Level 1 spec, 
"If the newChild is already in the tree, it is first removed."



Follow-Ups:

Date: 2000-Oct-11 19:55
By: fdrake

Comment:
Andrew:  Are you using 2.0c1 or CVS?
-------------------------------------------------------

Date: 2000-Oct-11 20:11
By: akuchling

Comment:
CVS as of this evening.  Did it work before?

(Hmm... tonight test_minidom is failing for me for some reason.  
Wonder if it's related?)
-------------------------------------------------------

Date: 2000-Oct-12 07:37
By: Nobody

Comment:
The test_minidom failure turned out to be caused by something else.  However, I rechecked my test case and it's still broken with tonight's CVS.
-------------------------------------------------------

Date: 2000-Oct-16 00:43
By: loewis

Comment:
This is indeed a bug in minidom, but I don't think it should be corrected for 2.0; I suggest to reduce the priority of it, or close it as "later".

While this is a deviation from the DOM spec, it seems as a border case. As such, it should be documented; users can always explicitly remove the node before appending it elsewhere.
-------------------------------------------------------

Date: 2000-Oct-16 06:47
By: akuchling

Comment:
I don't see why this particular deviation is a border case.
All the methods for modifying a DOM tree -- appendChild(),
insertBefore(), replaceChild() -- all behave the same way,
first removing the added node if it's already in the tree somewhere.  This will make it more difficult to translate DOM-using code from, say, Java, to Python + minidom, since you'll have to remember to add extra .removeChild() calls.
Worse still, the problems caused by this will be hard to track down; portions of your DOM tree are aliased, but .toxml() won't make this clear.
-------------------------------------------------------

Date: 2000-Nov-21 14:23
By: fdrake

Comment:
Re-categorized this bug to "XML".

This is *not* fixed by Lib/xml/dom/minidom.py revision 1.14.

Unfortunately, this bug will be a little harder to fix.  I looked to see if I could determine presence in the tree by checking for parentNode != None, but that isn't sufficient.  xml.dom.pulldom maintains state by filling in the parentNode attribute, so it has a chain of ancestors; it needs this to find the node to add children to in DOMEventStream.expandNode().  Testing that a node is already in the tree is harder, but not much harder.  A reasonable fix for this bug should not be difficult.
-------------------------------------------------------

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


From noreply@sourceforge.net  Tue Nov 21 22:23:12 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 21 Nov 2000 14:23:12 -0800
Subject: [Python-bugs-list] [Bug #116677] minidom:Node.appendChild() has wrong semantics
Message-ID: <200011212223.OAA06325@sf-web3.vaspecialprojects.com>

Bug #116677, was updated on 2000-Oct-11 19:24
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Summary: minidom:Node.appendChild() has wrong semantics

Details: Consider this test program:

from xml.dom import minidom
doc = minidom.Document()
root = doc.createElement('root') ; doc.appendChild( root )

elem = doc.createElement('leaf')
root.appendChild( elem )
root.appendChild( elem )

print doc.toxml()
print root.childNodes

It prints:
<root><leaf/><leaf/></root>
[<DOM Element: leaf at 135586476>, <DOM Element: leaf at 135586476>]

'elem' is now linked into the DOM tree in two places, which is wrong; according to the DOM Level 1 spec, 
"If the newChild is already in the tree, it is first removed."



Follow-Ups:

Date: 2000-Oct-11 19:55
By: fdrake

Comment:
Andrew:  Are you using 2.0c1 or CVS?
-------------------------------------------------------

Date: 2000-Oct-11 20:11
By: akuchling

Comment:
CVS as of this evening.  Did it work before?

(Hmm... tonight test_minidom is failing for me for some reason.  
Wonder if it's related?)
-------------------------------------------------------

Date: 2000-Oct-12 07:37
By: Nobody

Comment:
The test_minidom failure turned out to be caused by something else.  However, I rechecked my test case and it's still broken with tonight's CVS.
-------------------------------------------------------

Date: 2000-Oct-16 00:43
By: loewis

Comment:
This is indeed a bug in minidom, but I don't think it should be corrected for 2.0; I suggest to reduce the priority of it, or close it as "later".

While this is a deviation from the DOM spec, it seems as a border case. As such, it should be documented; users can always explicitly remove the node before appending it elsewhere.
-------------------------------------------------------

Date: 2000-Oct-16 06:47
By: akuchling

Comment:
I don't see why this particular deviation is a border case.
All the methods for modifying a DOM tree -- appendChild(),
insertBefore(), replaceChild() -- all behave the same way,
first removing the added node if it's already in the tree somewhere.  This will make it more difficult to translate DOM-using code from, say, Java, to Python + minidom, since you'll have to remember to add extra .removeChild() calls.
Worse still, the problems caused by this will be hard to track down; portions of your DOM tree are aliased, but .toxml() won't make this clear.
-------------------------------------------------------

Date: 2000-Nov-21 14:23
By: fdrake

Comment:
Re-categorized this bug to "XML".

This is *not* fixed by Lib/xml/dom/minidom.py revision 1.14.

Unfortunately, this bug will be a little harder to fix.  I looked to see if I could determine presence in the tree by checking for parentNode != None, but that isn't sufficient.  xml.dom.pulldom maintains state by filling in the parentNode attribute, so it has a chain of ancestors; it needs this to find the node to add children to in DOMEventStream.expandNode().  Testing that a node is already in the tree is harder, but not much harder.  A reasonable fix for this bug should not be difficult.
-------------------------------------------------------

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


From noreply@sourceforge.net  Tue Nov 21 22:33:06 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 21 Nov 2000 14:33:06 -0800
Subject: [Python-bugs-list] [Bug #116678] minidom doesn't raise exception for illegal children
Message-ID: <200011212233.OAA30473@sf-web2.i.sourceforge.net>

Bug #116678, was updated on 2000-Oct-11 19:30
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 6
Summary: minidom doesn't raise exception for illegal children

Details: Some types of DOM node such as Text can't have children.
minidom doesn't check for this at all:

from xml.dom import minidom
doc = minidom.Document()
text = doc.createTextNode('lorem ipsum')
elem = doc.createElement('leaf')
text.appendChild( elem )
print text.toxml()

This outputs just 'lorem ipsum', but elem really is a child 
of text; Text.toxml() just isn't recursing because it doesn't expect to do so.



Follow-Ups:

Date: 2000-Oct-12 20:02
By: fdrake

Comment:
This is a bug with detecting an improper use.  It should be fixed, but need not be for Python 2.0.  Correct use will not produce erroneous behavior.  Reducing priority by one.
-------------------------------------------------------

Date: 2000-Oct-15 07:06
By: loewis

Comment:
I believe this is not a bug, but an intended deviation from the DOM spec.
minidom (as the proposed documentation in patch 101821 explains) does
not support the IDL exceptions of module DOM, so it cannot report errors about improper usage.
-------------------------------------------------------

Date: 2000-Nov-21 14:33
By: fdrake

Comment:
From the documentation, I'd expect the Pythonic "moral equivalents" to be raised, which would be a ValueError in the case of illegal node types.

I'll even go so far as to say that ValueError should be raised when a second documentElement is appended, instead of a TypeError, to be more consistent with usage else where in the standard library:  Pythonic style is to raise a ValueError when the type of a value is right (in this case, a DOM Node), but the specific value is not acceptable, either because it is illegal or because it cannot be accepted given existing state (like already having a documentElement).
-------------------------------------------------------

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


From noreply@sourceforge.net  Tue Nov 21 22:33:06 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 21 Nov 2000 14:33:06 -0800
Subject: [Python-bugs-list] [Bug #116678] minidom doesn't raise exception for illegal children
Message-ID: <200011212233.OAA30476@sf-web2.i.sourceforge.net>

Bug #116678, was updated on 2000-Oct-11 19:30
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 6
Summary: minidom doesn't raise exception for illegal children

Details: Some types of DOM node such as Text can't have children.
minidom doesn't check for this at all:

from xml.dom import minidom
doc = minidom.Document()
text = doc.createTextNode('lorem ipsum')
elem = doc.createElement('leaf')
text.appendChild( elem )
print text.toxml()

This outputs just 'lorem ipsum', but elem really is a child 
of text; Text.toxml() just isn't recursing because it doesn't expect to do so.



Follow-Ups:

Date: 2000-Oct-12 20:02
By: fdrake

Comment:
This is a bug with detecting an improper use.  It should be fixed, but need not be for Python 2.0.  Correct use will not produce erroneous behavior.  Reducing priority by one.
-------------------------------------------------------

Date: 2000-Oct-15 07:06
By: loewis

Comment:
I believe this is not a bug, but an intended deviation from the DOM spec.
minidom (as the proposed documentation in patch 101821 explains) does
not support the IDL exceptions of module DOM, so it cannot report errors about improper usage.
-------------------------------------------------------

Date: 2000-Nov-21 14:33
By: fdrake

Comment:
From the documentation, I'd expect the Pythonic "moral equivalents" to be raised, which would be a ValueError in the case of illegal node types.

I'll even go so far as to say that ValueError should be raised when a second documentElement is appended, instead of a TypeError, to be more consistent with usage else where in the standard library:  Pythonic style is to raise a ValueError when the type of a value is right (in this case, a DOM Node), but the specific value is not acceptable, either because it is illegal or because it cannot be accepted given existing state (like already having a documentElement).
-------------------------------------------------------

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


From noreply@sourceforge.net  Tue Nov 21 22:33:42 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 21 Nov 2000 14:33:42 -0800
Subject: [Python-bugs-list] [Bug #116678] minidom doesn't raise exception for illegal children
Message-ID: <200011212233.OAA30494@sf-web2.i.sourceforge.net>

Bug #116678, was updated on 2000-Oct-11 19:30
Here is a current snapshot of the bug.

Project: Python
Category: XML
Status: Open
Resolution: None
Bug Group: None
Priority: 6
Summary: minidom doesn't raise exception for illegal children

Details: Some types of DOM node such as Text can't have children.
minidom doesn't check for this at all:

from xml.dom import minidom
doc = minidom.Document()
text = doc.createTextNode('lorem ipsum')
elem = doc.createElement('leaf')
text.appendChild( elem )
print text.toxml()

This outputs just 'lorem ipsum', but elem really is a child 
of text; Text.toxml() just isn't recursing because it doesn't expect to do so.



Follow-Ups:

Date: 2000-Oct-12 20:02
By: fdrake

Comment:
This is a bug with detecting an improper use.  It should be fixed, but need not be for Python 2.0.  Correct use will not produce erroneous behavior.  Reducing priority by one.
-------------------------------------------------------

Date: 2000-Oct-15 07:06
By: loewis

Comment:
I believe this is not a bug, but an intended deviation from the DOM spec.
minidom (as the proposed documentation in patch 101821 explains) does
not support the IDL exceptions of module DOM, so it cannot report errors about improper usage.
-------------------------------------------------------

Date: 2000-Nov-21 14:33
By: fdrake

Comment:
From the documentation, I'd expect the Pythonic "moral equivalents" to be raised, which would be a ValueError in the case of illegal node types.

I'll even go so far as to say that ValueError should be raised when a second documentElement is appended, instead of a TypeError, to be more consistent with usage else where in the standard library:  Pythonic style is to raise a ValueError when the type of a value is right (in this case, a DOM Node), but the specific value is not acceptable, either because it is illegal or because it cannot be accepted given existing state (like already having a documentElement).
-------------------------------------------------------

Date: 2000-Nov-21 14:33
By: fdrake

Comment:
Oops, should re-categorize this as "XML" while I'm at it.
-------------------------------------------------------

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


From noreply@sourceforge.net  Tue Nov 21 22:33:41 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 21 Nov 2000 14:33:41 -0800
Subject: [Python-bugs-list] [Bug #116678] minidom doesn't raise exception for illegal children
Message-ID: <200011212233.OAA30491@sf-web2.i.sourceforge.net>

Bug #116678, was updated on 2000-Oct-11 19:30
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 6
Summary: minidom doesn't raise exception for illegal children

Details: Some types of DOM node such as Text can't have children.
minidom doesn't check for this at all:

from xml.dom import minidom
doc = minidom.Document()
text = doc.createTextNode('lorem ipsum')
elem = doc.createElement('leaf')
text.appendChild( elem )
print text.toxml()

This outputs just 'lorem ipsum', but elem really is a child 
of text; Text.toxml() just isn't recursing because it doesn't expect to do so.



Follow-Ups:

Date: 2000-Oct-12 20:02
By: fdrake

Comment:
This is a bug with detecting an improper use.  It should be fixed, but need not be for Python 2.0.  Correct use will not produce erroneous behavior.  Reducing priority by one.
-------------------------------------------------------

Date: 2000-Oct-15 07:06
By: loewis

Comment:
I believe this is not a bug, but an intended deviation from the DOM spec.
minidom (as the proposed documentation in patch 101821 explains) does
not support the IDL exceptions of module DOM, so it cannot report errors about improper usage.
-------------------------------------------------------

Date: 2000-Nov-21 14:33
By: fdrake

Comment:
From the documentation, I'd expect the Pythonic "moral equivalents" to be raised, which would be a ValueError in the case of illegal node types.

I'll even go so far as to say that ValueError should be raised when a second documentElement is appended, instead of a TypeError, to be more consistent with usage else where in the standard library:  Pythonic style is to raise a ValueError when the type of a value is right (in this case, a DOM Node), but the specific value is not acceptable, either because it is illegal or because it cannot be accepted given existing state (like already having a documentElement).
-------------------------------------------------------

Date: 2000-Nov-21 14:33
By: fdrake

Comment:
Oops, should re-categorize this as "XML" while I'm at it.
-------------------------------------------------------

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


From noreply@sourceforge.net  Wed Nov 22 06:20:11 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 21 Nov 2000 22:20:11 -0800
Subject: [Python-bugs-list] [Bug #123045] httplib uses a case-sensitive comparision on HTTP-Version
Message-ID: <200011220620.WAA12291@sf-web3.vaspecialprojects.com>

Bug #123045, was updated on 2000-Nov-20 22:41
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: httplib uses a case-sensitive comparision on HTTP-Version

Details: I am working with an HTTP server that uses a lower-cased "HTTP" in the status line.  The server authors have refered me to RFC 2616 2.1, 3.1, 6.1, which imply that a conforming implementation can return a lower-cased "http" in the status line.  (6.1 defines that a "Status-Line" begins with an "HTTP-Version".  3.1 defines "HTTP-Version" as begining with "HTTP".  2.1 explains that string literals in ABNF are case-insensitive, unless otherwise stated.)

httlib.HTTPResponse.begin determines that the status line is bad if the following code tests true:

    if version[:5] != 'HTTP/'

using a case-sensitive comparison routine.  Subsequent code also uses case insensitive comparison routine.

A similar bug was submitted as #119556, but the resolution did not take case differences into account.


Follow-Ups:

Date: 2000-Nov-21 22:20
By: gstein

Comment:
I exchanged an email with Roy Fielding, author of RFC 2616 and explained the situation. He stated the /intent/ was to be case-sensitive. Further, that if the RFC implies/states otherwise, then it was a mistake (and one which probably happened during some last minute edits).

Roy was rather emphatic that the HTTP should be in upper case and that any client or server using anything different is broken (read: non-conforming).

Based on Roy's expert feedback, I'm closing this bug as "Invalid" / "Won't fix".

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

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


From noreply@sourceforge.net  Wed Nov 22 06:20:11 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 21 Nov 2000 22:20:11 -0800
Subject: [Python-bugs-list] [Bug #123045] httplib uses a case-sensitive comparision on HTTP-Version
Message-ID: <200011220620.WAA12294@sf-web3.vaspecialprojects.com>

Bug #123045, was updated on 2000-Nov-20 22:41
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: Invalid
Bug Group: None
Priority: 5
Summary: httplib uses a case-sensitive comparision on HTTP-Version

Details: I am working with an HTTP server that uses a lower-cased "HTTP" in the status line.  The server authors have refered me to RFC 2616 2.1, 3.1, 6.1, which imply that a conforming implementation can return a lower-cased "http" in the status line.  (6.1 defines that a "Status-Line" begins with an "HTTP-Version".  3.1 defines "HTTP-Version" as begining with "HTTP".  2.1 explains that string literals in ABNF are case-insensitive, unless otherwise stated.)

httlib.HTTPResponse.begin determines that the status line is bad if the following code tests true:

    if version[:5] != 'HTTP/'

using a case-sensitive comparison routine.  Subsequent code also uses case insensitive comparison routine.

A similar bug was submitted as #119556, but the resolution did not take case differences into account.


Follow-Ups:

Date: 2000-Nov-21 22:20
By: gstein

Comment:
I exchanged an email with Roy Fielding, author of RFC 2616 and explained the situation. He stated the /intent/ was to be case-sensitive. Further, that if the RFC implies/states otherwise, then it was a mistake (and one which probably happened during some last minute edits).

Roy was rather emphatic that the HTTP should be in upper case and that any client or server using anything different is broken (read: non-conforming).

Based on Roy's expert feedback, I'm closing this bug as "Invalid" / "Won't fix".

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

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


From noreply@sourceforge.net  Wed Nov 22 15:22:29 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 22 Nov 2000 07:22:29 -0800
Subject: [Python-bugs-list] [Bug #123166] Python20 installation overwrite a newer pdh.dll
Message-ID: <200011221522.HAA19889@sf-web3.vaspecialprojects.com>

Bug #123166, was updated on 2000-Nov-22 07:22
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Python20 installation overwrite a newer pdh.dll

Details: I installed python 2.0 on WinNT 4.0.  I use the version 5.00.1605.1 of the library pdh.dll.
After the installation, I notice that the pdh.dll has been replace by an older version of this library.
Normally, the python installation should rewrite a library only to update it to a new version.

tank you.

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


From noreply@sourceforge.net  Wed Nov 22 15:34:09 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 22 Nov 2000 07:34:09 -0800
Subject: [Python-bugs-list] [Bug #123166] Python20 installation overwrite a newer pdh.dll
Message-ID: <200011221534.HAA06624@sf-web1.i.sourceforge.net>

Bug #123166, was updated on 2000-Nov-22 07:22
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Python20 installation overwrite a newer pdh.dll

Details: I installed python 2.0 on WinNT 4.0.  I use the version 5.00.1605.1 of the library pdh.dll.
After the installation, I notice that the pdh.dll has been replace by an older version of this library.
Normally, the python installation should rewrite a library only to update it to a new version.

tank you.

Follow-Ups:

Date: 2000-Nov-22 07:34
By: tim_one

Comment:
I find this hard to believe:  the only system DLLs the installer contains are MSVCIRT.DLL and MSVCRT.DLL.

Look at the file install.log in the root of your installed Python tree.  Is pdh.dll mentioned in there?

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

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


From noreply@sourceforge.net  Wed Nov 22 15:34:09 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 22 Nov 2000 07:34:09 -0800
Subject: [Python-bugs-list] [Bug #123166] Python20 installation overwrite a newer pdh.dll
Message-ID: <200011221534.HAA06621@sf-web1.i.sourceforge.net>

Bug #123166, was updated on 2000-Nov-22 07:22
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Python20 installation overwrite a newer pdh.dll

Details: I installed python 2.0 on WinNT 4.0.  I use the version 5.00.1605.1 of the library pdh.dll.
After the installation, I notice that the pdh.dll has been replace by an older version of this library.
Normally, the python installation should rewrite a library only to update it to a new version.

tank you.

Follow-Ups:

Date: 2000-Nov-22 07:34
By: tim_one

Comment:
I find this hard to believe:  the only system DLLs the installer contains are MSVCIRT.DLL and MSVCRT.DLL.

Look at the file install.log in the root of your installed Python tree.  Is pdh.dll mentioned in there?

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

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


From noreply@sourceforge.net  Wed Nov 22 15:50:20 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 22 Nov 2000 07:50:20 -0800
Subject: [Python-bugs-list] [Bug #123166] Python20 installation overwrite a newer pdh.dll
Message-ID: <200011221550.HAA06876@sf-web1.i.sourceforge.net>

Bug #123166, was updated on 2000-Nov-22 07:22
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Python20 installation overwrite a newer pdh.dll

Details: I installed python 2.0 on WinNT 4.0.  I use the version 5.00.1605.1 of the library pdh.dll.
After the installation, I notice that the pdh.dll has been replace by an older version of this library.
Normally, the python installation should rewrite a library only to update it to a new version.

tank you.

Follow-Ups:

Date: 2000-Nov-22 07:34
By: tim_one

Comment:
I find this hard to believe:  the only system DLLs the installer contains are MSVCIRT.DLL and MSVCRT.DLL.

Look at the file install.log in the root of your installed Python tree.  Is pdh.dll mentioned in there?

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

Date: 2000-Nov-22 07:50
By: pbmtl

Comment:
Sorry, I think is not a python 2.0 problem.  I look at the install.log file and there is nothing about the file pdh.dll.
I also installed the win32all-135.exe from ActiveState after python 2.0.  It should be the source of my problem.

thank you very much
-------------------------------------------------------

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


From noreply@sourceforge.net  Wed Nov 22 22:18:21 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 22 Nov 2000 14:18:21 -0800
Subject: [Python-bugs-list] [Bug #123166] Python20 installation overwrite a newer pdh.dll
Message-ID: <200011222218.OAA13953@sf-web1.i.sourceforge.net>

Bug #123166, was updated on 2000-Nov-22 07:22
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Python20 installation overwrite a newer pdh.dll

Details: I installed python 2.0 on WinNT 4.0.  I use the version 5.00.1605.1 of the library pdh.dll.
After the installation, I notice that the pdh.dll has been replace by an older version of this library.
Normally, the python installation should rewrite a library only to update it to a new version.

tank you.

Follow-Ups:

Date: 2000-Nov-22 07:34
By: tim_one

Comment:
I find this hard to believe:  the only system DLLs the installer contains are MSVCIRT.DLL and MSVCRT.DLL.

Look at the file install.log in the root of your installed Python tree.  Is pdh.dll mentioned in there?

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

Date: 2000-Nov-22 07:50
By: pbmtl

Comment:
Sorry, I think is not a python 2.0 problem.  I look at the install.log file and there is nothing about the file pdh.dll.
I also installed the win32all-135.exe from ActiveState after python 2.0.  It should be the source of my problem.

thank you very much
-------------------------------------------------------

Date: 2000-Nov-22 14:18
By: tim_one

Comment:
Thank you for following up!  I've closed the bug based on best current information, but left it assigned to me:  if you determine that it really is the fault of the Python 2.0 installer (I don't see how, but ...), just add another note to this report saying so and I'll reopen it.  Certainly agree that no installer should overwrite DLLs with older versions.
-------------------------------------------------------

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


From noreply@sourceforge.net  Wed Nov 22 22:18:21 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 22 Nov 2000 14:18:21 -0800
Subject: [Python-bugs-list] [Bug #123166] Python20 installation overwrite a newer pdh.dll
Message-ID: <200011222218.OAA13956@sf-web1.i.sourceforge.net>

Bug #123166, was updated on 2000-Nov-22 07:22
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Closed
Resolution: Invalid
Bug Group: Not a Bug
Priority: 5
Summary: Python20 installation overwrite a newer pdh.dll

Details: I installed python 2.0 on WinNT 4.0.  I use the version 5.00.1605.1 of the library pdh.dll.
After the installation, I notice that the pdh.dll has been replace by an older version of this library.
Normally, the python installation should rewrite a library only to update it to a new version.

tank you.

Follow-Ups:

Date: 2000-Nov-22 07:34
By: tim_one

Comment:
I find this hard to believe:  the only system DLLs the installer contains are MSVCIRT.DLL and MSVCRT.DLL.

Look at the file install.log in the root of your installed Python tree.  Is pdh.dll mentioned in there?

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

Date: 2000-Nov-22 07:50
By: pbmtl

Comment:
Sorry, I think is not a python 2.0 problem.  I look at the install.log file and there is nothing about the file pdh.dll.
I also installed the win32all-135.exe from ActiveState after python 2.0.  It should be the source of my problem.

thank you very much
-------------------------------------------------------

Date: 2000-Nov-22 14:18
By: tim_one

Comment:
Thank you for following up!  I've closed the bug based on best current information, but left it assigned to me:  if you determine that it really is the fault of the Python 2.0 installer (I don't see how, but ...), just add another note to this report saying so and I'll reopen it.  Certainly agree that no installer should overwrite DLLs with older versions.
-------------------------------------------------------

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


From noreply@sourceforge.net  Wed Nov 22 22:38:31 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 22 Nov 2000 14:38:31 -0800
Subject: [Python-bugs-list] [Bug #122517] problems to compile 2.0 on IRIX 6.5
Message-ID: <200011222238.OAA21774@sf-web2.i.sourceforge.net>

Bug #122517, was updated on 2000-Nov-15 10:20
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: problems to compile 2.0 on IRIX 6.5

Details: ./configure --prefix=/usr/local/sbin/python/ --with-threads --without-gcc --with-cxx=CC

no errors...

gmake test:

PYTHONPATH= ./python -tt ./Lib/test/regrtest.py -l
'import site' failed; use -v for traceback
Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 35, in ?
    import string
ImportError: No module named string
gmake: [test] Error 1 (ignored)
PYTHONPATH= ./python -tt ./Lib/test/regrtest.py -l
'import site' failed; use -v for traceback
Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 35, in ?
    import string
ImportError: No module named string
gmake: *** [test] Error 1


Follow-Ups:

Date: 2000-Nov-22 14:38
By: cgw

Comment:
I am unable to reproduce this on:
	IRIX64 6.5 04191225 IP27
	MIPSpro Compilers: Version 7.30

using the identical ./configure command

Suggest doing a "make distclean" and retrying.

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

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


From noreply@sourceforge.net  Wed Nov 22 22:41:38 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 22 Nov 2000 14:41:38 -0800
Subject: [Python-bugs-list] [Bug #122680] compile python 2.0 on irix 6.5
Message-ID: <200011222241.OAA21829@sf-web2.i.sourceforge.net>

Bug #122680, was updated on 2000-Nov-17 04:11
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: compile python 2.0 on irix 6.5

Details: tried to compile python 2.0 with irix6.5
with irix-cc and egcs

'import site' failed; use -v for traceback
Python 2.0 (#3, Nov 17 2000, 13:05:58) 
[GCC egcs-2.91.66 19990314 (egcs-1.1.2 release)] on irix6
Type "copyright", "credits" or "license" for more information.

PYTHONPATH= ./python -tt ./Lib/test/regrtest.py -l
'import site' failed; use -v for traceback
Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 35, in ?
    import string
ImportError: No module named string
gmake: [test] Error 1 (ignored)
PYTHONPATH= ./python -tt ./Lib/test/regrtest.py -l
'import site' failed; use -v for traceback
Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 35, in ?
    import string
ImportError: No module named string
gmake: *** [test] Error 1

nearly same error-message with irix-cc, 
any ideas ??



Follow-Ups:

Date: 2000-Nov-22 14:41
By: cgw

Comment:
Are you the same "Nobody" who submitted bug #122517?
This looks like a nearly identical bug report.  I cannot
reproduce this on:
	IRIX64 6.5 04191225 IP27
	MIPSpro Compilers:  Version 7.30

Suggest doing a "make distclean" and retrying.
Possibly you have a corrupt source installation or something else is wrong with your system.

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

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


From noreply@sourceforge.net  Thu Nov 23 04:41:30 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 22 Nov 2000 20:41:30 -0800
Subject: [Python-bugs-list] [Bug #123225] asyncore.py should use select.poll(), not "import poll"
Message-ID: <200011230441.UAA26621@sf-web2.i.sourceforge.net>

Bug #123225, was updated on 2000-Nov-22 20:41
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: Not a Bug
Priority: 5
Summary: asyncore.py should use select.poll(), not "import poll"

Details: The Python2.0 asyncore module is able to use the poll system call
(claimed to be much more efficient than select for large numbers of requests),
however, it tries to "import poll", which fails (there is no pollmodule supplied with Python2.0), whereas it could
use the poll available with the select module (select.poll()).



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


From noreply@sourceforge.net  Thu Nov 23 16:07:58 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 23 Nov 2000 08:07:58 -0800
Subject: [Python-bugs-list] [Bug #116678] minidom doesn't raise exception for illegal children
Message-ID: <200011231607.IAA08024@sf-web3.vaspecialprojects.com>

Bug #116678, was updated on 2000-Oct-11 19:30
Here is a current snapshot of the bug.

Project: Python
Category: XML
Status: Open
Resolution: None
Bug Group: None
Priority: 6
Summary: minidom doesn't raise exception for illegal children

Details: Some types of DOM node such as Text can't have children.
minidom doesn't check for this at all:

from xml.dom import minidom
doc = minidom.Document()
text = doc.createTextNode('lorem ipsum')
elem = doc.createElement('leaf')
text.appendChild( elem )
print text.toxml()

This outputs just 'lorem ipsum', but elem really is a child 
of text; Text.toxml() just isn't recursing because it doesn't expect to do so.



Follow-Ups:

Date: 2000-Oct-12 20:02
By: fdrake

Comment:
This is a bug with detecting an improper use.  It should be fixed, but need not be for Python 2.0.  Correct use will not produce erroneous behavior.  Reducing priority by one.
-------------------------------------------------------

Date: 2000-Oct-15 07:06
By: loewis

Comment:
I believe this is not a bug, but an intended deviation from the DOM spec.
minidom (as the proposed documentation in patch 101821 explains) does
not support the IDL exceptions of module DOM, so it cannot report errors about improper usage.
-------------------------------------------------------

Date: 2000-Nov-21 14:33
By: fdrake

Comment:
From the documentation, I'd expect the Pythonic "moral equivalents" to be raised, which would be a ValueError in the case of illegal node types.

I'll even go so far as to say that ValueError should be raised when a second documentElement is appended, instead of a TypeError, to be more consistent with usage else where in the standard library:  Pythonic style is to raise a ValueError when the type of a value is right (in this case, a DOM Node), but the specific value is not acceptable, either because it is illegal or because it cannot be accepted given existing state (like already having a documentElement).
-------------------------------------------------------

Date: 2000-Nov-21 14:33
By: fdrake

Comment:
Oops, should re-categorize this as "XML" while I'm at it.
-------------------------------------------------------

Date: 2000-Nov-23 08:07
By: akuchling

Comment:
Patch #102485 has been submitted to fix this.
-------------------------------------------------------

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


From noreply@sourceforge.net  Thu Nov 23 16:07:58 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 23 Nov 2000 08:07:58 -0800
Subject: [Python-bugs-list] [Bug #116678] minidom doesn't raise exception for illegal children
Message-ID: <200011231607.IAA08027@sf-web3.vaspecialprojects.com>

Bug #116678, was updated on 2000-Oct-11 19:30
Here is a current snapshot of the bug.

Project: Python
Category: XML
Status: Open
Resolution: None
Bug Group: None
Priority: 6
Summary: minidom doesn't raise exception for illegal children

Details: Some types of DOM node such as Text can't have children.
minidom doesn't check for this at all:

from xml.dom import minidom
doc = minidom.Document()
text = doc.createTextNode('lorem ipsum')
elem = doc.createElement('leaf')
text.appendChild( elem )
print text.toxml()

This outputs just 'lorem ipsum', but elem really is a child 
of text; Text.toxml() just isn't recursing because it doesn't expect to do so.



Follow-Ups:

Date: 2000-Oct-12 20:02
By: fdrake

Comment:
This is a bug with detecting an improper use.  It should be fixed, but need not be for Python 2.0.  Correct use will not produce erroneous behavior.  Reducing priority by one.
-------------------------------------------------------

Date: 2000-Oct-15 07:06
By: loewis

Comment:
I believe this is not a bug, but an intended deviation from the DOM spec.
minidom (as the proposed documentation in patch 101821 explains) does
not support the IDL exceptions of module DOM, so it cannot report errors about improper usage.
-------------------------------------------------------

Date: 2000-Nov-21 14:33
By: fdrake

Comment:
From the documentation, I'd expect the Pythonic "moral equivalents" to be raised, which would be a ValueError in the case of illegal node types.

I'll even go so far as to say that ValueError should be raised when a second documentElement is appended, instead of a TypeError, to be more consistent with usage else where in the standard library:  Pythonic style is to raise a ValueError when the type of a value is right (in this case, a DOM Node), but the specific value is not acceptable, either because it is illegal or because it cannot be accepted given existing state (like already having a documentElement).
-------------------------------------------------------

Date: 2000-Nov-21 14:33
By: fdrake

Comment:
Oops, should re-categorize this as "XML" while I'm at it.
-------------------------------------------------------

Date: 2000-Nov-23 08:07
By: akuchling

Comment:
Patch #102485 has been submitted to fix this.
-------------------------------------------------------

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


From noreply@sourceforge.net  Thu Nov 23 16:29:12 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 23 Nov 2000 08:29:12 -0800
Subject: [Python-bugs-list] [Bug #122517] problems to compile 2.0 on IRIX 6.5
Message-ID: <200011231629.IAA29488@sf-web1.i.sourceforge.net>

Bug #122517, was updated on 2000-Nov-15 10:20
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: problems to compile 2.0 on IRIX 6.5

Details: ./configure --prefix=/usr/local/sbin/python/ --with-threads --without-gcc --with-cxx=CC

no errors...

gmake test:

PYTHONPATH= ./python -tt ./Lib/test/regrtest.py -l
'import site' failed; use -v for traceback
Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 35, in ?
    import string
ImportError: No module named string
gmake: [test] Error 1 (ignored)
PYTHONPATH= ./python -tt ./Lib/test/regrtest.py -l
'import site' failed; use -v for traceback
Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 35, in ?
    import string
ImportError: No module named string
gmake: *** [test] Error 1


Follow-Ups:

Date: 2000-Nov-22 14:38
By: cgw

Comment:
I am unable to reproduce this on:
	IRIX64 6.5 04191225 IP27
	MIPSpro Compilers: Version 7.30

using the identical ./configure command

Suggest doing a "make distclean" and retrying.

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

Date: 2000-Nov-23 08:29
By: HaraldS

Comment:
that's it, i'm sure that i tried this several
times but ...
well i started from scratch and now it works !
thanx

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

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


From noreply@sourceforge.net  Thu Nov 23 16:32:48 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 23 Nov 2000 08:32:48 -0800
Subject: [Python-bugs-list] [Bug #122680] compile python 2.0 on irix 6.5
Message-ID: <200011231632.IAA29546@sf-web1.i.sourceforge.net>

Bug #122680, was updated on 2000-Nov-17 04:11
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: compile python 2.0 on irix 6.5

Details: tried to compile python 2.0 with irix6.5
with irix-cc and egcs

'import site' failed; use -v for traceback
Python 2.0 (#3, Nov 17 2000, 13:05:58) 
[GCC egcs-2.91.66 19990314 (egcs-1.1.2 release)] on irix6
Type "copyright", "credits" or "license" for more information.

PYTHONPATH= ./python -tt ./Lib/test/regrtest.py -l
'import site' failed; use -v for traceback
Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 35, in ?
    import string
ImportError: No module named string
gmake: [test] Error 1 (ignored)
PYTHONPATH= ./python -tt ./Lib/test/regrtest.py -l
'import site' failed; use -v for traceback
Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 35, in ?
    import string
ImportError: No module named string
gmake: *** [test] Error 1

nearly same error-message with irix-cc, 
any ideas ??



Follow-Ups:

Date: 2000-Nov-22 14:41
By: cgw

Comment:
Are you the same "Nobody" who submitted bug #122517?
This looks like a nearly identical bug report.  I cannot
reproduce this on:
	IRIX64 6.5 04191225 IP27
	MIPSpro Compilers:  Version 7.30

Suggest doing a "make distclean" and retrying.
Possibly you have a corrupt source installation or something else is wrong with your system.

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

Date: 2000-Nov-23 08:32
By: HaraldS

Comment:
Yes, i was first time not shure
which Category to use,

no more problems now after starting
from scratch

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

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


From noreply@sourceforge.net  Thu Nov 23 17:38:10 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 23 Nov 2000 09:38:10 -0800
Subject: [Python-bugs-list] [Bug #123261] string.split
Message-ID: <200011231738.JAA30539@sf-web1.i.sourceforge.net>

Bug #123261, was updated on 2000-Nov-23 09:38
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: string.split

Details: Hi,

The following program:

#!/usr/bin/python
import string
print len(string.split('', ' '))
print len(string.split(' ', ' '))

prints:
1
2

This is of course sort of an undefined case, but I think it should be:
0
0
or at the very least:
0
1

Perl always prints 0.


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


From noreply@sourceforge.net  Fri Nov 24 02:29:06 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 23 Nov 2000 18:29:06 -0800
Subject: [Python-bugs-list] [Bug #116677] minidom:Node.appendChild() has wrong semantics
Message-ID: <200011240229.SAA05266@sf-web1.i.sourceforge.net>

Bug #116677, was updated on 2000-Oct-11 19:24
Here is a current snapshot of the bug.

Project: Python
Category: XML
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Summary: minidom:Node.appendChild() has wrong semantics

Details: Consider this test program:

from xml.dom import minidom
doc = minidom.Document()
root = doc.createElement('root') ; doc.appendChild( root )

elem = doc.createElement('leaf')
root.appendChild( elem )
root.appendChild( elem )

print doc.toxml()
print root.childNodes

It prints:
<root><leaf/><leaf/></root>
[<DOM Element: leaf at 135586476>, <DOM Element: leaf at 135586476>]

'elem' is now linked into the DOM tree in two places, which is wrong; according to the DOM Level 1 spec, 
"If the newChild is already in the tree, it is first removed."



Follow-Ups:

Date: 2000-Oct-11 19:55
By: fdrake

Comment:
Andrew:  Are you using 2.0c1 or CVS?
-------------------------------------------------------

Date: 2000-Oct-11 20:11
By: akuchling

Comment:
CVS as of this evening.  Did it work before?

(Hmm... tonight test_minidom is failing for me for some reason.  
Wonder if it's related?)
-------------------------------------------------------

Date: 2000-Oct-12 07:37
By: Nobody

Comment:
The test_minidom failure turned out to be caused by something else.  However, I rechecked my test case and it's still broken with tonight's CVS.
-------------------------------------------------------

Date: 2000-Oct-16 00:43
By: loewis

Comment:
This is indeed a bug in minidom, but I don't think it should be corrected for 2.0; I suggest to reduce the priority of it, or close it as "later".

While this is a deviation from the DOM spec, it seems as a border case. As such, it should be documented; users can always explicitly remove the node before appending it elsewhere.
-------------------------------------------------------

Date: 2000-Oct-16 06:47
By: akuchling

Comment:
I don't see why this particular deviation is a border case.
All the methods for modifying a DOM tree -- appendChild(),
insertBefore(), replaceChild() -- all behave the same way,
first removing the added node if it's already in the tree somewhere.  This will make it more difficult to translate DOM-using code from, say, Java, to Python + minidom, since you'll have to remember to add extra .removeChild() calls.
Worse still, the problems caused by this will be hard to track down; portions of your DOM tree are aliased, but .toxml() won't make this clear.
-------------------------------------------------------

Date: 2000-Nov-21 14:23
By: fdrake

Comment:
Re-categorized this bug to "XML".

This is *not* fixed by Lib/xml/dom/minidom.py revision 1.14.

Unfortunately, this bug will be a little harder to fix.  I looked to see if I could determine presence in the tree by checking for parentNode != None, but that isn't sufficient.  xml.dom.pulldom maintains state by filling in the parentNode attribute, so it has a chain of ancestors; it needs this to find the node to add children to in DOMEventStream.expandNode().  Testing that a node is already in the tree is harder, but not much harder.  A reasonable fix for this bug should not be difficult.
-------------------------------------------------------

Date: 2000-Nov-23 18:29
By: akuchling

Comment:
Patch #102492 has been submitted to fix this.
-------------------------------------------------------

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


From noreply@sourceforge.net  Fri Nov 24 02:29:06 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 23 Nov 2000 18:29:06 -0800
Subject: [Python-bugs-list] [Bug #116677] minidom:Node.appendChild() has wrong semantics
Message-ID: <200011240229.SAA05269@sf-web1.i.sourceforge.net>

Bug #116677, was updated on 2000-Oct-11 19:24
Here is a current snapshot of the bug.

Project: Python
Category: XML
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Summary: minidom:Node.appendChild() has wrong semantics

Details: Consider this test program:

from xml.dom import minidom
doc = minidom.Document()
root = doc.createElement('root') ; doc.appendChild( root )

elem = doc.createElement('leaf')
root.appendChild( elem )
root.appendChild( elem )

print doc.toxml()
print root.childNodes

It prints:
<root><leaf/><leaf/></root>
[<DOM Element: leaf at 135586476>, <DOM Element: leaf at 135586476>]

'elem' is now linked into the DOM tree in two places, which is wrong; according to the DOM Level 1 spec, 
"If the newChild is already in the tree, it is first removed."



Follow-Ups:

Date: 2000-Oct-11 19:55
By: fdrake

Comment:
Andrew:  Are you using 2.0c1 or CVS?
-------------------------------------------------------

Date: 2000-Oct-11 20:11
By: akuchling

Comment:
CVS as of this evening.  Did it work before?

(Hmm... tonight test_minidom is failing for me for some reason.  
Wonder if it's related?)
-------------------------------------------------------

Date: 2000-Oct-12 07:37
By: Nobody

Comment:
The test_minidom failure turned out to be caused by something else.  However, I rechecked my test case and it's still broken with tonight's CVS.
-------------------------------------------------------

Date: 2000-Oct-16 00:43
By: loewis

Comment:
This is indeed a bug in minidom, but I don't think it should be corrected for 2.0; I suggest to reduce the priority of it, or close it as "later".

While this is a deviation from the DOM spec, it seems as a border case. As such, it should be documented; users can always explicitly remove the node before appending it elsewhere.
-------------------------------------------------------

Date: 2000-Oct-16 06:47
By: akuchling

Comment:
I don't see why this particular deviation is a border case.
All the methods for modifying a DOM tree -- appendChild(),
insertBefore(), replaceChild() -- all behave the same way,
first removing the added node if it's already in the tree somewhere.  This will make it more difficult to translate DOM-using code from, say, Java, to Python + minidom, since you'll have to remember to add extra .removeChild() calls.
Worse still, the problems caused by this will be hard to track down; portions of your DOM tree are aliased, but .toxml() won't make this clear.
-------------------------------------------------------

Date: 2000-Nov-21 14:23
By: fdrake

Comment:
Re-categorized this bug to "XML".

This is *not* fixed by Lib/xml/dom/minidom.py revision 1.14.

Unfortunately, this bug will be a little harder to fix.  I looked to see if I could determine presence in the tree by checking for parentNode != None, but that isn't sufficient.  xml.dom.pulldom maintains state by filling in the parentNode attribute, so it has a chain of ancestors; it needs this to find the node to add children to in DOMEventStream.expandNode().  Testing that a node is already in the tree is harder, but not much harder.  A reasonable fix for this bug should not be difficult.
-------------------------------------------------------

Date: 2000-Nov-23 18:29
By: akuchling

Comment:
Patch #102492 has been submitted to fix this.
-------------------------------------------------------

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


From noreply@sourceforge.net  Fri Nov 24 09:32:53 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 24 Nov 2000 01:32:53 -0800
Subject: [Python-bugs-list] [Bug #119486] fcntl.lockf() is broken
Message-ID: <200011240932.BAA10348@sf-web1.i.sourceforge.net>

Bug #119486, was updated on 2000-Oct-26 14:18
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: fcntl.lockf() is broken

Details: Another observation by James Troup <troup@debian.org>: fcntl.lockf()
seems to be severly `broken': it's acting like flock, not like lockf, 
and the code seems to be a copy/paste of flock.
(registered in the Debian Bug Tracking System as bug #74777,
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=74777).

James includes a first start at filling in a correct lockf function.
Looks like it needs some more work, therefore I don't submit it as
patch. The patch is against 1.5.2, though there seem to be no changes in 2.0.

These are James' words:


fcntl.lockf() doesn't work as expected.  

        fcntl.lockf(fd, FCNTL.F_TLOCK);

will block.. looking at the source is exteremly confusing.
fcntl.lockf() appears to want flock() style arguments?!  It almost
looks like someone cut'n'wasted from the fcntl_flock() function just
above...

Anyway, here is a patch which is IMO the Right Thing,
i.e. fcnt.lockf() acting like libc lockf() and like it's documented to
do...

--- python-1.5.2/Modules/fcntlmodule.c.orig     Sat Oct 14 15:46:40 2000
+++ python-1.5.2/Modules/fcntlmodule.c  Sat Oct 14 18:31:44 2000
@@ -233,30 +233,12 @@
 {
        int fd, code, ret, whence = 0;
        PyObject *lenobj = NULL, *startobj = NULL;
+       struct flock l;
 
        if (!PyArg_ParseTuple(args, "ii|OOi", &fd, &code,
                              &lenobj, &startobj, &whence))
            return NULL;
 
-#ifndef LOCK_SH
-#define LOCK_SH                1       /* shared lock */
-#define LOCK_EX                2       /* exclusive lock */
-#define LOCK_NB                4       /* don't block when locking */
-#define LOCK_UN                8       /* unlock */
-#endif
-       {
-               struct flock l;
-               if (code == LOCK_UN)
-                       l.l_type = F_UNLCK;
-               else if (code & LOCK_SH)
-                       l.l_type = F_RDLCK;
-               else if (code & LOCK_EX)
-                       l.l_type = F_WRLCK;
-               else {
-                       PyErr_SetString(PyExc_ValueError,
-                                       "unrecognized flock argument");
-                       return NULL;
-               }
                l.l_start = l.l_len = 0;
                if (startobj != NULL) {
 #if !defined(HAVE_LARGEFILE_SUPPORT)
@@ -281,10 +263,48 @@
                                return NULL;
                }
                l.l_whence = whence;
+       switch (code)
+         {
+         case F_TEST:
+           /* Test the lock: return 0 if FD is unlocked or locked by this process;
+              return -1, set errno to EACCES, if another process holds the lock.  */
+           if (fcntl (fd, F_GETLK, &l) < 0) {
+             fprintf(stderr, "andrea: 1");
+             PyErr_SetFromErrno(PyExc_IOError);
+             return NULL;
+           }
+           if (l.l_type == F_UNLCK || l.l_pid == getpid ()) {
+             fprintf(stderr, "andrea: 2");
+             Py_INCREF(Py_None);
+             return Py_None;
+           }
+           fprintf(stderr, "andrea: 3");
+           errno = EACCES;
+           PyErr_SetFromErrno(PyExc_IOError);
+           return NULL;
+
+         case F_ULOCK:
+           l.l_type = F_UNLCK;
+           code = F_SETLK;
+           break;
+         case F_LOCK:
+           l.l_type = F_WRLCK;
+           code = F_SETLKW;
+           break;
+         case F_TLOCK:
+           l.l_type = F_WRLCK;
+           code = F_SETLK;
+           break;
+           
+         default:
+           PyErr_SetString(PyExc_ValueError,
+                           "unrecognized flock argument");
+           return NULL;
+         }
                Py_BEGIN_ALLOW_THREADS
-               ret = fcntl(fd, (code & LOCK_NB) ? F_SETLK : F_SETLKW, &l);
+         ret = fcntl(fd, code, &l);
                Py_END_ALLOW_THREADS
-       }
+
        if (ret < 0) {
                PyErr_SetFromErrno(PyExc_IOError);
                return NULL;



Follow-Ups:

Date: 2000-Oct-26 14:29
By: gvanrossum

Comment:
Sjoerd, you once looked at this code. Can you comment on this? If you don't have time, please assign back to me.
-------------------------------------------------------

Date: 2000-Nov-24 01:32
By: sjoerd

Comment:
Yeah, I looked at it.  In 1996.  I don't think I looked at flock since then.
Anyway, it compiles on my system (IRIX 6.5.2), and I don't think I will have time in the near future to look any further into this.
-------------------------------------------------------

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


From noreply@sourceforge.net  Fri Nov 24 09:32:54 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 24 Nov 2000 01:32:54 -0800
Subject: [Python-bugs-list] [Bug #119486] fcntl.lockf() is broken
Message-ID: <200011240932.BAA10351@sf-web1.i.sourceforge.net>

Bug #119486, was updated on 2000-Oct-26 14:18
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: fcntl.lockf() is broken

Details: Another observation by James Troup <troup@debian.org>: fcntl.lockf()
seems to be severly `broken': it's acting like flock, not like lockf, 
and the code seems to be a copy/paste of flock.
(registered in the Debian Bug Tracking System as bug #74777,
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=74777).

James includes a first start at filling in a correct lockf function.
Looks like it needs some more work, therefore I don't submit it as
patch. The patch is against 1.5.2, though there seem to be no changes in 2.0.

These are James' words:


fcntl.lockf() doesn't work as expected.  

        fcntl.lockf(fd, FCNTL.F_TLOCK);

will block.. looking at the source is exteremly confusing.
fcntl.lockf() appears to want flock() style arguments?!  It almost
looks like someone cut'n'wasted from the fcntl_flock() function just
above...

Anyway, here is a patch which is IMO the Right Thing,
i.e. fcnt.lockf() acting like libc lockf() and like it's documented to
do...

--- python-1.5.2/Modules/fcntlmodule.c.orig     Sat Oct 14 15:46:40 2000
+++ python-1.5.2/Modules/fcntlmodule.c  Sat Oct 14 18:31:44 2000
@@ -233,30 +233,12 @@
 {
        int fd, code, ret, whence = 0;
        PyObject *lenobj = NULL, *startobj = NULL;
+       struct flock l;
 
        if (!PyArg_ParseTuple(args, "ii|OOi", &fd, &code,
                              &lenobj, &startobj, &whence))
            return NULL;
 
-#ifndef LOCK_SH
-#define LOCK_SH                1       /* shared lock */
-#define LOCK_EX                2       /* exclusive lock */
-#define LOCK_NB                4       /* don't block when locking */
-#define LOCK_UN                8       /* unlock */
-#endif
-       {
-               struct flock l;
-               if (code == LOCK_UN)
-                       l.l_type = F_UNLCK;
-               else if (code & LOCK_SH)
-                       l.l_type = F_RDLCK;
-               else if (code & LOCK_EX)
-                       l.l_type = F_WRLCK;
-               else {
-                       PyErr_SetString(PyExc_ValueError,
-                                       "unrecognized flock argument");
-                       return NULL;
-               }
                l.l_start = l.l_len = 0;
                if (startobj != NULL) {
 #if !defined(HAVE_LARGEFILE_SUPPORT)
@@ -281,10 +263,48 @@
                                return NULL;
                }
                l.l_whence = whence;
+       switch (code)
+         {
+         case F_TEST:
+           /* Test the lock: return 0 if FD is unlocked or locked by this process;
+              return -1, set errno to EACCES, if another process holds the lock.  */
+           if (fcntl (fd, F_GETLK, &l) < 0) {
+             fprintf(stderr, "andrea: 1");
+             PyErr_SetFromErrno(PyExc_IOError);
+             return NULL;
+           }
+           if (l.l_type == F_UNLCK || l.l_pid == getpid ()) {
+             fprintf(stderr, "andrea: 2");
+             Py_INCREF(Py_None);
+             return Py_None;
+           }
+           fprintf(stderr, "andrea: 3");
+           errno = EACCES;
+           PyErr_SetFromErrno(PyExc_IOError);
+           return NULL;
+
+         case F_ULOCK:
+           l.l_type = F_UNLCK;
+           code = F_SETLK;
+           break;
+         case F_LOCK:
+           l.l_type = F_WRLCK;
+           code = F_SETLKW;
+           break;
+         case F_TLOCK:
+           l.l_type = F_WRLCK;
+           code = F_SETLK;
+           break;
+           
+         default:
+           PyErr_SetString(PyExc_ValueError,
+                           "unrecognized flock argument");
+           return NULL;
+         }
                Py_BEGIN_ALLOW_THREADS
-               ret = fcntl(fd, (code & LOCK_NB) ? F_SETLK : F_SETLKW, &l);
+         ret = fcntl(fd, code, &l);
                Py_END_ALLOW_THREADS
-       }
+
        if (ret < 0) {
                PyErr_SetFromErrno(PyExc_IOError);
                return NULL;



Follow-Ups:

Date: 2000-Oct-26 14:29
By: gvanrossum

Comment:
Sjoerd, you once looked at this code. Can you comment on this? If you don't have time, please assign back to me.
-------------------------------------------------------

Date: 2000-Nov-24 01:32
By: sjoerd

Comment:
Yeah, I looked at it.  In 1996.  I don't think I looked at flock since then.
Anyway, it compiles on my system (IRIX 6.5.2), and I don't think I will have time in the near future to look any further into this.
-------------------------------------------------------

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


From noreply@sourceforge.net  Fri Nov 24 09:47:45 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 24 Nov 2000 01:47:45 -0800
Subject: [Python-bugs-list] [Bug #122587] xmllib unable to parse "german scharfes ß" in UTF8 format
Message-ID: <200011240947.BAA10575@sf-web1.i.sourceforge.net>

Bug #122587, was updated on 2000-Nov-16 06:10
Here is a current snapshot of the bug.

Project: Python
Category: XML
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: xmllib unable to parse "german scharfes ß" in UTF8 format

Details: The xmllib.XMLParser seems to be unable to parse 
an XML file that contains 0xc3 0x9f (UTF8 representation
of the german ß).

Python 2.0 (Linux i386) always give me the following 
traceback:

suxlap@/tmp/xx(2)% python test.py test.xml
<?xml version="1.0" encoding="UTF-8" ?>

<test>Ã&#376;üöä</test>

Traceback (most recent call last):
  File "test.py", line 20, in ?
    pp.feed(data)
  File "/opt/python-2.0/lib/python2.0/xmllib.py", line 165, in feed
    self.goahead(0)
  File "/opt/python-2.0/lib/python2.0/xmllib.py", line 261, in goahead
    self.syntax_error('illegal character in content')
  File "/opt/python-2.0/lib/python2.0/xmllib.py", line 786, in syntax_error
    raise RuntimeError, 'Syntax error at line %d: %s' % (self.lineno, message)
RuntimeError: Syntax error at line 3: illegal character in content         



Other UTF8 characters seem to work

Follow-Ups:

Date: 2000-Nov-16 10:58
By: Nobody

Comment:
works with accept_utf=1 as additional parameter,
but using xml package instead.
 
-------------------------------------------------------

Date: 2000-Nov-24 01:47
By: sjoerd

Comment:
The problem here is the character reference &#376;. xmllib is from before Python support for Unicode, so it doesn't support any characters that are not representable in 8 bits, and it only really supports iso-8859-1 (latin1), and not even the utf-8 encoding of latin1. It also doesn't do the right thing for character references outside of the ASCII range, although it'll accept characters references in the range 0 - 255 (decimal).

It is too much work to fix this.

I will make available a rewrite of xmllib that has full Unicode support and what's more, is a validating XML parser. The main problem with this rewrite is that it is pretty slow (it uses many, big regular expressions, and compiling those re's is a time consuming task).  Mail me if you want a copy.
-------------------------------------------------------

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


From noreply@sourceforge.net  Fri Nov 24 09:47:49 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 24 Nov 2000 01:47:49 -0800
Subject: [Python-bugs-list] [Bug #122587] xmllib unable to parse "german scharfes ß" in UTF8 format
Message-ID: <200011240947.BAA10579@sf-web1.i.sourceforge.net>

Bug #122587, was updated on 2000-Nov-16 06:10
Here is a current snapshot of the bug.

Project: Python
Category: XML
Status: Closed
Resolution: Wont Fix
Bug Group: None
Priority: 5
Summary: xmllib unable to parse "german scharfes ß" in UTF8 format

Details: The xmllib.XMLParser seems to be unable to parse 
an XML file that contains 0xc3 0x9f (UTF8 representation
of the german ß).

Python 2.0 (Linux i386) always give me the following 
traceback:

suxlap@/tmp/xx(2)% python test.py test.xml
<?xml version="1.0" encoding="UTF-8" ?>

<test>Ã&#376;üöä</test>

Traceback (most recent call last):
  File "test.py", line 20, in ?
    pp.feed(data)
  File "/opt/python-2.0/lib/python2.0/xmllib.py", line 165, in feed
    self.goahead(0)
  File "/opt/python-2.0/lib/python2.0/xmllib.py", line 261, in goahead
    self.syntax_error('illegal character in content')
  File "/opt/python-2.0/lib/python2.0/xmllib.py", line 786, in syntax_error
    raise RuntimeError, 'Syntax error at line %d: %s' % (self.lineno, message)
RuntimeError: Syntax error at line 3: illegal character in content         



Other UTF8 characters seem to work

Follow-Ups:

Date: 2000-Nov-16 10:58
By: Nobody

Comment:
works with accept_utf=1 as additional parameter,
but using xml package instead.
 
-------------------------------------------------------

Date: 2000-Nov-24 01:47
By: sjoerd

Comment:
The problem here is the character reference &#376;. xmllib is from before Python support for Unicode, so it doesn't support any characters that are not representable in 8 bits, and it only really supports iso-8859-1 (latin1), and not even the utf-8 encoding of latin1. It also doesn't do the right thing for character references outside of the ASCII range, although it'll accept characters references in the range 0 - 255 (decimal).

It is too much work to fix this.

I will make available a rewrite of xmllib that has full Unicode support and what's more, is a validating XML parser. The main problem with this rewrite is that it is pretty slow (it uses many, big regular expressions, and compiling those re's is a time consuming task).  Mail me if you want a copy.
-------------------------------------------------------

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


From noreply@sourceforge.net  Sat Nov 25 04:29:09 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 24 Nov 2000 20:29:09 -0800
Subject: [Python-bugs-list] [Bug #123398] "Python/C API Reference Manual" erroneous Python/C exception
Message-ID: <200011250429.UAA26811@sf-web1.i.sourceforge.net>

Bug #123398, was updated on 2000-Nov-24 20:29
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: "Python/C API Reference Manual" erroneous Python/C exception

Details: The documentation page "Python20/Doc/api/exceptions.html" gives an example of how to handle Python exceptions in C.
It provides a Python function and what it claims is the equivalent C function.
However, they are not equivalent, in that the Python function returns a modified item from a list/dict, whereas the C function actually modifies the list/dict and returns only its success/failure.
I believe the two can be made equivalent by replacing the last line of the Python function:
  return item + 1
with:
  dict[key] = item + 1


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


From noreply@sourceforge.net  Sat Nov 25 07:58:48 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 24 Nov 2000 23:58:48 -0800
Subject: [Python-bugs-list] [Bug #123409] Global Module Index up link does not work
Message-ID: <200011250758.XAA29206@sf-web1.i.sourceforge.net>

Bug #123409, was updated on 2000-Nov-24 23:58
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Global Module Index up link does not work

Details: The Up button on the global module index page fails because the index page is on the same level as the general documentation index.

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


From noreply@sourceforge.net  Sat Nov 25 17:47:58 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 25 Nov 2000 09:47:58 -0800
Subject: [Python-bugs-list] [Bug #123261] string.split
Message-ID: <200011251747.JAA03884@sf-web1.i.sourceforge.net>

Bug #123261, was updated on 2000-Nov-23 09:38
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: string.split

Details: Hi,

The following program:

#!/usr/bin/python
import string
print len(string.split('', ' '))
print len(string.split(' ', ' '))

prints:
1
2

This is of course sort of an undefined case, but I think it should be:
0
0
or at the very least:
0
1

Perl always prints 0.


Follow-Ups:

Date: 2000-Nov-25 09:47
By: Nobody

Comment:
not a bug: it's behaving exactly as defined by the documentation:

If the second argument sep is present and not None, it specifies a string to be used as the word separator. The returned list will then have one more item than the number of non-overlapping occurrences of the separator in the string.

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

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


From noreply@sourceforge.net  Sun Nov 26 23:01:45 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 26 Nov 2000 15:01:45 -0800
Subject: [Python-bugs-list] [Bug #123261] string.split
Message-ID: <200011262301.PAA30539@sf-web1.i.sourceforge.net>

Bug #123261, was updated on 2000-Nov-23 09:38
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: string.split

Details: Hi,

The following program:

#!/usr/bin/python
import string
print len(string.split('', ' '))
print len(string.split(' ', ' '))

prints:
1
2

This is of course sort of an undefined case, but I think it should be:
0
0
or at the very least:
0
1

Perl always prints 0.


Follow-Ups:

Date: 2000-Nov-25 09:47
By: Nobody

Comment:
not a bug: it's behaving exactly as defined by the documentation:

If the second argument sep is present and not None, it specifies a string to be used as the word separator. The returned list will then have one more item than the number of non-overlapping occurrences of the separator in the string.

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

Date: 2000-Nov-26 15:01
By: tim_one

Comment:
Closed as Not-a-Bug; see /F's remarks.

Note that Perl special-cases the snot out of a single blank used as a separator:  "As a special case, specifying a PATTERN of space (' ') will split on white space just as split() with no arguments does. Thus, split(' ') can be used to emulate awk's default behavior, whereas split(/ /) will give you as many null initial fields as there are leading spaces. A split() on /\s+/ is like a split(' ') except that any leading whitespace produces a null first field. A split() with no arguments really does a split(' ', $_) internally."

That's why Perl acts so differently -- it's not splitting on a single blank at all!  Try splitting on / / in Perl and see what happens (which *really* splits on a blank):

@a = split / /, " ";
@b = split / /, "";
$a = @a;
$b = @b;
print "$a $b\n";

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

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


From noreply@sourceforge.net  Sun Nov 26 23:01:50 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 26 Nov 2000 15:01:50 -0800
Subject: [Python-bugs-list] [Bug #123261] string.split
Message-ID: <200011262301.PAA30542@sf-web1.i.sourceforge.net>

Bug #123261, was updated on 2000-Nov-23 09:38
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Invalid
Bug Group: Not a Bug
Priority: 5
Summary: string.split

Details: Hi,

The following program:

#!/usr/bin/python
import string
print len(string.split('', ' '))
print len(string.split(' ', ' '))

prints:
1
2

This is of course sort of an undefined case, but I think it should be:
0
0
or at the very least:
0
1

Perl always prints 0.


Follow-Ups:

Date: 2000-Nov-25 09:47
By: Nobody

Comment:
not a bug: it's behaving exactly as defined by the documentation:

If the second argument sep is present and not None, it specifies a string to be used as the word separator. The returned list will then have one more item than the number of non-overlapping occurrences of the separator in the string.

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

Date: 2000-Nov-26 15:01
By: tim_one

Comment:
Closed as Not-a-Bug; see /F's remarks.

Note that Perl special-cases the snot out of a single blank used as a separator:  "As a special case, specifying a PATTERN of space (' ') will split on white space just as split() with no arguments does. Thus, split(' ') can be used to emulate awk's default behavior, whereas split(/ /) will give you as many null initial fields as there are leading spaces. A split() on /\s+/ is like a split(' ') except that any leading whitespace produces a null first field. A split() with no arguments really does a split(' ', $_) internally."

That's why Perl acts so differently -- it's not splitting on a single blank at all!  Try splitting on / / in Perl and see what happens (which *really* splits on a blank):

@a = split / /, " ";
@b = split / /, "";
$a = @a;
$b = @b;
print "$a $b\n";

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

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


From noreply@sourceforge.net  Mon Nov 27 05:10:07 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 26 Nov 2000 21:10:07 -0800
Subject: [Python-bugs-list] [Bug #123520] Example code doesn't work
Message-ID: <200011270510.VAA02898@sf-web3.vaspecialprojects.com>

Bug #123520, was updated on 2000-Nov-26 21:10
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Example code doesn't work

Details: In section 4.7.4 the code snippet:

def make_incrementor(n):
    return lambda x, incr=n: x+incr

doesn't seem to work.  It seems to be returning the lambda function handle instead.  This occurred on Win98, using python interactively.

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


From noreply@sourceforge.net  Mon Nov 27 06:46:25 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 26 Nov 2000 22:46:25 -0800
Subject: [Python-bugs-list] [Bug #123520] Example code doesn't work
Message-ID: <200011270646.WAA04146@sf-web3.vaspecialprojects.com>

Bug #123520, was updated on 2000-Nov-26 21:10
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Example code doesn't work

Details: In section 4.7.4 the code snippet:

def make_incrementor(n):
    return lambda x, incr=n: x+incr

doesn't seem to work.  It seems to be returning the lambda function handle instead.  This occurred on Win98, using python interactively.

Follow-Ups:

Date: 2000-Nov-26 22:46
By: tim_one

Comment:
Not a bug.  It's *supposed* to return a (anonymous) function.  I added a little more to the tutorial's example (rev 1.121):

>>> def make_incrementor(n):
...     return lambda x, incr=n: x+incr
...
>>> f = make_incrementor(42)
>>> f(0)
42
>>> f(1)
43
>>>

Assigned to Fred for doc review, but already closed the bug report.
-------------------------------------------------------

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


From noreply@sourceforge.net  Mon Nov 27 06:46:25 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 26 Nov 2000 22:46:25 -0800
Subject: [Python-bugs-list] [Bug #123520] Example code doesn't work
Message-ID: <200011270646.WAA04149@sf-web3.vaspecialprojects.com>

Bug #123520, was updated on 2000-Nov-26 21:10
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Closed
Resolution: Invalid
Bug Group: Not a Bug
Priority: 5
Summary: Example code doesn't work

Details: In section 4.7.4 the code snippet:

def make_incrementor(n):
    return lambda x, incr=n: x+incr

doesn't seem to work.  It seems to be returning the lambda function handle instead.  This occurred on Win98, using python interactively.

Follow-Ups:

Date: 2000-Nov-26 22:46
By: tim_one

Comment:
Not a bug.  It's *supposed* to return a (anonymous) function.  I added a little more to the tutorial's example (rev 1.121):

>>> def make_incrementor(n):
...     return lambda x, incr=n: x+incr
...
>>> f = make_incrementor(42)
>>> f(0)
42
>>> f(1)
43
>>>

Assigned to Fred for doc review, but already closed the bug report.
-------------------------------------------------------

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


From noreply@sourceforge.net  Mon Nov 27 15:50:31 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 07:50:31 -0800
Subject: [Python-bugs-list] [Bug #123520] Example code doesn't work
Message-ID: <200011271550.HAA19086@sf-web2.i.sourceforge.net>

Bug #123520, was updated on 2000-Nov-26 21:10
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Closed
Resolution: Invalid
Bug Group: Not a Bug
Priority: 5
Summary: Example code doesn't work

Details: In section 4.7.4 the code snippet:

def make_incrementor(n):
    return lambda x, incr=n: x+incr

doesn't seem to work.  It seems to be returning the lambda function handle instead.  This occurred on Win98, using python interactively.

Follow-Ups:

Date: 2000-Nov-26 22:46
By: tim_one

Comment:
Not a bug.  It's *supposed* to return a (anonymous) function.  I added a little more to the tutorial's example (rev 1.121):

>>> def make_incrementor(n):
...     return lambda x, incr=n: x+incr
...
>>> f = make_incrementor(42)
>>> f(0)
42
>>> f(1)
43
>>>

Assigned to Fred for doc review, but already closed the bug report.
-------------------------------------------------------

Date: 2000-Nov-27 07:50
By: fdrake

Comment:
The doc update is fine, Tim.

If you want me to review something, don't close the bug!
-------------------------------------------------------

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


From noreply@sourceforge.net  Mon Nov 27 15:50:31 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 07:50:31 -0800
Subject: [Python-bugs-list] [Bug #123520] Example code doesn't work
Message-ID: <200011271550.HAA19083@sf-web2.i.sourceforge.net>

Bug #123520, was updated on 2000-Nov-26 21:10
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Closed
Resolution: Invalid
Bug Group: Not a Bug
Priority: 5
Summary: Example code doesn't work

Details: In section 4.7.4 the code snippet:

def make_incrementor(n):
    return lambda x, incr=n: x+incr

doesn't seem to work.  It seems to be returning the lambda function handle instead.  This occurred on Win98, using python interactively.

Follow-Ups:

Date: 2000-Nov-26 22:46
By: tim_one

Comment:
Not a bug.  It's *supposed* to return a (anonymous) function.  I added a little more to the tutorial's example (rev 1.121):

>>> def make_incrementor(n):
...     return lambda x, incr=n: x+incr
...
>>> f = make_incrementor(42)
>>> f(0)
42
>>> f(1)
43
>>>

Assigned to Fred for doc review, but already closed the bug report.
-------------------------------------------------------

Date: 2000-Nov-27 07:50
By: fdrake

Comment:
The doc update is fine, Tim.

If you want me to review something, don't close the bug!
-------------------------------------------------------

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


From noreply@sourceforge.net  Mon Nov 27 16:31:38 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 08:31:38 -0800
Subject: [Python-bugs-list] [Bug #123599] Need user-centered info for Windows users.
Message-ID: <200011271631.IAA12859@sf-web3.vaspecialprojects.com>

Bug #123599, was updated on 2000-Nov-27 08:31
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 6
Summary: Need user-centered info for Windows users.

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

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


From noreply@sourceforge.net  Mon Nov 27 18:12:17 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 10:12:17 -0800
Subject: [Python-bugs-list] [Bug #121013] codecs.StreamReadWriter.writelines method accesses null ptr
Message-ID: <200011271812.KAA16648@sf-web1.i.sourceforge.net>

Bug #121013, was updated on 2000-Nov-01 10:17
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Summary: codecs.StreamReadWriter.writelines method accesses null ptr

Details: Python 2.0 (#8, Oct 16 2000, 17:27:58) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
IDLE 0.6 -- press F1 for help
>>> import codecs
>>> f = codecs.open("c:\\temp\\junk.txt", "w", "UTF-8")
>>> msg = u"this is a test"
>>> f.writelines(msg)

result:
The instruction at "0x002925a6 referenced memory at "0x00000000".  The memory could not be "read".

Follow-Ups:

Date: 2000-Nov-01 11:06
By: lemburg

Comment:
The bug headline is misleading: the bug boils down to

""..join(u"this is a test")

causing a segfault. (Note that you should pass a list to .join()... not
a string.

The cause is the PySequence_Fast_GET_ITEM() macro:

#define PySequence_Fast_GET_ITEM(o, i)\
     (PyList_Check(o) ? PyList_GET_ITEM(o, i) : PyTuple_GET_ITEM(o, i))

... this only works for lists and tuples and not arbitrary sequences like
the name implies.

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

Date: 2000-Nov-01 14:39
By: jhylton

Comment:
I think the cause is whatever uses the PySequence_Fast_GET_ITEM macro (which may have a misleading name).

It looks like it might also be useful to raise an exception when join is passed a string.  I think it's more likely to be an error than deliberate.

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

Date: 2000-Nov-27 10:12
By: mwh

Comment:
I hope you're all suitably embarrassed - please see patch #102548 for the trivial fix...
-------------------------------------------------------

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


From noreply@sourceforge.net  Mon Nov 27 18:33:59 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 10:33:59 -0800
Subject: [Python-bugs-list] [Bug #123616] Tools/compiler needs documentation.
Message-ID: <200011271833.KAA22211@sf-web2.i.sourceforge.net>

Bug #123616, was updated on 2000-Nov-27 10:33
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: Tools/compiler needs documentation.

Details: The compiler package is not documented; this needs to be done before tools are likely to be written on top of it.

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


From noreply@sourceforge.net  Mon Nov 27 18:54:32 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 10:54:32 -0800
Subject: [Python-bugs-list] [Bug #121013] codecs.StreamReadWriter.writelines method accesses null ptr
Message-ID: <200011271854.KAA15304@sf-web3.vaspecialprojects.com>

Bug #121013, was updated on 2000-Nov-01 10:17
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Summary: codecs.StreamReadWriter.writelines method accesses null ptr

Details: Python 2.0 (#8, Oct 16 2000, 17:27:58) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
IDLE 0.6 -- press F1 for help
>>> import codecs
>>> f = codecs.open("c:\\temp\\junk.txt", "w", "UTF-8")
>>> msg = u"this is a test"
>>> f.writelines(msg)

result:
The instruction at "0x002925a6 referenced memory at "0x00000000".  The memory could not be "read".

Follow-Ups:

Date: 2000-Nov-01 11:06
By: lemburg

Comment:
The bug headline is misleading: the bug boils down to

""..join(u"this is a test")

causing a segfault. (Note that you should pass a list to .join()... not
a string.

The cause is the PySequence_Fast_GET_ITEM() macro:

#define PySequence_Fast_GET_ITEM(o, i)\
     (PyList_Check(o) ? PyList_GET_ITEM(o, i) : PyTuple_GET_ITEM(o, i))

... this only works for lists and tuples and not arbitrary sequences like
the name implies.

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

Date: 2000-Nov-01 14:39
By: jhylton

Comment:
I think the cause is whatever uses the PySequence_Fast_GET_ITEM macro (which may have a misleading name).

It looks like it might also be useful to raise an exception when join is passed a string.  I think it's more likely to be an error than deliberate.

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

Date: 2000-Nov-27 10:12
By: mwh

Comment:
I hope you're all suitably embarrassed - please see patch #102548 for the trivial fix...
-------------------------------------------------------

Date: 2000-Nov-27 10:54
By: gvanrossum

Comment:
Patch checked in.
-------------------------------------------------------

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


From noreply@sourceforge.net  Mon Nov 27 18:54:32 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 10:54:32 -0800
Subject: [Python-bugs-list] [Bug #121013] Bug in <stringobject>.join(<unicodestring>)
Message-ID: <200011271854.KAA15307@sf-web3.vaspecialprojects.com>

Bug #121013, was updated on 2000-Nov-01 10:17
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: None
Bug Group: None
Priority: 7
Summary: Bug in <stringobject>.join(<unicodestring>)

Details: Python 2.0 (#8, Oct 16 2000, 17:27:58) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
IDLE 0.6 -- press F1 for help
>>> import codecs
>>> f = codecs.open("c:\\temp\\junk.txt", "w", "UTF-8")
>>> msg = u"this is a test"
>>> f.writelines(msg)

result:
The instruction at "0x002925a6 referenced memory at "0x00000000".  The memory could not be "read".

Follow-Ups:

Date: 2000-Nov-01 11:06
By: lemburg

Comment:
The bug headline is misleading: the bug boils down to

""..join(u"this is a test")

causing a segfault. (Note that you should pass a list to .join()... not
a string.

The cause is the PySequence_Fast_GET_ITEM() macro:

#define PySequence_Fast_GET_ITEM(o, i)\
     (PyList_Check(o) ? PyList_GET_ITEM(o, i) : PyTuple_GET_ITEM(o, i))

... this only works for lists and tuples and not arbitrary sequences like
the name implies.

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

Date: 2000-Nov-01 14:39
By: jhylton

Comment:
I think the cause is whatever uses the PySequence_Fast_GET_ITEM macro (which may have a misleading name).

It looks like it might also be useful to raise an exception when join is passed a string.  I think it's more likely to be an error than deliberate.

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

Date: 2000-Nov-27 10:12
By: mwh

Comment:
I hope you're all suitably embarrassed - please see patch #102548 for the trivial fix...
-------------------------------------------------------

Date: 2000-Nov-27 10:54
By: gvanrossum

Comment:
Patch checked in.
-------------------------------------------------------

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


From noreply@sourceforge.net  Mon Nov 27 21:11:49 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 13:11:49 -0800
Subject: [Python-bugs-list] [Bug #114598] Blue Screen crash, popen, Win98, Norton Antivirus 2000
Message-ID: <200011272111.NAA20447@sf-web1.i.sourceforge.net>

Bug #114598, was updated on 2000-Sep-16 13:24
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Open
Resolution: None
Bug Group: 3rd Party
Priority: 3
Summary: Blue Screen crash, popen, Win98, Norton Antivirus 2000

Details: On Windows 98, all of the os.popen*() functions cause a hard "blue screen" crash requiring a reboot, when Nortin Antivirus 2000 is installed and enabled. (Not with Norton Antivirus version 5, not on Windows 2000.)

While this is probably a bug in Norton Antivirus 2000, and we're already warning for this on the download page, that's not enough (we've seen at least one report in the newsgroup), and it would be good if we could somehow prevent it. Even a call to Py_FatalError is better than the blue screen, and raising os.error would be a *lot* better.

Follow-Ups:

Date: 2000-Sep-16 14:26
By: tim_one

Comment:
I don't know how to stop this.  Pissed away an hour trying to get help on the Symantec site, and eventually found a support board to which I posted this msg:

Product: Norton AntiVirus 2000 6.0 for Windows 95/98/NT
Supported operating system: Windows 98
Action: Run Another Program
Error Message: 
Summary: Blue screen crash

I develop the Windows version of the core Python language. Several reports of blue-screen death on Win98 have been traced to NAV2000.  Here's the exact msg from one such:

An exception 0E has occurred at 0028:C02AD9D0 in VxD IFSMGR(04) + 000050E4. This was called from 0028:C000B511 in VxD VMM(01) + 0000A511. It may be possible to continue normally.

This occurs whenever a user executes a member of the popen family of functions from within Python; for example, this Python program:

import os
p = os.popen("dir")

popen is a std C library function, poorly implemented by Microsoft, but not *that* poorly <wink>.

You can get our latest installer here:

http://www.pythonlabs.com/tech/python2.0/download.html

As the warning there says:

-----------------
Incompatibility warning: Norton Antivirus 2000 can cause blue screen crashes on Windows 98 when a function in the os.popen*() family is invoked. To prevent this problem, disable Norton Antivirus when using Python. (Confirmed on Windows 98 Second Edition with Norton Antivirus version 6.10.20. The same Norton Antivirus version doesn't have this
problem on Windows 2000. Norton Antivirus version 5 on Windows 98SE doesn't have this problem either.) 
-----------------

ActiveState is seeing the same problem with their derivative work ActivePython, as is PythonWare with their derivative work PythonWorks. So this affects a lot of people. A recent change to the implementation of a popular library module has made it acutely visible recently (didn't use to use popen, but does now).

A workaround would be nice. More importantly, how can I *detect* whether an affected version of NAV is in use, so that we can shut down Python gracefully with an appropriate message before executing any of the popen functions that throw NAV into blue-screen territory? We try to be a very user-friendly language, and we'll do anything to prevent a crash. Alas, right now I don't know how to stop it.

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

Date: 2000-Sep-19 02:21
By: tim_one

Comment:
1. Sent Guido a small self-contained C program in the hope that it's enough to provoke the problem by itself.  Reassigned this bug to Guido since he has to tell me what happens with that next (then assign back to me).

2. That's because Symantec is being no help at all.  They suggest upgrading to NAV 2001(!).  If I can post a tiny C program, maybe it will embarrass then into doing something.  You can follow this soap opera at:

http://servicenews.symantec.com/cgi-bin/displayArticle.cgi?group=symantec.support.win9x.nortonantivirus2000.general&article=57765

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

Date: 2000-Sep-19 09:06
By: gvanrossum

Comment:
Tim's little C program crashes in the same way as Python when NAV2000 is enabled. back to Tim...
-------------------------------------------------------

Date: 2000-Sep-21 11:32
By: tim_one

Comment:
I cranked up my obnoxiousness level on the Symantec board (URL two comments down), and they may be on the edge of taking this seriously now.
-------------------------------------------------------

Date: 2000-Sep-22 20:46
By: tim_one

Comment:
Reduced the priority a notch.  The biggest trigger here was IDLE's use of os.popen (indirectly via webbrowser.py) to launch the Python HTML docs.  I put in a new Windows function (os.startfile) that uses Win32 ShellExecute instead, and changed webbrowser.py to use that.  IDLE now lives peacefully with NAV 6.10.20.

This was all Guido's idea, and he suggested that the priority of this bug should be dropped now.
-------------------------------------------------------

Date: 2000-Oct-06 12:23
By: gvanrossum

Comment:
Reduced priority even more. There's not much else we can do about this, it seems, except yell at Norton. :-(
-------------------------------------------------------

Date: 2000-Oct-06 16:23
By: tim_one

Comment:
Indeed, I can detect whether AutoProtect is loaded at system startup, but not whether it's currently running.  Just left another nag on the Symantec board but don't expect a useful response.
-------------------------------------------------------

Date: 2000-Nov-20 11:13
By: tim_one

Comment:
Assigned to Guido cuz there's something I want him to try:

My new desktop box is running Win98SE and has NAV 2000 version 6.10.20.  But I don't have any problem running os.popen with autoprotect engaged.

Could you try using the NAV LiveUpdate facility to make sure all your NAV components are up to date, and try this again?  The virus defs on my box are dated 11/13/2000.

Perhaps also use Windows Update to make sure your OS components are up to date too.
-------------------------------------------------------

Date: 2000-Nov-27 13:11
By: gvanrossum

Comment:
Yup, os.popen() still crashes after updating NAV. Windows Update doesn't tell me to do any critical updates.
-------------------------------------------------------

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


From noreply@sourceforge.net  Mon Nov 27 21:11:48 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 13:11:48 -0800
Subject: [Python-bugs-list] [Bug #114598] Blue Screen crash, popen, Win98, Norton Antivirus 2000
Message-ID: <200011272111.NAA20444@sf-web1.i.sourceforge.net>

Bug #114598, was updated on 2000-Sep-16 13:24
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Open
Resolution: None
Bug Group: 3rd Party
Priority: 3
Summary: Blue Screen crash, popen, Win98, Norton Antivirus 2000

Details: On Windows 98, all of the os.popen*() functions cause a hard "blue screen" crash requiring a reboot, when Nortin Antivirus 2000 is installed and enabled. (Not with Norton Antivirus version 5, not on Windows 2000.)

While this is probably a bug in Norton Antivirus 2000, and we're already warning for this on the download page, that's not enough (we've seen at least one report in the newsgroup), and it would be good if we could somehow prevent it. Even a call to Py_FatalError is better than the blue screen, and raising os.error would be a *lot* better.

Follow-Ups:

Date: 2000-Sep-16 14:26
By: tim_one

Comment:
I don't know how to stop this.  Pissed away an hour trying to get help on the Symantec site, and eventually found a support board to which I posted this msg:

Product: Norton AntiVirus 2000 6.0 for Windows 95/98/NT
Supported operating system: Windows 98
Action: Run Another Program
Error Message: 
Summary: Blue screen crash

I develop the Windows version of the core Python language. Several reports of blue-screen death on Win98 have been traced to NAV2000.  Here's the exact msg from one such:

An exception 0E has occurred at 0028:C02AD9D0 in VxD IFSMGR(04) + 000050E4. This was called from 0028:C000B511 in VxD VMM(01) + 0000A511. It may be possible to continue normally.

This occurs whenever a user executes a member of the popen family of functions from within Python; for example, this Python program:

import os
p = os.popen("dir")

popen is a std C library function, poorly implemented by Microsoft, but not *that* poorly <wink>.

You can get our latest installer here:

http://www.pythonlabs.com/tech/python2.0/download.html

As the warning there says:

-----------------
Incompatibility warning: Norton Antivirus 2000 can cause blue screen crashes on Windows 98 when a function in the os.popen*() family is invoked. To prevent this problem, disable Norton Antivirus when using Python. (Confirmed on Windows 98 Second Edition with Norton Antivirus version 6.10.20. The same Norton Antivirus version doesn't have this
problem on Windows 2000. Norton Antivirus version 5 on Windows 98SE doesn't have this problem either.) 
-----------------

ActiveState is seeing the same problem with their derivative work ActivePython, as is PythonWare with their derivative work PythonWorks. So this affects a lot of people. A recent change to the implementation of a popular library module has made it acutely visible recently (didn't use to use popen, but does now).

A workaround would be nice. More importantly, how can I *detect* whether an affected version of NAV is in use, so that we can shut down Python gracefully with an appropriate message before executing any of the popen functions that throw NAV into blue-screen territory? We try to be a very user-friendly language, and we'll do anything to prevent a crash. Alas, right now I don't know how to stop it.

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

Date: 2000-Sep-19 02:21
By: tim_one

Comment:
1. Sent Guido a small self-contained C program in the hope that it's enough to provoke the problem by itself.  Reassigned this bug to Guido since he has to tell me what happens with that next (then assign back to me).

2. That's because Symantec is being no help at all.  They suggest upgrading to NAV 2001(!).  If I can post a tiny C program, maybe it will embarrass then into doing something.  You can follow this soap opera at:

http://servicenews.symantec.com/cgi-bin/displayArticle.cgi?group=symantec.support.win9x.nortonantivirus2000.general&article=57765

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

Date: 2000-Sep-19 09:06
By: gvanrossum

Comment:
Tim's little C program crashes in the same way as Python when NAV2000 is enabled. back to Tim...
-------------------------------------------------------

Date: 2000-Sep-21 11:32
By: tim_one

Comment:
I cranked up my obnoxiousness level on the Symantec board (URL two comments down), and they may be on the edge of taking this seriously now.
-------------------------------------------------------

Date: 2000-Sep-22 20:46
By: tim_one

Comment:
Reduced the priority a notch.  The biggest trigger here was IDLE's use of os.popen (indirectly via webbrowser.py) to launch the Python HTML docs.  I put in a new Windows function (os.startfile) that uses Win32 ShellExecute instead, and changed webbrowser.py to use that.  IDLE now lives peacefully with NAV 6.10.20.

This was all Guido's idea, and he suggested that the priority of this bug should be dropped now.
-------------------------------------------------------

Date: 2000-Oct-06 12:23
By: gvanrossum

Comment:
Reduced priority even more. There's not much else we can do about this, it seems, except yell at Norton. :-(
-------------------------------------------------------

Date: 2000-Oct-06 16:23
By: tim_one

Comment:
Indeed, I can detect whether AutoProtect is loaded at system startup, but not whether it's currently running.  Just left another nag on the Symantec board but don't expect a useful response.
-------------------------------------------------------

Date: 2000-Nov-20 11:13
By: tim_one

Comment:
Assigned to Guido cuz there's something I want him to try:

My new desktop box is running Win98SE and has NAV 2000 version 6.10.20.  But I don't have any problem running os.popen with autoprotect engaged.

Could you try using the NAV LiveUpdate facility to make sure all your NAV components are up to date, and try this again?  The virus defs on my box are dated 11/13/2000.

Perhaps also use Windows Update to make sure your OS components are up to date too.
-------------------------------------------------------

Date: 2000-Nov-27 13:11
By: gvanrossum

Comment:
Yup, os.popen() still crashes after updating NAV. Windows Update doesn't tell me to do any critical updates.
-------------------------------------------------------

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


From noreply@sourceforge.net  Mon Nov 27 21:13:14 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 13:13:14 -0800
Subject: [Python-bugs-list] [Bug #122756] BaseHTTPServer subclass I/O call blocks forever
Message-ID: <200011272113.NAA25154@sf-web2.i.sourceforge.net>

Bug #122756, was updated on 2000-Nov-18 00:14
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: BaseHTTPServer subclass I/O call blocks forever

Details: The following BaseHTTPServer subclass blocks in the do_POST() method under Python 2.0, 1.5.2 (on Windows NT and Linux) and JPython 1.1+09.  It seems to block in the write() calls after the read() call.




import BaseHTTPServer 
 
 
class VASTestHTTPRequestHandler(BaseHTTPServer.BaseHTTPRequestHandler): 
 
    contentType="text/html" 
 
    htmlForm="<FORM METHOD=POST ACTION=/handler>\r\n<br>NAME:&nbsp;<INPUT TYPE=\
TEXT NAME=name></INPUT><br><INPUT TYPE=SUBMIT></INPUT><p>\r\n</FORM>\r\n" 
    rspGETContent="<HTML>\r\n<HEAD>\r\n</HEAD>\r\n<BODY>\r\n<H1>GET</H1>\r\n%s<\
/BODY>\r\n</HTML>\r\n" 
 
    rspPOSTContent="\r\n\r\n<HTML>\r\n<HEAD>\r\n</HEAD>\r\n<BODY>\r\n<H1>POST</\
H1>\r\n%s</BODY>\r\n</HTML>\r\n" 
 
    def do_GET(self): 
        self.send_head() 
        self.wfile.write(self.rspGETContent % (self.htmlForm)) 
         
    def do_HEAD(self): 
        self.send_head() 
    def do_POST(self): 
        self.log_message("%s","Processing POST  ...") 
        self.log_message("%s",self.rspPOSTContent % (self.htmlForm)) 
        self.contentLength=int(self.headers.getheader("Content-Length")) 
        self.log_message("content-length=%d",self.contentLength) 
 
        # this read blocks forever 
        self.reqContent=self.rfile.read() 
        self.log_message("%s",self.reqContent) 
 
        self.send_head() 
        self.wfile.write(self.rspPOSTContent % (self.htmlForm)) 
        self.log_message("%s","Processed POST") 
         
    def send_head(self): 
        self.send_response(200) 
        self.send_header("Content-Type",self.contentType) 
        self.send_header("Expires","0") 
        self.end_headers() 
 
    def setContentType(self,type): 
        self.contentType=type 
 
 
def test(HandlerClass = VASTestHTTPRequestHandler, 
         ServerClass = BaseHTTPServer.HTTPServer): 
    port=8888 
    serverAddress=('',port) 
    httpd = ServerClass(serverAddress, HandlerClass) 
 
    print "Serving HTTP on port", port, "..." 
    httpd.serve_forever() 
 
 
if __name__ == '__main__': 
    test() 
 

Follow-Ups:

Date: 2000-Nov-27 13:13
By: gvanrossum

Comment:
As the author of said module I'll look at this.
-------------------------------------------------------

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


From noreply@sourceforge.net  Mon Nov 27 21:13:15 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 13:13:15 -0800
Subject: [Python-bugs-list] [Bug #122756] BaseHTTPServer subclass I/O call blocks forever
Message-ID: <200011272113.NAA25157@sf-web2.i.sourceforge.net>

Bug #122756, was updated on 2000-Nov-18 00:14
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: BaseHTTPServer subclass I/O call blocks forever

Details: The following BaseHTTPServer subclass blocks in the do_POST() method under Python 2.0, 1.5.2 (on Windows NT and Linux) and JPython 1.1+09.  It seems to block in the write() calls after the read() call.




import BaseHTTPServer 
 
 
class VASTestHTTPRequestHandler(BaseHTTPServer.BaseHTTPRequestHandler): 
 
    contentType="text/html" 
 
    htmlForm="<FORM METHOD=POST ACTION=/handler>\r\n<br>NAME:&nbsp;<INPUT TYPE=\
TEXT NAME=name></INPUT><br><INPUT TYPE=SUBMIT></INPUT><p>\r\n</FORM>\r\n" 
    rspGETContent="<HTML>\r\n<HEAD>\r\n</HEAD>\r\n<BODY>\r\n<H1>GET</H1>\r\n%s<\
/BODY>\r\n</HTML>\r\n" 
 
    rspPOSTContent="\r\n\r\n<HTML>\r\n<HEAD>\r\n</HEAD>\r\n<BODY>\r\n<H1>POST</\
H1>\r\n%s</BODY>\r\n</HTML>\r\n" 
 
    def do_GET(self): 
        self.send_head() 
        self.wfile.write(self.rspGETContent % (self.htmlForm)) 
         
    def do_HEAD(self): 
        self.send_head() 
    def do_POST(self): 
        self.log_message("%s","Processing POST  ...") 
        self.log_message("%s",self.rspPOSTContent % (self.htmlForm)) 
        self.contentLength=int(self.headers.getheader("Content-Length")) 
        self.log_message("content-length=%d",self.contentLength) 
 
        # this read blocks forever 
        self.reqContent=self.rfile.read() 
        self.log_message("%s",self.reqContent) 
 
        self.send_head() 
        self.wfile.write(self.rspPOSTContent % (self.htmlForm)) 
        self.log_message("%s","Processed POST") 
         
    def send_head(self): 
        self.send_response(200) 
        self.send_header("Content-Type",self.contentType) 
        self.send_header("Expires","0") 
        self.end_headers() 
 
    def setContentType(self,type): 
        self.contentType=type 
 
 
def test(HandlerClass = VASTestHTTPRequestHandler, 
         ServerClass = BaseHTTPServer.HTTPServer): 
    port=8888 
    serverAddress=('',port) 
    httpd = ServerClass(serverAddress, HandlerClass) 
 
    print "Serving HTTP on port", port, "..." 
    httpd.serve_forever() 
 
 
if __name__ == '__main__': 
    test() 
 

Follow-Ups:

Date: 2000-Nov-27 13:13
By: gvanrossum

Comment:
As the author of said module I'll look at this.
-------------------------------------------------------

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


From noreply@sourceforge.net  Mon Nov 27 21:16:35 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 13:16:35 -0800
Subject: [Python-bugs-list] [Bug #122756] BaseHTTPServer subclass I/O call blocks forever
Message-ID: <200011272116.NAA20531@sf-web1.i.sourceforge.net>

Bug #122756, was updated on 2000-Nov-18 00:14
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Invalid
Bug Group: Not a Bug
Priority: 5
Summary: BaseHTTPServer subclass I/O call blocks forever

Details: The following BaseHTTPServer subclass blocks in the do_POST() method under Python 2.0, 1.5.2 (on Windows NT and Linux) and JPython 1.1+09.  It seems to block in the write() calls after the read() call.




import BaseHTTPServer 
 
 
class VASTestHTTPRequestHandler(BaseHTTPServer.BaseHTTPRequestHandler): 
 
    contentType="text/html" 
 
    htmlForm="<FORM METHOD=POST ACTION=/handler>\r\n<br>NAME:&nbsp;<INPUT TYPE=\
TEXT NAME=name></INPUT><br><INPUT TYPE=SUBMIT></INPUT><p>\r\n</FORM>\r\n" 
    rspGETContent="<HTML>\r\n<HEAD>\r\n</HEAD>\r\n<BODY>\r\n<H1>GET</H1>\r\n%s<\
/BODY>\r\n</HTML>\r\n" 
 
    rspPOSTContent="\r\n\r\n<HTML>\r\n<HEAD>\r\n</HEAD>\r\n<BODY>\r\n<H1>POST</\
H1>\r\n%s</BODY>\r\n</HTML>\r\n" 
 
    def do_GET(self): 
        self.send_head() 
        self.wfile.write(self.rspGETContent % (self.htmlForm)) 
         
    def do_HEAD(self): 
        self.send_head() 
    def do_POST(self): 
        self.log_message("%s","Processing POST  ...") 
        self.log_message("%s",self.rspPOSTContent % (self.htmlForm)) 
        self.contentLength=int(self.headers.getheader("Content-Length")) 
        self.log_message("content-length=%d",self.contentLength) 
 
        # this read blocks forever 
        self.reqContent=self.rfile.read() 
        self.log_message("%s",self.reqContent) 
 
        self.send_head() 
        self.wfile.write(self.rspPOSTContent % (self.htmlForm)) 
        self.log_message("%s","Processed POST") 
         
    def send_head(self): 
        self.send_response(200) 
        self.send_header("Content-Type",self.contentType) 
        self.send_header("Expires","0") 
        self.end_headers() 
 
    def setContentType(self,type): 
        self.contentType=type 
 
 
def test(HandlerClass = VASTestHTTPRequestHandler, 
         ServerClass = BaseHTTPServer.HTTPServer): 
    port=8888 
    serverAddress=('',port) 
    httpd = ServerClass(serverAddress, HandlerClass) 
 
    print "Serving HTTP on port", port, "..." 
    httpd.serve_forever() 
 
 
if __name__ == '__main__': 
    test() 
 

Follow-Ups:

Date: 2000-Nov-27 13:13
By: gvanrossum

Comment:
As the author of said module I'll look at this.
-------------------------------------------------------

Date: 2000-Nov-27 13:16
By: gvanrossum

Comment:
This is a bug in the test code. You call self.rfile.read(), which attempts to read until it sees an EOF. Not all browsers send an EOF. To fix, use self.rfile.read(self.contentLength) instead.
-------------------------------------------------------

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


From noreply@sourceforge.net  Mon Nov 27 21:16:34 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 13:16:34 -0800
Subject: [Python-bugs-list] [Bug #122756] BaseHTTPServer subclass I/O call blocks forever
Message-ID: <200011272116.NAA20528@sf-web1.i.sourceforge.net>

Bug #122756, was updated on 2000-Nov-18 00:14
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: BaseHTTPServer subclass I/O call blocks forever

Details: The following BaseHTTPServer subclass blocks in the do_POST() method under Python 2.0, 1.5.2 (on Windows NT and Linux) and JPython 1.1+09.  It seems to block in the write() calls after the read() call.




import BaseHTTPServer 
 
 
class VASTestHTTPRequestHandler(BaseHTTPServer.BaseHTTPRequestHandler): 
 
    contentType="text/html" 
 
    htmlForm="<FORM METHOD=POST ACTION=/handler>\r\n<br>NAME:&nbsp;<INPUT TYPE=\
TEXT NAME=name></INPUT><br><INPUT TYPE=SUBMIT></INPUT><p>\r\n</FORM>\r\n" 
    rspGETContent="<HTML>\r\n<HEAD>\r\n</HEAD>\r\n<BODY>\r\n<H1>GET</H1>\r\n%s<\
/BODY>\r\n</HTML>\r\n" 
 
    rspPOSTContent="\r\n\r\n<HTML>\r\n<HEAD>\r\n</HEAD>\r\n<BODY>\r\n<H1>POST</\
H1>\r\n%s</BODY>\r\n</HTML>\r\n" 
 
    def do_GET(self): 
        self.send_head() 
        self.wfile.write(self.rspGETContent % (self.htmlForm)) 
         
    def do_HEAD(self): 
        self.send_head() 
    def do_POST(self): 
        self.log_message("%s","Processing POST  ...") 
        self.log_message("%s",self.rspPOSTContent % (self.htmlForm)) 
        self.contentLength=int(self.headers.getheader("Content-Length")) 
        self.log_message("content-length=%d",self.contentLength) 
 
        # this read blocks forever 
        self.reqContent=self.rfile.read() 
        self.log_message("%s",self.reqContent) 
 
        self.send_head() 
        self.wfile.write(self.rspPOSTContent % (self.htmlForm)) 
        self.log_message("%s","Processed POST") 
         
    def send_head(self): 
        self.send_response(200) 
        self.send_header("Content-Type",self.contentType) 
        self.send_header("Expires","0") 
        self.end_headers() 
 
    def setContentType(self,type): 
        self.contentType=type 
 
 
def test(HandlerClass = VASTestHTTPRequestHandler, 
         ServerClass = BaseHTTPServer.HTTPServer): 
    port=8888 
    serverAddress=('',port) 
    httpd = ServerClass(serverAddress, HandlerClass) 
 
    print "Serving HTTP on port", port, "..." 
    httpd.serve_forever() 
 
 
if __name__ == '__main__': 
    test() 
 

Follow-Ups:

Date: 2000-Nov-27 13:13
By: gvanrossum

Comment:
As the author of said module I'll look at this.
-------------------------------------------------------

Date: 2000-Nov-27 13:16
By: gvanrossum

Comment:
This is a bug in the test code. You call self.rfile.read(), which attempts to read until it sees an EOF. Not all browsers send an EOF. To fix, use self.rfile.read(self.contentLength) instead.
-------------------------------------------------------

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


From noreply@sourceforge.net  Mon Nov 27 21:17:14 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 13:17:14 -0800
Subject: [Python-bugs-list] [Bug #123398] "Python/C API Reference Manual" erroneous Python/C exception
Message-ID: <200011272117.NAA25233@sf-web2.i.sourceforge.net>

Bug #123398, was updated on 2000-Nov-24 20:29
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: "Python/C API Reference Manual" erroneous Python/C exception

Details: The documentation page "Python20/Doc/api/exceptions.html" gives an example of how to handle Python exceptions in C.
It provides a Python function and what it claims is the equivalent C function.
However, they are not equivalent, in that the Python function returns a modified item from a list/dict, whereas the C function actually modifies the list/dict and returns only its success/failure.
I believe the two can be made equivalent by replacing the last line of the Python function:
  return item + 1
with:
  dict[key] = item + 1


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


From noreply@sourceforge.net  Mon Nov 27 21:17:28 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 13:17:28 -0800
Subject: [Python-bugs-list] [Bug #123225] asyncore.py should use select.poll(), not "import poll"
Message-ID: <200011272117.NAA20548@sf-web1.i.sourceforge.net>

Bug #123225, was updated on 2000-Nov-22 20:41
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: Not a Bug
Priority: 5
Summary: asyncore.py should use select.poll(), not "import poll"

Details: The Python2.0 asyncore module is able to use the poll system call
(claimed to be much more efficient than select for large numbers of requests),
however, it tries to "import poll", which fails (there is no pollmodule supplied with Python2.0), whereas it could
use the poll available with the select module (select.poll()).



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


From noreply@sourceforge.net  Mon Nov 27 21:17:02 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 13:17:02 -0800
Subject: [Python-bugs-list] [Bug #123409] Global Module Index up link does not work
Message-ID: <200011272117.NAA25230@sf-web2.i.sourceforge.net>

Bug #123409, was updated on 2000-Nov-24 23:58
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 3
Summary: Global Module Index up link does not work

Details: The Up button on the global module index page fails because the index page is on the same level as the general documentation index.

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


From noreply@sourceforge.net  Mon Nov 27 21:17:43 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 13:17:43 -0800
Subject: [Python-bugs-list] [Bug #122729] writable not writeable in asyncore
Message-ID: <200011272117.NAA20551@sf-web1.i.sourceforge.net>

Bug #122729, was updated on 2000-Nov-17 14:59
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: writable not writeable in asyncore

Details: in the asyncore docs it refers to the function as "writeable" when it is "writable"

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


From noreply@sourceforge.net  Mon Nov 27 21:21:19 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 13:21:19 -0800
Subject: [Python-bugs-list] [Bug #122690] invalid default module path
Message-ID: <200011272121.NAA25304@sf-web2.i.sourceforge.net>

Bug #122690, was updated on 2000-Nov-17 07:35
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 1
Summary: invalid default module path

Details: I have installed Python2.0 in a Linux 2.2 box under /usr/local/python/

I can define PYTHONHOME and PYTHONPATH pointing to the correct places and everything will work fine, but If I just do to include "/usr/local/python/bin/" in the PATH, python is unable to find any module from the standart module set.

Is this the correct behaviour?



Follow-Ups:

Date: 2000-Nov-27 13:21
By: gvanrossum

Comment:
This is not correct behavior, but the problem is probably in how your system is set up. Is PATH exported? Are there other Python installations? Are all the permissions set correctly? 

The best clue may be: what is sys.path when it doesn't work? (It should still be able to import "sys" even if everything else fails). Also try python -v.
-------------------------------------------------------

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


From noreply@sourceforge.net  Mon Nov 27 21:21:19 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 13:21:19 -0800
Subject: [Python-bugs-list] [Bug #122690] invalid default module path
Message-ID: <200011272121.NAA25301@sf-web2.i.sourceforge.net>

Bug #122690, was updated on 2000-Nov-17 07:35
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: invalid default module path

Details: I have installed Python2.0 in a Linux 2.2 box under /usr/local/python/

I can define PYTHONHOME and PYTHONPATH pointing to the correct places and everything will work fine, but If I just do to include "/usr/local/python/bin/" in the PATH, python is unable to find any module from the standart module set.

Is this the correct behaviour?



Follow-Ups:

Date: 2000-Nov-27 13:21
By: gvanrossum

Comment:
This is not correct behavior, but the problem is probably in how your system is set up. Is PATH exported? Are there other Python installations? Are all the permissions set correctly? 

The best clue may be: what is sys.path when it doesn't work? (It should still be able to import "sys" even if everything else fails). Also try python -v.
-------------------------------------------------------

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


From noreply@sourceforge.net  Mon Nov 27 21:22:39 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 13:22:39 -0800
Subject: [Python-bugs-list] [Bug #110843] Low FD_SETSIZE limit on Win32 (PR#41)
Message-ID: <200011272122.NAA25341@sf-web2.i.sourceforge.net>

Bug #110843, was updated on 2000-Aug-01 14:15
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 3
Summary: Low FD_SETSIZE limit on Win32 (PR#41)

Details: Jitterbug-Id: 41
Submitted-By: brian@digicool.com
Date: Fri, 30 Jul 1999 10:10:49 -0400 (EDT)
Version: 1.5.2
OS: NT


It appears that win32 has a default limit of 64 descriptors that 
can be handed to the select() function. This is pretty low for
any serious async servers, and causes them to raise lots of errors
under very moderate loads.

We at DC ran into this using Medusa as a basis for ZServer, which
serves Zope sites. It turns out that you can actually add a define
when compiling the python15.dll for windows to bump the default
fd limit to a more reasonable level.

The approach _I_ took was to add the define: FD_SETSIZE=1024
to the preprocessor options in the MSVC project settings for
python15.dll, though I imagine you could also roll the define
into config.h or something (so long as it's defined before
windows.h or any of the select / socket include files are
referenced). It would make life much easier for win32 server
developers if this define could find its way into the next
official python release :^)

Thanks!


Brian Lloyd        brian@digicool.com
Software Engineer  540.371.6909              
Digital Creations  http://www.digicool.com 




====================================================================
Audit trail:
Fri Jul 30 10:43:41 1999	guido	moved from incoming to request

Follow-Ups:

Date: 2000-Aug-30 23:19
By: mhammond

Comment:
I am a little worried that adding it to config.h may have side-effects when Python is embedded in other projects with their own socket config (eg, Mozilla :-)

Now that socket and select are external .pyd modules, will it be sufficient to only add it to these extension modules?
-------------------------------------------------------

Date: 2000-Sep-21 21:16
By: tim_one

Comment:
Changed summary to say "Win32" instead of "NT", as this is a general Win32 issue.

Mark, did you email your question directly to Brian?  (This bug got moved over from Jitterbug, so he didn't see your note otherwise.)

I certainly agree Python can't go changing the MS default value in any way visible from Python.h (which #includes config.h).
-------------------------------------------------------

Date: 2000-Oct-05 21:11
By: mhammond

Comment:
Brian has agreed to help with a specific patch that will remain local to the Python build.  Dropping priority to reflect that it wont affect most users, and wont make 2.0.
-------------------------------------------------------

Date: 2000-Nov-10 12:51
By: tim_one

Comment:
Mark, Guido is agreeable to Python adding its own

#ifndef FD_SETSIZE
#define FD_SETSIZE ???
#endif

block.  If other people are doing the define-this-thing-on-the-cmdline trick, fine, such a block won't interfere with their beliefs.

So the primary remaining question is what "???" should be.  Is 1024 enough?  Someone else just bumped into the 64 limit (Python-Help), but didn't commit to a specific amount.
-------------------------------------------------------

Date: 2000-Nov-10 15:27
By: Nobody

Comment:
I recently raised this in the help desk for python. 
I am running into this in the WInsock arena and I really want to get over this hump. Can I get a Python dll with 1024 sockets in 1.5.2? I would be happy to test this in the Win2k arena for you (like that is a major gold star).

Really even 256 would be ok for me .. but 1024 is a spot more attractive (as I wouldn't have to keep watch on this all the time). Many thanks to Martin von Loewis and Tim Peters for thier help.


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

Date: 2000-Nov-27 13:22
By: gvanrossum

Comment:
Tim -- it's time to commit on this. I recommend 512 as a compromise. <0.5 wink>
-------------------------------------------------------

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


From noreply@sourceforge.net  Mon Nov 27 21:22:39 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 13:22:39 -0800
Subject: [Python-bugs-list] [Bug #110843] Low FD_SETSIZE limit on Win32 (PR#41)
Message-ID: <200011272122.NAA25344@sf-web2.i.sourceforge.net>

Bug #110843, was updated on 2000-Aug-01 14:15
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 3
Summary: Low FD_SETSIZE limit on Win32 (PR#41)

Details: Jitterbug-Id: 41
Submitted-By: brian@digicool.com
Date: Fri, 30 Jul 1999 10:10:49 -0400 (EDT)
Version: 1.5.2
OS: NT


It appears that win32 has a default limit of 64 descriptors that 
can be handed to the select() function. This is pretty low for
any serious async servers, and causes them to raise lots of errors
under very moderate loads.

We at DC ran into this using Medusa as a basis for ZServer, which
serves Zope sites. It turns out that you can actually add a define
when compiling the python15.dll for windows to bump the default
fd limit to a more reasonable level.

The approach _I_ took was to add the define: FD_SETSIZE=1024
to the preprocessor options in the MSVC project settings for
python15.dll, though I imagine you could also roll the define
into config.h or something (so long as it's defined before
windows.h or any of the select / socket include files are
referenced). It would make life much easier for win32 server
developers if this define could find its way into the next
official python release :^)

Thanks!


Brian Lloyd        brian@digicool.com
Software Engineer  540.371.6909              
Digital Creations  http://www.digicool.com 




====================================================================
Audit trail:
Fri Jul 30 10:43:41 1999	guido	moved from incoming to request

Follow-Ups:

Date: 2000-Aug-30 23:19
By: mhammond

Comment:
I am a little worried that adding it to config.h may have side-effects when Python is embedded in other projects with their own socket config (eg, Mozilla :-)

Now that socket and select are external .pyd modules, will it be sufficient to only add it to these extension modules?
-------------------------------------------------------

Date: 2000-Sep-21 21:16
By: tim_one

Comment:
Changed summary to say "Win32" instead of "NT", as this is a general Win32 issue.

Mark, did you email your question directly to Brian?  (This bug got moved over from Jitterbug, so he didn't see your note otherwise.)

I certainly agree Python can't go changing the MS default value in any way visible from Python.h (which #includes config.h).
-------------------------------------------------------

Date: 2000-Oct-05 21:11
By: mhammond

Comment:
Brian has agreed to help with a specific patch that will remain local to the Python build.  Dropping priority to reflect that it wont affect most users, and wont make 2.0.
-------------------------------------------------------

Date: 2000-Nov-10 12:51
By: tim_one

Comment:
Mark, Guido is agreeable to Python adding its own

#ifndef FD_SETSIZE
#define FD_SETSIZE ???
#endif

block.  If other people are doing the define-this-thing-on-the-cmdline trick, fine, such a block won't interfere with their beliefs.

So the primary remaining question is what "???" should be.  Is 1024 enough?  Someone else just bumped into the 64 limit (Python-Help), but didn't commit to a specific amount.
-------------------------------------------------------

Date: 2000-Nov-10 15:27
By: Nobody

Comment:
I recently raised this in the help desk for python. 
I am running into this in the WInsock arena and I really want to get over this hump. Can I get a Python dll with 1024 sockets in 1.5.2? I would be happy to test this in the Win2k arena for you (like that is a major gold star).

Really even 256 would be ok for me .. but 1024 is a spot more attractive (as I wouldn't have to keep watch on this all the time). Many thanks to Martin von Loewis and Tim Peters for thier help.


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

Date: 2000-Nov-27 13:22
By: gvanrossum

Comment:
Tim -- it's time to commit on this. I recommend 512 as a compromise. <0.5 wink>
-------------------------------------------------------

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


From noreply@sourceforge.net  Mon Nov 27 21:23:43 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 13:23:43 -0800
Subject: [Python-bugs-list] [Bug #122680] compile python 2.0 on irix 6.5
Message-ID: <200011272123.NAA25363@sf-web2.i.sourceforge.net>

Bug #122680, was updated on 2000-Nov-17 04:11
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: Duplicate
Bug Group: Irreproducible
Priority: 5
Summary: compile python 2.0 on irix 6.5

Details: tried to compile python 2.0 with irix6.5
with irix-cc and egcs

'import site' failed; use -v for traceback
Python 2.0 (#3, Nov 17 2000, 13:05:58) 
[GCC egcs-2.91.66 19990314 (egcs-1.1.2 release)] on irix6
Type "copyright", "credits" or "license" for more information.

PYTHONPATH= ./python -tt ./Lib/test/regrtest.py -l
'import site' failed; use -v for traceback
Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 35, in ?
    import string
ImportError: No module named string
gmake: [test] Error 1 (ignored)
PYTHONPATH= ./python -tt ./Lib/test/regrtest.py -l
'import site' failed; use -v for traceback
Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 35, in ?
    import string
ImportError: No module named string
gmake: *** [test] Error 1

nearly same error-message with irix-cc, 
any ideas ??



Follow-Ups:

Date: 2000-Nov-22 14:41
By: cgw

Comment:
Are you the same "Nobody" who submitted bug #122517?
This looks like a nearly identical bug report.  I cannot
reproduce this on:
	IRIX64 6.5 04191225 IP27
	MIPSpro Compilers:  Version 7.30

Suggest doing a "make distclean" and retrying.
Possibly you have a corrupt source installation or something else is wrong with your system.

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

Date: 2000-Nov-23 08:32
By: HaraldS

Comment:
Yes, i was first time not shure
which Category to use,

no more problems now after starting
from scratch

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

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


From noreply@sourceforge.net  Mon Nov 27 21:24:56 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 13:24:56 -0800
Subject: [Python-bugs-list] [Bug #122625] Using os.system() does not execute some programs
Message-ID: <200011272124.NAA20712@sf-web1.i.sourceforge.net>

Bug #122625, was updated on 2000-Nov-16 13:29
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 3
Summary: Using os.system() does not execute some programs

Details: I do not think I can fully explain what is happening. Here is my attempt.
I use Python as a scripting to run large programs. Sometimes the code I expect python to run in os.system(command) does not run. I cannot figure out why it does not run. 

My guess is that os.system() cannot execute large programs (sometimes?). Becuase when I run
	command = "XYZ"   # whatever long program
	print command
	os.system(command)
it sometimes works. I have not just piped it to tcsh as 
	command = "XYZ"
	print command
Take the above program | tcsh
This works all the time.

Follow-Ups:

Date: 2000-Nov-16 13:42
By: gvanrossum

Comment:
We don't have enough information to go on here. What's the platform used?

It may well have to do with the exact contents of "XYZ". Can you give an example of an XYZ that doesn't work? (As a baseline, an example that *does* work for you would be helpful too.)

I'm not sure what you mean by "large program", but I'm suspecting that you mean "a large amount of sh script code". If this is the case, consider using os.popen() to pipe the script into tcsh under control of your program.

I *think* this is not a bug but a "HOWTO" question.

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

Date: 2000-Nov-27 13:24
By: gvanrossum

Comment:
I'll close this, the submitter is clearly not very interested.
-------------------------------------------------------

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


From noreply@sourceforge.net  Mon Nov 27 21:24:56 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 13:24:56 -0800
Subject: [Python-bugs-list] [Bug #122625] Using os.system() does not execute some programs
Message-ID: <200011272124.NAA20715@sf-web1.i.sourceforge.net>

Bug #122625, was updated on 2000-Nov-16 13:29
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: None
Bug Group: Platform-specific
Priority: 1
Summary: Using os.system() does not execute some programs

Details: I do not think I can fully explain what is happening. Here is my attempt.
I use Python as a scripting to run large programs. Sometimes the code I expect python to run in os.system(command) does not run. I cannot figure out why it does not run. 

My guess is that os.system() cannot execute large programs (sometimes?). Becuase when I run
	command = "XYZ"   # whatever long program
	print command
	os.system(command)
it sometimes works. I have not just piped it to tcsh as 
	command = "XYZ"
	print command
Take the above program | tcsh
This works all the time.

Follow-Ups:

Date: 2000-Nov-16 13:42
By: gvanrossum

Comment:
We don't have enough information to go on here. What's the platform used?

It may well have to do with the exact contents of "XYZ". Can you give an example of an XYZ that doesn't work? (As a baseline, an example that *does* work for you would be helpful too.)

I'm not sure what you mean by "large program", but I'm suspecting that you mean "a large amount of sh script code". If this is the case, consider using os.popen() to pipe the script into tcsh under control of your program.

I *think* this is not a bug but a "HOWTO" question.

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

Date: 2000-Nov-27 13:24
By: gvanrossum

Comment:
I'll close this, the submitter is clearly not very interested.
-------------------------------------------------------

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


From noreply@sourceforge.net  Mon Nov 27 21:25:30 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 13:25:30 -0800
Subject: [Python-bugs-list] [Bug #122517] problems to compile 2.0 on IRIX 6.5
Message-ID: <200011272125.NAA25421@sf-web2.i.sourceforge.net>

Bug #122517, was updated on 2000-Nov-15 10:20
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: Invalid
Bug Group: Not a Bug
Priority: 5
Summary: problems to compile 2.0 on IRIX 6.5

Details: ./configure --prefix=/usr/local/sbin/python/ --with-threads --without-gcc --with-cxx=CC

no errors...

gmake test:

PYTHONPATH= ./python -tt ./Lib/test/regrtest.py -l
'import site' failed; use -v for traceback
Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 35, in ?
    import string
ImportError: No module named string
gmake: [test] Error 1 (ignored)
PYTHONPATH= ./python -tt ./Lib/test/regrtest.py -l
'import site' failed; use -v for traceback
Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 35, in ?
    import string
ImportError: No module named string
gmake: *** [test] Error 1


Follow-Ups:

Date: 2000-Nov-22 14:38
By: cgw

Comment:
I am unable to reproduce this on:
	IRIX64 6.5 04191225 IP27
	MIPSpro Compilers: Version 7.30

using the identical ./configure command

Suggest doing a "make distclean" and retrying.

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

Date: 2000-Nov-23 08:29
By: HaraldS

Comment:
that's it, i'm sure that i tried this several
times but ...
well i started from scratch and now it works !
thanx

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

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


From noreply@sourceforge.net  Mon Nov 27 21:32:28 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 13:32:28 -0800
Subject: [Python-bugs-list] [Bug #122463] ./configure --help double trouble
Message-ID: <200011272132.NAA17983@sf-web3.vaspecialprojects.com>

Bug #122463, was updated on 2000-Nov-14 18:27
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 3
Summary: ./configure --help double trouble

Details: When you do a ./configure --help it reports that you can use a '--program-suffix=SUFFIX' to append SUFFIX to installed program names AND '--with-suffix=.exe' to set executable suffix.  Are these the same?  If so the program-suffix doesn't work. 

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


From noreply@sourceforge.net  Mon Nov 27 22:03:37 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 14:03:37 -0800
Subject: [Python-bugs-list] [Bug #123634] Pickle broken on Unicode strings
Message-ID: <200011272203.OAA18602@sf-web3.vaspecialprojects.com>

Bug #123634, was updated on 2000-Nov-27 14:03
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Pickle broken on Unicode strings

Details: Two one-liners that produce incorrect output:

>>> cPickle.loads(cPickle.dumps(u''))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
cPickle.UnpicklingError: pickle data was truncated
>>> cPickle.loads(cPickle.dumps(u'\u03b1 alpha\n\u03b2 beta'))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
cPickle.UnpicklingError: invalid load key, '\'.

The format of the Unicode string in the pickled representation is not escaped, as it is with regular strings.  It should be.  The latter bug occurs in both pickle and cPickle; the former is only a problem with cPickle.

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


From noreply@sourceforge.net  Mon Nov 27 22:10:42 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 14:10:42 -0800
Subject: [Python-bugs-list] [Bug #122463] ./configure --help double trouble
Message-ID: <200011272210.OAA18720@sf-web3.vaspecialprojects.com>

Bug #122463, was updated on 2000-Nov-14 18:27
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 3
Summary: ./configure --help double trouble

Details: When you do a ./configure --help it reports that you can use a '--program-suffix=SUFFIX' to append SUFFIX to installed program names AND '--with-suffix=.exe' to set executable suffix.  Are these the same?  If so the program-suffix doesn't work. 

Follow-Ups:

Date: 2000-Nov-27 14:10
By: gvanrossum

Comment:
The --program-suffix option is a freebie from the standard autoconf library. It is unused. Sorry for the confusion.
-------------------------------------------------------

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


From noreply@sourceforge.net  Mon Nov 27 22:10:42 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 14:10:42 -0800
Subject: [Python-bugs-list] [Bug #122463] ./configure --help double trouble
Message-ID: <200011272210.OAA18723@sf-web3.vaspecialprojects.com>

Bug #122463, was updated on 2000-Nov-14 18:27
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: Wont Fix
Bug Group: None
Priority: 3
Summary: ./configure --help double trouble

Details: When you do a ./configure --help it reports that you can use a '--program-suffix=SUFFIX' to append SUFFIX to installed program names AND '--with-suffix=.exe' to set executable suffix.  Are these the same?  If so the program-suffix doesn't work. 

Follow-Ups:

Date: 2000-Nov-27 14:10
By: gvanrossum

Comment:
The --program-suffix option is a freebie from the standard autoconf library. It is unused. Sorry for the confusion.
-------------------------------------------------------

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


From noreply@sourceforge.net  Mon Nov 27 22:14:42 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 14:14:42 -0800
Subject: [Python-bugs-list] [Bug #123634] Pickle broken on Unicode strings
Message-ID: <200011272214.OAA26459@sf-web2.i.sourceforge.net>

Bug #123634, was updated on 2000-Nov-27 14:03
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Pickle broken on Unicode strings

Details: Two one-liners that produce incorrect output:

>>> cPickle.loads(cPickle.dumps(u''))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
cPickle.UnpicklingError: pickle data was truncated
>>> cPickle.loads(cPickle.dumps(u'\u03b1 alpha\n\u03b2 beta'))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
cPickle.UnpicklingError: invalid load key, '\'.

The format of the Unicode string in the pickled representation is not escaped, as it is with regular strings.  It should be.  The latter bug occurs in both pickle and cPickle; the former is only a problem with cPickle.

Follow-Ups:

Date: 2000-Nov-27 14:14
By: gvanrossum

Comment:
Jim, do you have time to look into this?
-------------------------------------------------------

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


From noreply@sourceforge.net  Mon Nov 27 22:14:42 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 14:14:42 -0800
Subject: [Python-bugs-list] [Bug #123634] Pickle broken on Unicode strings
Message-ID: <200011272214.OAA26456@sf-web2.i.sourceforge.net>

Bug #123634, was updated on 2000-Nov-27 14:03
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Pickle broken on Unicode strings

Details: Two one-liners that produce incorrect output:

>>> cPickle.loads(cPickle.dumps(u''))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
cPickle.UnpicklingError: pickle data was truncated
>>> cPickle.loads(cPickle.dumps(u'\u03b1 alpha\n\u03b2 beta'))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
cPickle.UnpicklingError: invalid load key, '\'.

The format of the Unicode string in the pickled representation is not escaped, as it is with regular strings.  It should be.  The latter bug occurs in both pickle and cPickle; the former is only a problem with cPickle.

Follow-Ups:

Date: 2000-Nov-27 14:14
By: gvanrossum

Comment:
Jim, do you have time to look into this?
-------------------------------------------------------

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


From noreply@sourceforge.net  Mon Nov 27 22:20:22 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 14:20:22 -0800
Subject: [Python-bugs-list] [Bug #123634] Pickle broken on Unicode strings
Message-ID: <200011272220.OAA26561@sf-web2.i.sourceforge.net>

Bug #123634, was updated on 2000-Nov-27 14:03
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Pickle broken on Unicode strings

Details: Two one-liners that produce incorrect output:

>>> cPickle.loads(cPickle.dumps(u''))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
cPickle.UnpicklingError: pickle data was truncated
>>> cPickle.loads(cPickle.dumps(u'\u03b1 alpha\n\u03b2 beta'))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
cPickle.UnpicklingError: invalid load key, '\'.

The format of the Unicode string in the pickled representation is not escaped, as it is with regular strings.  It should be.  The latter bug occurs in both pickle and cPickle; the former is only a problem with cPickle.

Follow-Ups:

Date: 2000-Nov-27 14:14
By: gvanrossum

Comment:
Jim, do you have time to look into this?
-------------------------------------------------------

Date: 2000-Nov-27 14:20
By: tlau

Comment:
Here's my proposed patch to Lib/pickle.py (cPickle should be changed similarly):

--- /scratch/tlau/Python-2.0/Lib/pickle.py      Mon Oct 16 14:49:51 2000
+++ pickle.py   Mon Nov 27 14:07:01 2000
@@ -286,9 +286,9 @@
             encoding = object.encode('utf-8')
             l = len(encoding)
             s = mdumps(l)[1:]
-            self.write(BINUNICODE + s + encoding)
+            self.write(BINUNICODE + `s` + encoding)
         else:
-            self.write(UNICODE + object.encode('raw-unicode-escape') + '\n')
+            self.write(UNICODE + `object.encode('raw-unicode-escape')` + '\n')
 
         memo_len = len(memo)
         self.write(self.put(memo_len))
@@ -627,7 +627,12 @@
     dispatch[BINSTRING] = load_binstring
 
     def load_unicode(self):
-        self.append(unicode(self.readline()[:-1],'raw-unicode-escape'))
+        rep = self.readline()[:-1]
+        if not self._is_string_secure(rep):
+            raise ValueError, "insecure string pickle"
+        rep = eval(rep,
+                   {'__builtins__': {}}) # Let's be careful
+        self.append(unicode(rep, 'raw-unicode-escape'))
     dispatch[UNICODE] = load_unicode
 
     def load_binunicode(self):

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

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


From noreply@sourceforge.net  Mon Nov 27 22:35:03 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 14:35:03 -0800
Subject: [Python-bugs-list] [Bug #123634] Pickle broken on Unicode strings
Message-ID: <200011272235.OAA19103@sf-web3.vaspecialprojects.com>

Bug #123634, was updated on 2000-Nov-27 14:03
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Pickle broken on Unicode strings

Details: Two one-liners that produce incorrect output:

>>> cPickle.loads(cPickle.dumps(u''))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
cPickle.UnpicklingError: pickle data was truncated
>>> cPickle.loads(cPickle.dumps(u'\u03b1 alpha\n\u03b2 beta'))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
cPickle.UnpicklingError: invalid load key, '\'.

The format of the Unicode string in the pickled representation is not escaped, as it is with regular strings.  It should be.  The latter bug occurs in both pickle and cPickle; the former is only a problem with cPickle.

Follow-Ups:

Date: 2000-Nov-27 14:14
By: gvanrossum

Comment:
Jim, do you have time to look into this?
-------------------------------------------------------

Date: 2000-Nov-27 14:20
By: tlau

Comment:
Here's my proposed patch to Lib/pickle.py (cPickle should be changed similarly):

--- /scratch/tlau/Python-2.0/Lib/pickle.py      Mon Oct 16 14:49:51 2000
+++ pickle.py   Mon Nov 27 14:07:01 2000
@@ -286,9 +286,9 @@
             encoding = object.encode('utf-8')
             l = len(encoding)
             s = mdumps(l)[1:]
-            self.write(BINUNICODE + s + encoding)
+            self.write(BINUNICODE + `s` + encoding)
         else:
-            self.write(UNICODE + object.encode('raw-unicode-escape') + '\n')
+            self.write(UNICODE + `object.encode('raw-unicode-escape')` + '\n')
 
         memo_len = len(memo)
         self.write(self.put(memo_len))
@@ -627,7 +627,12 @@
     dispatch[BINSTRING] = load_binstring
 
     def load_unicode(self):
-        self.append(unicode(self.readline()[:-1],'raw-unicode-escape'))
+        rep = self.readline()[:-1]
+        if not self._is_string_secure(rep):
+            raise ValueError, "insecure string pickle"
+        rep = eval(rep,
+                   {'__builtins__': {}}) # Let's be careful
+        self.append(unicode(rep, 'raw-unicode-escape'))
     dispatch[UNICODE] = load_unicode
 
     def load_binunicode(self):

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

Date: 2000-Nov-27 14:35
By: lemburg

Comment:
Some background (no time to fix this myself):

When I added the Unicode handlers, I wanted to avoid the
problems that the string dump mechanism has with
quoted strings. The encodings used either carry length information
(in binary mode: UTF-8) or do not include the \n character
(in ascii mode: raw-unicode-escape encoding). 

Unfortunately, the raw-unicode-escape codec does not
escape the newline character which is used by pickle
to break the input into tokens.... 

Proposed fix: change the encoding to "unicode-escape"
which doesn't have this problem. This will break code,
but only code that is already broken :-/

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

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


From noreply@sourceforge.net  Mon Nov 27 22:36:53 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 14:36:53 -0800
Subject: [Python-bugs-list] [Bug #123634] Pickle broken on Unicode strings
Message-ID: <200011272236.OAA19136@sf-web3.vaspecialprojects.com>

Bug #123634, was updated on 2000-Nov-27 14:03
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Pickle broken on Unicode strings

Details: Two one-liners that produce incorrect output:

>>> cPickle.loads(cPickle.dumps(u''))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
cPickle.UnpicklingError: pickle data was truncated
>>> cPickle.loads(cPickle.dumps(u'\u03b1 alpha\n\u03b2 beta'))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
cPickle.UnpicklingError: invalid load key, '\'.

The format of the Unicode string in the pickled representation is not escaped, as it is with regular strings.  It should be.  The latter bug occurs in both pickle and cPickle; the former is only a problem with cPickle.

Follow-Ups:

Date: 2000-Nov-27 14:14
By: gvanrossum

Comment:
Jim, do you have time to look into this?
-------------------------------------------------------

Date: 2000-Nov-27 14:20
By: tlau

Comment:
Here's my proposed patch to Lib/pickle.py (cPickle should be changed similarly):

--- /scratch/tlau/Python-2.0/Lib/pickle.py      Mon Oct 16 14:49:51 2000
+++ pickle.py   Mon Nov 27 14:07:01 2000
@@ -286,9 +286,9 @@
             encoding = object.encode('utf-8')
             l = len(encoding)
             s = mdumps(l)[1:]
-            self.write(BINUNICODE + s + encoding)
+            self.write(BINUNICODE + `s` + encoding)
         else:
-            self.write(UNICODE + object.encode('raw-unicode-escape') + '\n')
+            self.write(UNICODE + `object.encode('raw-unicode-escape')` + '\n')
 
         memo_len = len(memo)
         self.write(self.put(memo_len))
@@ -627,7 +627,12 @@
     dispatch[BINSTRING] = load_binstring
 
     def load_unicode(self):
-        self.append(unicode(self.readline()[:-1],'raw-unicode-escape'))
+        rep = self.readline()[:-1]
+        if not self._is_string_secure(rep):
+            raise ValueError, "insecure string pickle"
+        rep = eval(rep,
+                   {'__builtins__': {}}) # Let's be careful
+        self.append(unicode(rep, 'raw-unicode-escape'))
     dispatch[UNICODE] = load_unicode
 
     def load_binunicode(self):

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

Date: 2000-Nov-27 14:35
By: lemburg

Comment:
Some background (no time to fix this myself):

When I added the Unicode handlers, I wanted to avoid the
problems that the string dump mechanism has with
quoted strings. The encodings used either carry length information
(in binary mode: UTF-8) or do not include the \n character
(in ascii mode: raw-unicode-escape encoding). 

Unfortunately, the raw-unicode-escape codec does not
escape the newline character which is used by pickle
to break the input into tokens.... 

Proposed fix: change the encoding to "unicode-escape"
which doesn't have this problem. This will break code,
but only code that is already broken :-/

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

Date: 2000-Nov-27 14:36
By: tlau

Comment:
One more comment: binary-format pickles are not affected, only text-format pickles.  Thus the part of my patch that applies to the binary section of the save_unicode function should not be applied.
-------------------------------------------------------

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


From noreply@sourceforge.net  Mon Nov 27 22:51:16 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 14:51:16 -0800
Subject: [Python-bugs-list] [Bug #122729] writable not writeable in asyncore
Message-ID: <200011272251.OAA19376@sf-web3.vaspecialprojects.com>

Bug #122729, was updated on 2000-Nov-17 14:59
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: writable not writeable in asyncore

Details: in the asyncore docs it refers to the function as "writeable" when it is "writable"

Follow-Ups:

Date: 2000-Nov-27 14:51
By: fdrake

Comment:
Already fixed in CVS.

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

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


From noreply@sourceforge.net  Mon Nov 27 22:51:16 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 14:51:16 -0800
Subject: [Python-bugs-list] [Bug #122729] writable not writeable in asyncore
Message-ID: <200011272251.OAA19379@sf-web3.vaspecialprojects.com>

Bug #122729, was updated on 2000-Nov-17 14:59
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: writable not writeable in asyncore

Details: in the asyncore docs it refers to the function as "writeable" when it is "writable"

Follow-Ups:

Date: 2000-Nov-27 14:51
By: fdrake

Comment:
Already fixed in CVS.

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

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


From noreply@sourceforge.net  Mon Nov 27 23:09:47 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 15:09:47 -0800
Subject: [Python-bugs-list] [Bug #123642] Add site-codecs package to enable drop-in codec support
Message-ID: <200011272309.PAA19715@sf-web3.vaspecialprojects.com>

Bug #123642, was updated on 2000-Nov-27 15:09
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: Add site-codecs package to enable drop-in codec support

Details: (This report is just meant as reminder, so this feature request does
get forgotten.)

There were numerous requests for a better drop-in support for
codecs on the i18n-sig list without having to register the codecs
at startup.

Since adding non-core modules to the Lib/encodings directory is not a good
strategy, I proposed to add a new reserved package "sitecodecs"
which can then be used by codec package writer to place their
codecs.

The encodings/__init__.py will then also look in that new package
for codecs it cannot find in its own directory. That way, the new codecs
won't have to register themselves and are available as soon as the
codec modules can be found in the site-codecs package.

The "sitecodecs" package should probably live in site-packages...
perhaps the installation process should provide a default subdir for
this ?!


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


From noreply@sourceforge.net  Mon Nov 27 23:05:48 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 15:05:48 -0800
Subject: [Python-bugs-list] [Bug #123642] Add site-codecs package to enable drop-in codec support
Message-ID: <200011272305.PAA27480@sf-web2.i.sourceforge.net>

Bug #123642, was updated on 2000-Nov-27 15:09
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: Add site-codecs package to enable drop-in codec support

Details: (This report is just meant as reminder, so this feature request does
get forgotten.)

There were numerous requests for a better drop-in support for
codecs on the i18n-sig list without having to register the codecs
at startup.

Since adding non-core modules to the Lib/encodings directory is not a good
strategy, I proposed to add a new reserved package "sitecodecs"
which can then be used by codec package writer to place their
codecs.

The encodings/__init__.py will then also look in that new package
for codecs it cannot find in its own directory. That way, the new codecs
won't have to register themselves and are available as soon as the
codec modules can be found in the site-codecs package.

The "sitecodecs" package should probably live in site-packages...
perhaps the installation process should provide a default subdir for
this ?!


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


From noreply@sourceforge.net  Mon Nov 27 23:43:48 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 15:43:48 -0800
Subject: [Python-bugs-list] [Bug #110843] Low FD_SETSIZE limit on Win32 (PR#41)
Message-ID: <200011272343.PAA20226@sf-web3.vaspecialprojects.com>

Bug #110843, was updated on 2000-Aug-01 14:15
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 3
Summary: Low FD_SETSIZE limit on Win32 (PR#41)

Details: Jitterbug-Id: 41
Submitted-By: brian@digicool.com
Date: Fri, 30 Jul 1999 10:10:49 -0400 (EDT)
Version: 1.5.2
OS: NT


It appears that win32 has a default limit of 64 descriptors that 
can be handed to the select() function. This is pretty low for
any serious async servers, and causes them to raise lots of errors
under very moderate loads.

We at DC ran into this using Medusa as a basis for ZServer, which
serves Zope sites. It turns out that you can actually add a define
when compiling the python15.dll for windows to bump the default
fd limit to a more reasonable level.

The approach _I_ took was to add the define: FD_SETSIZE=1024
to the preprocessor options in the MSVC project settings for
python15.dll, though I imagine you could also roll the define
into config.h or something (so long as it's defined before
windows.h or any of the select / socket include files are
referenced). It would make life much easier for win32 server
developers if this define could find its way into the next
official python release :^)

Thanks!


Brian Lloyd        brian@digicool.com
Software Engineer  540.371.6909              
Digital Creations  http://www.digicool.com 




====================================================================
Audit trail:
Fri Jul 30 10:43:41 1999	guido	moved from incoming to request

Follow-Ups:

Date: 2000-Aug-30 23:19
By: mhammond

Comment:
I am a little worried that adding it to config.h may have side-effects when Python is embedded in other projects with their own socket config (eg, Mozilla :-)

Now that socket and select are external .pyd modules, will it be sufficient to only add it to these extension modules?
-------------------------------------------------------

Date: 2000-Sep-21 21:16
By: tim_one

Comment:
Changed summary to say "Win32" instead of "NT", as this is a general Win32 issue.

Mark, did you email your question directly to Brian?  (This bug got moved over from Jitterbug, so he didn't see your note otherwise.)

I certainly agree Python can't go changing the MS default value in any way visible from Python.h (which #includes config.h).
-------------------------------------------------------

Date: 2000-Oct-05 21:11
By: mhammond

Comment:
Brian has agreed to help with a specific patch that will remain local to the Python build.  Dropping priority to reflect that it wont affect most users, and wont make 2.0.
-------------------------------------------------------

Date: 2000-Nov-10 12:51
By: tim_one

Comment:
Mark, Guido is agreeable to Python adding its own

#ifndef FD_SETSIZE
#define FD_SETSIZE ???
#endif

block.  If other people are doing the define-this-thing-on-the-cmdline trick, fine, such a block won't interfere with their beliefs.

So the primary remaining question is what "???" should be.  Is 1024 enough?  Someone else just bumped into the 64 limit (Python-Help), but didn't commit to a specific amount.
-------------------------------------------------------

Date: 2000-Nov-10 15:27
By: Nobody

Comment:
I recently raised this in the help desk for python. 
I am running into this in the WInsock arena and I really want to get over this hump. Can I get a Python dll with 1024 sockets in 1.5.2? I would be happy to test this in the Win2k arena for you (like that is a major gold star).

Really even 256 would be ok for me .. but 1024 is a spot more attractive (as I wouldn't have to keep watch on this all the time). Many thanks to Martin von Loewis and Tim Peters for thier help.


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

Date: 2000-Nov-27 13:22
By: gvanrossum

Comment:
Tim -- it's time to commit on this. I recommend 512 as a compromise. <0.5 wink>
-------------------------------------------------------

Date: 2000-Nov-27 15:43
By: tim_one

Comment:
Reassigned from MarkH to me.  Unclear what the new value should be (nothing is free ...).

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

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


From noreply@sourceforge.net  Mon Nov 27 23:43:48 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 15:43:48 -0800
Subject: [Python-bugs-list] [Bug #110843] Low FD_SETSIZE limit on Win32 (PR#41)
Message-ID: <200011272343.PAA20229@sf-web3.vaspecialprojects.com>

Bug #110843, was updated on 2000-Aug-01 14:15
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 3
Summary: Low FD_SETSIZE limit on Win32 (PR#41)

Details: Jitterbug-Id: 41
Submitted-By: brian@digicool.com
Date: Fri, 30 Jul 1999 10:10:49 -0400 (EDT)
Version: 1.5.2
OS: NT


It appears that win32 has a default limit of 64 descriptors that 
can be handed to the select() function. This is pretty low for
any serious async servers, and causes them to raise lots of errors
under very moderate loads.

We at DC ran into this using Medusa as a basis for ZServer, which
serves Zope sites. It turns out that you can actually add a define
when compiling the python15.dll for windows to bump the default
fd limit to a more reasonable level.

The approach _I_ took was to add the define: FD_SETSIZE=1024
to the preprocessor options in the MSVC project settings for
python15.dll, though I imagine you could also roll the define
into config.h or something (so long as it's defined before
windows.h or any of the select / socket include files are
referenced). It would make life much easier for win32 server
developers if this define could find its way into the next
official python release :^)

Thanks!


Brian Lloyd        brian@digicool.com
Software Engineer  540.371.6909              
Digital Creations  http://www.digicool.com 




====================================================================
Audit trail:
Fri Jul 30 10:43:41 1999	guido	moved from incoming to request

Follow-Ups:

Date: 2000-Aug-30 23:19
By: mhammond

Comment:
I am a little worried that adding it to config.h may have side-effects when Python is embedded in other projects with their own socket config (eg, Mozilla :-)

Now that socket and select are external .pyd modules, will it be sufficient to only add it to these extension modules?
-------------------------------------------------------

Date: 2000-Sep-21 21:16
By: tim_one

Comment:
Changed summary to say "Win32" instead of "NT", as this is a general Win32 issue.

Mark, did you email your question directly to Brian?  (This bug got moved over from Jitterbug, so he didn't see your note otherwise.)

I certainly agree Python can't go changing the MS default value in any way visible from Python.h (which #includes config.h).
-------------------------------------------------------

Date: 2000-Oct-05 21:11
By: mhammond

Comment:
Brian has agreed to help with a specific patch that will remain local to the Python build.  Dropping priority to reflect that it wont affect most users, and wont make 2.0.
-------------------------------------------------------

Date: 2000-Nov-10 12:51
By: tim_one

Comment:
Mark, Guido is agreeable to Python adding its own

#ifndef FD_SETSIZE
#define FD_SETSIZE ???
#endif

block.  If other people are doing the define-this-thing-on-the-cmdline trick, fine, such a block won't interfere with their beliefs.

So the primary remaining question is what "???" should be.  Is 1024 enough?  Someone else just bumped into the 64 limit (Python-Help), but didn't commit to a specific amount.
-------------------------------------------------------

Date: 2000-Nov-10 15:27
By: Nobody

Comment:
I recently raised this in the help desk for python. 
I am running into this in the WInsock arena and I really want to get over this hump. Can I get a Python dll with 1024 sockets in 1.5.2? I would be happy to test this in the Win2k arena for you (like that is a major gold star).

Really even 256 would be ok for me .. but 1024 is a spot more attractive (as I wouldn't have to keep watch on this all the time). Many thanks to Martin von Loewis and Tim Peters for thier help.


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

Date: 2000-Nov-27 13:22
By: gvanrossum

Comment:
Tim -- it's time to commit on this. I recommend 512 as a compromise. <0.5 wink>
-------------------------------------------------------

Date: 2000-Nov-27 15:43
By: tim_one

Comment:
Reassigned from MarkH to me.  Unclear what the new value should be (nothing is free ...).

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

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


From noreply@sourceforge.net  Tue Nov 28 12:49:17 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 28 Nov 2000 04:49:17 -0800
Subject: [Python-bugs-list] [Bug #123685] bug in extension handling Py_RunSimpleFile
Message-ID: <200011281249.EAA07621@sf-web2.i.sourceforge.net>

Bug #123685, was updated on 2000-Nov-28 04:49
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: bug in extension handling Py_RunSimpleFile

Details: On line 559 of pythonrun.c there's an error:

ext = filename + strlen(filename) - 4;

This line assumes that the extension is 3 chars long, while it can be any size imaginable. Correct behaviour is to search the string from the end for a dot and use the string to the right of the dot as extension.

Floris

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


From noreply@sourceforge.net  Tue Nov 28 14:22:47 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 28 Nov 2000 06:22:47 -0800
Subject: [Python-bugs-list] [Bug #123685] bug in extension handling Py_RunSimpleFile
Message-ID: <200011281422.GAA09449@sf-web2.i.sourceforge.net>

Bug #123685, was updated on 2000-Nov-28 04:49
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: bug in extension handling Py_RunSimpleFile

Details: On line 559 of pythonrun.c there's an error:

ext = filename + strlen(filename) - 4;

This line assumes that the extension is 3 chars long, while it can be any size imaginable. Correct behaviour is to search the string from the end for a dot and use the string to the right of the dot as extension.

Floris

Follow-Ups:

Date: 2000-Nov-28 06:22
By: gvanrossum

Comment:
The code there is correct. The only use made of the ext variable is to compare it to various strings for equality, all of which are exactly 4 characters long. If the actual extension is not 4 characters long, that comparison can never succeed, so it doesn't matter that the ext variable is not pointing to the start of the extension.
-------------------------------------------------------

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


From noreply@sourceforge.net  Tue Nov 28 14:22:48 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 28 Nov 2000 06:22:48 -0800
Subject: [Python-bugs-list] [Bug #123685] bug in extension handling Py_RunSimpleFile
Message-ID: <200011281422.GAA09452@sf-web2.i.sourceforge.net>

Bug #123685, was updated on 2000-Nov-28 04:49
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Closed
Resolution: Invalid
Bug Group: Not a Bug
Priority: 5
Summary: bug in extension handling Py_RunSimpleFile

Details: On line 559 of pythonrun.c there's an error:

ext = filename + strlen(filename) - 4;

This line assumes that the extension is 3 chars long, while it can be any size imaginable. Correct behaviour is to search the string from the end for a dot and use the string to the right of the dot as extension.

Floris

Follow-Ups:

Date: 2000-Nov-28 06:22
By: gvanrossum

Comment:
The code there is correct. The only use made of the ext variable is to compare it to various strings for equality, all of which are exactly 4 characters long. If the actual extension is not 4 characters long, that comparison can never succeed, so it doesn't matter that the ext variable is not pointing to the start of the extension.
-------------------------------------------------------

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


From noreply@sourceforge.net  Tue Nov 28 14:25:23 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 28 Nov 2000 06:25:23 -0800
Subject: [Python-bugs-list] [Bug #123694] String join of Unicode string crashes
Message-ID: <200011281425.GAA04143@sf-web1.i.sourceforge.net>

Bug #123694, was updated on 2000-Nov-28 06:25
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: String join of Unicode string crashes

Details: This is with Python 2.0 (ActiveState build 202).

Start the interpreter, and enter

''.join(u'22')

The interpreter immediately crashes.

Paul Moore <paul.moore@uk.origin-it.com>

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


From noreply@sourceforge.net  Tue Nov 28 14:26:21 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 28 Nov 2000 06:26:21 -0800
Subject: [Python-bugs-list] [Bug #123695] xml.sax.handler.ContentHandler.characters() not SAX2
Message-ID: <200011281426.GAA09672@sf-web2.i.sourceforge.net>

Bug #123695, was updated on 2000-Nov-28 06:26
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: xml.sax.handler.ContentHandler.characters() not SAX2

Details: It takes the wrong arguments and differs from the SAX specification.
I also submitted the following bug to the pyxml-sig bugtracker:

http://sourceforge.net/bugs/?func=detailbug&bug_id=123693&group_id=6473

	SAX2 API documentation says: 	http://www.megginson.com/SAX/Java/javadoc/org/xml/sax/ContentHandler.html#characters(char[], 

                     public void characters(char[] ch,int start, int length) 

                     PyXML-0.6.2/doc/xml-howto.txt says: 
                     def characters(self, ch) 
                     in line 770 

                     This corresponds to how the pyexpat implementation distributed with python 2.0 works, but is not following the SAX API as pyexpat in pyXML 0.6.2 does. 

                     It looks like a bug in python 2.0 and at least a documentation bug for pyxml 0.6.2. 


See the following example program, which should work.

import xml.sax
import xml.sax.handler


class processTask(xml.sax.handler.ContentHandler):
    def startElement(self, name, attrs):
        print "startElement: %s=" % (name),
        print repr(attrs)

# SAX compliant
    def characters(self, ch, start, length):
        print "characters=%s" %(ch[start:start+length])

# works with python 2.0, but is not SAX compliant
#    def characters(self, ch):
#        print "characters=%s" %(ch)
#
    def endElement(self, name): 
        print "endElement: %s=" % (name)


dh = processTask()
string="""<?xml version="1.0"?>
     <parent id="top"><child1 name="paul">Text goes here</child1>
     <child2 name="fred">More text</child2>
     </parent>"""
xml.sax.parseString(string,dh)

but instead is bombs:
startElement: parent= <xml.sax.xmlreader.AttributesImpl instance at 0x813b0e4>
startElement: child1= <xml.sax.xmlreader.AttributesImpl instance at 0x813b0e4>
Traceback (most recent call last):
  File "xmltest2.py", line 27, in ?
    xml.sax.parseString(string,dh)
  File "/usr/src/packages/python/install//lib/python2.0/xml/sax/__init__.py", line 49, in parseString
    parser.parse(inpsrc)
  File "/usr/src/packages/python/install//lib/python2.0/xml/sax/expatreader.py", line 42, in parse
    xmlreader.IncrementalParser.parse(self, source)            
  File "/usr/src/packages/python/install//lib/python2.0/xml/sax/xmlreader.py", line 120, in parse
    self.feed(buffer)
  File "/usr/src/packages/python/install//lib/python2.0/xml/sax/expatreader.py", line 81, in feed
    self._parser.Parse(data, isFinal)
TypeError: not enough arguments; expected 4, got 2


Regards,
	Bernhard Reiter <bernhard@intevation.de>

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


From noreply@sourceforge.net  Tue Nov 28 14:59:28 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 28 Nov 2000 06:59:28 -0800
Subject: [Python-bugs-list] [Bug #123694] String join of Unicode string crashes
Message-ID: <200011281459.GAA32743@sf-web3.vaspecialprojects.com>

Bug #123694, was updated on 2000-Nov-28 06:25
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Duplicate
Bug Group: None
Priority: 5
Summary: String join of Unicode string crashes

Details: This is with Python 2.0 (ActiveState build 202).

Start the interpreter, and enter

''.join(u'22')

The interpreter immediately crashes.

Paul Moore <paul.moore@uk.origin-it.com>

Follow-Ups:

Date: 2000-Nov-28 06:59
By: gvanrossum

Comment:
This was just fixed in the CVS version. Thanks for reporting!
-------------------------------------------------------

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


From noreply@sourceforge.net  Tue Nov 28 14:59:28 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 28 Nov 2000 06:59:28 -0800
Subject: [Python-bugs-list] [Bug #123694] String join of Unicode string crashes
Message-ID: <200011281459.GAA32740@sf-web3.vaspecialprojects.com>

Bug #123694, was updated on 2000-Nov-28 06:25
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: String join of Unicode string crashes

Details: This is with Python 2.0 (ActiveState build 202).

Start the interpreter, and enter

''.join(u'22')

The interpreter immediately crashes.

Paul Moore <paul.moore@uk.origin-it.com>

Follow-Ups:

Date: 2000-Nov-28 06:59
By: gvanrossum

Comment:
This was just fixed in the CVS version. Thanks for reporting!
-------------------------------------------------------

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


From noreply@sourceforge.net  Tue Nov 28 14:53:04 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 28 Nov 2000 06:53:04 -0800
Subject: [Python-bugs-list] [Bug #123695] xml.sax.handler.ContentHandler.characters() not SAX2
Message-ID: <200011281453.GAA10180@sf-web2.i.sourceforge.net>

Bug #123695, was updated on 2000-Nov-28 06:26
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: xml.sax.handler.ContentHandler.characters() not SAX2

Details: It takes the wrong arguments and differs from the SAX specification.
I also submitted the following bug to the pyxml-sig bugtracker:

http://sourceforge.net/bugs/?func=detailbug&bug_id=123693&group_id=6473

	SAX2 API documentation says: 	http://www.megginson.com/SAX/Java/javadoc/org/xml/sax/ContentHandler.html#characters(char[], 

                     public void characters(char[] ch,int start, int length) 

                     PyXML-0.6.2/doc/xml-howto.txt says: 
                     def characters(self, ch) 
                     in line 770 

                     This corresponds to how the pyexpat implementation distributed with python 2.0 works, but is not following the SAX API as pyexpat in pyXML 0.6.2 does. 

                     It looks like a bug in python 2.0 and at least a documentation bug for pyxml 0.6.2. 


See the following example program, which should work.

import xml.sax
import xml.sax.handler


class processTask(xml.sax.handler.ContentHandler):
    def startElement(self, name, attrs):
        print "startElement: %s=" % (name),
        print repr(attrs)

# SAX compliant
    def characters(self, ch, start, length):
        print "characters=%s" %(ch[start:start+length])

# works with python 2.0, but is not SAX compliant
#    def characters(self, ch):
#        print "characters=%s" %(ch)
#
    def endElement(self, name): 
        print "endElement: %s=" % (name)


dh = processTask()
string="""<?xml version="1.0"?>
     <parent id="top"><child1 name="paul">Text goes here</child1>
     <child2 name="fred">More text</child2>
     </parent>"""
xml.sax.parseString(string,dh)

but instead is bombs:
startElement: parent= <xml.sax.xmlreader.AttributesImpl instance at 0x813b0e4>
startElement: child1= <xml.sax.xmlreader.AttributesImpl instance at 0x813b0e4>
Traceback (most recent call last):
  File "xmltest2.py", line 27, in ?
    xml.sax.parseString(string,dh)
  File "/usr/src/packages/python/install//lib/python2.0/xml/sax/__init__.py", line 49, in parseString
    parser.parse(inpsrc)
  File "/usr/src/packages/python/install//lib/python2.0/xml/sax/expatreader.py", line 42, in parse
    xmlreader.IncrementalParser.parse(self, source)            
  File "/usr/src/packages/python/install//lib/python2.0/xml/sax/xmlreader.py", line 120, in parse
    self.feed(buffer)
  File "/usr/src/packages/python/install//lib/python2.0/xml/sax/expatreader.py", line 81, in feed
    self._parser.Parse(data, isFinal)
TypeError: not enough arguments; expected 4, got 2


Regards,
	Bernhard Reiter <bernhard@intevation.de>

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


From noreply@sourceforge.net  Tue Nov 28 18:53:36 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 28 Nov 2000 10:53:36 -0800
Subject: [Python-bugs-list] [Bug #123730] Extra backslash in web page
Message-ID: <200011281853.KAA09039@sf-web1.i.sourceforge.net>

Bug #123730, was updated on 2000-Nov-28 10:53
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Extra backslash in web page

Details: On page http://www.python.org/doc/current/tut/node5.html
this -------> u'Hello\\u0020World !'
should be --> u'Hello\u0020World !'


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


From noreply@sourceforge.net  Wed Nov 29 04:15:09 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 28 Nov 2000 20:15:09 -0800
Subject: [Python-bugs-list] [Bug #123769] sre bug for non-greedy match
Message-ID: <200011290415.UAA12562@sf-web3.vaspecialprojects.com>

Bug #123769, was updated on 2000-Nov-28 20:15
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: sre bug for non-greedy match

Details: import pre, sre

print pre.match(r'.*?\S *:', 'xx:').group()  # ok
print sre.match(r'.*?\S *:', 'xx:').group()  # error



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


From noreply@sourceforge.net  Wed Nov 29 05:54:11 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 28 Nov 2000 21:54:11 -0800
Subject: [Python-bugs-list] [Bug #123730] Extra backslash in web page
Message-ID: <200011290554.VAA25264@sf-web2.i.sourceforge.net>

Bug #123730, was updated on 2000-Nov-28 10:53
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Extra backslash in web page

Details: On page http://www.python.org/doc/current/tut/node5.html
this -------> u'Hello\\u0020World !'
should be --> u'Hello\u0020World !'


Follow-Ups:

Date: 2000-Nov-28 21:54
By: tim_one

Comment:
Fixed the specific complaint in tut.tex rev 1.122.

Fred, the later instances of

\code{\\u0020}

and

\code{\\uXXXX}

obviously don't display as intended either, but don't know how to fix those.

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

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


From noreply@sourceforge.net  Wed Nov 29 05:54:11 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 28 Nov 2000 21:54:11 -0800
Subject: [Python-bugs-list] [Bug #123730] Extra backslash in web page
Message-ID: <200011290554.VAA25267@sf-web2.i.sourceforge.net>

Bug #123730, was updated on 2000-Nov-28 10:53
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Extra backslash in web page

Details: On page http://www.python.org/doc/current/tut/node5.html
this -------> u'Hello\\u0020World !'
should be --> u'Hello\u0020World !'


Follow-Ups:

Date: 2000-Nov-28 21:54
By: tim_one

Comment:
Fixed the specific complaint in tut.tex rev 1.122.

Fred, the later instances of

\code{\\u0020}

and

\code{\\uXXXX}

obviously don't display as intended either, but don't know how to fix those.

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

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


From noreply@sourceforge.net  Wed Nov 29 06:11:17 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 28 Nov 2000 22:11:17 -0800
Subject: [Python-bugs-list] [Bug #123730] Extra backslash in web page
Message-ID: <200011290611.WAA13913@sf-web3.vaspecialprojects.com>

Bug #123730, was updated on 2000-Nov-28 10:53
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: Extra backslash in web page

Details: On page http://www.python.org/doc/current/tut/node5.html
this -------> u'Hello\\u0020World !'
should be --> u'Hello\u0020World !'


Follow-Ups:

Date: 2000-Nov-28 21:54
By: tim_one

Comment:
Fixed the specific complaint in tut.tex rev 1.122.

Fred, the later instances of

\code{\\u0020}

and

\code{\\uXXXX}

obviously don't display as intended either, but don't know how to fix those.

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

Date: 2000-Nov-28 22:11
By: fdrake

Comment:
Two remaining broken backslashes in Unicode string section fixed in Doc/tut/tut.tex revision 1.123.

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

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


From noreply@sourceforge.net  Wed Nov 29 06:11:17 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 28 Nov 2000 22:11:17 -0800
Subject: [Python-bugs-list] [Bug #123730] Extra backslash in web page
Message-ID: <200011290611.WAA13910@sf-web3.vaspecialprojects.com>

Bug #123730, was updated on 2000-Nov-28 10:53
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Extra backslash in web page

Details: On page http://www.python.org/doc/current/tut/node5.html
this -------> u'Hello\\u0020World !'
should be --> u'Hello\u0020World !'


Follow-Ups:

Date: 2000-Nov-28 21:54
By: tim_one

Comment:
Fixed the specific complaint in tut.tex rev 1.122.

Fred, the later instances of

\code{\\u0020}

and

\code{\\uXXXX}

obviously don't display as intended either, but don't know how to fix those.

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

Date: 2000-Nov-28 22:11
By: fdrake

Comment:
Two remaining broken backslashes in Unicode string section fixed in Doc/tut/tut.tex revision 1.123.

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

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


From noreply@sourceforge.net  Wed Nov 29 12:09:21 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 29 Nov 2000 04:09:21 -0800
Subject: [Python-bugs-list] [Bug #123769] sre bug for non-greedy match
Message-ID: <200011291209.EAA18519@sf-web3.vaspecialprojects.com>

Bug #123769, was updated on 2000-Nov-28 20:15
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: sre bug for non-greedy match

Details: import pre, sre

print pre.match(r'.*?\S *:', 'xx:').group()  # ok
print sre.match(r'.*?\S *:', 'xx:').group()  # error



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


From noreply@sourceforge.net  Wed Nov 29 15:33:50 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 29 Nov 2000 07:33:50 -0800
Subject: [Python-bugs-list] [Bug #119221] Include/graminit.h and Parser/graminit.c erroneously in dist
Message-ID: <200011291533.HAA01890@sf-web2.i.sourceforge.net>

Bug #119221, was updated on 2000-Oct-25 22:03
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Include/graminit.h and Parser/graminit.c erroneously in dist

Details: I install for multiple architectures by first unpacking the tar file into a read-only directory, then symlinking the files into a shadow tree, via X11 'lndir'.  Worked fine on Python 1.*.  With 2.0, however, the files Include/graminit.h and Parser/graminit.c are supplied in the tar file, and also generated by the build process.  Of course, they cannot be copied into their respective directories, because the files they are overwriting are in a read-only volume.

Follow-Ups:

Date: 2000-Oct-28 11:58
By: effbot

Comment:
Note that these files are not generated on all platforms; if you remove them, you'll break all non-Unix builds.
-------------------------------------------------------

Date: 2000-Nov-29 07:33
By: fdrake

Comment:
I think this is a "don't do that" problem -- although that isn't the very satisfying.  The files need to be supplied in the source distribution since the non-Unix build processes cannot rebuild them, and removing the rules to build them would impose a substantial burden on the developers working on the grammar.

I'm closing this as a bug report and adding an entry to the Feature Request PEP.
-------------------------------------------------------

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


From noreply@sourceforge.net  Wed Nov 29 15:33:50 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 29 Nov 2000 07:33:50 -0800
Subject: [Python-bugs-list] [Bug #119221] Include/graminit.h and Parser/graminit.c erroneously in dist
Message-ID: <200011291533.HAA01893@sf-web2.i.sourceforge.net>

Bug #119221, was updated on 2000-Oct-25 22:03
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: Include/graminit.h and Parser/graminit.c erroneously in dist

Details: I install for multiple architectures by first unpacking the tar file into a read-only directory, then symlinking the files into a shadow tree, via X11 'lndir'.  Worked fine on Python 1.*.  With 2.0, however, the files Include/graminit.h and Parser/graminit.c are supplied in the tar file, and also generated by the build process.  Of course, they cannot be copied into their respective directories, because the files they are overwriting are in a read-only volume.

Follow-Ups:

Date: 2000-Oct-28 11:58
By: effbot

Comment:
Note that these files are not generated on all platforms; if you remove them, you'll break all non-Unix builds.
-------------------------------------------------------

Date: 2000-Nov-29 07:33
By: fdrake

Comment:
I think this is a "don't do that" problem -- although that isn't the very satisfying.  The files need to be supplied in the source distribution since the non-Unix build processes cannot rebuild them, and removing the rules to build them would impose a substantial burden on the developers working on the grammar.

I'm closing this as a bug report and adding an entry to the Feature Request PEP.
-------------------------------------------------------

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


From noreply@sourceforge.net  Wed Nov 29 15:56:02 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 29 Nov 2000 07:56:02 -0800
Subject: [Python-bugs-list] [Bug #123398] "Python/C API Reference Manual" erroneous Python/C exception
Message-ID: <200011291556.HAA22080@sf-web3.vaspecialprojects.com>

Bug #123398, was updated on 2000-Nov-24 20:29
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: "Python/C API Reference Manual" erroneous Python/C exception

Details: The documentation page "Python20/Doc/api/exceptions.html" gives an example of how to handle Python exceptions in C.
It provides a Python function and what it claims is the equivalent C function.
However, they are not equivalent, in that the Python function returns a modified item from a list/dict, whereas the C function actually modifies the list/dict and returns only its success/failure.
I believe the two can be made equivalent by replacing the last line of the Python function:
  return item + 1
with:
  dict[key] = item + 1


Follow-Ups:

Date: 2000-Nov-29 07:56
By: fdrake

Comment:
Fixed in Doc/api/api.tex revision 1.99.
-------------------------------------------------------

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


From noreply@sourceforge.net  Wed Nov 29 15:56:02 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 29 Nov 2000 07:56:02 -0800
Subject: [Python-bugs-list] [Bug #123398] "Python/C API Reference Manual" erroneous Python/C exception
Message-ID: <200011291556.HAA22083@sf-web3.vaspecialprojects.com>

Bug #123398, was updated on 2000-Nov-24 20:29
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: "Python/C API Reference Manual" erroneous Python/C exception

Details: The documentation page "Python20/Doc/api/exceptions.html" gives an example of how to handle Python exceptions in C.
It provides a Python function and what it claims is the equivalent C function.
However, they are not equivalent, in that the Python function returns a modified item from a list/dict, whereas the C function actually modifies the list/dict and returns only its success/failure.
I believe the two can be made equivalent by replacing the last line of the Python function:
  return item + 1
with:
  dict[key] = item + 1


Follow-Ups:

Date: 2000-Nov-29 07:56
By: fdrake

Comment:
Fixed in Doc/api/api.tex revision 1.99.
-------------------------------------------------------

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


From noreply@sourceforge.net  Wed Nov 29 16:02:00 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 29 Nov 2000 08:02:00 -0800
Subject: [Python-bugs-list] [Bug #123409] Global Module Index up link does not work
Message-ID: <200011291602.IAA22212@sf-web3.vaspecialprojects.com>

Bug #123409, was updated on 2000-Nov-24 23:58
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 3
Summary: Global Module Index up link does not work

Details: The Up button on the global module index page fails because the index page is on the same level as the general documentation index.

Follow-Ups:

Date: 2000-Nov-29 08:02
By: fdrake

Comment:
Already fixed in the development sources.
-------------------------------------------------------

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


From noreply@sourceforge.net  Wed Nov 29 16:02:00 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 29 Nov 2000 08:02:00 -0800
Subject: [Python-bugs-list] [Bug #123409] Global Module Index up link does not work
Message-ID: <200011291602.IAA22209@sf-web3.vaspecialprojects.com>

Bug #123409, was updated on 2000-Nov-24 23:58
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 3
Summary: Global Module Index up link does not work

Details: The Up button on the global module index page fails because the index page is on the same level as the general documentation index.

Follow-Ups:

Date: 2000-Nov-29 08:02
By: fdrake

Comment:
Already fixed in the development sources.
-------------------------------------------------------

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


From noreply@sourceforge.net  Wed Nov 29 17:14:30 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 29 Nov 2000 09:14:30 -0800
Subject: [Python-bugs-list] [Bug #123816] Can not install Python2.0
Message-ID: <200011291714.JAA23455@sf-web3.vaspecialprojects.com>

Bug #123816, was updated on 2000-Nov-29 09:14
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Can not install Python2.0

Details: I try to upgrade Python 1.5.2 on LinuxMandrake7.0 to Python2.0

 rpm -Uvh BeOpen-Python-2.0-1....rpm

and got error 

libreadline.so.3 is needed by BeOpen-Python......

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


From noreply@sourceforge.net  Wed Nov 29 22:38:42 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 29 Nov 2000 14:38:42 -0800
Subject: [Python-bugs-list] [Bug #123859] %[duxXo] long formats inconsistent
Message-ID: <200011292238.OAA09977@sf-web2.i.sourceforge.net>

Bug #123859, was updated on 2000-Nov-29 14:38
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: %[duxXo] long formats inconsistent

Details: Guido, if you want me to do what I suggested, assign it back to me.

[Finn Bock]
> While adding support to Jython for formatting of
> longs in "%[duxXo]", I inadvertently introduced another
> difference between Python and Jython:
>
> Python 2.0 (#8, Oct 16 2000, 17:27:58) [MSC 32 bit (Intel)] on win32
> Type "copyright", "credits" or "license" for more information.
> >>> print '%030o' % -10L
> 000000000000000000037777777766
> >>>
>
> Jython 2.0alpha1 on java1.3.0 (JIT: null)
> Type "copyright", "credits" or "license" for more information.
> >>> print '%030o' % -10L
> -00000000000000000000000000012
> >>>
>
> The CPython behaviour looks as if the number have been through a C long
> before it is formatted. It that intended?

[Tim]
Hard to say, but it is what the code does <wink>.  In 1.5.2, "true longs" raised an error in this context, so the code first looked to see whether the putative Python long actually fit in a C long first; if so, it did not raise
an error, and ran the value thru C long formatting instead (in stringobject.c):

				if (PyLong_Check(v) && PyLong_AsLong(v) == -1
				    && PyErr_Occurred()) {
					/* Too big for a C long. */

That test survived in 2.0; the difference is that it no longer raises an error if the value doesn't fit in a C long.

> Would jython be wrong if it used the result above?

Hard to say!  Since the size of a Python int varies across platforms, not even CPython will display the same thing for all Python longs across all platforms.  I'm in favor of changing the test above to

				if (PyLong_Check(v)) {

Then CPython will match JPython here, and CPython will produce the same result across all platforms when given a Python long.  The downside is that it will not produce the same result as 2.0 (or earlier).

Guido, you can Pronounce now <wink>.


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


From noreply@sourceforge.net  Thu Nov 30 05:26:38 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 29 Nov 2000 21:26:38 -0800
Subject: [Python-bugs-list] [Bug #123859] %[duxXo] long formats inconsistent
Message-ID: <200011300526.VAA11128@sf-web1.i.sourceforge.net>

Bug #123859, was updated on 2000-Nov-29 14:38
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: %[duxXo] long formats inconsistent

Details: Guido, if you want me to do what I suggested, assign it back to me.

[Finn Bock]
> While adding support to Jython for formatting of
> longs in "%[duxXo]", I inadvertently introduced another
> difference between Python and Jython:
>
> Python 2.0 (#8, Oct 16 2000, 17:27:58) [MSC 32 bit (Intel)] on win32
> Type "copyright", "credits" or "license" for more information.
> >>> print '%030o' % -10L
> 000000000000000000037777777766
> >>>
>
> Jython 2.0alpha1 on java1.3.0 (JIT: null)
> Type "copyright", "credits" or "license" for more information.
> >>> print '%030o' % -10L
> -00000000000000000000000000012
> >>>
>
> The CPython behaviour looks as if the number have been through a C long
> before it is formatted. It that intended?

[Tim]
Hard to say, but it is what the code does <wink>.  In 1.5.2, "true longs" raised an error in this context, so the code first looked to see whether the putative Python long actually fit in a C long first; if so, it did not raise
an error, and ran the value thru C long formatting instead (in stringobject.c):

				if (PyLong_Check(v) && PyLong_AsLong(v) == -1
				    && PyErr_Occurred()) {
					/* Too big for a C long. */

That test survived in 2.0; the difference is that it no longer raises an error if the value doesn't fit in a C long.

> Would jython be wrong if it used the result above?

Hard to say!  Since the size of a Python int varies across platforms, not even CPython will display the same thing for all Python longs across all platforms.  I'm in favor of changing the test above to

				if (PyLong_Check(v)) {

Then CPython will match JPython here, and CPython will produce the same result across all platforms when given a Python long.  The downside is that it will not produce the same result as 2.0 (or earlier).

Guido, you can Pronounce now <wink>.


Follow-Ups:

Date: 2000-Nov-29 21:26
By: tim_one

Comment:
Closed.  test_format.py revision 1.3; NEWS 1.82; stringobject.c 2.94; unicodeobject.c 2.67.

Guido added, on Python-Dev:

I just skimmed the pipermail python-dev archives and found one item to pronounce on: what "%o" should do with negative longs.  I agree with Tim.  Also for "%x".  Reason: this matches oct() and hex().

>>> oct(-10L)
'-012L'
>>> oct(-10)
'037777777766'
>>> hex(-10L)
'-0xAL'
>>> hex(-10)
'0xfffffff6'
>>> 

Compatibility be damned (in this case).

(One could argue that for plain ints, the same result are desirable; however when these are used as bitmasks, I as human reader prefer to see '0xfffffff6' rather than '-0xA'.  Ah the insanity of consistency!)

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

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


From noreply@sourceforge.net  Thu Nov 30 05:26:38 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 29 Nov 2000 21:26:38 -0800
Subject: [Python-bugs-list] [Bug #123859] %[duxXo] long formats inconsistent
Message-ID: <200011300526.VAA11125@sf-web1.i.sourceforge.net>

Bug #123859, was updated on 2000-Nov-29 14:38
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: %[duxXo] long formats inconsistent

Details: Guido, if you want me to do what I suggested, assign it back to me.

[Finn Bock]
> While adding support to Jython for formatting of
> longs in "%[duxXo]", I inadvertently introduced another
> difference between Python and Jython:
>
> Python 2.0 (#8, Oct 16 2000, 17:27:58) [MSC 32 bit (Intel)] on win32
> Type "copyright", "credits" or "license" for more information.
> >>> print '%030o' % -10L
> 000000000000000000037777777766
> >>>
>
> Jython 2.0alpha1 on java1.3.0 (JIT: null)
> Type "copyright", "credits" or "license" for more information.
> >>> print '%030o' % -10L
> -00000000000000000000000000012
> >>>
>
> The CPython behaviour looks as if the number have been through a C long
> before it is formatted. It that intended?

[Tim]
Hard to say, but it is what the code does <wink>.  In 1.5.2, "true longs" raised an error in this context, so the code first looked to see whether the putative Python long actually fit in a C long first; if so, it did not raise
an error, and ran the value thru C long formatting instead (in stringobject.c):

				if (PyLong_Check(v) && PyLong_AsLong(v) == -1
				    && PyErr_Occurred()) {
					/* Too big for a C long. */

That test survived in 2.0; the difference is that it no longer raises an error if the value doesn't fit in a C long.

> Would jython be wrong if it used the result above?

Hard to say!  Since the size of a Python int varies across platforms, not even CPython will display the same thing for all Python longs across all platforms.  I'm in favor of changing the test above to

				if (PyLong_Check(v)) {

Then CPython will match JPython here, and CPython will produce the same result across all platforms when given a Python long.  The downside is that it will not produce the same result as 2.0 (or earlier).

Guido, you can Pronounce now <wink>.


Follow-Ups:

Date: 2000-Nov-29 21:26
By: tim_one

Comment:
Closed.  test_format.py revision 1.3; NEWS 1.82; stringobject.c 2.94; unicodeobject.c 2.67.

Guido added, on Python-Dev:

I just skimmed the pipermail python-dev archives and found one item to pronounce on: what "%o" should do with negative longs.  I agree with Tim.  Also for "%x".  Reason: this matches oct() and hex().

>>> oct(-10L)
'-012L'
>>> oct(-10)
'037777777766'
>>> hex(-10L)
'-0xAL'
>>> hex(-10)
'0xfffffff6'
>>> 

Compatibility be damned (in this case).

(One could argue that for plain ints, the same result are desirable; however when these are used as bitmasks, I as human reader prefer to see '0xfffffff6' rather than '-0xA'.  Ah the insanity of consistency!)

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

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


From noreply@sourceforge.net  Thu Nov 30 14:11:12 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 30 Nov 2000 06:11:12 -0800
Subject: [Python-bugs-list] [Bug #123924] Windows - using OpenSSL, problem with socket in httplib.py
Message-ID: <200011301411.GAA10155@sf-web3.vaspecialprojects.com>

Bug #123924, was updated on 2000-Nov-30 06:11
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Windows - using OpenSSL, problem with socket in httplib.py

Details: We found that when compiling python with USE_SSL on Windows, an exception occurred on the line:
        ssl = socket.ssl(sock, self.key_file, self.cert_file)

The socket.ssl function expected arg 1 to be a socket object and not an instance of a class.  We changed it to the following, which resolved the problem.  However, this is not a generic solution and breaks again under Linux.

on class HTTPSConnection:
    def connect(self):
        "Connect to a host on a given (SSL) port."
 
        sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        sock.connect((self.host, self.port))
        ssl = socket.ssl(sock._sock, self.key_file, self.cert_file)
        self.sock = FakeSocket(sock, ssl)
                                                                                                                                                                             

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


From noreply@sourceforge.net  Thu Nov 30 14:15:33 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 30 Nov 2000 06:15:33 -0800
Subject: [Python-bugs-list] [Bug #123924] Windows - using OpenSSL, problem with socket in httplib.py
Message-ID: <200011301415.GAA19283@sf-web1.i.sourceforge.net>

Bug #123924, was updated on 2000-Nov-30 06:11
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Windows - using OpenSSL, problem with socket in httplib.py

Details: We found that when compiling python with USE_SSL on Windows, an exception occurred on the line:
        ssl = socket.ssl(sock, self.key_file, self.cert_file)

The socket.ssl function expected arg 1 to be a socket object and not an instance of a class.  We changed it to the following, which resolved the problem.  However, this is not a generic solution and breaks again under Linux.

on class HTTPSConnection:
    def connect(self):
        "Connect to a host on a given (SSL) port."
 
        sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        sock.connect((self.host, self.port))
        ssl = socket.ssl(sock._sock, self.key_file, self.cert_file)
        self.sock = FakeSocket(sock, ssl)
                                                                                                                                                                             

Follow-Ups:

Date: 2000-Nov-30 06:15
By: gvanrossum

Comment:
Try this patch instead:

Index: httplib.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/httplib.py,v
retrieving revision 1.24
diff -c -r1.24 httplib.py
*** httplib.py	2000/10/12 19:58:36	1.24
--- httplib.py	2000/11/30 14:14:43
***************
*** 613,619 ****
  
          sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
          sock.connect((self.host, self.port))
!         ssl = socket.ssl(sock, self.key_file, self.cert_file)
          self.sock = FakeSocket(sock, ssl)
  
  
--- 613,622 ----
  
          sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
          sock.connect((self.host, self.port))
!         realsock = sock
!         if hasattr(sock, "_sock"):
!             realsock = sock._sock
!         ssl = socket.ssl(realsock, self.key_file, self.cert_file)
          self.sock = FakeSocket(sock, ssl)
  

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

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


From noreply@sourceforge.net  Thu Nov 30 14:15:32 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 30 Nov 2000 06:15:32 -0800
Subject: [Python-bugs-list] [Bug #123924] Windows - using OpenSSL, problem with socket in httplib.py
Message-ID: <200011301415.GAA19280@sf-web1.i.sourceforge.net>

Bug #123924, was updated on 2000-Nov-30 06:11
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Windows - using OpenSSL, problem with socket in httplib.py

Details: We found that when compiling python with USE_SSL on Windows, an exception occurred on the line:
        ssl = socket.ssl(sock, self.key_file, self.cert_file)

The socket.ssl function expected arg 1 to be a socket object and not an instance of a class.  We changed it to the following, which resolved the problem.  However, this is not a generic solution and breaks again under Linux.

on class HTTPSConnection:
    def connect(self):
        "Connect to a host on a given (SSL) port."
 
        sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        sock.connect((self.host, self.port))
        ssl = socket.ssl(sock._sock, self.key_file, self.cert_file)
        self.sock = FakeSocket(sock, ssl)
                                                                                                                                                                             

Follow-Ups:

Date: 2000-Nov-30 06:15
By: gvanrossum

Comment:
Try this patch instead:

Index: httplib.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/httplib.py,v
retrieving revision 1.24
diff -c -r1.24 httplib.py
*** httplib.py	2000/10/12 19:58:36	1.24
--- httplib.py	2000/11/30 14:14:43
***************
*** 613,619 ****
  
          sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
          sock.connect((self.host, self.port))
!         ssl = socket.ssl(sock, self.key_file, self.cert_file)
          self.sock = FakeSocket(sock, ssl)
  
  
--- 613,622 ----
  
          sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
          sock.connect((self.host, self.port))
!         realsock = sock
!         if hasattr(sock, "_sock"):
!             realsock = sock._sock
!         ssl = socket.ssl(realsock, self.key_file, self.cert_file)
          self.sock = FakeSocket(sock, ssl)
  

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

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


From noreply@sourceforge.net  Thu Nov 30 14:16:16 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 30 Nov 2000 06:16:16 -0800
Subject: [Python-bugs-list] [Bug #123816] Can not install Python2.0
Message-ID: <200011301416.GAA24668@sf-web2.i.sourceforge.net>

Bug #123816, was updated on 2000-Nov-29 09:14
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Can not install Python2.0

Details: I try to upgrade Python 1.5.2 on LinuxMandrake7.0 to Python2.0

 rpm -Uvh BeOpen-Python-2.0-1....rpm

and got error 

libreadline.so.3 is needed by BeOpen-Python......

Follow-Ups:

Date: 2000-Nov-30 06:16
By: gvanrossum

Comment:
Try building from source instead.
-------------------------------------------------------

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


From noreply@sourceforge.net  Thu Nov 30 14:16:16 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 30 Nov 2000 06:16:16 -0800
Subject: [Python-bugs-list] [Bug #123816] Can not install Python2.0
Message-ID: <200011301416.GAA24671@sf-web2.i.sourceforge.net>

Bug #123816, was updated on 2000-Nov-29 09:14
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Closed
Resolution: Wont Fix
Bug Group: Platform-specific
Priority: 5
Summary: Can not install Python2.0

Details: I try to upgrade Python 1.5.2 on LinuxMandrake7.0 to Python2.0

 rpm -Uvh BeOpen-Python-2.0-1....rpm

and got error 

libreadline.so.3 is needed by BeOpen-Python......

Follow-Ups:

Date: 2000-Nov-30 06:16
By: gvanrossum

Comment:
Try building from source instead.
-------------------------------------------------------

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


From noreply@sourceforge.net  Fri Nov  3 20:09:52 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 3 Nov 2000 12:09:52 -0800
Subject: [Python-bugs-list] [Bug #119709] A make error
Message-ID: <200011032009.MAA28109@sf-web3.vaspecialprojects.com>

Bug #119709, was updated on 2000-Oct-29 16:20
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: A make error

Details: I use:

Slackware96
Linux 2.0.0
gcc 2.7.2
glibc2
PC/i486

And I try to install Python-2.0.tar.gz package.
I use default Modules/Setup.

When run:

#./configure
#make

gcc tells me in Modules/selectmodule.c, begins from the 345 line,

POLLIN undeclared,...

Every POLL* name follows are all undeclared.

Which header file lost? poll.h? Or something wrong?

Thanks.


Follow-Ups:

Date: 2000-Nov-02 20:16
By: fdrake

Comment:
I think this has been fixed post-2.0, but I'm not sure.  Assigned to Andrew since he'll know and, if it's not fixed, will be the one to do so.   ;-)
-------------------------------------------------------

Date: 2000-Nov-03 12:09
By: akuchling

Comment:
Can you provide the exact output from make, please, 
and a copy of the config.h generated by Python's configure script?  It's possible that both HAVE_POLL_H and HAVE_POLL
are defined but the header files are wrong in some way that POLLIN isn't defined.

You can provide the output and config.h via private e-mail 
to akuchlin@mems-exchange.org.

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

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


From noreply@sourceforge.net  Fri Nov  3 20:49:13 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 3 Nov 2000 12:49:13 -0800
Subject: [Python-bugs-list] [Bug #119960] Encoding bugs.
Message-ID: <200011032049.MAA28722@sf-web3.vaspecialprojects.com>

Bug #119960, was updated on 2000-Oct-31 13:38
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Open
Resolution: None
Bug Group: None
Priority: 3
Summary: Encoding bugs.

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

Follow-Ups:

Date: 2000-Nov-01 08:00
By: jhylton

Comment:
I am not entirely sure what the bug is, though I agree that it can be confusing to deal with Unicode strings.

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

Date: 2000-Nov-01 12:47
By: lemburg

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

Date: 2000-Nov-01 13:16
By: kirill_simonov

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

Date: 2000-Nov-03 12:49
By: gvanrossum

Comment:
Assigned to Marc-Andre, since I have no idea what to do about this... :-(
-------------------------------------------------------

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