From noreply@sourceforge.net  Tue Apr  1 07:35:41 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 31 Mar 2003 23:35:41 -0800
Subject: [Python-bugs-list] [ python-Bugs-713169 ] Python 2.3 pty test fails on HP-UX11i
Message-ID: <E190GJ3-0000hS-00@sc8-sf-web3.sourceforge.net>

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

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Townsend (rptownsend)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.3 pty test fails on HP-UX11i

Initial Comment:
Here is the output from test_pty.py:

capulet:dist/src > ./python Lib/test/test_pty.py
Calling master_open()
Got master_fd '3', slave_name '/dev/pts/0'
Calling slave_open('/dev/pts/0')
Got slave_fd '4'
Traceback (most recent call last):
  File "Lib/test/test_pty.py", line 58, in ?
    test_basic_pty()
  File "Lib/test/test_pty.py", line 29, in 
test_basic_pty
    if not os.isatty(slave_fd):
  File "Lib/test/test_pty.py", line 50, in handle_sig
    raise TestFailed, "isatty hung"
test.test_support.TestFailed: isatty hung


This was running Python 2.3a2 (downloaded from 
CVS on Sunday 30th March) built on HP-UX11i.

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

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


From noreply@sourceforge.net  Tue Apr  1 07:38:42 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 31 Mar 2003 23:38:42 -0800
Subject: [Python-bugs-list] [ python-Bugs-713172 ] Python 2.3 tempfile test fails on HP-UX11i
Message-ID: <E190GLy-0000nN-00@sc8-sf-web3.sourceforge.net>

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

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Townsend (rptownsend)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.3 tempfile test fails on HP-UX11i

Initial Comment:
Here is the output from test_tempfile.py

capulet:dist/src > ./python 
Lib/test/test_tempfile.py
test_exports (__main__.test_exports) ... ok
test_get_six_char_str 
(__main__.test__RandomNameSequence) ... ok
test_many 
(__main__.test__RandomNameSequence) ... ok
test_supports_iter 
(__main__.test__RandomNameSequence) ... ok
test_nonempty_list 
(__main__.test__candidate_tempdir_list) ... ok
test_wanted_dirs 
(__main__.test__candidate_tempdir_list) ... ok
test_retval 
(__main__.test__get_candidate_names) ... ok
test_same_thing 
(__main__.test__get_candidate_names) ... ok
test_basic (__main__.test__mkstemp_inner) ... ok
test_basic_many 
(__main__.test__mkstemp_inner) ... FAIL
Exception exceptions.AttributeError: "mkstemped 
instance has no attribute 'fd'" in <bound method 
mkstemped.__del__ of <__main__.mkstemped 
instance at 0x4012de40>> ignored
test_choose_directory 
(__main__.test__mkstemp_inner) ... ok
test_file_mode (__main__.test__mkstemp_inner) ... 
ok
test_noinherit (__main__.test__mkstemp_inner) ... 
ok
test_textmode (__main__.test__mkstemp_inner) ... 
ok
test_sane_template 
(__main__.test_gettempprefix) ... ok
test_usable_template 
(__main__.test_gettempprefix) ... ok
test_directory_exists (__main__.test_gettempdir) ... 
ok
test_directory_writable 
(__main__.test_gettempdir) ... ok
test_same_thing (__main__.test_gettempdir) ... ok
test_basic (__main__.test_mkstemp) ... ok
test_choose_directory (__main__.test_mkstemp) ... 
ok
test_basic (__main__.test_mkdtemp) ... ok
test_basic_many (__main__.test_mkdtemp) ... ok
test_choose_directory (__main__.test_mkdtemp) ... 
ok
test_mode (__main__.test_mkdtemp) ... ok
test_basic (__main__.test_mktemp) ... ok
test_many (__main__.test_mktemp) ... ok
test_basic (__main__.test_NamedTemporaryFile) ... 
ok
test_creates_named 
(__main__.test_NamedTemporaryFile) ... ok
test_del_on_close 
(__main__.test_NamedTemporaryFile) ... ok
test_multiple_close 
(__main__.test_NamedTemporaryFile) ... ok
test_basic (__main__.test_TemporaryFile) ... ok
test_has_no_name 
(__main__.test_TemporaryFile) ... ok
test_multiple_close 
(__main__.test_TemporaryFile) ... ok

=================================
=================================
====
FAIL: test_basic_many 
(__main__.test__mkstemp_inner)
-----------------------------------------
-----------------------------
Traceback (most recent call last):
  File "Lib/test/test_tempfile.py", line 246, in 
test_basic_many
  File "Lib/test/test_tempfile.py", line 229, in 
do_create
  File "Lib/test/test_tempfile.py", line 45, in 
failOnException
  
File "/home/richardt/python.new/python/dist/src/
Lib/unittest.py", line 260, in fail
AssertionError: _mkstemp_inner raised 
exceptions.OSError: [Errno 24] Too many open 
files: '/tmp/aafmevUO'

-----------------------------------------
-----------------------------
Ran 34 tests in 0.604s

FAILED (failures=1)
Traceback (most recent call last):
  File "Lib/test/test_tempfile.py", line 654, in ?
    test_main()
  File "Lib/test/test_tempfile.py", line 651, in 
test_main
    test_support.run_suite(suite)
  
File "/home/richardt/python.new/python/dist/src/
Lib/test/test_support.py", line 225, in run_suite
    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most 
recent call last):
  File "Lib/test/test_tempfile.py", line 246, in 
test_basic_many
  File "Lib/test/test_tempfile.py", line 229, in 
do_create
  File "Lib/test/test_tempfile.py", line 45, in 
failOnException
  
File "/home/richardt/python.new/python/dist/src/
Lib/unittest.py", line 260, in fail
AssertionError: _mkstemp_inner raised 
exceptions.OSError: [Errno 24] Too many open 
files: '/tmp/aafmevUO'


This was running Python 2.3a2 (downloaded from 
CVS on Sunday 30th March) built on HP-UX11i.

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

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


From noreply@sourceforge.net  Tue Apr  1 10:28:27 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 01 Apr 2003 02:28:27 -0800
Subject: [Python-bugs-list] [ python-Bugs-713172 ] Python 2.3 tempfile test fails on HP-UX11i
Message-ID: <E190J0F-00024T-00@sc8-sf-web2.sourceforge.net>

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

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Townsend (rptownsend)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.3 tempfile test fails on HP-UX11i

Initial Comment:
Here is the output from test_tempfile.py

capulet:dist/src > ./python 
Lib/test/test_tempfile.py
test_exports (__main__.test_exports) ... ok
test_get_six_char_str 
(__main__.test__RandomNameSequence) ... ok
test_many 
(__main__.test__RandomNameSequence) ... ok
test_supports_iter 
(__main__.test__RandomNameSequence) ... ok
test_nonempty_list 
(__main__.test__candidate_tempdir_list) ... ok
test_wanted_dirs 
(__main__.test__candidate_tempdir_list) ... ok
test_retval 
(__main__.test__get_candidate_names) ... ok
test_same_thing 
(__main__.test__get_candidate_names) ... ok
test_basic (__main__.test__mkstemp_inner) ... ok
test_basic_many 
(__main__.test__mkstemp_inner) ... FAIL
Exception exceptions.AttributeError: "mkstemped 
instance has no attribute 'fd'" in <bound method 
mkstemped.__del__ of <__main__.mkstemped 
instance at 0x4012de40>> ignored
test_choose_directory 
(__main__.test__mkstemp_inner) ... ok
test_file_mode (__main__.test__mkstemp_inner) ... 
ok
test_noinherit (__main__.test__mkstemp_inner) ... 
ok
test_textmode (__main__.test__mkstemp_inner) ... 
ok
test_sane_template 
(__main__.test_gettempprefix) ... ok
test_usable_template 
(__main__.test_gettempprefix) ... ok
test_directory_exists (__main__.test_gettempdir) ... 
ok
test_directory_writable 
(__main__.test_gettempdir) ... ok
test_same_thing (__main__.test_gettempdir) ... ok
test_basic (__main__.test_mkstemp) ... ok
test_choose_directory (__main__.test_mkstemp) ... 
ok
test_basic (__main__.test_mkdtemp) ... ok
test_basic_many (__main__.test_mkdtemp) ... ok
test_choose_directory (__main__.test_mkdtemp) ... 
ok
test_mode (__main__.test_mkdtemp) ... ok
test_basic (__main__.test_mktemp) ... ok
test_many (__main__.test_mktemp) ... ok
test_basic (__main__.test_NamedTemporaryFile) ... 
ok
test_creates_named 
(__main__.test_NamedTemporaryFile) ... ok
test_del_on_close 
(__main__.test_NamedTemporaryFile) ... ok
test_multiple_close 
(__main__.test_NamedTemporaryFile) ... ok
test_basic (__main__.test_TemporaryFile) ... ok
test_has_no_name 
(__main__.test_TemporaryFile) ... ok
test_multiple_close 
(__main__.test_TemporaryFile) ... ok

=================================
=================================
====
FAIL: test_basic_many 
(__main__.test__mkstemp_inner)
-----------------------------------------
-----------------------------
Traceback (most recent call last):
  File "Lib/test/test_tempfile.py", line 246, in 
test_basic_many
  File "Lib/test/test_tempfile.py", line 229, in 
do_create
  File "Lib/test/test_tempfile.py", line 45, in 
failOnException
  
File "/home/richardt/python.new/python/dist/src/
Lib/unittest.py", line 260, in fail
AssertionError: _mkstemp_inner raised 
exceptions.OSError: [Errno 24] Too many open 
files: '/tmp/aafmevUO'

-----------------------------------------
-----------------------------
Ran 34 tests in 0.604s

FAILED (failures=1)
Traceback (most recent call last):
  File "Lib/test/test_tempfile.py", line 654, in ?
    test_main()
  File "Lib/test/test_tempfile.py", line 651, in 
test_main
    test_support.run_suite(suite)
  
File "/home/richardt/python.new/python/dist/src/
Lib/test/test_support.py", line 225, in run_suite
    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most 
recent call last):
  File "Lib/test/test_tempfile.py", line 246, in 
test_basic_many
  File "Lib/test/test_tempfile.py", line 229, in 
do_create
  File "Lib/test/test_tempfile.py", line 45, in 
failOnException
  
File "/home/richardt/python.new/python/dist/src/
Lib/unittest.py", line 260, in fail
AssertionError: _mkstemp_inner raised 
exceptions.OSError: [Errno 24] Too many open 
files: '/tmp/aafmevUO'


This was running Python 2.3a2 (downloaded from 
CVS on Sunday 30th March) built on HP-UX11i.

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

>Comment By: Michael Hudson (mwh)
Date: 2003-04-01 11:28

Message:
Logged In: YES 
user_id=6656

On the surface this just looks like the test opens more
files than you're allowed to, IOW not like a deep problem.

Can you raise that limit and try again?

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

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


From noreply@sourceforge.net  Tue Apr  1 10:26:08 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 01 Apr 2003 02:26:08 -0800
Subject: [Python-bugs-list] [ python-Bugs-713169 ] Python 2.3 pty test fails on HP-UX11i
Message-ID: <E190Iy0-0001xr-00@sc8-sf-web2.sourceforge.net>

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

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Townsend (rptownsend)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: Python 2.3 pty test fails on HP-UX11i

Initial Comment:
Here is the output from test_pty.py:

capulet:dist/src > ./python Lib/test/test_pty.py
Calling master_open()
Got master_fd '3', slave_name '/dev/pts/0'
Calling slave_open('/dev/pts/0')
Got slave_fd '4'
Traceback (most recent call last):
  File "Lib/test/test_pty.py", line 58, in ?
    test_basic_pty()
  File "Lib/test/test_pty.py", line 29, in 
test_basic_pty
    if not os.isatty(slave_fd):
  File "Lib/test/test_pty.py", line 50, in handle_sig
    raise TestFailed, "isatty hung"
test.test_support.TestFailed: isatty hung


This was running Python 2.3a2 (downloaded from 
CVS on Sunday 30th March) built on HP-UX11i.

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

>Comment By: Michael Hudson (mwh)
Date: 2003-04-01 11:26

Message:
Logged In: YES 
user_id=6656

Neal?  I thought you thought this was fixed?

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

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


From noreply@sourceforge.net  Tue Apr  1 10:30:05 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 01 Apr 2003 02:30:05 -0800
Subject: [Python-bugs-list] [ python-Bugs-712975 ] Cannot change the class of a list
Message-ID: <E190J1p-00028f-00@sc8-sf-web2.sourceforge.net>

Bugs item #712975, was opened at 2003-03-31 23:00
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=712975&group_id=5470

Category: Type/class unification
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jiba (jiba)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: Cannot change the class of a list

Initial Comment:
The class of list (or dict) can no longer be changed in
Python 2.3a2 ; this was possible with Python 2.2.2 (as
long as the new class extend list and has no slot).
When doing so ([].__class__ = ...), i get this error :

TypeError: __class__ assignment: only for heap types


Not being able to change the class of non-mutable
object (e.g. int, float or tuple) is AMHO not a great
loss, but list and dict ARE mutable, and so changing
their class does have a sens !

Typically it can be used to observed a list that you
have not created yourself (see atteched script); i was
relying a lot on such observation features.

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

>Comment By: Michael Hudson (mwh)
Date: 2003-04-01 11:30

Message:
Logged In: YES 
user_id=6656

IMHO, changing the class of an immutable object is, was and
always will be Right Out.

Changing the class of a mutable is dicier.  I personally
don't think it's worth the effort, but assigning to Guido
for pronouncement.

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

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


From noreply@sourceforge.net  Tue Apr  1 12:27:26 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 01 Apr 2003 04:27:26 -0800
Subject: [Python-bugs-list] [ python-Bugs-713172 ] Python 2.3 tempfile test fails on HP-UX11i
Message-ID: <E190KrO-0006VF-00@sc8-sf-web2.sourceforge.net>

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

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Townsend (rptownsend)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.3 tempfile test fails on HP-UX11i

Initial Comment:
Here is the output from test_tempfile.py

capulet:dist/src > ./python 
Lib/test/test_tempfile.py
test_exports (__main__.test_exports) ... ok
test_get_six_char_str 
(__main__.test__RandomNameSequence) ... ok
test_many 
(__main__.test__RandomNameSequence) ... ok
test_supports_iter 
(__main__.test__RandomNameSequence) ... ok
test_nonempty_list 
(__main__.test__candidate_tempdir_list) ... ok
test_wanted_dirs 
(__main__.test__candidate_tempdir_list) ... ok
test_retval 
(__main__.test__get_candidate_names) ... ok
test_same_thing 
(__main__.test__get_candidate_names) ... ok
test_basic (__main__.test__mkstemp_inner) ... ok
test_basic_many 
(__main__.test__mkstemp_inner) ... FAIL
Exception exceptions.AttributeError: "mkstemped 
instance has no attribute 'fd'" in <bound method 
mkstemped.__del__ of <__main__.mkstemped 
instance at 0x4012de40>> ignored
test_choose_directory 
(__main__.test__mkstemp_inner) ... ok
test_file_mode (__main__.test__mkstemp_inner) ... 
ok
test_noinherit (__main__.test__mkstemp_inner) ... 
ok
test_textmode (__main__.test__mkstemp_inner) ... 
ok
test_sane_template 
(__main__.test_gettempprefix) ... ok
test_usable_template 
(__main__.test_gettempprefix) ... ok
test_directory_exists (__main__.test_gettempdir) ... 
ok
test_directory_writable 
(__main__.test_gettempdir) ... ok
test_same_thing (__main__.test_gettempdir) ... ok
test_basic (__main__.test_mkstemp) ... ok
test_choose_directory (__main__.test_mkstemp) ... 
ok
test_basic (__main__.test_mkdtemp) ... ok
test_basic_many (__main__.test_mkdtemp) ... ok
test_choose_directory (__main__.test_mkdtemp) ... 
ok
test_mode (__main__.test_mkdtemp) ... ok
test_basic (__main__.test_mktemp) ... ok
test_many (__main__.test_mktemp) ... ok
test_basic (__main__.test_NamedTemporaryFile) ... 
ok
test_creates_named 
(__main__.test_NamedTemporaryFile) ... ok
test_del_on_close 
(__main__.test_NamedTemporaryFile) ... ok
test_multiple_close 
(__main__.test_NamedTemporaryFile) ... ok
test_basic (__main__.test_TemporaryFile) ... ok
test_has_no_name 
(__main__.test_TemporaryFile) ... ok
test_multiple_close 
(__main__.test_TemporaryFile) ... ok

=================================
=================================
====
FAIL: test_basic_many 
(__main__.test__mkstemp_inner)
-----------------------------------------
-----------------------------
Traceback (most recent call last):
  File "Lib/test/test_tempfile.py", line 246, in 
test_basic_many
  File "Lib/test/test_tempfile.py", line 229, in 
do_create
  File "Lib/test/test_tempfile.py", line 45, in 
failOnException
  
File "/home/richardt/python.new/python/dist/src/
Lib/unittest.py", line 260, in fail
AssertionError: _mkstemp_inner raised 
exceptions.OSError: [Errno 24] Too many open 
files: '/tmp/aafmevUO'

-----------------------------------------
-----------------------------
Ran 34 tests in 0.604s

FAILED (failures=1)
Traceback (most recent call last):
  File "Lib/test/test_tempfile.py", line 654, in ?
    test_main()
  File "Lib/test/test_tempfile.py", line 651, in 
test_main
    test_support.run_suite(suite)
  
File "/home/richardt/python.new/python/dist/src/
Lib/test/test_support.py", line 225, in run_suite
    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most 
recent call last):
  File "Lib/test/test_tempfile.py", line 246, in 
test_basic_many
  File "Lib/test/test_tempfile.py", line 229, in 
do_create
  File "Lib/test/test_tempfile.py", line 45, in 
failOnException
  
File "/home/richardt/python.new/python/dist/src/
Lib/unittest.py", line 260, in fail
AssertionError: _mkstemp_inner raised 
exceptions.OSError: [Errno 24] Too many open 
files: '/tmp/aafmevUO'


This was running Python 2.3a2 (downloaded from 
CVS on Sunday 30th March) built on HP-UX11i.

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

>Comment By: Richard Townsend (rptownsend)
Date: 2003-04-01 13:27

Message:
Logged In: YES 
user_id=200117

You are correct. The kernel parameter 'maxfiles' was set 
to 60, but test_tempfile.py tries to open 100 files.

I increased maxfiles to 128 and the test now runs 
without errors.

Thank you.

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

Comment By: Michael Hudson (mwh)
Date: 2003-04-01 11:28

Message:
Logged In: YES 
user_id=6656

On the surface this just looks like the test opens more
files than you're allowed to, IOW not like a deep problem.

Can you raise that limit and try again?

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

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


From noreply@sourceforge.net  Tue Apr  1 12:33:29 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 01 Apr 2003 04:33:29 -0800
Subject: [Python-bugs-list] [ python-Bugs-713172 ] Python 2.3 tempfile test fails on HP-UX11i
Message-ID: <E190KxF-00048o-00@sc8-sf-web4.sourceforge.net>

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

Category: Build
Group: Python 2.3
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Richard Townsend (rptownsend)
>Assigned to: Michael Hudson (mwh)
Summary: Python 2.3 tempfile test fails on HP-UX11i

Initial Comment:
Here is the output from test_tempfile.py

capulet:dist/src > ./python 
Lib/test/test_tempfile.py
test_exports (__main__.test_exports) ... ok
test_get_six_char_str 
(__main__.test__RandomNameSequence) ... ok
test_many 
(__main__.test__RandomNameSequence) ... ok
test_supports_iter 
(__main__.test__RandomNameSequence) ... ok
test_nonempty_list 
(__main__.test__candidate_tempdir_list) ... ok
test_wanted_dirs 
(__main__.test__candidate_tempdir_list) ... ok
test_retval 
(__main__.test__get_candidate_names) ... ok
test_same_thing 
(__main__.test__get_candidate_names) ... ok
test_basic (__main__.test__mkstemp_inner) ... ok
test_basic_many 
(__main__.test__mkstemp_inner) ... FAIL
Exception exceptions.AttributeError: "mkstemped 
instance has no attribute 'fd'" in <bound method 
mkstemped.__del__ of <__main__.mkstemped 
instance at 0x4012de40>> ignored
test_choose_directory 
(__main__.test__mkstemp_inner) ... ok
test_file_mode (__main__.test__mkstemp_inner) ... 
ok
test_noinherit (__main__.test__mkstemp_inner) ... 
ok
test_textmode (__main__.test__mkstemp_inner) ... 
ok
test_sane_template 
(__main__.test_gettempprefix) ... ok
test_usable_template 
(__main__.test_gettempprefix) ... ok
test_directory_exists (__main__.test_gettempdir) ... 
ok
test_directory_writable 
(__main__.test_gettempdir) ... ok
test_same_thing (__main__.test_gettempdir) ... ok
test_basic (__main__.test_mkstemp) ... ok
test_choose_directory (__main__.test_mkstemp) ... 
ok
test_basic (__main__.test_mkdtemp) ... ok
test_basic_many (__main__.test_mkdtemp) ... ok
test_choose_directory (__main__.test_mkdtemp) ... 
ok
test_mode (__main__.test_mkdtemp) ... ok
test_basic (__main__.test_mktemp) ... ok
test_many (__main__.test_mktemp) ... ok
test_basic (__main__.test_NamedTemporaryFile) ... 
ok
test_creates_named 
(__main__.test_NamedTemporaryFile) ... ok
test_del_on_close 
(__main__.test_NamedTemporaryFile) ... ok
test_multiple_close 
(__main__.test_NamedTemporaryFile) ... ok
test_basic (__main__.test_TemporaryFile) ... ok
test_has_no_name 
(__main__.test_TemporaryFile) ... ok
test_multiple_close 
(__main__.test_TemporaryFile) ... ok

=================================
=================================
====
FAIL: test_basic_many 
(__main__.test__mkstemp_inner)
-----------------------------------------
-----------------------------
Traceback (most recent call last):
  File "Lib/test/test_tempfile.py", line 246, in 
test_basic_many
  File "Lib/test/test_tempfile.py", line 229, in 
do_create
  File "Lib/test/test_tempfile.py", line 45, in 
failOnException
  
File "/home/richardt/python.new/python/dist/src/
Lib/unittest.py", line 260, in fail
AssertionError: _mkstemp_inner raised 
exceptions.OSError: [Errno 24] Too many open 
files: '/tmp/aafmevUO'

-----------------------------------------
-----------------------------
Ran 34 tests in 0.604s

FAILED (failures=1)
Traceback (most recent call last):
  File "Lib/test/test_tempfile.py", line 654, in ?
    test_main()
  File "Lib/test/test_tempfile.py", line 651, in 
test_main
    test_support.run_suite(suite)
  
File "/home/richardt/python.new/python/dist/src/
Lib/test/test_support.py", line 225, in run_suite
    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most 
recent call last):
  File "Lib/test/test_tempfile.py", line 246, in 
test_basic_many
  File "Lib/test/test_tempfile.py", line 229, in 
do_create
  File "Lib/test/test_tempfile.py", line 45, in 
failOnException
  
File "/home/richardt/python.new/python/dist/src/
Lib/unittest.py", line 260, in fail
AssertionError: _mkstemp_inner raised 
exceptions.OSError: [Errno 24] Too many open 
files: '/tmp/aafmevUO'


This was running Python 2.3a2 (downloaded from 
CVS on Sunday 30th March) built on HP-UX11i.

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

>Comment By: Michael Hudson (mwh)
Date: 2003-04-01 13:33

Message:
Logged In: YES 
user_id=6656

OK, thanks.  I'll close this, although it's possible that
the test suite should make efforts to cope with this failure...

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

Comment By: Richard Townsend (rptownsend)
Date: 2003-04-01 13:27

Message:
Logged In: YES 
user_id=200117

You are correct. The kernel parameter 'maxfiles' was set 
to 60, but test_tempfile.py tries to open 100 files.

I increased maxfiles to 128 and the test now runs 
without errors.

Thank you.

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

Comment By: Michael Hudson (mwh)
Date: 2003-04-01 11:28

Message:
Logged In: YES 
user_id=6656

On the surface this just looks like the test opens more
files than you're allowed to, IOW not like a deep problem.

Can you raise that limit and try again?

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

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


From noreply@sourceforge.net  Tue Apr  1 16:02:02 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 01 Apr 2003 08:02:02 -0800
Subject: [Python-bugs-list] [ python-Bugs-713169 ] Python 2.3 pty test fails on HP-UX11i
Message-ID: <E190OD4-0004Fc-00@sc8-sf-web4.sourceforge.net>

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

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Townsend (rptownsend)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Python 2.3 pty test fails on HP-UX11i

Initial Comment:
Here is the output from test_pty.py:

capulet:dist/src > ./python Lib/test/test_pty.py
Calling master_open()
Got master_fd '3', slave_name '/dev/pts/0'
Calling slave_open('/dev/pts/0')
Got slave_fd '4'
Traceback (most recent call last):
  File "Lib/test/test_pty.py", line 58, in ?
    test_basic_pty()
  File "Lib/test/test_pty.py", line 29, in 
test_basic_pty
    if not os.isatty(slave_fd):
  File "Lib/test/test_pty.py", line 50, in handle_sig
    raise TestFailed, "isatty hung"
test.test_support.TestFailed: isatty hung


This was running Python 2.3a2 (downloaded from 
CVS on Sunday 30th March) built on HP-UX11i.

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-01 11:02

Message:
Logged In: YES 
user_id=33168

I fixed the test hanging, but not the actual bug.  The bug
appears when running test_pty after test_openpty.  There's
some interaction, but I don't know what it is.  The problem
happens on AIX also.  I searched through some man pages, but
nothing leapt out at me.  I think I tried googling for the
answer to no avail. Any insight or ideas would be helpful. 
This may have started when adding /dev/ptmx (ptc for AIX)
support.

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

Comment By: Michael Hudson (mwh)
Date: 2003-04-01 05:26

Message:
Logged In: YES 
user_id=6656

Neal?  I thought you thought this was fixed?

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

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


From noreply@sourceforge.net  Tue Apr  1 16:05:18 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 01 Apr 2003 08:05:18 -0800
Subject: [Python-bugs-list] [ python-Bugs-712322 ] test_zipimport failing on ia64 (at least)
Message-ID: <E190OGE-0008CD-00@sc8-sf-web2.sourceforge.net>

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

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: test_zipimport failing on ia64 (at least)

Initial Comment:
test_zipimport is failing on the snake-farm.  I'm
pretty sure this test worked before.  The only
difference is the file ends in .py vs. .pyc.  I don't
know what changed recently which would have cause this.

http://www.lysator.liu.se/xenofarm/python/files/454_3/python-testlog.txt

test test_zipimport failed -- Traceback (most recent
call last):
  File
"/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/Lib/test/test_zipimport.py",
line 108, in testBoth
    self.doTest(pyc_ext, files, TESTMOD)
  File
"/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/Lib/test/test_zipimport.py",
line 66, in doTest
    self.assertEquals(file, os.path.join(TEMP_ZIP,
  File
"/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/Lib/unittest.py",
line 292, in failUnlessEqual
    raise self.failureException, \
AssertionError:
'/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/junk95142.zip/ziptestmodule.py'
!=
'/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/junk95142.zip/ziptestmodule.pyc'




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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-01 11:05

Message:
Logged In: YES 
user_id=33168

This test is now failing on most unixes.  AIX, HPUX and
others I think.  I tried building some older versions from
3/1, 2/20, etc. but the problem persists.  Even though I
thought those versions worked at the time.  This will take
some time to look into further.  Assigning to me, but
hopefully someone else who also sees this problem can help.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-31 09:32

Message:
Logged In: YES 
user_id=33168

Yes, I believe it worked more recently, but I could be
wrong...  I checked out source from 3/20 and that still
fails, so I have to keep going back until I find exactly
where it failed.  I'll keep trying too.

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

Comment By: Just van Rossum (jvr)
Date: 2003-03-31 09:22

Message:
Logged In: YES 
user_id=92689

dict order should not have relevance to the test. I currently have no idea what could have caused it, and zipimport.c itself hasn't been changed significantly in a while. I see in the logs that in february you fixed some 64-bit issues, but I guess that by "it worked before" you mean something much more recent than that. I'll continue trying to figure out potential causes.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-31 08:33

Message:
Logged In: YES 
user_id=33168

It is also broken on AIX which I do have access to.  I'm
trying to determine what broke it.  One guess is dictionary
order.  I'm not sure if the test relies on .pyc being
written before .py as a result of file.items().  It is
broken on 3/26.  Unfortunately it takes a very long time to
build on these boxes (hours).  Let me know if you have any
idea of what might have recently changed to break zipimports.

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

Comment By: Just van Rossum (jvr)
Date: 2003-03-31 02:40

Message:
Logged In: YES 
user_id=92689

Then how are we/am I supposed to fix this? Assigning to None.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-30 17:32

Message:
Logged In: YES 
user_id=33168

Unfortunately, I don't have access to the boxes where this
is failling.  The only possibility would be in the compaq
(hp) test drive machines.

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

Comment By: Just van Rossum (jvr)
Date: 2003-03-30 16:03

Message:
Logged In: YES 
user_id=92689

Hm, apparently loading from pyc fails. Perhaps a bug with zipimport's pyc magic or mod date checking code?

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

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


From noreply@sourceforge.net  Tue Apr  1 16:03:44 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 01 Apr 2003 08:03:44 -0800
Subject: [Python-bugs-list] [ python-Bugs-713169 ] test_pty fails on HP-UX and AIX when run after test_openpty
Message-ID: <E190OEi-0004Jm-00@sc8-sf-web4.sourceforge.net>

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

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Townsend (rptownsend)
Assigned to: Neal Norwitz (nnorwitz)
>Summary: test_pty fails on HP-UX and AIX when run after test_openpty

Initial Comment:
Here is the output from test_pty.py:

capulet:dist/src > ./python Lib/test/test_pty.py
Calling master_open()
Got master_fd '3', slave_name '/dev/pts/0'
Calling slave_open('/dev/pts/0')
Got slave_fd '4'
Traceback (most recent call last):
  File "Lib/test/test_pty.py", line 58, in ?
    test_basic_pty()
  File "Lib/test/test_pty.py", line 29, in 
test_basic_pty
    if not os.isatty(slave_fd):
  File "Lib/test/test_pty.py", line 50, in handle_sig
    raise TestFailed, "isatty hung"
test.test_support.TestFailed: isatty hung


This was running Python 2.3a2 (downloaded from 
CVS on Sunday 30th March) built on HP-UX11i.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-01 11:02

Message:
Logged In: YES 
user_id=33168

I fixed the test hanging, but not the actual bug.  The bug
appears when running test_pty after test_openpty.  There's
some interaction, but I don't know what it is.  The problem
happens on AIX also.  I searched through some man pages, but
nothing leapt out at me.  I think I tried googling for the
answer to no avail. Any insight or ideas would be helpful. 
This may have started when adding /dev/ptmx (ptc for AIX)
support.

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

Comment By: Michael Hudson (mwh)
Date: 2003-04-01 05:26

Message:
Logged In: YES 
user_id=6656

Neal?  I thought you thought this was fixed?

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

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


From noreply@sourceforge.net  Tue Apr  1 16:31:46 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 01 Apr 2003 08:31:46 -0800
Subject: [Python-bugs-list] [ python-Bugs-713169 ] test_pty fails on HP-UX and AIX when run after test_openpty
Message-ID: <E190Ofq-0005Qy-00@sc8-sf-web4.sourceforge.net>

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

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Townsend (rptownsend)
Assigned to: Neal Norwitz (nnorwitz)
Summary: test_pty fails on HP-UX and AIX when run after test_openpty

Initial Comment:
Here is the output from test_pty.py:

capulet:dist/src > ./python Lib/test/test_pty.py
Calling master_open()
Got master_fd '3', slave_name '/dev/pts/0'
Calling slave_open('/dev/pts/0')
Got slave_fd '4'
Traceback (most recent call last):
  File "Lib/test/test_pty.py", line 58, in ?
    test_basic_pty()
  File "Lib/test/test_pty.py", line 29, in 
test_basic_pty
    if not os.isatty(slave_fd):
  File "Lib/test/test_pty.py", line 50, in handle_sig
    raise TestFailed, "isatty hung"
test.test_support.TestFailed: isatty hung


This was running Python 2.3a2 (downloaded from 
CVS on Sunday 30th March) built on HP-UX11i.

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-01 11:31

Message:
Logged In: YES 
user_id=33168

Actually, there is a 'fix' which is really a work-around the
problem.  You can disable os.openpty() in pty.master_open. 
I added a raise OSError at line 50 (before os.openpty()). 
This allows the test to pass.  I think Martin and I agreed
that globally disabling wasn't the best solution.  That
would probably be in some patch.

Also, just in case it isn't clear--if you run test_pty
BEFORE test_openpty, both tests pass.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-01 11:02

Message:
Logged In: YES 
user_id=33168

I fixed the test hanging, but not the actual bug.  The bug
appears when running test_pty after test_openpty.  There's
some interaction, but I don't know what it is.  The problem
happens on AIX also.  I searched through some man pages, but
nothing leapt out at me.  I think I tried googling for the
answer to no avail. Any insight or ideas would be helpful. 
This may have started when adding /dev/ptmx (ptc for AIX)
support.

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

Comment By: Michael Hudson (mwh)
Date: 2003-04-01 05:26

Message:
Logged In: YES 
user_id=6656

Neal?  I thought you thought this was fixed?

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

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


From noreply@sourceforge.net  Tue Apr  1 18:23:35 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 01 Apr 2003 10:23:35 -0800
Subject: [Python-bugs-list] [ python-Bugs-712322 ] test_zipimport failing on ia64 (at least)
Message-ID: <E190QQ3-0007dl-00@sc8-sf-web1.sourceforge.net>

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

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Neal Norwitz (nnorwitz)
Summary: test_zipimport failing on ia64 (at least)

Initial Comment:
test_zipimport is failing on the snake-farm.  I'm
pretty sure this test worked before.  The only
difference is the file ends in .py vs. .pyc.  I don't
know what changed recently which would have cause this.

http://www.lysator.liu.se/xenofarm/python/files/454_3/python-testlog.txt

test test_zipimport failed -- Traceback (most recent
call last):
  File
"/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/Lib/test/test_zipimport.py",
line 108, in testBoth
    self.doTest(pyc_ext, files, TESTMOD)
  File
"/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/Lib/test/test_zipimport.py",
line 66, in doTest
    self.assertEquals(file, os.path.join(TEMP_ZIP,
  File
"/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/Lib/unittest.py",
line 292, in failUnlessEqual
    raise self.failureException, \
AssertionError:
'/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/junk95142.zip/ziptestmodule.py'
!=
'/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/junk95142.zip/ziptestmodule.pyc'




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

>Comment By: Just van Rossum (jvr)
Date: 2003-04-01 20:23

Message:
Logged In: YES 
user_id=92689

Ah, duh, it even fails on OSX, so I can do some research myself.

Wild guess: are the other failing boxes also big endian machines?

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-01 18:05

Message:
Logged In: YES 
user_id=33168

This test is now failing on most unixes.  AIX, HPUX and
others I think.  I tried building some older versions from
3/1, 2/20, etc. but the problem persists.  Even though I
thought those versions worked at the time.  This will take
some time to look into further.  Assigning to me, but
hopefully someone else who also sees this problem can help.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-31 16:32

Message:
Logged In: YES 
user_id=33168

Yes, I believe it worked more recently, but I could be
wrong...  I checked out source from 3/20 and that still
fails, so I have to keep going back until I find exactly
where it failed.  I'll keep trying too.

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

Comment By: Just van Rossum (jvr)
Date: 2003-03-31 16:22

Message:
Logged In: YES 
user_id=92689

dict order should not have relevance to the test. I currently have no idea what could have caused it, and zipimport.c itself hasn't been changed significantly in a while. I see in the logs that in february you fixed some 64-bit issues, but I guess that by "it worked before" you mean something much more recent than that. I'll continue trying to figure out potential causes.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-31 15:33

Message:
Logged In: YES 
user_id=33168

It is also broken on AIX which I do have access to.  I'm
trying to determine what broke it.  One guess is dictionary
order.  I'm not sure if the test relies on .pyc being
written before .py as a result of file.items().  It is
broken on 3/26.  Unfortunately it takes a very long time to
build on these boxes (hours).  Let me know if you have any
idea of what might have recently changed to break zipimports.

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

Comment By: Just van Rossum (jvr)
Date: 2003-03-31 09:40

Message:
Logged In: YES 
user_id=92689

Then how are we/am I supposed to fix this? Assigning to None.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-31 00:32

Message:
Logged In: YES 
user_id=33168

Unfortunately, I don't have access to the boxes where this
is failling.  The only possibility would be in the compaq
(hp) test drive machines.

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

Comment By: Just van Rossum (jvr)
Date: 2003-03-30 23:03

Message:
Logged In: YES 
user_id=92689

Hm, apparently loading from pyc fails. Perhaps a bug with zipimport's pyc magic or mod date checking code?

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

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


From noreply@sourceforge.net  Tue Apr  1 19:28:50 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 01 Apr 2003 11:28:50 -0800
Subject: [Python-bugs-list] [ python-Bugs-712322 ] test_zipimport failing on ia64 (at least)
Message-ID: <E190RRC-0004ap-00@sc8-sf-web4.sourceforge.net>

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

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Neal Norwitz (nnorwitz)
Summary: test_zipimport failing on ia64 (at least)

Initial Comment:
test_zipimport is failing on the snake-farm.  I'm
pretty sure this test worked before.  The only
difference is the file ends in .py vs. .pyc.  I don't
know what changed recently which would have cause this.

http://www.lysator.liu.se/xenofarm/python/files/454_3/python-testlog.txt

test test_zipimport failed -- Traceback (most recent
call last):
  File
"/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/Lib/test/test_zipimport.py",
line 108, in testBoth
    self.doTest(pyc_ext, files, TESTMOD)
  File
"/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/Lib/test/test_zipimport.py",
line 66, in doTest
    self.assertEquals(file, os.path.join(TEMP_ZIP,
  File
"/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/Lib/unittest.py",
line 292, in failUnlessEqual
    raise self.failureException, \
AssertionError:
'/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/junk95142.zip/ziptestmodule.py'
!=
'/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/junk95142.zip/ziptestmodule.pyc'




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

>Comment By: Just van Rossum (jvr)
Date: 2003-04-01 21:28

Message:
Logged In: YES 
user_id=92689

Found the cause: daylight saving. I think it's a mismatch between zipfile.py's handling of time and zipimport.c's.

I just tested with a manually created zip file and the same problem occurs, so I'm fairly sure the problem is with zipimport's parse_dostime(). The effbot wrote that one for me, but perhaps someone else with the necessary time.h expertise can advise what's wrong?

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

Comment By: Just van Rossum (jvr)
Date: 2003-04-01 20:23

Message:
Logged In: YES 
user_id=92689

Ah, duh, it even fails on OSX, so I can do some research myself.

Wild guess: are the other failing boxes also big endian machines?

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-01 18:05

Message:
Logged In: YES 
user_id=33168

This test is now failing on most unixes.  AIX, HPUX and
others I think.  I tried building some older versions from
3/1, 2/20, etc. but the problem persists.  Even though I
thought those versions worked at the time.  This will take
some time to look into further.  Assigning to me, but
hopefully someone else who also sees this problem can help.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-31 16:32

Message:
Logged In: YES 
user_id=33168

Yes, I believe it worked more recently, but I could be
wrong...  I checked out source from 3/20 and that still
fails, so I have to keep going back until I find exactly
where it failed.  I'll keep trying too.

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

Comment By: Just van Rossum (jvr)
Date: 2003-03-31 16:22

Message:
Logged In: YES 
user_id=92689

dict order should not have relevance to the test. I currently have no idea what could have caused it, and zipimport.c itself hasn't been changed significantly in a while. I see in the logs that in february you fixed some 64-bit issues, but I guess that by "it worked before" you mean something much more recent than that. I'll continue trying to figure out potential causes.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-31 15:33

Message:
Logged In: YES 
user_id=33168

It is also broken on AIX which I do have access to.  I'm
trying to determine what broke it.  One guess is dictionary
order.  I'm not sure if the test relies on .pyc being
written before .py as a result of file.items().  It is
broken on 3/26.  Unfortunately it takes a very long time to
build on these boxes (hours).  Let me know if you have any
idea of what might have recently changed to break zipimports.

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

Comment By: Just van Rossum (jvr)
Date: 2003-03-31 09:40

Message:
Logged In: YES 
user_id=92689

Then how are we/am I supposed to fix this? Assigning to None.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-31 00:32

Message:
Logged In: YES 
user_id=33168

Unfortunately, I don't have access to the boxes where this
is failling.  The only possibility would be in the compaq
(hp) test drive machines.

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

Comment By: Just van Rossum (jvr)
Date: 2003-03-30 23:03

Message:
Logged In: YES 
user_id=92689

Hm, apparently loading from pyc fails. Perhaps a bug with zipimport's pyc magic or mod date checking code?

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

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


From noreply@sourceforge.net  Tue Apr  1 20:34:24 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 01 Apr 2003 12:34:24 -0800
Subject: [Python-bugs-list] [ python-Bugs-712322 ] test_zipimport failing on ia64 (at least)
Message-ID: <E190SSe-0003zt-00@sc8-sf-web2.sourceforge.net>

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

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Neal Norwitz (nnorwitz)
Summary: test_zipimport failing on ia64 (at least)

Initial Comment:
test_zipimport is failing on the snake-farm.  I'm
pretty sure this test worked before.  The only
difference is the file ends in .py vs. .pyc.  I don't
know what changed recently which would have cause this.

http://www.lysator.liu.se/xenofarm/python/files/454_3/python-testlog.txt

test test_zipimport failed -- Traceback (most recent
call last):
  File
"/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/Lib/test/test_zipimport.py",
line 108, in testBoth
    self.doTest(pyc_ext, files, TESTMOD)
  File
"/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/Lib/test/test_zipimport.py",
line 66, in doTest
    self.assertEquals(file, os.path.join(TEMP_ZIP,
  File
"/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/Lib/unittest.py",
line 292, in failUnlessEqual
    raise self.failureException, \
AssertionError:
'/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/junk95142.zip/ziptestmodule.py'
!=
'/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/junk95142.zip/ziptestmodule.pyc'




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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-01 15:34

Message:
Logged In: YES 
user_id=33168

Changing the tm_isdst to -1 fixed the problem on HPUX.  I'm
not sure if this will work on all platforms.  -1 means
mktime should guess whether DST is in effect or not.  0
means it's never DST.  I can see problems with any value. 
Perhaps there's some zip documentation which describes what
should be done?  Or perhaps the time (dostime, dosdate) are
encoded incorrectly?

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

Comment By: Just van Rossum (jvr)
Date: 2003-04-01 14:28

Message:
Logged In: YES 
user_id=92689

Found the cause: daylight saving. I think it's a mismatch between zipfile.py's handling of time and zipimport.c's.

I just tested with a manually created zip file and the same problem occurs, so I'm fairly sure the problem is with zipimport's parse_dostime(). The effbot wrote that one for me, but perhaps someone else with the necessary time.h expertise can advise what's wrong?

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

Comment By: Just van Rossum (jvr)
Date: 2003-04-01 13:23

Message:
Logged In: YES 
user_id=92689

Ah, duh, it even fails on OSX, so I can do some research myself.

Wild guess: are the other failing boxes also big endian machines?

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-01 11:05

Message:
Logged In: YES 
user_id=33168

This test is now failing on most unixes.  AIX, HPUX and
others I think.  I tried building some older versions from
3/1, 2/20, etc. but the problem persists.  Even though I
thought those versions worked at the time.  This will take
some time to look into further.  Assigning to me, but
hopefully someone else who also sees this problem can help.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-31 09:32

Message:
Logged In: YES 
user_id=33168

Yes, I believe it worked more recently, but I could be
wrong...  I checked out source from 3/20 and that still
fails, so I have to keep going back until I find exactly
where it failed.  I'll keep trying too.

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

Comment By: Just van Rossum (jvr)
Date: 2003-03-31 09:22

Message:
Logged In: YES 
user_id=92689

dict order should not have relevance to the test. I currently have no idea what could have caused it, and zipimport.c itself hasn't been changed significantly in a while. I see in the logs that in february you fixed some 64-bit issues, but I guess that by "it worked before" you mean something much more recent than that. I'll continue trying to figure out potential causes.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-31 08:33

Message:
Logged In: YES 
user_id=33168

It is also broken on AIX which I do have access to.  I'm
trying to determine what broke it.  One guess is dictionary
order.  I'm not sure if the test relies on .pyc being
written before .py as a result of file.items().  It is
broken on 3/26.  Unfortunately it takes a very long time to
build on these boxes (hours).  Let me know if you have any
idea of what might have recently changed to break zipimports.

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

Comment By: Just van Rossum (jvr)
Date: 2003-03-31 02:40

Message:
Logged In: YES 
user_id=92689

Then how are we/am I supposed to fix this? Assigning to None.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-30 17:32

Message:
Logged In: YES 
user_id=33168

Unfortunately, I don't have access to the boxes where this
is failling.  The only possibility would be in the compaq
(hp) test drive machines.

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

Comment By: Just van Rossum (jvr)
Date: 2003-03-30 16:03

Message:
Logged In: YES 
user_id=92689

Hm, apparently loading from pyc fails. Perhaps a bug with zipimport's pyc magic or mod date checking code?

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

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


From noreply@sourceforge.net  Tue Apr  1 23:40:38 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 01 Apr 2003 15:40:38 -0800
Subject: [Python-bugs-list] [ python-Bugs-713601 ] site.py breaks if prefix is empty
Message-ID: <E190VMs-0003OS-00@sc8-sf-web2.sourceforge.net>

Bugs item #713601, was opened at 2003-04-01 20:40
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=713601&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Lalo Martins (lalo)
Assigned to: Nobody/Anonymous (nobody)
Summary: site.py breaks if prefix is empty

Initial Comment:
verified in 2.3a1 and 2.2.2:

prefixes = [sys.prefix]
if sys.exec_prefix != sys.prefix:
    prefixes.append(sys.exec_prefix)
for prefix in prefixes:
    if prefix:
        # do stuff - in particular, define the
"sitedir" variable
        # and add site-packages to the path
del prefix, sitedir

if sys.prefix == sys.exec_prefix and both are empty
(which is the case if you compile with --prefix=/ as
for the
Gnu OS for example), this will have two unfortunate
results:

1. site-packages will not be added to the path.

2. site.py will abort with a NameError (it tries to del
sitedir
which isn't defined)

The fix seems to be as simple as removing the "if prefix"
line.  From mailing list archives, it seems to have been
added to cope with unusual loading environments related
to windows and COM - in this case, there is probably a
safer way to check for this condition.  If the prefix is
empty, this just means it's the root, and no further
assumptions should be made.

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

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


From noreply@sourceforge.net  Wed Apr  2 00:37:05 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 01 Apr 2003 16:37:05 -0800
Subject: [Python-bugs-list] [ python-Feature Requests-494854 ] add platform.py
Message-ID: <E190WFV-0003ox-00@sc8-sf-web3.sourceforge.net>

Feature Requests item #494854, was opened at 2001-12-18 18:16
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=494854&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 7
Submitted By: Jason R. Mastaler (jasonrm)
Assigned to: M.-A. Lemburg (lemburg)
Summary: add platform.py

Initial Comment:
Here's a request to add Marc-Andre Lemburg's
platform.py to the Python standard library.

It provides more complete platform information
than either sys.platform or
distutils.util.get_platform()

For more info, see:
http://www.lemburg.com/files/python/platform.py


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

>Comment By: Jason R. Mastaler (jasonrm)
Date: 2003-04-01 17:37

Message:
Logged In: YES 
user_id=85984

How about adding platform.py to the 
distribution even if there is no docs 
forthcoming?  It's not like this would be 
the first undocumented module. 
 

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-29 08:14

Message:
Logged In: YES 
user_id=21627

Is there any hope of getting documentation?

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-03-05 09:51

Message:
Logged In: YES 
user_id=38388

Guido has already approved the addition; so it's basically
just the docs that are currently missing...

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-12-19 02:27

Message:
Logged In: YES 
user_id=38388

No problem from here :-)

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

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


From noreply@sourceforge.net  Wed Apr  2 06:27:36 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 01 Apr 2003 22:27:36 -0800
Subject: [Python-bugs-list] [ python-Bugs-713722 ] Distutils documentation amputated
Message-ID: <E190bii-0006Yv-00@sc8-sf-web1.sourceforge.net>

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

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregory Ewing (gcewing)
Assigned to: Nobody/Anonymous (nobody)
Summary: Distutils documentation amputated

Initial Comment:
Somewhere between the 2.0 and 2.1 documentation releases,
a big chunk of the Distributing Python Modules manual
seems to have gone missing.

Section 7 (Examples), 8 (Extending the Distutils) and most
of 9 (Reference) are absent. Section 7 contains a small
part of what used to be section 9.


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

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


From noreply@sourceforge.net  Wed Apr  2 08:26:20 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 02 Apr 2003 00:26:20 -0800
Subject: [Python-bugs-list] [ python-Bugs-712322 ] test_zipimport failing on ia64 (at least)
Message-ID: <E190dZc-0004QO-00@sc8-sf-web4.sourceforge.net>

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

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Neal Norwitz (nnorwitz)
Summary: test_zipimport failing on ia64 (at least)

Initial Comment:
test_zipimport is failing on the snake-farm.  I'm
pretty sure this test worked before.  The only
difference is the file ends in .py vs. .pyc.  I don't
know what changed recently which would have cause this.

http://www.lysator.liu.se/xenofarm/python/files/454_3/python-testlog.txt

test test_zipimport failed -- Traceback (most recent
call last):
  File
"/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/Lib/test/test_zipimport.py",
line 108, in testBoth
    self.doTest(pyc_ext, files, TESTMOD)
  File
"/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/Lib/test/test_zipimport.py",
line 66, in doTest
    self.assertEquals(file, os.path.join(TEMP_ZIP,
  File
"/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/Lib/unittest.py",
line 292, in failUnlessEqual
    raise self.failureException, \
AssertionError:
'/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/junk95142.zip/ziptestmodule.py'
!=
'/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/junk95142.zip/ziptestmodule.pyc'




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

>Comment By: Just van Rossum (jvr)
Date: 2003-04-02 10:26

Message:
Logged In: YES 
user_id=92689

It sure works for OSX!

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-01 22:34

Message:
Logged In: YES 
user_id=33168

Changing the tm_isdst to -1 fixed the problem on HPUX.  I'm
not sure if this will work on all platforms.  -1 means
mktime should guess whether DST is in effect or not.  0
means it's never DST.  I can see problems with any value. 
Perhaps there's some zip documentation which describes what
should be done?  Or perhaps the time (dostime, dosdate) are
encoded incorrectly?

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

Comment By: Just van Rossum (jvr)
Date: 2003-04-01 21:28

Message:
Logged In: YES 
user_id=92689

Found the cause: daylight saving. I think it's a mismatch between zipfile.py's handling of time and zipimport.c's.

I just tested with a manually created zip file and the same problem occurs, so I'm fairly sure the problem is with zipimport's parse_dostime(). The effbot wrote that one for me, but perhaps someone else with the necessary time.h expertise can advise what's wrong?

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

Comment By: Just van Rossum (jvr)
Date: 2003-04-01 20:23

Message:
Logged In: YES 
user_id=92689

Ah, duh, it even fails on OSX, so I can do some research myself.

Wild guess: are the other failing boxes also big endian machines?

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-01 18:05

Message:
Logged In: YES 
user_id=33168

This test is now failing on most unixes.  AIX, HPUX and
others I think.  I tried building some older versions from
3/1, 2/20, etc. but the problem persists.  Even though I
thought those versions worked at the time.  This will take
some time to look into further.  Assigning to me, but
hopefully someone else who also sees this problem can help.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-31 16:32

Message:
Logged In: YES 
user_id=33168

Yes, I believe it worked more recently, but I could be
wrong...  I checked out source from 3/20 and that still
fails, so I have to keep going back until I find exactly
where it failed.  I'll keep trying too.

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

Comment By: Just van Rossum (jvr)
Date: 2003-03-31 16:22

Message:
Logged In: YES 
user_id=92689

dict order should not have relevance to the test. I currently have no idea what could have caused it, and zipimport.c itself hasn't been changed significantly in a while. I see in the logs that in february you fixed some 64-bit issues, but I guess that by "it worked before" you mean something much more recent than that. I'll continue trying to figure out potential causes.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-31 15:33

Message:
Logged In: YES 
user_id=33168

It is also broken on AIX which I do have access to.  I'm
trying to determine what broke it.  One guess is dictionary
order.  I'm not sure if the test relies on .pyc being
written before .py as a result of file.items().  It is
broken on 3/26.  Unfortunately it takes a very long time to
build on these boxes (hours).  Let me know if you have any
idea of what might have recently changed to break zipimports.

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

Comment By: Just van Rossum (jvr)
Date: 2003-03-31 09:40

Message:
Logged In: YES 
user_id=92689

Then how are we/am I supposed to fix this? Assigning to None.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-31 00:32

Message:
Logged In: YES 
user_id=33168

Unfortunately, I don't have access to the boxes where this
is failling.  The only possibility would be in the compaq
(hp) test drive machines.

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

Comment By: Just van Rossum (jvr)
Date: 2003-03-30 23:03

Message:
Logged In: YES 
user_id=92689

Hm, apparently loading from pyc fails. Perhaps a bug with zipimport's pyc magic or mod date checking code?

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

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


From noreply@sourceforge.net  Wed Apr  2 19:39:02 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 02 Apr 2003 11:39:02 -0800
Subject: [Python-bugs-list] [ python-Bugs-697220 ] string.strip implementation/doc mismatch
Message-ID: <E190o4c-0006hP-00@sc8-sf-web1.sourceforge.net>

Bugs item #697220, was opened at 2003-03-04 13:48
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697220&group_id=5470

Category: Documentation
Group: Python 2.2.2
Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Gerhard Häring (ghaering)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: string.strip implementation/doc mismatch

Initial Comment:
#v+
>>> "test".strip("t")
'es'
>>> import string
>>> print string.strip("test", "t")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: strip() takes exactly 1 argument (2 given)
>>>
#v-

*But* the Python documentation says that not only the
string *method* strip() will allow a second optional
argument, but also the strip function in the string
module.
(http://www.python.org/doc/current/lib/module-string.html)

string.strip should be changed to accept the additional
 parameter.

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

>Comment By: Walter Dörwald (doerwalter)
Date: 2003-04-02 21:39

Message:
Logged In: YES 
user_id=89016

Here are updated patches: I've renamed the arguments from
sep to chars in UserString too and I've added the
"versionchanged" info to all three functions in both patches.

I think the patches are ready now.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-30 21:54

Message:
Logged In: YES 
user_id=33168

Updated both patches to fix problem with sep--changed
docstrings to use chars.  Updated string_tests for 2.3.

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

Comment By: Walter Dörwald (doerwalter)
Date: 2003-03-20 12:36

Message:
Logged In: YES 
user_id=89016

In the patch for 2.3 a few docstrings in string.py still
mention sep instead of chars. The tests in
test/string_tests.py::MixinStrUnicodeUserStringTest.test_strip_args()
should be moved to CommonTest.test_strip() so that these
tests will be run for the string module too.

I haven't looked at the 2.2.3 patch yet.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-06 07:25

Message:
Logged In: YES 
user_id=33168

Gerhard, hopefully I've cleaned things up this time.  Could
you review both patches attached (one for 2.2.3, the other
for 2.3)?  I will send a message to python-dev to get
concurrence on the changes and hopefully more review.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-04 19:20

Message:
Logged In: YES 
user_id=33168

Thanks, you are correct.  The problem was with the string
object, not the string module.  :-(  I need to look at this
more.

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

Comment By: Gerhard Häring (ghaering)
Date: 2003-03-04 19:10

Message:
Logged In: YES 
user_id=163326

Neil, I don't think this was implemented in the 2.2
maintenance branch. That's why I'm reopening this. At least
for my 2.2 Pythons string.strip accepts one parameter only:

Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more
information.
>>> import string
>>> string.strip("test", "t")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: strip() takes exactly 1 argument (2 given)
>>>

and

Python 2.2.2 (#1, Feb  9 2003, 13:22:07)
[GCC 3.2.1 [FreeBSD] 20021119 (release)] on freebsd5
Type "help", "copyright", "credits" or "license" for more
information.
>>> import string
>>> string.strip("test", "t")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: strip() takes exactly 1 argument (2 given)

Confused.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-04 18:55

Message:
Logged In: YES 
user_id=33168

Gerhard, 2.2.2 does have 2 arguments, but 2.2.1 and before
do not.  We should really update the doc.  I thought this
was done, but apparently not.

Checked in as: libstring.tex 1.45.8.4

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

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


From noreply@sourceforge.net  Thu Apr  3 01:34:23 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 02 Apr 2003 17:34:23 -0800
Subject: [Python-bugs-list] [ python-Bugs-705295 ] Error when using PyZipFile to create archive
Message-ID: <E190tcV-0003b5-00@sc8-sf-web3.sourceforge.net>

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

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Dave Kuhlman (dkuhlman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error when using PyZipFile to create archive

Initial Comment:
I get the following trace back while using the PyZipFile class to create zip import files.

Traceback (most recent call last):
  File "../fsmGenerate.py", line 125, in ?
    main()
  File "../fsmGenerate.py", line 121, in main
    generate(inFileName, outName, app, gui, schema, zip)
  File "../fsmGenerate.py", line 56, in generate
    outZip.write(name)
  File "/usr/local/lib/python2.3/zipfile.py", line 427, in write
    self.fp.write(zinfo.FileHeader())
  File "/usr/local/lib/python2.3/zipfile.py", line 167, in FileHeader
    fileHeader = '%s%s%s' % (header, self.filename, self.extra)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xf0 in position 10: ordinal not in range(128)

This error occurs intermitently.  It seems to be related to the time.

Looking in file Lib/zipfile.py, it appears that the call to struct.pack() in method ZipInfo.FileHeader() is creating a string containing bytes with values > 0x7F.  I believe that these values are coming from local variable dostime in ZipInfo.FileHeader().

I'm using Python 2.3a2, built from source on Linux.



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

>Comment By: Dave Kuhlman (dkuhlman)
Date: 2003-04-02 17:34

Message:
Logged In: YES 
user_id=629965

I can no longer reproduce this bug.  I'm the one who originally submitted this bug report. There must have been a bug in my original code.  The test I'm using now executes with no problems.


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

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


From noreply@sourceforge.net  Thu Apr  3 09:01:15 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 03 Apr 2003 01:01:15 -0800
Subject: [Python-bugs-list] [ python-Feature Requests-714469 ] Easy tutorial printing should be possible
Message-ID: <E1910ax-0001B1-00@sc8-sf-web2.sourceforge.net>

Feature Requests item #714469, was opened at 2003-04-03 11:01
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=714469&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Joost Jacob (wspace)
Assigned to: Nobody/Anonymous (nobody)
Summary: Easy tutorial printing should be possible

Initial Comment:
I wanted to print the Python Tutorial by Guido for a 
colleague who might be interested in Python.  But this 
was not easy since it is distributed over a 18 different 
html files!  So now he has something looking bad 
because page numbers restart at every section.  I didn't 
have the time to think of a better solution: I wanted to 
give a printed tutorial fast.

So the request is this:  make the tutorial available in 
ONE html file so anybody can print it nicely with correct 
pagenumbers etc. from their browser.  This could also 
be interesting for the other documentation?

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

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


From noreply@sourceforge.net  Thu Apr  3 09:44:52 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 03 Apr 2003 01:44:52 -0800
Subject: [Python-bugs-list] [ python-Feature Requests-714469 ] Easy tutorial printing should be possible
Message-ID: <E1911HA-0006jn-00@sc8-sf-web4.sourceforge.net>

Feature Requests item #714469, was opened at 2003-04-03 11:01
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=714469&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Joost Jacob (wspace)
Assigned to: Nobody/Anonymous (nobody)
Summary: Easy tutorial printing should be possible

Initial Comment:
I wanted to print the Python Tutorial by Guido for a 
colleague who might be interested in Python.  But this 
was not easy since it is distributed over a 18 different 
html files!  So now he has something looking bad 
because page numbers restart at every section.  I didn't 
have the time to think of a better solution: I wanted to 
give a printed tutorial fast.

So the request is this:  make the tutorial available in 
ONE html file so anybody can print it nicely with correct 
pagenumbers etc. from their browser.  This could also 
be interesting for the other documentation?

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

>Comment By: Jack Jansen (jackjansen)
Date: 2003-04-03 11:44

Message:
Logged In: YES 
user_id=45365

The tutorial is also available in PDF, but at the moment only if you download an archive containing the full documentation set (on the doc/current/download.html page).

Maybe it is a good idea to make the PDFs available separately too? The letter variation is probably best, non-americans are more used to letter than americans to A4, I guess...

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

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


From noreply@sourceforge.net  Thu Apr  3 09:54:53 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 03 Apr 2003 01:54:53 -0800
Subject: [Python-bugs-list] [ python-Feature Requests-714469 ] Easy tutorial printing should be possible
Message-ID: <E1911Qr-0003Hu-00@sc8-sf-web2.sourceforge.net>

Feature Requests item #714469, was opened at 2003-04-03 11:01
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=714469&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Joost Jacob (wspace)
Assigned to: Nobody/Anonymous (nobody)
Summary: Easy tutorial printing should be possible

Initial Comment:
I wanted to print the Python Tutorial by Guido for a 
colleague who might be interested in Python.  But this 
was not easy since it is distributed over a 18 different 
html files!  So now he has something looking bad 
because page numbers restart at every section.  I didn't 
have the time to think of a better solution: I wanted to 
give a printed tutorial fast.

So the request is this:  make the tutorial available in 
ONE html file so anybody can print it nicely with correct 
pagenumbers etc. from their browser.  This could also 
be interesting for the other documentation?

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

>Comment By: Joost Jacob (wspace)
Date: 2003-04-03 11:54

Message:
Logged In: YES 
user_id=697662

Jack Jansen mentions availability of PDF files, but I did not 
find those on the Python web site when I was (in a hurry) 
looking for the tutorial.  Also he mentions "Letter" or "A4" 
variations, but this is one of the reasons I think one HTML file 
would be best for each document: the users' browser can 
print that to postscript or send it directly to a printer with all 
the users' favorite options.

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

Comment By: Jack Jansen (jackjansen)
Date: 2003-04-03 11:44

Message:
Logged In: YES 
user_id=45365

The tutorial is also available in PDF, but at the moment only if you download an archive containing the full documentation set (on the doc/current/download.html page).

Maybe it is a good idea to make the PDFs available separately too? The letter variation is probably best, non-americans are more used to letter than americans to A4, I guess...

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

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


From noreply@sourceforge.net  Thu Apr  3 16:44:10 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 03 Apr 2003 08:44:10 -0800
Subject: [Python-bugs-list] [ python-Bugs-714733 ] cPickle fails to pickle inf
Message-ID: <E1917ow-0001lJ-00@sc8-sf-web4.sourceforge.net>

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

Category: Python Library
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Kochanski (gpk)
Assigned to: Nobody/Anonymous (nobody)
Summary: cPickle fails to pickle inf

Initial Comment:
cPickle fails, and throws an exception when
you ask it to pickle infinity, and cPickle
is set for binary mode.

See example:

gpk* python2.2
Python 2.2.1 (#1, Jul 29 2002, 23:15:49) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> x = float("Inf")
>>> x
inf
>>> import cPickle
>>> import sys      
>>> cPickle.dump(x, sys.stdout)
Finf
.>>> cPickle.dump(x, sys.stdout, 1)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
SystemError: frexp() result out of range
>>> 


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

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


From noreply@sourceforge.net  Fri Apr  4 04:03:21 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 03 Apr 2003 20:03:21 -0800
Subject: [Python-bugs-list] [ python-Bugs-715063 ] bsddb.first()/next() raise undocumented exception
Message-ID: <E191IQD-0003ts-00@sc8-sf-web4.sourceforge.net>

Bugs item #715063, was opened at 2003-04-03 20:03
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=715063&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Christian Stork (cst)
Assigned to: Nobody/Anonymous (nobody)
Summary: bsddb.first()/next() raise undocumented exception

Initial Comment:
bsddb object's first() & next() methods raise an undocumented 
exception.  Wouldn't returning None make much more sense?  
And shouldn't this be documented? 

Python 2.3a2+ (#2, Mar 21 2003, 22:13:05) 
[GCC 3.2.3 20030316 (Debian prerelease)] on linux2
>>> import bsddb
>>> h.bsddb.hashopen("testdb")
>>> h.first()
------------------------------------------------------------
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.3/bsddb/__init__.py", line 134, in first
    rv = self.dbc.first()
DBNotFoundError: (-30991, 'DB_NOTFOUND: No matching key/
data pair found')

Note: The same exception appeared for the equivalent dbhash 
methods.  But I assume this should be fixed if this bug is fixed.

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

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


From noreply@sourceforge.net  Fri Apr  4 08:25:12 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 04 Apr 2003 00:25:12 -0800
Subject: [Python-bugs-list] [ python-Bugs-715145 ] unittest.py still uses != in failUnlessEqual.
Message-ID: <E191MVc-00043I-00@sc8-sf-web2.sourceforge.net>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Fincher (jemfinch)
Assigned to: Nobody/Anonymous (nobody)
Summary: unittest.py still uses != in failUnlessEqual.

Initial Comment:
It was submitted a long time ago to the PyUnit SF.net bug 
tracker 
(http://sourceforge.net/tracker/index.php?func=detail&aid=453281&group_id=3912&atid=103912), 
and even got the BDFL approval, but still hasn't been 
changed.  See the linked bug for the actual fix. 
 
(I also agree with rengelink's opinion that if __eq__ is 
defined but not __ne__, != should be equivalent to not ==, 
in which case this wouldn't be a problem.) 

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

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


From noreply@sourceforge.net  Fri Apr  4 12:26:33 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 04 Apr 2003 04:26:33 -0800
Subject: [Python-bugs-list] [ python-Feature Requests-715263 ] Access to DOM Element attributes using __getitem__
Message-ID: <E191QHB-0002mR-00@sc8-sf-web1.sourceforge.net>

Feature Requests item #715263, was opened at 2003-04-04 14:26
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=715263&group_id=5470

Category: XML
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: chris burdess (bluezoo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Access to DOM Element attributes using __getitem__

Initial Comment:
Element objects in XML DOM implementations in Python
should provide access to their attributes in a standard
Python way, using __getitem__. Thus, the following code
to print the version of an XMI document should work:

  import xml.dom.minidom
  print
xml.dom.minidom.parse(filename).documentElement['xmi.version']


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

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


From noreply@sourceforge.net  Fri Apr  4 13:29:52 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 04 Apr 2003 05:29:52 -0800
Subject: [Python-bugs-list] [ python-Feature Requests-706392 ] faster _socket.connect variant desired
Message-ID: <E191RGS-0004zw-00@sc8-sf-web3.sourceforge.net>

Feature Requests item #706392, was opened at 2003-03-19 11:14
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=706392&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Marcus Mendenhall (mendenhall)
Assigned to: Nobody/Anonymous (nobody)
Summary: faster _socket.connect variant desired

Initial Comment:
The  _socket.connect() call is not quite semantically equivalent to the underlying bsd connect() call in that it always parses an internet address.  This process can be quite slow, since it attempts to determine names and cnames (etc) using getaddrinfo(), which may require DNS lookups to complete.  In an environment where many sockets are being connected and disconnected, this is expensive.  

I would like to propose two minor additions to the _socket module:

1) A python wrapper to the internal getsockaddrarg(), allowing a fully processed socket address to be returned as a string

2) a connect_raw_address() call which is a pure wrapper to the bsd connect() call, and which assumes it is passed a string from getsockaddrarg().

This would allow a socket to be disconnected and reconnected many times to the same address, but with much less network chatter and OS overhead.  Effectively, I would like an unbundled version of _socket.connect(), with each of the two processes it uses able to be carried out independently.  

This is also useful in environments where one is communicating on aprivate network which is connected to the outside world over a (for example) PPP or PPPoE link.  Internal traffic handled through this connect will not result in gratuitous DNS traffic which will keep the link from ever closing.

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

>Comment By: Marcus Mendenhall (mendenhall)
Date: 2003-04-04 07:29

Message:
Logged In: YES 
user_id=470295

OK, I followed your suggestion and made a very lightweight type sockaddr, which has only a constructor, a destructor, and a method called to_tuple() which allows one to get the data out for reconstruction.  I have included, I think, decent docstrings, but haven't patched any of the main Python doc tree.  If you look at the top of getsockaddrarg(), this is the _only_ place this new type interacts with the rest of the _socket module.  Here is a prototype patch.  I have tried it a bit, and I think it works and is safe.  If you have any comments, please let me know.

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

Comment By: Marcus Mendenhall (mendenhall)
Date: 2003-03-30 14:34

Message:
Logged In: YES 
user_id=470295

Aha, now I see what you are suggesting.  I didn't quite understand what you intended before.  This (wrapping sockaddr and having connect check for the wrapped object) sounds like a very plausible idea.  I will consider strongly doing it this way.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-29 11:35

Message:
Logged In: YES 
user_id=21627

Providing a wrapper would allow to reuse the connect
operation, as it could check whether the argument is the
wrapper. If you prefer to use plain strings and a separate
function: that would be fine as well.

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

Comment By: Marcus Mendenhall (mendenhall)
Date: 2003-03-29 11:16

Message:
Logged In: YES 
user_id=470295

Does it really require wrapping sockaddr?  It seems that returning an opaque string containing the data returned by getsockaddrarg that can be passed to the new connect_arw (or whatever) is sufficient.  There doesn't need to be any way to access/mess with the data in this string, since its format is whatever the underlying unix utilities return, and varies by socket address family, etc, but it only needs to be able to be passed blindly to connect.  

Anyway, I would be glad to provide a patch to provide the other routines.    

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-29 09:08

Message:
Logged In: YES 
user_id=21627

I think this requires creating a struct sockaddr wrapper
object. Would you be interested in developing a patch?

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

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


From noreply@sourceforge.net  Fri Apr  4 23:11:52 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 04 Apr 2003 15:11:52 -0800
Subject: [Python-bugs-list] [ python-Bugs-715145 ] unittest.py still uses != in failUnlessEqual.
Message-ID: <E191aLg-000833-00@sc8-sf-web2.sourceforge.net>

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

Category: None
>Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jeremy Fincher (jemfinch)
Assigned to: Nobody/Anonymous (nobody)
Summary: unittest.py still uses != in failUnlessEqual.

Initial Comment:
It was submitted a long time ago to the PyUnit SF.net bug 
tracker 
(http://sourceforge.net/tracker/index.php?func=detail&aid=453281&group_id=3912&atid=103912), 
and even got the BDFL approval, but still hasn't been 
changed.  See the linked bug for the actual fix. 
 
(I also agree with rengelink's opinion that if __eq__ is 
defined but not __ne__, != should be equivalent to not ==, 
in which case this wouldn't be a problem.) 

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-04 18:11

Message:
Logged In: YES 
user_id=80475

Fixed.
See Lib/unittest.py 1.23

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

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


From noreply@sourceforge.net  Sat Apr  5 11:36:50 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 05 Apr 2003 03:36:50 -0800
Subject: [Python-bugs-list] [ python-Bugs-715782 ] pydoc support for keywords
Message-ID: <E191lyc-0002OR-00@sc8-sf-web1.sourceforge.net>

Bugs item #715782, was opened at 2003-04-05 11:36
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=715782&group_id=5470

Category: Documentation
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: pydoc support for keywords

Initial Comment:
[ from http://bugs.debian.org/186775 ]

If one uses $ man perl
one gets on a path that can lead one to eventually find
docs for the
most basic commands like 'while'

However for python one sees one is to use pydoc. But
running pydoc,
one just sees
  pydoc - the Python documentation tool

  /usr/bin/pydoc <name> ...

etc. no hint about how to learn about basics like 'while'.

BTW, I wish it would say pydoc, not /usr/bin/pydoc


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

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


From noreply@sourceforge.net  Sun Apr  6 09:33:38 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 06 Apr 2003 00:33:38 -0800
Subject: [Python-bugs-list] [ python-Bugs-715782 ] pydoc support for keywords
Message-ID: <E1925as-0001ML-00@sc8-sf-web2.sourceforge.net>

Bugs item #715782, was opened at 2003-04-05 14:36
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=715782&group_id=5470

Category: Documentation
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: pydoc support for keywords

Initial Comment:
[ from http://bugs.debian.org/186775 ]

If one uses $ man perl
one gets on a path that can lead one to eventually find
docs for the
most basic commands like 'while'

However for python one sees one is to use pydoc. But
running pydoc,
one just sees
  pydoc - the Python documentation tool

  /usr/bin/pydoc <name> ...

etc. no hint about how to learn about basics like 'while'.

BTW, I wish it would say pydoc, not /usr/bin/pydoc


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

Comment By: Cherniavsky Beni (cben)
Date: 2003-04-06 11:33

Message:
Logged In: YES 
user_id=36166

It should suggest to run ``python`` and type ``help()``. 
Then one can type ``topics`` and access the language
documentation itself, e.g. ``LOOPING`` would tell one that
there is a ``while`` whose specific documentation is
accessible by typing the ``while`` keyword itself.  Also
some sentences about the usefulness of the Python prompt,
`dir()` and `help()` for learning might be in order...

BTW, it would be more consistent if pydoc would support the
special topics from the command line (it would require a
non-ambiguos option to avoid shadowing modules in current
directoy that happen to have one of the special name)...

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

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


From noreply@sourceforge.net  Sun Apr  6 11:09:50 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 06 Apr 2003 03:09:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-716168 ] Minor nested scopes doc issues
Message-ID: <E19275y-0003xq-00@sc8-sf-web2.sourceforge.net>

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

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Cherniavsky Beni (cben)
Assigned to: Nobody/Anonymous (nobody)
Summary: Minor nested scopes doc issues

Initial Comment:
1. In section "4.1 Naming and binding", in the list of
binding operations, list comprehensions are missing.

2. Appendix "A. Future statements and nested scopes"
doesn't contain the nested scopes docs (it's now
section 4.1) but still says it does and that "it will
be removed in Python 2.2" :-).


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

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


From noreply@sourceforge.net  Sun Apr  6 11:10:23 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 06 Apr 2003 03:10:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-699934 ] Obscure error message
Message-ID: <E19276V-0002MF-00@sc8-sf-web4.sourceforge.net>

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

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Bjorn Pettersen (bpettersen)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Obscure error message

Initial Comment:
>>> class A(object):
...   m = 1
...
>>> class B(A): pass
...
>>> class C(A): pass
...
>>> class D(A,B): pass
...
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: MRO conflict among bases A, B

I happen to know what MRO stands for, but probably 
most people that made the typo I did in the diamond 
inheritance graph will have no idea what they did wrong...

How about "One of the declared superclasses A, B 
inherits from the other, the method resolution order 
(MRO) would therefore be undefined. Cannot create 
class."

-- bjorn


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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-06 05:10

Message:
Logged In: YES 
user_id=80475

Michael, do you have a preference?

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-03-14 01:34

Message:
Logged In: YES 
user_id=80475

Idea 1
------
TypeError: Cannot create class.  
Accessing superclasses A, B in order creates conflicting
inheritance trees which leave the method resolution order 
(MRO) undefined.

Idea 2
------
Cannot create a consistent method resolution order (MRO) 
for bases A, B.

Idea 3
------
Doh!

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

Comment By: Michael Hudson (mwh)
Date: 2003-03-12 08:01

Message:
Logged In: YES 
user_id=6656

Unfortunately the new error message makes no sense when you
get it by rearranging __bases__.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-03-11 23:38

Message:
Logged In: YES 
user_id=80475

Fixed.  See:

Objects/typeobject.c 2.216
Lib/test/test_descr.py 1.187


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

Comment By: Bjorn Pettersen (bpettersen)
Date: 2003-03-11 21:50

Message:
Logged In: YES 
user_id=556638

Even better. If I were to suggest anything, it would be to 
add "(lookup)" after "resolution" since that seems to be the 
more frequently used terminology -- not a big issue though.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-03-11 20:29

Message:
Logged In: YES 
user_id=80475

I don't think the first part of the sentence is accurate.
MRO conflicts can arise for less straight-forward reasons.
How about:

"Cannot create class.  Superclasses A, B have conflicting 
inheritance trees which leave the method resolution order 
(MRO) undefined."


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

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


From noreply@sourceforge.net  Sun Apr  6 11:54:06 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 06 Apr 2003 03:54:06 -0700
Subject: [Python-bugs-list] [ python-Bugs-712322 ] test_zipimport failing on ia64 (at least)
Message-ID: <E1927mo-0004aA-00@sc8-sf-web4.sourceforge.net>

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

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Neal Norwitz (nnorwitz)
Summary: test_zipimport failing on ia64 (at least)

Initial Comment:
test_zipimport is failing on the snake-farm.  I'm
pretty sure this test worked before.  The only
difference is the file ends in .py vs. .pyc.  I don't
know what changed recently which would have cause this.

http://www.lysator.liu.se/xenofarm/python/files/454_3/python-testlog.txt

test test_zipimport failed -- Traceback (most recent
call last):
  File
"/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/Lib/test/test_zipimport.py",
line 108, in testBoth
    self.doTest(pyc_ext, files, TESTMOD)
  File
"/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/Lib/test/test_zipimport.py",
line 66, in doTest
    self.assertEquals(file, os.path.join(TEMP_ZIP,
  File
"/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/Lib/unittest.py",
line 292, in failUnlessEqual
    raise self.failureException, \
AssertionError:
'/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/junk95142.zip/ziptestmodule.py'
!=
'/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/junk95142.zip/ziptestmodule.pyc'




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

>Comment By: Just van Rossum (jvr)
Date: 2003-04-06 12:54

Message:
Logged In: YES 
user_id=92689

How do we proceed on this one? Shall I just check this change in, and we'll see what happens on other platforms?

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

Comment By: Just van Rossum (jvr)
Date: 2003-04-02 10:26

Message:
Logged In: YES 
user_id=92689

It sure works for OSX!

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-01 22:34

Message:
Logged In: YES 
user_id=33168

Changing the tm_isdst to -1 fixed the problem on HPUX.  I'm
not sure if this will work on all platforms.  -1 means
mktime should guess whether DST is in effect or not.  0
means it's never DST.  I can see problems with any value. 
Perhaps there's some zip documentation which describes what
should be done?  Or perhaps the time (dostime, dosdate) are
encoded incorrectly?

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

Comment By: Just van Rossum (jvr)
Date: 2003-04-01 21:28

Message:
Logged In: YES 
user_id=92689

Found the cause: daylight saving. I think it's a mismatch between zipfile.py's handling of time and zipimport.c's.

I just tested with a manually created zip file and the same problem occurs, so I'm fairly sure the problem is with zipimport's parse_dostime(). The effbot wrote that one for me, but perhaps someone else with the necessary time.h expertise can advise what's wrong?

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

Comment By: Just van Rossum (jvr)
Date: 2003-04-01 20:23

Message:
Logged In: YES 
user_id=92689

Ah, duh, it even fails on OSX, so I can do some research myself.

Wild guess: are the other failing boxes also big endian machines?

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-01 18:05

Message:
Logged In: YES 
user_id=33168

This test is now failing on most unixes.  AIX, HPUX and
others I think.  I tried building some older versions from
3/1, 2/20, etc. but the problem persists.  Even though I
thought those versions worked at the time.  This will take
some time to look into further.  Assigning to me, but
hopefully someone else who also sees this problem can help.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-31 16:32

Message:
Logged In: YES 
user_id=33168

Yes, I believe it worked more recently, but I could be
wrong...  I checked out source from 3/20 and that still
fails, so I have to keep going back until I find exactly
where it failed.  I'll keep trying too.

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

Comment By: Just van Rossum (jvr)
Date: 2003-03-31 16:22

Message:
Logged In: YES 
user_id=92689

dict order should not have relevance to the test. I currently have no idea what could have caused it, and zipimport.c itself hasn't been changed significantly in a while. I see in the logs that in february you fixed some 64-bit issues, but I guess that by "it worked before" you mean something much more recent than that. I'll continue trying to figure out potential causes.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-31 15:33

Message:
Logged In: YES 
user_id=33168

It is also broken on AIX which I do have access to.  I'm
trying to determine what broke it.  One guess is dictionary
order.  I'm not sure if the test relies on .pyc being
written before .py as a result of file.items().  It is
broken on 3/26.  Unfortunately it takes a very long time to
build on these boxes (hours).  Let me know if you have any
idea of what might have recently changed to break zipimports.

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

Comment By: Just van Rossum (jvr)
Date: 2003-03-31 09:40

Message:
Logged In: YES 
user_id=92689

Then how are we/am I supposed to fix this? Assigning to None.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-31 00:32

Message:
Logged In: YES 
user_id=33168

Unfortunately, I don't have access to the boxes where this
is failling.  The only possibility would be in the compaq
(hp) test drive machines.

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

Comment By: Just van Rossum (jvr)
Date: 2003-03-30 23:03

Message:
Logged In: YES 
user_id=92689

Hm, apparently loading from pyc fails. Perhaps a bug with zipimport's pyc magic or mod date checking code?

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

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


From noreply@sourceforge.net  Sun Apr  6 14:35:26 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 06 Apr 2003 06:35:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-699934 ] Obscure error message
Message-ID: <E192AIw-0003yu-00@sc8-sf-web2.sourceforge.net>

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

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Bjorn Pettersen (bpettersen)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Obscure error message

Initial Comment:
>>> class A(object):
...   m = 1
...
>>> class B(A): pass
...
>>> class C(A): pass
...
>>> class D(A,B): pass
...
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: MRO conflict among bases A, B

I happen to know what MRO stands for, but probably 
most people that made the typo I did in the diamond 
inheritance graph will have no idea what they did wrong...

How about "One of the declared superclasses A, B 
inherits from the other, the method resolution order 
(MRO) would therefore be undefined. Cannot create 
class."

-- bjorn


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

>Comment By: Michael Hudson (mwh)
Date: 2003-04-06 14:35

Message:
Logged In: YES 
user_id=6656

I'd say "idea 2".  the issues too complicated to have a hope
of explaining in the error message, so the only hope is to
hand out enough key words to make finding the relavent
section of the docs easy.

I'd also like to say:

The "of course, while I have no problem with this at all,
it's surely too much for a lesser being" flavor of argument
always rings hollow to me. -- Tim Peters, 29 Apr 1998

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-06 11:10

Message:
Logged In: YES 
user_id=80475

Michael, do you have a preference?

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-03-14 06:34

Message:
Logged In: YES 
user_id=80475

Idea 1
------
TypeError: Cannot create class.  
Accessing superclasses A, B in order creates conflicting
inheritance trees which leave the method resolution order 
(MRO) undefined.

Idea 2
------
Cannot create a consistent method resolution order (MRO) 
for bases A, B.

Idea 3
------
Doh!

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

Comment By: Michael Hudson (mwh)
Date: 2003-03-12 13:01

Message:
Logged In: YES 
user_id=6656

Unfortunately the new error message makes no sense when you
get it by rearranging __bases__.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-03-12 04:38

Message:
Logged In: YES 
user_id=80475

Fixed.  See:

Objects/typeobject.c 2.216
Lib/test/test_descr.py 1.187


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

Comment By: Bjorn Pettersen (bpettersen)
Date: 2003-03-12 02:50

Message:
Logged In: YES 
user_id=556638

Even better. If I were to suggest anything, it would be to 
add "(lookup)" after "resolution" since that seems to be the 
more frequently used terminology -- not a big issue though.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-03-12 01:29

Message:
Logged In: YES 
user_id=80475

I don't think the first part of the sentence is accurate.
MRO conflicts can arise for less straight-forward reasons.
How about:

"Cannot create class.  Superclasses A, B have conflicting 
inheritance trees which leave the method resolution order 
(MRO) undefined."


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

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


From noreply@sourceforge.net  Sun Apr  6 20:30:08 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 06 Apr 2003 12:30:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-699934 ] Obscure error message
Message-ID: <E192FqC-0004q8-00@sc8-sf-web3.sourceforge.net>

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

Category: Python Interpreter Core
Group: Python 2.3
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Bjorn Pettersen (bpettersen)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Obscure error message

Initial Comment:
>>> class A(object):
...   m = 1
...
>>> class B(A): pass
...
>>> class C(A): pass
...
>>> class D(A,B): pass
...
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: MRO conflict among bases A, B

I happen to know what MRO stands for, but probably 
most people that made the typo I did in the diamond 
inheritance graph will have no idea what they did wrong...

How about "One of the declared superclasses A, B 
inherits from the other, the method resolution order 
(MRO) would therefore be undefined. Cannot create 
class."

-- bjorn


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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-06 14:30

Message:
Logged In: YES 
user_id=80475

Fixed.

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

Comment By: Michael Hudson (mwh)
Date: 2003-04-06 08:35

Message:
Logged In: YES 
user_id=6656

I'd say "idea 2".  the issues too complicated to have a hope
of explaining in the error message, so the only hope is to
hand out enough key words to make finding the relavent
section of the docs easy.

I'd also like to say:

The "of course, while I have no problem with this at all,
it's surely too much for a lesser being" flavor of argument
always rings hollow to me. -- Tim Peters, 29 Apr 1998

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-06 05:10

Message:
Logged In: YES 
user_id=80475

Michael, do you have a preference?

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-03-14 01:34

Message:
Logged In: YES 
user_id=80475

Idea 1
------
TypeError: Cannot create class.  
Accessing superclasses A, B in order creates conflicting
inheritance trees which leave the method resolution order 
(MRO) undefined.

Idea 2
------
Cannot create a consistent method resolution order (MRO) 
for bases A, B.

Idea 3
------
Doh!

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

Comment By: Michael Hudson (mwh)
Date: 2003-03-12 08:01

Message:
Logged In: YES 
user_id=6656

Unfortunately the new error message makes no sense when you
get it by rearranging __bases__.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-03-11 23:38

Message:
Logged In: YES 
user_id=80475

Fixed.  See:

Objects/typeobject.c 2.216
Lib/test/test_descr.py 1.187


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

Comment By: Bjorn Pettersen (bpettersen)
Date: 2003-03-11 21:50

Message:
Logged In: YES 
user_id=556638

Even better. If I were to suggest anything, it would be to 
add "(lookup)" after "resolution" since that seems to be the 
more frequently used terminology -- not a big issue though.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-03-11 20:29

Message:
Logged In: YES 
user_id=80475

I don't think the first part of the sentence is accurate.
MRO conflicts can arise for less straight-forward reasons.
How about:

"Cannot create class.  Superclasses A, B have conflicting 
inheritance trees which leave the method resolution order 
(MRO) undefined."


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

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


From noreply@sourceforge.net  Mon Apr  7 01:01:20 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 06 Apr 2003 17:01:20 -0700
Subject: [Python-bugs-list] [ python-Bugs-712322 ] test_zipimport failing on ia64 (at least)
Message-ID: <E192K4e-0003x6-00@sc8-sf-web1.sourceforge.net>

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

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Neal Norwitz (nnorwitz)
Summary: test_zipimport failing on ia64 (at least)

Initial Comment:
test_zipimport is failing on the snake-farm.  I'm
pretty sure this test worked before.  The only
difference is the file ends in .py vs. .pyc.  I don't
know what changed recently which would have cause this.

http://www.lysator.liu.se/xenofarm/python/files/454_3/python-testlog.txt

test test_zipimport failed -- Traceback (most recent
call last):
  File
"/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/Lib/test/test_zipimport.py",
line 108, in testBoth
    self.doTest(pyc_ext, files, TESTMOD)
  File
"/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/Lib/test/test_zipimport.py",
line 66, in doTest
    self.assertEquals(file, os.path.join(TEMP_ZIP,
  File
"/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/Lib/unittest.py",
line 292, in failUnlessEqual
    raise self.failureException, \
AssertionError:
'/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/junk95142.zip/ziptestmodule.py'
!=
'/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/junk95142.zip/ziptestmodule.pyc'




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

>Comment By: Tim Peters (tim_one)
Date: 2003-04-06 20:01

Message:
Logged In: YES 
user_id=31435

Noting that DST began in the USA this morning, and 
test_zipimport started failing on Windows immediately 
after.  I don't know what will work across all platforms, but 
you've got ample evidence that what's there now will 
eventually fail on all platforms <wink>.

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

Comment By: Just van Rossum (jvr)
Date: 2003-04-06 06:54

Message:
Logged In: YES 
user_id=92689

How do we proceed on this one? Shall I just check this change in, and we'll see what happens on other platforms?

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

Comment By: Just van Rossum (jvr)
Date: 2003-04-02 03:26

Message:
Logged In: YES 
user_id=92689

It sure works for OSX!

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-01 15:34

Message:
Logged In: YES 
user_id=33168

Changing the tm_isdst to -1 fixed the problem on HPUX.  I'm
not sure if this will work on all platforms.  -1 means
mktime should guess whether DST is in effect or not.  0
means it's never DST.  I can see problems with any value. 
Perhaps there's some zip documentation which describes what
should be done?  Or perhaps the time (dostime, dosdate) are
encoded incorrectly?

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

Comment By: Just van Rossum (jvr)
Date: 2003-04-01 14:28

Message:
Logged In: YES 
user_id=92689

Found the cause: daylight saving. I think it's a mismatch between zipfile.py's handling of time and zipimport.c's.

I just tested with a manually created zip file and the same problem occurs, so I'm fairly sure the problem is with zipimport's parse_dostime(). The effbot wrote that one for me, but perhaps someone else with the necessary time.h expertise can advise what's wrong?

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

Comment By: Just van Rossum (jvr)
Date: 2003-04-01 13:23

Message:
Logged In: YES 
user_id=92689

Ah, duh, it even fails on OSX, so I can do some research myself.

Wild guess: are the other failing boxes also big endian machines?

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-01 11:05

Message:
Logged In: YES 
user_id=33168

This test is now failing on most unixes.  AIX, HPUX and
others I think.  I tried building some older versions from
3/1, 2/20, etc. but the problem persists.  Even though I
thought those versions worked at the time.  This will take
some time to look into further.  Assigning to me, but
hopefully someone else who also sees this problem can help.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-31 09:32

Message:
Logged In: YES 
user_id=33168

Yes, I believe it worked more recently, but I could be
wrong...  I checked out source from 3/20 and that still
fails, so I have to keep going back until I find exactly
where it failed.  I'll keep trying too.

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

Comment By: Just van Rossum (jvr)
Date: 2003-03-31 09:22

Message:
Logged In: YES 
user_id=92689

dict order should not have relevance to the test. I currently have no idea what could have caused it, and zipimport.c itself hasn't been changed significantly in a while. I see in the logs that in february you fixed some 64-bit issues, but I guess that by "it worked before" you mean something much more recent than that. I'll continue trying to figure out potential causes.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-31 08:33

Message:
Logged In: YES 
user_id=33168

It is also broken on AIX which I do have access to.  I'm
trying to determine what broke it.  One guess is dictionary
order.  I'm not sure if the test relies on .pyc being
written before .py as a result of file.items().  It is
broken on 3/26.  Unfortunately it takes a very long time to
build on these boxes (hours).  Let me know if you have any
idea of what might have recently changed to break zipimports.

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

Comment By: Just van Rossum (jvr)
Date: 2003-03-31 02:40

Message:
Logged In: YES 
user_id=92689

Then how are we/am I supposed to fix this? Assigning to None.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-30 17:32

Message:
Logged In: YES 
user_id=33168

Unfortunately, I don't have access to the boxes where this
is failling.  The only possibility would be in the compaq
(hp) test drive machines.

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

Comment By: Just van Rossum (jvr)
Date: 2003-03-30 16:03

Message:
Logged In: YES 
user_id=92689

Hm, apparently loading from pyc fails. Perhaps a bug with zipimport's pyc magic or mod date checking code?

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

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


From noreply@sourceforge.net  Mon Apr  7 07:07:19 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 06 Apr 2003 23:07:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-712322 ] test_zipimport failing on ia64 (at least)
Message-ID: <E192Pmp-00064e-00@sc8-sf-web1.sourceforge.net>

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

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Neal Norwitz (nnorwitz)
Summary: test_zipimport failing on ia64 (at least)

Initial Comment:
test_zipimport is failing on the snake-farm.  I'm
pretty sure this test worked before.  The only
difference is the file ends in .py vs. .pyc.  I don't
know what changed recently which would have cause this.

http://www.lysator.liu.se/xenofarm/python/files/454_3/python-testlog.txt

test test_zipimport failed -- Traceback (most recent
call last):
  File
"/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/Lib/test/test_zipimport.py",
line 108, in testBoth
    self.doTest(pyc_ext, files, TESTMOD)
  File
"/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/Lib/test/test_zipimport.py",
line 66, in doTest
    self.assertEquals(file, os.path.join(TEMP_ZIP,
  File
"/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/Lib/unittest.py",
line 292, in failUnlessEqual
    raise self.failureException, \
AssertionError:
'/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/junk95142.zip/ziptestmodule.py'
!=
'/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/junk95142.zip/ziptestmodule.pyc'




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

>Comment By: Just van Rossum (jvr)
Date: 2003-04-07 08:07

Message:
Logged In: YES 
user_id=92689

Glad we didn't fix it sooner, then ;-)

Can you verify whether changing
    tm_isdst = 0;
to
    tm_isdst = -1;
(somewhere in zipimport.c)

Helps on Windows, too?

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

Comment By: Tim Peters (tim_one)
Date: 2003-04-07 02:01

Message:
Logged In: YES 
user_id=31435

Noting that DST began in the USA this morning, and 
test_zipimport started failing on Windows immediately 
after.  I don't know what will work across all platforms, but 
you've got ample evidence that what's there now will 
eventually fail on all platforms <wink>.

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

Comment By: Just van Rossum (jvr)
Date: 2003-04-06 12:54

Message:
Logged In: YES 
user_id=92689

How do we proceed on this one? Shall I just check this change in, and we'll see what happens on other platforms?

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

Comment By: Just van Rossum (jvr)
Date: 2003-04-02 10:26

Message:
Logged In: YES 
user_id=92689

It sure works for OSX!

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-01 22:34

Message:
Logged In: YES 
user_id=33168

Changing the tm_isdst to -1 fixed the problem on HPUX.  I'm
not sure if this will work on all platforms.  -1 means
mktime should guess whether DST is in effect or not.  0
means it's never DST.  I can see problems with any value. 
Perhaps there's some zip documentation which describes what
should be done?  Or perhaps the time (dostime, dosdate) are
encoded incorrectly?

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

Comment By: Just van Rossum (jvr)
Date: 2003-04-01 21:28

Message:
Logged In: YES 
user_id=92689

Found the cause: daylight saving. I think it's a mismatch between zipfile.py's handling of time and zipimport.c's.

I just tested with a manually created zip file and the same problem occurs, so I'm fairly sure the problem is with zipimport's parse_dostime(). The effbot wrote that one for me, but perhaps someone else with the necessary time.h expertise can advise what's wrong?

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

Comment By: Just van Rossum (jvr)
Date: 2003-04-01 20:23

Message:
Logged In: YES 
user_id=92689

Ah, duh, it even fails on OSX, so I can do some research myself.

Wild guess: are the other failing boxes also big endian machines?

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-01 18:05

Message:
Logged In: YES 
user_id=33168

This test is now failing on most unixes.  AIX, HPUX and
others I think.  I tried building some older versions from
3/1, 2/20, etc. but the problem persists.  Even though I
thought those versions worked at the time.  This will take
some time to look into further.  Assigning to me, but
hopefully someone else who also sees this problem can help.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-31 16:32

Message:
Logged In: YES 
user_id=33168

Yes, I believe it worked more recently, but I could be
wrong...  I checked out source from 3/20 and that still
fails, so I have to keep going back until I find exactly
where it failed.  I'll keep trying too.

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

Comment By: Just van Rossum (jvr)
Date: 2003-03-31 16:22

Message:
Logged In: YES 
user_id=92689

dict order should not have relevance to the test. I currently have no idea what could have caused it, and zipimport.c itself hasn't been changed significantly in a while. I see in the logs that in february you fixed some 64-bit issues, but I guess that by "it worked before" you mean something much more recent than that. I'll continue trying to figure out potential causes.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-31 15:33

Message:
Logged In: YES 
user_id=33168

It is also broken on AIX which I do have access to.  I'm
trying to determine what broke it.  One guess is dictionary
order.  I'm not sure if the test relies on .pyc being
written before .py as a result of file.items().  It is
broken on 3/26.  Unfortunately it takes a very long time to
build on these boxes (hours).  Let me know if you have any
idea of what might have recently changed to break zipimports.

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

Comment By: Just van Rossum (jvr)
Date: 2003-03-31 09:40

Message:
Logged In: YES 
user_id=92689

Then how are we/am I supposed to fix this? Assigning to None.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-31 00:32

Message:
Logged In: YES 
user_id=33168

Unfortunately, I don't have access to the boxes where this
is failling.  The only possibility would be in the compaq
(hp) test drive machines.

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

Comment By: Just van Rossum (jvr)
Date: 2003-03-30 23:03

Message:
Logged In: YES 
user_id=92689

Hm, apparently loading from pyc fails. Perhaps a bug with zipimport's pyc magic or mod date checking code?

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

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


From noreply@sourceforge.net  Mon Apr  7 07:56:15 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 06 Apr 2003 23:56:15 -0700
Subject: [Python-bugs-list] [ python-Bugs-716587 ] profile.run makes assumption regarding namespace
Message-ID: <E192QYB-0000RT-00@sc8-sf-web3.sourceforge.net>

Bugs item #716587, was opened at 2003-04-07 00:56
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=716587&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Fortune (gregfortune)
Assigned to: Nobody/Anonymous (nobody)
Summary: profile.run makes assumption regarding namespace

Initial Comment:
When profile.run() is executed, it assumes that the local 
and global namespace should be determined from the 
locals and globals for __main__.  In the case of an 
embedded interpreter, this is an annoying assumption.

For instance, I have a PyQt program that has an 
embedded interpreter running as a "debug" console and 
need to profile a little segement of misbehaving code.  
With direct access to all the gui interactively, it seemed 
like a simple task of profiling a function call on one of my 
gui elements, but the namespace in the interpreter is very 
different from that of the main application.

A simple fix is to allow profile.run to be executed with an 
optional dict so the user can give their own namespace.  
A diff -u is attached which accomplishes this.

Note that this problem appears in the current Python CVS 
on sourceforge, but exists at least as early as Python 2.2.


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

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


From noreply@sourceforge.net  Mon Apr  7 10:13:15 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 07 Apr 2003 02:13:15 -0700
Subject: [Python-bugs-list] [ python-Bugs-716634 ] "build_ext" "libraries" subcommand not split into values
Message-ID: <E192Sgl-00069m-00@sc8-sf-web1.sourceforge.net>

Bugs item #716634, was opened at 2003-04-07 09:13
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=716634&group_id=5470

Category: Distutils
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Dieter Maurer (dmaurer)
Assigned to: Nobody/Anonymous (nobody)
Summary: "build_ext" "libraries" subcommand not split into values

Initial Comment:
The "libraries" command for "build_ext" is definitely one that 
should accept multiple libraries. However, 
this is impossible for both the command line 
as well as the configuration file. 
 
Patch attached. 

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

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


From noreply@sourceforge.net  Mon Apr  7 13:23:09 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 07 Apr 2003 05:23:09 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-661203 ] sigprocmask: None argument
Message-ID: <E192VeX-0003yX-00@sc8-sf-web4.sourceforge.net>

Feature Requests item #661203, was opened at 2003-01-02 17:38
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=661203&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Michael Pomraning (pilcrow)
Assigned to: Michael Hudson (mwh)
Summary: sigprocmask: None argument

Initial Comment:
signal.sigprocmask ought allow a None argument instead
of a signal sequence:

  a)  cur_mask = signal.sigprocmask(any_but_SETMASK, [])
     # sigprocmask(how, &empty_set, &cur_mask)

  b)  cur_mask = signal.sigprocmask(dummy, None)
     # sigprocmask(dummy, NULL, &cur_mask)

"a" is slightly more work for the kernel, and permits
accidental SETMASKing.  "b" avoids both, and is
comfortably analogous to the familiar, ugly C interface
(as opposed to, say, cur_mask = signal.sigprocmask()).


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

>Comment By: Michael Hudson (mwh)
Date: 2003-04-07 13:23

Message:
Logged In: YES 
user_id=6656

I've withdrawn the sigprocmask code from CVS, so this
feature request no longer applies.

Sorry.

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

Comment By: Michael Pomraning (pilcrow)
Date: 2003-01-06 14:28

Message:
Logged In: YES 
user_id=679184

linux 2.4; x86.

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

Comment By: Michael Hudson (mwh)
Date: 2003-01-03 12:01

Message:
Logged In: YES 
user_id=6656

Sounds fair enough.

Should warn you that the sigmask stuff is currently not
being compiled owing to unpleasantly exciting x-platform
behaviour.  I ought to do something about that, too.

What platform are you on?

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

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


From noreply@sourceforge.net  Mon Apr  7 13:31:00 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 07 Apr 2003 05:31:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-716587 ] profile.run makes assumption regarding namespace
Message-ID: <E192Vm8-0007Ow-00@sc8-sf-web3.sourceforge.net>

Bugs item #716587, was opened at 2003-04-07 07:56
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=716587&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Fortune (gregfortune)
Assigned to: Nobody/Anonymous (nobody)
Summary: profile.run makes assumption regarding namespace

Initial Comment:
When profile.run() is executed, it assumes that the local 
and global namespace should be determined from the 
locals and globals for __main__.  In the case of an 
embedded interpreter, this is an annoying assumption.

For instance, I have a PyQt program that has an 
embedded interpreter running as a "debug" console and 
need to profile a little segement of misbehaving code.  
With direct access to all the gui interactively, it seemed 
like a simple task of profiling a function call on one of my 
gui elements, but the namespace in the interpreter is very 
different from that of the main application.

A simple fix is to allow profile.run to be executed with an 
optional dict so the user can give their own namespace.  
A diff -u is attached which accomplishes this.

Note that this problem appears in the current Python CVS 
on sourceforge, but exists at least as early as Python 2.2.


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

Comment By: Michael Hudson (mwh)
Date: 2003-04-07 13:31

Message:
Logged In: YES 
user_id=6656

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

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

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


From noreply@sourceforge.net  Mon Apr  7 15:36:31 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 07 Apr 2003 07:36:31 -0700
Subject: [Python-bugs-list] [ python-Bugs-712322 ] test_zipimport failing on ia64 (at least)
Message-ID: <E192Xjb-0004f8-00@sc8-sf-web3.sourceforge.net>

Bugs item #712322, was opened at 2003-03-30 15:32
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=712322&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Neal Norwitz (nnorwitz)
Summary: test_zipimport failing on ia64 (at least)

Initial Comment:
test_zipimport is failing on the snake-farm.  I'm
pretty sure this test worked before.  The only
difference is the file ends in .py vs. .pyc.  I don't
know what changed recently which would have cause this.

http://www.lysator.liu.se/xenofarm/python/files/454_3/python-testlog.txt

test test_zipimport failed -- Traceback (most recent
call last):
  File
"/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/Lib/test/test_zipimport.py",
line 108, in testBoth
    self.doTest(pyc_ext, files, TESTMOD)
  File
"/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/Lib/test/test_zipimport.py",
line 66, in doTest
    self.assertEquals(file, os.path.join(TEMP_ZIP,
  File
"/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/Lib/unittest.py",
line 292, in failUnlessEqual
    raise self.failureException, \
AssertionError:
'/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/junk95142.zip/ziptestmodule.py'
!=
'/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/junk95142.zip/ziptestmodule.pyc'




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

>Comment By: Tim Peters (tim_one)
Date: 2003-04-07 10:36

Message:
Logged In: YES 
user_id=31435

Setting tm_isdst to -1 does fix the test on Windows, now that 
it's DST here.  I can't say whether it would also have left the 
test working before DST kicked in yesterday, but am happy 
to assume that it would:  with any luck, I'll die before October, 
and then fixing it on Windows will be somebody else's 
headache <wink>.

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

Comment By: Just van Rossum (jvr)
Date: 2003-04-07 02:07

Message:
Logged In: YES 
user_id=92689

Glad we didn't fix it sooner, then ;-)

Can you verify whether changing
    tm_isdst = 0;
to
    tm_isdst = -1;
(somewhere in zipimport.c)

Helps on Windows, too?

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

Comment By: Tim Peters (tim_one)
Date: 2003-04-06 20:01

Message:
Logged In: YES 
user_id=31435

Noting that DST began in the USA this morning, and 
test_zipimport started failing on Windows immediately 
after.  I don't know what will work across all platforms, but 
you've got ample evidence that what's there now will 
eventually fail on all platforms <wink>.

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

Comment By: Just van Rossum (jvr)
Date: 2003-04-06 06:54

Message:
Logged In: YES 
user_id=92689

How do we proceed on this one? Shall I just check this change in, and we'll see what happens on other platforms?

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

Comment By: Just van Rossum (jvr)
Date: 2003-04-02 03:26

Message:
Logged In: YES 
user_id=92689

It sure works for OSX!

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-01 15:34

Message:
Logged In: YES 
user_id=33168

Changing the tm_isdst to -1 fixed the problem on HPUX.  I'm
not sure if this will work on all platforms.  -1 means
mktime should guess whether DST is in effect or not.  0
means it's never DST.  I can see problems with any value. 
Perhaps there's some zip documentation which describes what
should be done?  Or perhaps the time (dostime, dosdate) are
encoded incorrectly?

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

Comment By: Just van Rossum (jvr)
Date: 2003-04-01 14:28

Message:
Logged In: YES 
user_id=92689

Found the cause: daylight saving. I think it's a mismatch between zipfile.py's handling of time and zipimport.c's.

I just tested with a manually created zip file and the same problem occurs, so I'm fairly sure the problem is with zipimport's parse_dostime(). The effbot wrote that one for me, but perhaps someone else with the necessary time.h expertise can advise what's wrong?

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

Comment By: Just van Rossum (jvr)
Date: 2003-04-01 13:23

Message:
Logged In: YES 
user_id=92689

Ah, duh, it even fails on OSX, so I can do some research myself.

Wild guess: are the other failing boxes also big endian machines?

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-01 11:05

Message:
Logged In: YES 
user_id=33168

This test is now failing on most unixes.  AIX, HPUX and
others I think.  I tried building some older versions from
3/1, 2/20, etc. but the problem persists.  Even though I
thought those versions worked at the time.  This will take
some time to look into further.  Assigning to me, but
hopefully someone else who also sees this problem can help.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-31 09:32

Message:
Logged In: YES 
user_id=33168

Yes, I believe it worked more recently, but I could be
wrong...  I checked out source from 3/20 and that still
fails, so I have to keep going back until I find exactly
where it failed.  I'll keep trying too.

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

Comment By: Just van Rossum (jvr)
Date: 2003-03-31 09:22

Message:
Logged In: YES 
user_id=92689

dict order should not have relevance to the test. I currently have no idea what could have caused it, and zipimport.c itself hasn't been changed significantly in a while. I see in the logs that in february you fixed some 64-bit issues, but I guess that by "it worked before" you mean something much more recent than that. I'll continue trying to figure out potential causes.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-31 08:33

Message:
Logged In: YES 
user_id=33168

It is also broken on AIX which I do have access to.  I'm
trying to determine what broke it.  One guess is dictionary
order.  I'm not sure if the test relies on .pyc being
written before .py as a result of file.items().  It is
broken on 3/26.  Unfortunately it takes a very long time to
build on these boxes (hours).  Let me know if you have any
idea of what might have recently changed to break zipimports.

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

Comment By: Just van Rossum (jvr)
Date: 2003-03-31 02:40

Message:
Logged In: YES 
user_id=92689

Then how are we/am I supposed to fix this? Assigning to None.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-30 17:32

Message:
Logged In: YES 
user_id=33168

Unfortunately, I don't have access to the boxes where this
is failling.  The only possibility would be in the compaq
(hp) test drive machines.

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

Comment By: Just van Rossum (jvr)
Date: 2003-03-30 16:03

Message:
Logged In: YES 
user_id=92689

Hm, apparently loading from pyc fails. Perhaps a bug with zipimport's pyc magic or mod date checking code?

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

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


From noreply@sourceforge.net  Mon Apr  7 15:36:19 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 07 Apr 2003 07:36:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-716587 ] profile.run makes assumption regarding namespace
Message-ID: <E192XjP-0002dB-00@sc8-sf-web2.sourceforge.net>

Bugs item #716587, was opened at 2003-04-07 00:56
Message generated for change (Comment added) made by gregfortune
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=716587&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Fortune (gregfortune)
Assigned to: Nobody/Anonymous (nobody)
Summary: profile.run makes assumption regarding namespace

Initial Comment:
When profile.run() is executed, it assumes that the local 
and global namespace should be determined from the 
locals and globals for __main__.  In the case of an 
embedded interpreter, this is an annoying assumption.

For instance, I have a PyQt program that has an 
embedded interpreter running as a "debug" console and 
need to profile a little segement of misbehaving code.  
With direct access to all the gui interactively, it seemed 
like a simple task of profiling a function call on one of my 
gui elements, but the namespace in the interpreter is very 
different from that of the main application.

A simple fix is to allow profile.run to be executed with an 
optional dict so the user can give their own namespace.  
A diff -u is attached which accomplishes this.

Note that this problem appears in the current Python CVS 
on sourceforge, but exists at least as early as Python 2.2.


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

>Comment By: Greg Fortune (gregfortune)
Date: 2003-04-07 08:36

Message:
Logged In: YES 
user_id=155459

Doh, sorry about that.  Guess I should actually check it after I 
submit...


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

Comment By: Michael Hudson (mwh)
Date: 2003-04-07 06:31

Message:
Logged In: YES 
user_id=6656

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

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

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


From noreply@sourceforge.net  Mon Apr  7 16:06:27 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 07 Apr 2003 08:06:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-712322 ] test_zipimport failing on ia64 (at least)
Message-ID: <E192YCZ-0005EG-00@sc8-sf-web2.sourceforge.net>

Bugs item #712322, was opened at 2003-03-30 15:32
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=712322&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
>Assigned to: Just van Rossum (jvr)
Summary: test_zipimport failing on ia64 (at least)

Initial Comment:
test_zipimport is failing on the snake-farm.  I'm
pretty sure this test worked before.  The only
difference is the file ends in .py vs. .pyc.  I don't
know what changed recently which would have cause this.

http://www.lysator.liu.se/xenofarm/python/files/454_3/python-testlog.txt

test test_zipimport failed -- Traceback (most recent
call last):
  File
"/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/Lib/test/test_zipimport.py",
line 108, in testBoth
    self.doTest(pyc_ext, files, TESTMOD)
  File
"/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/Lib/test/test_zipimport.py",
line 66, in doTest
    self.assertEquals(file, os.path.join(TEMP_ZIP,
  File
"/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/Lib/unittest.py",
line 292, in failUnlessEqual
    raise self.failureException, \
AssertionError:
'/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/junk95142.zip/ziptestmodule.py'
!=
'/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/junk95142.zip/ziptestmodule.pyc'




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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-07 11:06

Message:
Logged In: YES 
user_id=33168

I agree, let's do the -1 now.  I'll check in later, unless
Just beats me to it.

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

Comment By: Tim Peters (tim_one)
Date: 2003-04-07 10:36

Message:
Logged In: YES 
user_id=31435

Setting tm_isdst to -1 does fix the test on Windows, now that 
it's DST here.  I can't say whether it would also have left the 
test working before DST kicked in yesterday, but am happy 
to assume that it would:  with any luck, I'll die before October, 
and then fixing it on Windows will be somebody else's 
headache <wink>.

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

Comment By: Just van Rossum (jvr)
Date: 2003-04-07 02:07

Message:
Logged In: YES 
user_id=92689

Glad we didn't fix it sooner, then ;-)

Can you verify whether changing
    tm_isdst = 0;
to
    tm_isdst = -1;
(somewhere in zipimport.c)

Helps on Windows, too?

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

Comment By: Tim Peters (tim_one)
Date: 2003-04-06 20:01

Message:
Logged In: YES 
user_id=31435

Noting that DST began in the USA this morning, and 
test_zipimport started failing on Windows immediately 
after.  I don't know what will work across all platforms, but 
you've got ample evidence that what's there now will 
eventually fail on all platforms <wink>.

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

Comment By: Just van Rossum (jvr)
Date: 2003-04-06 06:54

Message:
Logged In: YES 
user_id=92689

How do we proceed on this one? Shall I just check this change in, and we'll see what happens on other platforms?

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

Comment By: Just van Rossum (jvr)
Date: 2003-04-02 03:26

Message:
Logged In: YES 
user_id=92689

It sure works for OSX!

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-01 15:34

Message:
Logged In: YES 
user_id=33168

Changing the tm_isdst to -1 fixed the problem on HPUX.  I'm
not sure if this will work on all platforms.  -1 means
mktime should guess whether DST is in effect or not.  0
means it's never DST.  I can see problems with any value. 
Perhaps there's some zip documentation which describes what
should be done?  Or perhaps the time (dostime, dosdate) are
encoded incorrectly?

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

Comment By: Just van Rossum (jvr)
Date: 2003-04-01 14:28

Message:
Logged In: YES 
user_id=92689

Found the cause: daylight saving. I think it's a mismatch between zipfile.py's handling of time and zipimport.c's.

I just tested with a manually created zip file and the same problem occurs, so I'm fairly sure the problem is with zipimport's parse_dostime(). The effbot wrote that one for me, but perhaps someone else with the necessary time.h expertise can advise what's wrong?

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

Comment By: Just van Rossum (jvr)
Date: 2003-04-01 13:23

Message:
Logged In: YES 
user_id=92689

Ah, duh, it even fails on OSX, so I can do some research myself.

Wild guess: are the other failing boxes also big endian machines?

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-01 11:05

Message:
Logged In: YES 
user_id=33168

This test is now failing on most unixes.  AIX, HPUX and
others I think.  I tried building some older versions from
3/1, 2/20, etc. but the problem persists.  Even though I
thought those versions worked at the time.  This will take
some time to look into further.  Assigning to me, but
hopefully someone else who also sees this problem can help.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-31 09:32

Message:
Logged In: YES 
user_id=33168

Yes, I believe it worked more recently, but I could be
wrong...  I checked out source from 3/20 and that still
fails, so I have to keep going back until I find exactly
where it failed.  I'll keep trying too.

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

Comment By: Just van Rossum (jvr)
Date: 2003-03-31 09:22

Message:
Logged In: YES 
user_id=92689

dict order should not have relevance to the test. I currently have no idea what could have caused it, and zipimport.c itself hasn't been changed significantly in a while. I see in the logs that in february you fixed some 64-bit issues, but I guess that by "it worked before" you mean something much more recent than that. I'll continue trying to figure out potential causes.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-31 08:33

Message:
Logged In: YES 
user_id=33168

It is also broken on AIX which I do have access to.  I'm
trying to determine what broke it.  One guess is dictionary
order.  I'm not sure if the test relies on .pyc being
written before .py as a result of file.items().  It is
broken on 3/26.  Unfortunately it takes a very long time to
build on these boxes (hours).  Let me know if you have any
idea of what might have recently changed to break zipimports.

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

Comment By: Just van Rossum (jvr)
Date: 2003-03-31 02:40

Message:
Logged In: YES 
user_id=92689

Then how are we/am I supposed to fix this? Assigning to None.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-30 17:32

Message:
Logged In: YES 
user_id=33168

Unfortunately, I don't have access to the boxes where this
is failling.  The only possibility would be in the compaq
(hp) test drive machines.

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

Comment By: Just van Rossum (jvr)
Date: 2003-03-30 16:03

Message:
Logged In: YES 
user_id=92689

Hm, apparently loading from pyc fails. Perhaps a bug with zipimport's pyc magic or mod date checking code?

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

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


From noreply@sourceforge.net  Mon Apr  7 19:29:07 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 07 Apr 2003 11:29:07 -0700
Subject: [Python-bugs-list] [ python-Bugs-712975 ] Cannot change the class of a list
Message-ID: <E192bMh-0006JL-00@sc8-sf-web3.sourceforge.net>

Bugs item #712975, was opened at 2003-03-31 17:00
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=712975&group_id=5470

Category: Type/class unification
Group: Python 2.3
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Jiba (jiba)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Cannot change the class of a list

Initial Comment:
The class of list (or dict) can no longer be changed in
Python 2.3a2 ; this was possible with Python 2.2.2 (as
long as the new class extend list and has no slot).
When doing so ([].__class__ = ...), i get this error :

TypeError: __class__ assignment: only for heap types


Not being able to change the class of non-mutable
object (e.g. int, float or tuple) is AMHO not a great
loss, but list and dict ARE mutable, and so changing
their class does have a sens !

Typically it can be used to observed a list that you
have not created yourself (see atteched script); i was
relying a lot on such observation features.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-07 14:29

Message:
Logged In: YES 
user_id=6380

The reason for the restriction is not (im)mutability, but
the fact that many built-in types have (or can have)
non-standard (de)allocators. A subclass of a built-in type
doesn't necessarily have the same deallocator. If someone
can come up with a patch *AND* a proof that the patch is
correct, I'll consider it, but I'd rather be safe than
sorry. Until then, I'll close this as "won't fix".

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

Comment By: Michael Hudson (mwh)
Date: 2003-04-01 05:30

Message:
Logged In: YES 
user_id=6656

IMHO, changing the class of an immutable object is, was and
always will be Right Out.

Changing the class of a mutable is dicier.  I personally
don't think it's worth the effort, but assigning to Guido
for pronouncement.

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

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


From noreply@sourceforge.net  Mon Apr  7 22:09:53 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 07 Apr 2003 14:09:53 -0700
Subject: [Python-bugs-list] [ python-Bugs-714733 ] cPickle fails to pickle inf
Message-ID: <E192dsH-0001JI-00@sc8-sf-web4.sourceforge.net>

Bugs item #714733, was opened at 2003-04-03 11:44
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=714733&group_id=5470

Category: Python Library
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Kochanski (gpk)
Assigned to: Nobody/Anonymous (nobody)
Summary: cPickle fails to pickle inf

Initial Comment:
cPickle fails, and throws an exception when
you ask it to pickle infinity, and cPickle
is set for binary mode.

See example:

gpk* python2.2
Python 2.2.1 (#1, Jul 29 2002, 23:15:49) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> x = float("Inf")
>>> x
inf
>>> import cPickle
>>> import sys      
>>> cPickle.dump(x, sys.stdout)
Finf
.>>> cPickle.dump(x, sys.stdout, 1)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
SystemError: frexp() result out of range
>>> 


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

>Comment By: Tim Peters (tim_one)
Date: 2003-04-07 17:09

Message:
Logged In: YES 
user_id=31435

It's true that pickle doesn't know what to do with an infinity.  
Ditto the struct module.  It also doesn't know what to do with 
a NaN, and doesn't preserve the sign of -0.0.  This has 
always been so; Python doesn't know anything about 754's 
special values.

Note that it's a platform-dependent accident that float("inf") 
didn't raise an exception.  What the platform frexp() does 
when passed an infinity is also left undefined by C89.

In short, Python has no 754 story:  anything that works, or 
doesn't work, wrt infinities, NaNs, and signed zeroes is an 
accident.  About once a year, someone says they're going to 
volunteer work to improve this.  So far, it hasn't happened.  
Until it does, you're simply out of luck.

This should probably be changed to a feature request.

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

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


From noreply@sourceforge.net  Mon Apr  7 23:46:55 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 07 Apr 2003 15:46:55 -0700
Subject: [Python-bugs-list] [ python-Bugs-715063 ] bsddb.first()/next() raise undocumented exception
Message-ID: <E192fOB-0002PJ-00@sc8-sf-web1.sourceforge.net>

Bugs item #715063, was opened at 2003-04-03 23:03
Message generated for change (Comment added) made by bwarsaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=715063&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Christian Stork (cst)
Assigned to: Nobody/Anonymous (nobody)
Summary: bsddb.first()/next() raise undocumented exception

Initial Comment:
bsddb object's first() & next() methods raise an undocumented 
exception.  Wouldn't returning None make much more sense?  
And shouldn't this be documented? 

Python 2.3a2+ (#2, Mar 21 2003, 22:13:05) 
[GCC 3.2.3 20030316 (Debian prerelease)] on linux2
>>> import bsddb
>>> h.bsddb.hashopen("testdb")
>>> h.first()
------------------------------------------------------------
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.3/bsddb/__init__.py", line 134, in first
    rv = self.dbc.first()
DBNotFoundError: (-30991, 'DB_NOTFOUND: No matching key/
data pair found')

Note: The same exception appeared for the equivalent dbhash 
methods.  But I assume this should be fixed if this bug is fixed.

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

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-04-07 18:46

Message:
Logged In: YES 
user_id=12800

pybsddb has this option to return None from cursor.get()
methods instead of raising DBNotFoundError.  The DBEnv
method set_get_returns_none() can be used to change the
behavior, although the default is to return None.  I agree
that this is very handy!

I suppose .first() and .last() should perhaps honor this
config as well?


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

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


From noreply@sourceforge.net  Tue Apr  8 03:37:27 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 07 Apr 2003 19:37:27 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-706392 ] faster _socket.connect variant desired
Message-ID: <E192izH-0005c7-00@sc8-sf-web2.sourceforge.net>

Feature Requests item #706392, was opened at 2003-03-19 11:14
Message generated for change (Comment added) made by mendenhall
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=706392&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Marcus Mendenhall (mendenhall)
Assigned to: Nobody/Anonymous (nobody)
Summary: faster _socket.connect variant desired

Initial Comment:
The  _socket.connect() call is not quite semantically equivalent to the underlying bsd connect() call in that it always parses an internet address.  This process can be quite slow, since it attempts to determine names and cnames (etc) using getaddrinfo(), which may require DNS lookups to complete.  In an environment where many sockets are being connected and disconnected, this is expensive.  

I would like to propose two minor additions to the _socket module:

1) A python wrapper to the internal getsockaddrarg(), allowing a fully processed socket address to be returned as a string

2) a connect_raw_address() call which is a pure wrapper to the bsd connect() call, and which assumes it is passed a string from getsockaddrarg().

This would allow a socket to be disconnected and reconnected many times to the same address, but with much less network chatter and OS overhead.  Effectively, I would like an unbundled version of _socket.connect(), with each of the two processes it uses able to be carried out independently.  

This is also useful in environments where one is communicating on aprivate network which is connected to the outside world over a (for example) PPP or PPPoE link.  Internal traffic handled through this connect will not result in gratuitous DNS traffic which will keep the link from ever closing.

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

>Comment By: Marcus Mendenhall (mendenhall)
Date: 2003-04-07 21:37

Message:
Logged In: YES 
user_id=470295

Fater thiunking about what I have done with this patch, I would also like to suggest another change (for which I am also willing to submit the patch, which is quite simple):  Consistent with some of the already extant glue in _socet to handle addresses like <broadcast>, would there be any reason no to modify setipaddr() and getaddrinfo() so that if an address is prefixed with <numeric> (e.g. <numeric>127.0.0.1) that the PASSIVE and NUMERIC flags are always set so these routines reject any non-numeric address, but handle numeric ones very efficiently?

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

Comment By: Marcus Mendenhall (mendenhall)
Date: 2003-04-04 07:29

Message:
Logged In: YES 
user_id=470295

OK, I followed your suggestion and made a very lightweight type sockaddr, which has only a constructor, a destructor, and a method called to_tuple() which allows one to get the data out for reconstruction.  I have included, I think, decent docstrings, but haven't patched any of the main Python doc tree.  If you look at the top of getsockaddrarg(), this is the _only_ place this new type interacts with the rest of the _socket module.  Here is a prototype patch.  I have tried it a bit, and I think it works and is safe.  If you have any comments, please let me know.

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

Comment By: Marcus Mendenhall (mendenhall)
Date: 2003-03-30 14:34

Message:
Logged In: YES 
user_id=470295

Aha, now I see what you are suggesting.  I didn't quite understand what you intended before.  This (wrapping sockaddr and having connect check for the wrapped object) sounds like a very plausible idea.  I will consider strongly doing it this way.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-29 11:35

Message:
Logged In: YES 
user_id=21627

Providing a wrapper would allow to reuse the connect
operation, as it could check whether the argument is the
wrapper. If you prefer to use plain strings and a separate
function: that would be fine as well.

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

Comment By: Marcus Mendenhall (mendenhall)
Date: 2003-03-29 11:16

Message:
Logged In: YES 
user_id=470295

Does it really require wrapping sockaddr?  It seems that returning an opaque string containing the data returned by getsockaddrarg that can be passed to the new connect_arw (or whatever) is sufficient.  There doesn't need to be any way to access/mess with the data in this string, since its format is whatever the underlying unix utilities return, and varies by socket address family, etc, but it only needs to be able to be passed blindly to connect.  

Anyway, I would be glad to provide a patch to provide the other routines.    

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-29 09:08

Message:
Logged In: YES 
user_id=21627

I think this requires creating a struct sockaddr wrapper
object. Would you be interested in developing a patch?

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

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


From noreply@sourceforge.net  Tue Apr  8 03:39:53 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 07 Apr 2003 19:39:53 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-706392 ] faster _socket.connect variant desired
Message-ID: <E192j1d-0000Pm-00@sc8-sf-web3.sourceforge.net>

Feature Requests item #706392, was opened at 2003-03-19 11:14
Message generated for change (Comment added) made by mendenhall
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=706392&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Marcus Mendenhall (mendenhall)
Assigned to: Nobody/Anonymous (nobody)
Summary: faster _socket.connect variant desired

Initial Comment:
The  _socket.connect() call is not quite semantically equivalent to the underlying bsd connect() call in that it always parses an internet address.  This process can be quite slow, since it attempts to determine names and cnames (etc) using getaddrinfo(), which may require DNS lookups to complete.  In an environment where many sockets are being connected and disconnected, this is expensive.  

I would like to propose two minor additions to the _socket module:

1) A python wrapper to the internal getsockaddrarg(), allowing a fully processed socket address to be returned as a string

2) a connect_raw_address() call which is a pure wrapper to the bsd connect() call, and which assumes it is passed a string from getsockaddrarg().

This would allow a socket to be disconnected and reconnected many times to the same address, but with much less network chatter and OS overhead.  Effectively, I would like an unbundled version of _socket.connect(), with each of the two processes it uses able to be carried out independently.  

This is also useful in environments where one is communicating on aprivate network which is connected to the outside world over a (for example) PPP or PPPoE link.  Internal traffic handled through this connect will not result in gratuitous DNS traffic which will keep the link from ever closing.

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

>Comment By: Marcus Mendenhall (mendenhall)
Date: 2003-04-07 21:39

Message:
Logged In: YES 
user_id=470295

Wow, my typing on the previous comment was incredible... it was supposed to start "After thinking..."

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

Comment By: Marcus Mendenhall (mendenhall)
Date: 2003-04-07 21:37

Message:
Logged In: YES 
user_id=470295

Fater thiunking about what I have done with this patch, I would also like to suggest another change (for which I am also willing to submit the patch, which is quite simple):  Consistent with some of the already extant glue in _socet to handle addresses like <broadcast>, would there be any reason no to modify setipaddr() and getaddrinfo() so that if an address is prefixed with <numeric> (e.g. <numeric>127.0.0.1) that the PASSIVE and NUMERIC flags are always set so these routines reject any non-numeric address, but handle numeric ones very efficiently?

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

Comment By: Marcus Mendenhall (mendenhall)
Date: 2003-04-04 07:29

Message:
Logged In: YES 
user_id=470295

OK, I followed your suggestion and made a very lightweight type sockaddr, which has only a constructor, a destructor, and a method called to_tuple() which allows one to get the data out for reconstruction.  I have included, I think, decent docstrings, but haven't patched any of the main Python doc tree.  If you look at the top of getsockaddrarg(), this is the _only_ place this new type interacts with the rest of the _socket module.  Here is a prototype patch.  I have tried it a bit, and I think it works and is safe.  If you have any comments, please let me know.

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

Comment By: Marcus Mendenhall (mendenhall)
Date: 2003-03-30 14:34

Message:
Logged In: YES 
user_id=470295

Aha, now I see what you are suggesting.  I didn't quite understand what you intended before.  This (wrapping sockaddr and having connect check for the wrapped object) sounds like a very plausible idea.  I will consider strongly doing it this way.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-29 11:35

Message:
Logged In: YES 
user_id=21627

Providing a wrapper would allow to reuse the connect
operation, as it could check whether the argument is the
wrapper. If you prefer to use plain strings and a separate
function: that would be fine as well.

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

Comment By: Marcus Mendenhall (mendenhall)
Date: 2003-03-29 11:16

Message:
Logged In: YES 
user_id=470295

Does it really require wrapping sockaddr?  It seems that returning an opaque string containing the data returned by getsockaddrarg that can be passed to the new connect_arw (or whatever) is sufficient.  There doesn't need to be any way to access/mess with the data in this string, since its format is whatever the underlying unix utilities return, and varies by socket address family, etc, but it only needs to be able to be passed blindly to connect.  

Anyway, I would be glad to provide a patch to provide the other routines.    

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-29 09:08

Message:
Logged In: YES 
user_id=21627

I think this requires creating a struct sockaddr wrapper
object. Would you be interested in developing a patch?

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

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


From noreply@sourceforge.net  Tue Apr  8 06:12:03 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 07 Apr 2003 22:12:03 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-706392 ] faster _socket.connect variant desired
Message-ID: <E192lOt-0006jn-00@sc8-sf-web1.sourceforge.net>

Feature Requests item #706392, was opened at 2003-03-19 18:14
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=706392&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Marcus Mendenhall (mendenhall)
Assigned to: Nobody/Anonymous (nobody)
Summary: faster _socket.connect variant desired

Initial Comment:
The  _socket.connect() call is not quite semantically equivalent to the underlying bsd connect() call in that it always parses an internet address.  This process can be quite slow, since it attempts to determine names and cnames (etc) using getaddrinfo(), which may require DNS lookups to complete.  In an environment where many sockets are being connected and disconnected, this is expensive.  

I would like to propose two minor additions to the _socket module:

1) A python wrapper to the internal getsockaddrarg(), allowing a fully processed socket address to be returned as a string

2) a connect_raw_address() call which is a pure wrapper to the bsd connect() call, and which assumes it is passed a string from getsockaddrarg().

This would allow a socket to be disconnected and reconnected many times to the same address, but with much less network chatter and OS overhead.  Effectively, I would like an unbundled version of _socket.connect(), with each of the two processes it uses able to be carried out independently.  

This is also useful in environments where one is communicating on aprivate network which is connected to the outside world over a (for example) PPP or PPPoE link.  Internal traffic handled through this connect will not result in gratuitous DNS traffic which will keep the link from ever closing.

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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-04-08 07:12

Message:
Logged In: YES 
user_id=21627

Would you consider this approach as an alternative to the
one you have just implemented? I admit I like it better than
exposing "raw" sockaddrs.

I invite you to python-dev@python.org to suggest your
proposal to a wider audience before starting to implement it.

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

Comment By: Marcus Mendenhall (mendenhall)
Date: 2003-04-08 04:39

Message:
Logged In: YES 
user_id=470295

Wow, my typing on the previous comment was incredible... it was supposed to start "After thinking..."

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

Comment By: Marcus Mendenhall (mendenhall)
Date: 2003-04-08 04:37

Message:
Logged In: YES 
user_id=470295

Fater thiunking about what I have done with this patch, I would also like to suggest another change (for which I am also willing to submit the patch, which is quite simple):  Consistent with some of the already extant glue in _socet to handle addresses like <broadcast>, would there be any reason no to modify setipaddr() and getaddrinfo() so that if an address is prefixed with <numeric> (e.g. <numeric>127.0.0.1) that the PASSIVE and NUMERIC flags are always set so these routines reject any non-numeric address, but handle numeric ones very efficiently?

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

Comment By: Marcus Mendenhall (mendenhall)
Date: 2003-04-04 15:29

Message:
Logged In: YES 
user_id=470295

OK, I followed your suggestion and made a very lightweight type sockaddr, which has only a constructor, a destructor, and a method called to_tuple() which allows one to get the data out for reconstruction.  I have included, I think, decent docstrings, but haven't patched any of the main Python doc tree.  If you look at the top of getsockaddrarg(), this is the _only_ place this new type interacts with the rest of the _socket module.  Here is a prototype patch.  I have tried it a bit, and I think it works and is safe.  If you have any comments, please let me know.

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

Comment By: Marcus Mendenhall (mendenhall)
Date: 2003-03-30 22:34

Message:
Logged In: YES 
user_id=470295

Aha, now I see what you are suggesting.  I didn't quite understand what you intended before.  This (wrapping sockaddr and having connect check for the wrapped object) sounds like a very plausible idea.  I will consider strongly doing it this way.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-29 18:35

Message:
Logged In: YES 
user_id=21627

Providing a wrapper would allow to reuse the connect
operation, as it could check whether the argument is the
wrapper. If you prefer to use plain strings and a separate
function: that would be fine as well.

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

Comment By: Marcus Mendenhall (mendenhall)
Date: 2003-03-29 18:16

Message:
Logged In: YES 
user_id=470295

Does it really require wrapping sockaddr?  It seems that returning an opaque string containing the data returned by getsockaddrarg that can be passed to the new connect_arw (or whatever) is sufficient.  There doesn't need to be any way to access/mess with the data in this string, since its format is whatever the underlying unix utilities return, and varies by socket address family, etc, but it only needs to be able to be passed blindly to connect.  

Anyway, I would be glad to provide a patch to provide the other routines.    

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-29 16:08

Message:
Logged In: YES 
user_id=21627

I think this requires creating a struct sockaddr wrapper
object. Would you be interested in developing a patch?

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

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


From noreply@sourceforge.net  Tue Apr  8 12:45:04 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 08 Apr 2003 04:45:04 -0700
Subject: [Python-bugs-list] [ python-Bugs-717455 ] cygwin build failing
Message-ID: <E192rXE-0005CD-00@sc8-sf-web1.sourceforge.net>

Bugs item #717455, was opened at 2003-04-08 21:45
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=717455&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Hammond (mhammond)
Assigned to: Jason Tishler (jlt63)
Summary: cygwin build failing

Initial Comment:
Win2k, fairly recent cygwin, Python CVS trunk

configure works, build starts fine, until

gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes 
Parser/acceler.o Parser/grammar1.o Parser/listnode.o
Parser/node.o Parser/parser.o Parser/parsetok.o
Parser/bitset.o Parser/metagrammar.o Objects/obmallo
c.o Python/mysnprintf.o Parser/tokenizer_pgen.o
Parser/firstsets.o Parser/grammar.o Parser/pgen.o Pa
rser/printgrammar.o Parser/pgenmain.o  -o Parser/pgen.exe
Parser/firstsets.o(.text+0x299): In function
`calcfirstset':
/f/src/python-cvs/Parser/firstsets.c:62: undefined
reference to `__PyObject_DebugMalloc'
Parser/firstsets.o(.text+0x388):/f/src/python-cvs/Parser/firstsets.c:76:
undefined reference to `__P
yObject_DebugRealloc'
Parser/grammar.o(.text+0x24): In function `_Py_newgrammar':
/f/src/python-cvs/Parser/grammar.c:19: undefined
reference to `__PyObject_DebugMalloc'
Parser/grammar.o(.text+0xe6): In function `_Py_adddfa':
/f/src/python-cvs/Parser/grammar.c:36: undefined
reference to `__PyObject_DebugRealloc'
Parser/grammar.o(.text+0x1cb): In function `_Py_addstate':
/f/src/python-cvs/Parser/grammar.c:54: undefined
reference to `__PyObject_DebugRealloc'
Parser/grammar.o(.text+0x397): In function `_Py_addarc':
/f/src/python-cvs/Parser/grammar.c:77: undefined
reference to `__PyObject_DebugRealloc'
Parser/grammar.o(.text+0x4b1): In function `_Py_addlabel':
/f/src/python-cvs/Parser/grammar.c:96: undefined
reference to `__PyObject_DebugRealloc'

firstsetc.c:62: is a PyMem_NEW call.  The error implies
a debug build, but the flags imply release.  Configure
was done with no options.

I'm not even sure I want a pgen.exe :)  A quick scan of
python-dev and the bug list showed nothing


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

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


From noreply@sourceforge.net  Tue Apr  8 16:54:28 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 08 Apr 2003 08:54:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-717455 ] cygwin build failing
Message-ID: <E192vQa-0008DB-00@sc8-sf-web1.sourceforge.net>

Bugs item #717455, was opened at 2003-04-08 03:45
Message generated for change (Comment added) made by jlt63
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=717455&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Hammond (mhammond)
Assigned to: Jason Tishler (jlt63)
Summary: cygwin build failing

Initial Comment:
Win2k, fairly recent cygwin, Python CVS trunk

configure works, build starts fine, until

gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes 
Parser/acceler.o Parser/grammar1.o Parser/listnode.o
Parser/node.o Parser/parser.o Parser/parsetok.o
Parser/bitset.o Parser/metagrammar.o Objects/obmallo
c.o Python/mysnprintf.o Parser/tokenizer_pgen.o
Parser/firstsets.o Parser/grammar.o Parser/pgen.o Pa
rser/printgrammar.o Parser/pgenmain.o  -o Parser/pgen.exe
Parser/firstsets.o(.text+0x299): In function
`calcfirstset':
/f/src/python-cvs/Parser/firstsets.c:62: undefined
reference to `__PyObject_DebugMalloc'
Parser/firstsets.o(.text+0x388):/f/src/python-cvs/Parser/firstsets.c:76:
undefined reference to `__P
yObject_DebugRealloc'
Parser/grammar.o(.text+0x24): In function `_Py_newgrammar':
/f/src/python-cvs/Parser/grammar.c:19: undefined
reference to `__PyObject_DebugMalloc'
Parser/grammar.o(.text+0xe6): In function `_Py_adddfa':
/f/src/python-cvs/Parser/grammar.c:36: undefined
reference to `__PyObject_DebugRealloc'
Parser/grammar.o(.text+0x1cb): In function `_Py_addstate':
/f/src/python-cvs/Parser/grammar.c:54: undefined
reference to `__PyObject_DebugRealloc'
Parser/grammar.o(.text+0x397): In function `_Py_addarc':
/f/src/python-cvs/Parser/grammar.c:77: undefined
reference to `__PyObject_DebugRealloc'
Parser/grammar.o(.text+0x4b1): In function `_Py_addlabel':
/f/src/python-cvs/Parser/grammar.c:96: undefined
reference to `__PyObject_DebugRealloc'

firstsetc.c:62: is a PyMem_NEW call.  The error implies
a debug build, but the flags imply release.  Configure
was done with no options.

I'm not even sure I want a pgen.exe :)  A quick scan of
python-dev and the bug list showed nothing


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

>Comment By: Jason Tishler (jlt63)
Date: 2003-04-08 07:54

Message:
Logged In: YES 
user_id=86216

Sorry, I cannot reproduce with CVS updated this morning
(ET) using my normal build procedure:

$ cvs update
...
$ mkdir build
$ cd build
$ ../configure --prefix=/usr
...
$ make
...

How did you configure? Are you building in the source tree
or a separate build tree?

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

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


From noreply@sourceforge.net  Tue Apr  8 17:50:53 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 08 Apr 2003 09:50:53 -0700
Subject: [Python-bugs-list] [ python-Bugs-717614 ] Freebsd - Cannot open file discriptor 3
Message-ID: <E192wJB-0000wm-00@sc8-sf-web3.sourceforge.net>

Bugs item #717614, was opened at 2003-04-08 10:50
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=717614&group_id=5470

Category: Python Library
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Ramsay (lack)
Assigned to: Nobody/Anonymous (nobody)
Summary: Freebsd - Cannot open file discriptor 3

Initial Comment:
For some reason on my FreeBSD system whenever I run
python I am unable to access file descriptor 3 or 4. 
According to my system's fstat, there is a pipe there:

lack     python     36683    3* pipe cd5b2cc0 <->
cd99f9e0      0 rw
lack     python     36683    4* pipe cd99f9e0 <->
cd5b2cc0      0 rw

But I did not open this pipe, nor can I figure out
where it came from.

I also cannot close this file descriptor or use it in
any way - I recieve the error:

>>> os.close(3)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OSError: [Errno 9] Bad file descriptor
>>>

There is some strange behaviour if I close one of the
standard descriptors first:

>>> os.close(2)
>>> os.close(3)
>>> os.close(4)
>>> 

But despite the lack of error messages, the pipe from 3
to 4 is still open.

I do not know why this happens. and am at a loss at how
to access FD#3.

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

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


From noreply@sourceforge.net  Tue Apr  8 18:30:30 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 08 Apr 2003 10:30:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-717614 ] Uthread problem - Pipe left open
Message-ID: <E192wvW-0000Sk-00@sc8-sf-web4.sourceforge.net>

Bugs item #717614, was opened at 2003-04-08 10:50
Message generated for change (Comment added) made by lack
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=717614&group_id=5470

>Category: Python Interpreter Core
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Ramsay (lack)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Uthread problem - Pipe left open

Initial Comment:
For some reason on my FreeBSD system whenever I run
python I am unable to access file descriptor 3 or 4. 
According to my system's fstat, there is a pipe there:

lack     python     36683    3* pipe cd5b2cc0 <->
cd99f9e0      0 rw
lack     python     36683    4* pipe cd99f9e0 <->
cd5b2cc0      0 rw

But I did not open this pipe, nor can I figure out
where it came from.

I also cannot close this file descriptor or use it in
any way - I recieve the error:

>>> os.close(3)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OSError: [Errno 9] Bad file descriptor
>>>

There is some strange behaviour if I close one of the
standard descriptors first:

>>> os.close(2)
>>> os.close(3)
>>> os.close(4)
>>> 

But despite the lack of error messages, the pipe from 3
to 4 is still open.

I do not know why this happens. and am at a loss at how
to access FD#3.

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

>Comment By: Jim Ramsay (lack)
Date: 2003-04-08 11:30

Message:
Logged In: YES 
user_id=185022

Update:

This seems to be linked to "uthread" support.  This pipe is
opened in uthread_init.c around line 167, and should be
closed by uthread_execve.c around line 59.

For some reason the pipe is not being closed.

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

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


From noreply@sourceforge.net  Tue Apr  8 21:23:43 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 08 Apr 2003 13:23:43 -0700
Subject: [Python-bugs-list] [ python-Bugs-712322 ] test_zipimport failing on ia64 (at least)
Message-ID: <E192zd9-0000XV-00@sc8-sf-web4.sourceforge.net>

Bugs item #712322, was opened at 2003-03-30 22:32
Message generated for change (Comment added) made by jvr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=712322&group_id=5470

Category: Extension Modules
Group: Python 2.3
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Just van Rossum (jvr)
Summary: test_zipimport failing on ia64 (at least)

Initial Comment:
test_zipimport is failing on the snake-farm.  I'm
pretty sure this test worked before.  The only
difference is the file ends in .py vs. .pyc.  I don't
know what changed recently which would have cause this.

http://www.lysator.liu.se/xenofarm/python/files/454_3/python-testlog.txt

test test_zipimport failed -- Traceback (most recent
call last):
  File
"/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/Lib/test/test_zipimport.py",
line 108, in testBoth
    self.doTest(pyc_ext, files, TESTMOD)
  File
"/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/Lib/test/test_zipimport.py",
line 66, in doTest
    self.assertEquals(file, os.path.join(TEMP_ZIP,
  File
"/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/Lib/unittest.py",
line 292, in failUnlessEqual
    raise self.failureException, \
AssertionError:
'/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/junk95142.zip/ziptestmodule.py'
!=
'/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/junk95142.zip/ziptestmodule.pyc'




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

>Comment By: Just van Rossum (jvr)
Date: 2003-04-08 22:23

Message:
Logged In: YES 
user_id=92689

checked in as rev. 1.13 of Modules/zipimport.c

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-07 17:06

Message:
Logged In: YES 
user_id=33168

I agree, let's do the -1 now.  I'll check in later, unless
Just beats me to it.

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

Comment By: Tim Peters (tim_one)
Date: 2003-04-07 16:36

Message:
Logged In: YES 
user_id=31435

Setting tm_isdst to -1 does fix the test on Windows, now that 
it's DST here.  I can't say whether it would also have left the 
test working before DST kicked in yesterday, but am happy 
to assume that it would:  with any luck, I'll die before October, 
and then fixing it on Windows will be somebody else's 
headache <wink>.

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

Comment By: Just van Rossum (jvr)
Date: 2003-04-07 08:07

Message:
Logged In: YES 
user_id=92689

Glad we didn't fix it sooner, then ;-)

Can you verify whether changing
    tm_isdst = 0;
to
    tm_isdst = -1;
(somewhere in zipimport.c)

Helps on Windows, too?

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

Comment By: Tim Peters (tim_one)
Date: 2003-04-07 02:01

Message:
Logged In: YES 
user_id=31435

Noting that DST began in the USA this morning, and 
test_zipimport started failing on Windows immediately 
after.  I don't know what will work across all platforms, but 
you've got ample evidence that what's there now will 
eventually fail on all platforms <wink>.

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

Comment By: Just van Rossum (jvr)
Date: 2003-04-06 12:54

Message:
Logged In: YES 
user_id=92689

How do we proceed on this one? Shall I just check this change in, and we'll see what happens on other platforms?

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

Comment By: Just van Rossum (jvr)
Date: 2003-04-02 10:26

Message:
Logged In: YES 
user_id=92689

It sure works for OSX!

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-01 22:34

Message:
Logged In: YES 
user_id=33168

Changing the tm_isdst to -1 fixed the problem on HPUX.  I'm
not sure if this will work on all platforms.  -1 means
mktime should guess whether DST is in effect or not.  0
means it's never DST.  I can see problems with any value. 
Perhaps there's some zip documentation which describes what
should be done?  Or perhaps the time (dostime, dosdate) are
encoded incorrectly?

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

Comment By: Just van Rossum (jvr)
Date: 2003-04-01 21:28

Message:
Logged In: YES 
user_id=92689

Found the cause: daylight saving. I think it's a mismatch between zipfile.py's handling of time and zipimport.c's.

I just tested with a manually created zip file and the same problem occurs, so I'm fairly sure the problem is with zipimport's parse_dostime(). The effbot wrote that one for me, but perhaps someone else with the necessary time.h expertise can advise what's wrong?

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

Comment By: Just van Rossum (jvr)
Date: 2003-04-01 20:23

Message:
Logged In: YES 
user_id=92689

Ah, duh, it even fails on OSX, so I can do some research myself.

Wild guess: are the other failing boxes also big endian machines?

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-01 18:05

Message:
Logged In: YES 
user_id=33168

This test is now failing on most unixes.  AIX, HPUX and
others I think.  I tried building some older versions from
3/1, 2/20, etc. but the problem persists.  Even though I
thought those versions worked at the time.  This will take
some time to look into further.  Assigning to me, but
hopefully someone else who also sees this problem can help.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-31 16:32

Message:
Logged In: YES 
user_id=33168

Yes, I believe it worked more recently, but I could be
wrong...  I checked out source from 3/20 and that still
fails, so I have to keep going back until I find exactly
where it failed.  I'll keep trying too.

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

Comment By: Just van Rossum (jvr)
Date: 2003-03-31 16:22

Message:
Logged In: YES 
user_id=92689

dict order should not have relevance to the test. I currently have no idea what could have caused it, and zipimport.c itself hasn't been changed significantly in a while. I see in the logs that in february you fixed some 64-bit issues, but I guess that by "it worked before" you mean something much more recent than that. I'll continue trying to figure out potential causes.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-31 15:33

Message:
Logged In: YES 
user_id=33168

It is also broken on AIX which I do have access to.  I'm
trying to determine what broke it.  One guess is dictionary
order.  I'm not sure if the test relies on .pyc being
written before .py as a result of file.items().  It is
broken on 3/26.  Unfortunately it takes a very long time to
build on these boxes (hours).  Let me know if you have any
idea of what might have recently changed to break zipimports.

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

Comment By: Just van Rossum (jvr)
Date: 2003-03-31 09:40

Message:
Logged In: YES 
user_id=92689

Then how are we/am I supposed to fix this? Assigning to None.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-31 00:32

Message:
Logged In: YES 
user_id=33168

Unfortunately, I don't have access to the boxes where this
is failling.  The only possibility would be in the compaq
(hp) test drive machines.

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

Comment By: Just van Rossum (jvr)
Date: 2003-03-30 23:03

Message:
Logged In: YES 
user_id=92689

Hm, apparently loading from pyc fails. Perhaps a bug with zipimport's pyc magic or mod date checking code?

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

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


From noreply@sourceforge.net  Wed Apr  9 05:10:57 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 08 Apr 2003 21:10:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-717455 ] cygwin build failing
Message-ID: <E1936vJ-0002r9-00@sc8-sf-web3.sourceforge.net>

Bugs item #717455, was opened at 2003-04-08 07:45
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=717455&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Hammond (mhammond)
Assigned to: Jason Tishler (jlt63)
Summary: cygwin build failing

Initial Comment:
Win2k, fairly recent cygwin, Python CVS trunk

configure works, build starts fine, until

gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes 
Parser/acceler.o Parser/grammar1.o Parser/listnode.o
Parser/node.o Parser/parser.o Parser/parsetok.o
Parser/bitset.o Parser/metagrammar.o Objects/obmallo
c.o Python/mysnprintf.o Parser/tokenizer_pgen.o
Parser/firstsets.o Parser/grammar.o Parser/pgen.o Pa
rser/printgrammar.o Parser/pgenmain.o  -o Parser/pgen.exe
Parser/firstsets.o(.text+0x299): In function
`calcfirstset':
/f/src/python-cvs/Parser/firstsets.c:62: undefined
reference to `__PyObject_DebugMalloc'
Parser/firstsets.o(.text+0x388):/f/src/python-cvs/Parser/firstsets.c:76:
undefined reference to `__P
yObject_DebugRealloc'
Parser/grammar.o(.text+0x24): In function `_Py_newgrammar':
/f/src/python-cvs/Parser/grammar.c:19: undefined
reference to `__PyObject_DebugMalloc'
Parser/grammar.o(.text+0xe6): In function `_Py_adddfa':
/f/src/python-cvs/Parser/grammar.c:36: undefined
reference to `__PyObject_DebugRealloc'
Parser/grammar.o(.text+0x1cb): In function `_Py_addstate':
/f/src/python-cvs/Parser/grammar.c:54: undefined
reference to `__PyObject_DebugRealloc'
Parser/grammar.o(.text+0x397): In function `_Py_addarc':
/f/src/python-cvs/Parser/grammar.c:77: undefined
reference to `__PyObject_DebugRealloc'
Parser/grammar.o(.text+0x4b1): In function `_Py_addlabel':
/f/src/python-cvs/Parser/grammar.c:96: undefined
reference to `__PyObject_DebugRealloc'

firstsetc.c:62: is a PyMem_NEW call.  The error implies
a debug build, but the flags imply release.  Configure
was done with no options.

I'm not even sure I want a pgen.exe :)  A quick scan of
python-dev and the bug list showed nothing


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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-09 00:10

Message:
Logged In: YES 
user_id=33168

This kind of problem happens to me when I build with debug,
cvs update, then build without debug.  I suspect a make
clean will fix the problem.

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

Comment By: Jason Tishler (jlt63)
Date: 2003-04-08 11:54

Message:
Logged In: YES 
user_id=86216

Sorry, I cannot reproduce with CVS updated this morning
(ET) using my normal build procedure:

$ cvs update
...
$ mkdir build
$ cd build
$ ../configure --prefix=/usr
...
$ make
...

How did you configure? Are you building in the source tree
or a separate build tree?

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

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


From noreply@sourceforge.net  Wed Apr  9 11:48:01 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 09 Apr 2003 03:48:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-692776 ] new.function() leads to segfault
Message-ID: <E193D7Z-00060L-00@sc8-sf-web2.sourceforge.net>

Bugs item #692776, was opened at 2003-02-25 08:04
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=692776&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Jp Calderone (kuran)
>Assigned to: Jeremy Hylton (jhylton)
Summary: new.function() leads to segfault

Initial Comment:
If a code object which requires a closure is passed to
new.function(), a segfault (Python/ceval.c:2578).  This
seems to be fixed in 2.3.  Attached is a short code
example that demonstrates the behavior.


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

>Comment By: Michael Hudson (mwh)
Date: 2003-04-09 11:48

Message:
Logged In: YES 
user_id=6656

Jeremy, is this easy for you to fix?  It's fiddlier than I
expected.

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

Comment By: Michael Hudson (mwh)
Date: 2003-02-25 09:31

Message:
Logged In: YES 
user_id=6656

You're right.

I guess the fix is to backport the extra 'closure' argument
from 2.3.  I'll look into this.

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

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


From noreply@sourceforge.net  Wed Apr  9 14:47:50 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 09 Apr 2003 06:47:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-697179 ] gensuitemodule overhaul
Message-ID: <E193Fva-000697-00@sc8-sf-web3.sourceforge.net>

Bugs item #697179, was opened at 2003-03-04 11:42
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697179&group_id=5470

Category: Macintosh
Group: Feature Request
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: gensuitemodule overhaul

Initial Comment:
Gensuitemodule needs an overhaul, if possible before 2.3.

Things that need to be done:
- Use more MacOSX-compatible ways to get at the AETE. Donovan Preston posted a note on how to use the ascr/gdte call. There's also some interesting-looking calls in the OpenScripting framework.
- Distinguish between running while building a distribution (things go into Lib/plat-mac/lib-scriptpackages) and running as a user (things should go into site-packages).
- Allow for non-interactive use. Main problem is that some suites need a name-mapping, and there's undefined enums to be catered for.

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

>Comment By: Jack Jansen (jackjansen)
Date: 2003-04-09 15:47

Message:
Logged In: YES 
user_id=45365

All done. Only documentation is still needed, but this is a separate bug report already.

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

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


From noreply@sourceforge.net  Wed Apr  9 17:53:31 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 09 Apr 2003 09:53:31 -0700
Subject: [Python-bugs-list] [ python-Bugs-718380 ] xml.dom.minidom - text node truncated
Message-ID: <E193IpH-00063z-00@sc8-sf-web2.sourceforge.net>

Bugs item #718380, was opened at 2003-04-09 12:53
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=718380&group_id=5470

Category: XML
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Bucciarelli (mbucc)
Assigned to: Nobody/Anonymous (nobody)
Summary: xml.dom.minidom - text node truncated

Initial Comment:
The attached program raises an assertion error on Windows, but 
does not on Linux.  The text child node of the TYPE element is 
trunctated when the "does_not_work" string is parsed, but is fine 
when the "works" string is parsed.  If you progressively shorten the 
length of the "abcdef" element ("abcde", "abcd", ...), eventually the 
"works" string will fail as well. 

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

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


From noreply@sourceforge.net  Wed Apr  9 19:57:46 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 09 Apr 2003 11:57:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-692776 ] new.function() leads to segfault
Message-ID: <E193KlW-0002k9-00@sc8-sf-web4.sourceforge.net>

Bugs item #692776, was opened at 2003-02-25 08:04
Message generated for change (Comment added) made by jhylton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=692776&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Jp Calderone (kuran)
Assigned to: Jeremy Hylton (jhylton)
Summary: new.function() leads to segfault

Initial Comment:
If a code object which requires a closure is passed to
new.function(), a segfault (Python/ceval.c:2578).  This
seems to be fixed in 2.3.  Attached is a short code
example that demonstrates the behavior.


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

>Comment By: Jeremy Hylton (jhylton)
Date: 2003-04-09 18:57

Message:
Logged In: YES 
user_id=31392

I think I can swap in the state without too much pain.


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

Comment By: Michael Hudson (mwh)
Date: 2003-04-09 10:48

Message:
Logged In: YES 
user_id=6656

Jeremy, is this easy for you to fix?  It's fiddlier than I
expected.

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

Comment By: Michael Hudson (mwh)
Date: 2003-02-25 09:31

Message:
Logged In: YES 
user_id=6656

You're right.

I guess the fix is to backport the extra 'closure' argument
from 2.3.  I'll look into this.

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

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


From noreply@sourceforge.net  Wed Apr  9 20:01:48 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 09 Apr 2003 12:01:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-716168 ] Minor nested scopes doc issues
Message-ID: <E193KpQ-0004aJ-00@sc8-sf-web2.sourceforge.net>

Bugs item #716168, was opened at 2003-04-06 10:09
Message generated for change (Settings changed) made by jhylton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=716168&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Cherniavsky Beni (cben)
>Assigned to: Jeremy Hylton (jhylton)
Summary: Minor nested scopes doc issues

Initial Comment:
1. In section "4.1 Naming and binding", in the list of
binding operations, list comprehensions are missing.

2. Appendix "A. Future statements and nested scopes"
doesn't contain the nested scopes docs (it's now
section 4.1) but still says it does and that "it will
be removed in Python 2.2" :-).


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

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


From noreply@sourceforge.net  Wed Apr  9 21:01:14 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 09 Apr 2003 13:01:14 -0700
Subject: [Python-bugs-list] [ python-Bugs-718532 ] inspect, class instances and __getattr__
Message-ID: <E193Lkw-0007Iw-00@sc8-sf-web2.sourceforge.net>

Bugs item #718532, was opened at 2003-04-09 22:01
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=718532&group_id=5470

Category: Python Library
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Stefan Schwarzer (sschwarzer)
Assigned to: Nobody/Anonymous (nobody)
Summary: inspect, class instances and __getattr__

Initial Comment:
inspect.isclass(class_instance) fails if the
corresponding class uses a "wildcard" implementation of
__getattr__.

Example:

Python 2.2.2 (#1, Nov 13 2002, 22:53:57) 
[GCC 2.95.4 20020320 [FreeBSD]] on freebsd4
Type "help", "copyright", "credits" or "license" for
more information.
>>> import inspect
>>> class X:
...     def __getattr__(self, name):
...             if name == 'foo':
...                     return 1   
...             if name == 'bar':
...                     return 2
...             else:
...                     return "default"
... 
>>> x = X()
>>> inspect.isclass(x)
1

The problematic expression in inspect.isclass is
hasattr(object, '__bases__') which returns a true value.

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

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


From noreply@sourceforge.net  Wed Apr  9 21:36:54 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 09 Apr 2003 13:36:54 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-712375 ] unicodedata should have a version available
Message-ID: <E193MJS-0002Mj-00@sc8-sf-web1.sourceforge.net>

Feature Requests item #712375, was opened at 2003-03-31 01:00
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=712375&group_id=5470

Category: Unicode
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: James Matthew Farrow (jmfarrow)
Assigned to: Nobody/Anonymous (nobody)
Summary: unicodedata should have a version available

Initial Comment:
The unicodedata module should have a version (or
revision) symbol available as an entry containing the
corresponding Unicode revision from the Unicode data
encoded.

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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-04-09 22:36

Message:
Logged In: YES 
user_id=21627

It does:

Python 2.3a2+ (#39, Mar  4 2003, 12:17:32) [MSC v.1200 32 
bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import unicodedata
>>> unicodedata.unidata_version
'3.2.0'


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

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


From noreply@sourceforge.net  Wed Apr  9 22:46:07 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 09 Apr 2003 14:46:07 -0700
Subject: [Python-bugs-list] [ python-Bugs-718380 ] xml.dom.minidom - text node truncated
Message-ID: <E193NOR-0003L8-00@sc8-sf-web2.sourceforge.net>

Bugs item #718380, was opened at 2003-04-09 12:53
Message generated for change (Comment added) made by mbucc
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=718380&group_id=5470

Category: XML
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Bucciarelli (mbucc)
Assigned to: Nobody/Anonymous (nobody)
Summary: xml.dom.minidom - text node truncated

Initial Comment:
The attached program raises an assertion error on Windows, but 
does not on Linux.  The text child node of the TYPE element is 
trunctated when the "does_not_work" string is parsed, but is fine 
when the "works" string is parsed.  If you progressively shorten the 
length of the "abcdef" element ("abcde", "abcd", ...), eventually the 
"works" string will fail as well. 

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

>Comment By: Mark Bucciarelli (mbucc)
Date: 2003-04-09 17:46

Message:
Logged In: YES 
user_id=35056

Work around: use xml.sax. 
 
 

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

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


From noreply@sourceforge.net  Wed Apr  9 23:53:49 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 09 Apr 2003 15:53:49 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-708125 ] Requesting Mock Object support for unittest.TestCase
Message-ID: <E193ORx-0004Gs-00@sc8-sf-web3.sourceforge.net>

Feature Requests item #708125, was opened at 2003-03-22 20:05
Message generated for change (Comment added) made by mattruss
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=708125&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Russell (mattruss)
Assigned to: Nobody/Anonymous (nobody)
Summary: Requesting Mock Object support for unittest.TestCase

Initial Comment:
I previously submitted a patch (sf id 706590),
since I was following www.python.com's notes on how 
to contribute - since using sf more i think i should of 
added it to this RFE. Since posting the orignal patch I 
have updated the code based upon sugestions from 
python-dev and others.

please view my origanal patch here:
https://sourceforge.net/tracker/index.php?
func=detail&aid=706590&group_id=5470&atid=305470

This patch adds one method - createMockInstance
(classDef, overrides, *initArgs, **initKwds)
to unittest.TestCase, and two classes MockFactory and 
MockMethod.

Since both these classes should never really be used 
outside the scope of a unittest, I thought it best to add 
them to the unittest module (allthough it is getting rather 
big - should be split into a package?)




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

>Comment By: Matthew Russell (mattruss)
Date: 2003-04-09 23:53

Message:
Logged In: YES 
user_id=737261

I have made some changes to my patch - i hope it's made 
things clearer (?)

have also replaced 0/1's with False/True where appropriate
added boolean kwd arg to main - exitsOnResult
which if set to false will not do sys.exit (now you can run 
python -i test_mystuff.py using this and not be thrown back 
out to the command line)


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

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


From noreply@sourceforge.net  Thu Apr 10 00:23:05 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 09 Apr 2003 16:23:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-585792 ] Invalid mmap crashes Python interpreter
Message-ID: <E193OuH-00005Q-00@sc8-sf-web1.sourceforge.net>

Bugs item #585792, was opened at 2002-07-24 18:52
Message generated for change (Comment added) made by liqx
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=585792&group_id=5470

Category: Extension Modules
Group: None
Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Invalid mmap crashes Python interpreter

Initial Comment:
This is under Red Hat 7.2, Linux kernel 2.4.7.   "x" is
an empty file, i.e. zero bytes long.

import mmap
f = open(x,"r+")m = mmap.mmap(f.fileno(), 10)
print m[1]

Crashes Python with a bus error.  Python should catch
the bus error signal
and raise an appropriate exception that the script can
catch.


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

Comment By: Alastair (LiQUiDx) Tse (liqx)
Date: 2003-04-10 09:23

Message:
Logged In: YES 
user_id=338973

i'm having some problems with this patch.

how does one use mmap on a device file with on a unix device
file?

# example - with a webcam on /dev/video0:
import os, mmap
fd = os.open("/dev/video0",os.O_RDONLY)
mm = mmap.mmap(fd, 1024, mmap.MAP_SHARED)

# this will result in:
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ValueError: mmap length is greater than file size

even though this is a perfectly valid way to access the
buffer for video devices on linux (not sure about other unicies)

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-09-06 08:33

Message:
Logged In: YES 
user_id=33168

Sorry Martin, I apparently didn't upload the last patch. 
Feel free to fix the test if you see a problem.

Checked in as:
 Modules/mmapmodule.c: 2.41, 2.35.6.3
 Lib/test/test_mmap.py: 1.24, 1.19.8.3
 Lib/test/output/test_mmap: 1.9, 1.8.6.1
 Misc/NEWS: 1.480, 1.337.2.4.2.34

I backported the fix, since your last message Guido seemed
to indicate that we are still supposed to do it.

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

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

Message:
Logged In: YES 
user_id=21627

I may be missing something: How precisely does this
special-case Windows in the test?

Apart from that, the patch is fine.

I'm uncertain on backporting it, because I'm uncertain how
backporting works at all since the PBF got instantiated. So
I'd suggest to mark this as a backport candidate, and let
the patch czar decide.



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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-18 02:08

Message:
Logged In: YES 
user_id=33168

Martin, would you like one last review and test on windows
before I check in?  Also, should this be backported to 2.2.?

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-14 03:39

Message:
Logged In: YES 
user_id=33168

I can't test windows.  I've attached a patch which tries to
test windows doesn't raise an exception.
I also modified the NEWS to state this change affects
non-Windows platforms.

Tim/Martin, can you test (or at least review the test code)
that this works on Windows before I check it in?  Or let me
know if you want me to check it in.  It should be easy to
fix if it doesn't work on Windows.

Thanks.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-08-13 12:11

Message:
Logged In: NO 

I'd say the following is reasonable:

- on mmap object creation, stat the file and check its size
against the size arg passed to mmap.  Signal an error if the
file is smaller than the requested mmap size.  

- On access, compare the subscript to the mmap object size
and signal an error if out of bounds (presumably this is
done already)

- Figure out if another process can truncate the file while
the mmap is alive.  If yes, maybe add a method to the mmap
object that re-stats the file and makes sure it's still
larger than the mmap size.  

- Add warnings to the mmap documentation that weirdness can
result from the file size changing etc.


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

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

Message:
Logged In: YES 
user_id=21627

I think we should special-case Windows, then. For the
mmapmodule patch proper, nothing needs to be done; for the
testsuite test, pass and fail are exactly reversed on
Windows (but then, we'd test the implementation of Windows,
so skipping that test sounds reasonable as well).

With those changes, the patch is fine.

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

Comment By: Tim Peters (tim_one)
Date: 2002-08-13 01:59

Message:
Logged In: YES 
user_id=31435

mmap() on WIndows doesn't care if you map more bytes 
than exist in the file -- if you do, it grows the file to match.

"""
If an application specifies a size for the file mapping object 
that is larger than the size of the actual named file on disk, 
the file on disk is grown to match the specified size of the 
file mapping object. If the file cannot be grown, this results 
in a failure to create the file mapping object. GetLastError 
will return ERROR_DISK_FULL.
"""

Like so:

>>> import mmap
>>> import os
>>> os.path.getsize('abc.abc')
12L
>>> f = file('abc.abc', 'r+')
>>> m = mmap.mmap(f.fileno(), 10000)
>>> m.close()
>>> os.path.getsize('abc.abc')
10000L
>>>


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-13 01:49

Message:
Logged In: YES 
user_id=33168

That last comment was supposed to be:  I don't know how
Windows behaves...

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-13 01:47

Message:
Logged In: YES 
user_id=33168

I thought the st_size was updated by the code in
new_buffersize.  It was only the position, so the comment
should go.  ValueError is fine with me.  Should I add an
entry to NEWS?  New patch attached w/NEWS and test.

There is another issue--Windows.  I how Windows behaves and
I can't test it.

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

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

Message:
Logged In: YES 
user_id=21627

I'd say it is a ValueError if the map size is larger than
the file size, instead of silently decreasing the size:
Errors should never pass silently, Unless explicitly silenced.

On the trick of new_buffersize: I'm not sure I understand
what you are referring to: we don't use stdio in mmap at all.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-12 23:30

Message:
Logged In: YES 
user_id=33168

I wasn't sure if I could change the size.  For Solaris at
least, it seems this is the right thing to do.  Is it likely
that other systems allow the file size to change?  I've
forced the size to be the max(size_arg, size_of_file).  This
has the added benefit of working for writing too.  Prior to
this patch, writing past the end crashed on Linux.

There are 2 comments in the patch:  one worrying about the
file changing, the other producing a warning message if the
size argument is larger than the file.  Do we have to worry
about the size changing?  Should we tell the user what they did?

Sorry about the old style diff.  I remembered to do the cvs
-f diff part, but forgot the -C5.  My defaults are unified.
New context patch attached.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-08-12 17:45

Message:
Logged In: NO 

Please don't even think of adding a stat call to every
access.  The whole idea of mmap is to speed up access by
eliminating system calls when you touch the file contents. 
Checking the file size at map creation is reasonable.  Some
note should also be added to the mmap doc about possible
crashes if the file size changes.

>From a Python script writer's viewpoint, the most convenient
fix is for Python to catch the bus error signal and inspect
the stack to figure out that the trap occurred in the mmap
routine, then generate and return an appropriate Python
exception.  However, doing that is pretty
platform-dependent, and attempting it in all the Python
ports that support mmap doesn't sound practical.  

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

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

Message:
Logged In: YES 
user_id=21627

Ah, an old-style diff. I assume that goes into mmap_item?

I'd rather avoid the stat call on every access, and check
the size on map creation.

The Solaris man page says this about changing files:

     If the size of the mapped file changes  after  the 
call  to
     mmap()  as  a  result  of some other operation on the
mapped
     file, the effect of references to  portions  of  the 
mapped
     region  that  correspond to added or removed portions
of the
     file is unspecified.

So it appears that this is a case of "don"t do this, then",
and that it atleast won't crash - but we might want to
perform a few experiments.



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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-12 01:05

Message:
Logged In: YES 
user_id=33168

Martin, could you please review the patch?

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-07-29 01:00

Message:
Logged In: YES 
user_id=33168

Attached is a patch which fixes this problem.  I'm not sure
this patch it correct nor appropriate.  But it stops the
crash.  I'm hoping some mmap expert can shed some light on this.

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

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


From noreply@sourceforge.net  Thu Apr 10 01:32:25 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 09 Apr 2003 17:32:25 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-708125 ] Requesting Mock Object support for unittest.TestCase
Message-ID: <E193PzN-0000Oq-00@sc8-sf-web2.sourceforge.net>

Feature Requests item #708125, was opened at 2003-03-22 20:05
Message generated for change (Comment added) made by mattruss
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=708125&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Russell (mattruss)
Assigned to: Nobody/Anonymous (nobody)
Summary: Requesting Mock Object support for unittest.TestCase

Initial Comment:
I previously submitted a patch (sf id 706590),
since I was following www.python.com's notes on how 
to contribute - since using sf more i think i should of 
added it to this RFE. Since posting the orignal patch I 
have updated the code based upon sugestions from 
python-dev and others.

please view my origanal patch here:
https://sourceforge.net/tracker/index.php?
func=detail&aid=706590&group_id=5470&atid=305470

This patch adds one method - createMockInstance
(classDef, overrides, *initArgs, **initKwds)
to unittest.TestCase, and two classes MockFactory and 
MockMethod.

Since both these classes should never really be used 
outside the scope of a unittest, I thought it best to add 
them to the unittest module (allthough it is getting rather 
big - should be split into a package?)




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

>Comment By: Matthew Russell (mattruss)
Date: 2003-04-10 01:32

Message:
Logged In: YES 
user_id=737261

I wrote these unittests first before i wrote the code.
Hopefully proves that it works for new style classes and old
(allthought tests are now a little out of date as the updated 
diff uses sets, therefore is 2.3 specific)

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

Comment By: Matthew Russell (mattruss)
Date: 2003-04-09 23:53

Message:
Logged In: YES 
user_id=737261

I have made some changes to my patch - i hope it's made 
things clearer (?)

have also replaced 0/1's with False/True where appropriate
added boolean kwd arg to main - exitsOnResult
which if set to false will not do sys.exit (now you can run 
python -i test_mystuff.py using this and not be thrown back 
out to the command line)


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

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


From noreply@sourceforge.net  Thu Apr 10 13:43:55 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 10 Apr 2003 05:43:55 -0700
Subject: [Python-bugs-list] [ python-Bugs-718380 ] xml.dom.minidom - text node truncated
Message-ID: <E193bPH-0006hg-00@sc8-sf-web4.sourceforge.net>

Bugs item #718380, was opened at 2003-04-09 12:53
Message generated for change (Comment added) made by mbucc
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=718380&group_id=5470

Category: XML
Group: Python 2.2.2
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Mark Bucciarelli (mbucc)
Assigned to: Nobody/Anonymous (nobody)
Summary: xml.dom.minidom - text node truncated

Initial Comment:
The attached program raises an assertion error on Windows, but 
does not on Linux.  The text child node of the TYPE element is 
trunctated when the "does_not_work" string is parsed, but is fine 
when the "works" string is parsed.  If you progressively shorten the 
length of the "abcdef" element ("abcde", "abcd", ...), eventually the 
"works" string will fail as well. 

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

>Comment By: Mark Bucciarelli (mbucc)
Date: 2003-04-10 08:43

Message:
Logged In: YES 
user_id=35056

the bug is in my script.  Need to call n.normalize() before processing the 
text nodes. 

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

Comment By: Mark Bucciarelli (mbucc)
Date: 2003-04-09 17:46

Message:
Logged In: YES 
user_id=35056

Work around: use xml.sax. 
 
 

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

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


From noreply@sourceforge.net  Thu Apr 10 18:13:27 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 10 Apr 2003 10:13:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-585792 ] Invalid mmap crashes Python interpreter
Message-ID: <E193fc7-0004nx-00@sc8-sf-web2.sourceforge.net>

Bugs item #585792, was opened at 2002-07-24 04:52
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=585792&group_id=5470

Category: Extension Modules
Group: None
Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Invalid mmap crashes Python interpreter

Initial Comment:
This is under Red Hat 7.2, Linux kernel 2.4.7.   "x" is
an empty file, i.e. zero bytes long.

import mmap
f = open(x,"r+")m = mmap.mmap(f.fileno(), 10)
print m[1]

Crashes Python with a bus error.  Python should catch
the bus error signal
and raise an appropriate exception that the script can
catch.


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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-10 13:13

Message:
Logged In: YES 
user_id=33168

The problem is that character devices should be excluded
from the offset check.  This fix is in patch 708374.  That
part of the patch should be backported to 2.2.3.

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

Comment By: Alastair (LiQUiDx) Tse (liqx)
Date: 2003-04-09 19:23

Message:
Logged In: YES 
user_id=338973

i'm having some problems with this patch.

how does one use mmap on a device file with on a unix device
file?

# example - with a webcam on /dev/video0:
import os, mmap
fd = os.open("/dev/video0",os.O_RDONLY)
mm = mmap.mmap(fd, 1024, mmap.MAP_SHARED)

# this will result in:
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ValueError: mmap length is greater than file size

even though this is a perfectly valid way to access the
buffer for video devices on linux (not sure about other unicies)

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-09-05 18:33

Message:
Logged In: YES 
user_id=33168

Sorry Martin, I apparently didn't upload the last patch. 
Feel free to fix the test if you see a problem.

Checked in as:
 Modules/mmapmodule.c: 2.41, 2.35.6.3
 Lib/test/test_mmap.py: 1.24, 1.19.8.3
 Lib/test/output/test_mmap: 1.9, 1.8.6.1
 Misc/NEWS: 1.480, 1.337.2.4.2.34

I backported the fix, since your last message Guido seemed
to indicate that we are still supposed to do it.

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

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

Message:
Logged In: YES 
user_id=21627

I may be missing something: How precisely does this
special-case Windows in the test?

Apart from that, the patch is fine.

I'm uncertain on backporting it, because I'm uncertain how
backporting works at all since the PBF got instantiated. So
I'd suggest to mark this as a backport candidate, and let
the patch czar decide.



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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-17 12:08

Message:
Logged In: YES 
user_id=33168

Martin, would you like one last review and test on windows
before I check in?  Also, should this be backported to 2.2.?

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-13 13:39

Message:
Logged In: YES 
user_id=33168

I can't test windows.  I've attached a patch which tries to
test windows doesn't raise an exception.
I also modified the NEWS to state this change affects
non-Windows platforms.

Tim/Martin, can you test (or at least review the test code)
that this works on Windows before I check it in?  Or let me
know if you want me to check it in.  It should be easy to
fix if it doesn't work on Windows.

Thanks.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-08-12 22:11

Message:
Logged In: NO 

I'd say the following is reasonable:

- on mmap object creation, stat the file and check its size
against the size arg passed to mmap.  Signal an error if the
file is smaller than the requested mmap size.  

- On access, compare the subscript to the mmap object size
and signal an error if out of bounds (presumably this is
done already)

- Figure out if another process can truncate the file while
the mmap is alive.  If yes, maybe add a method to the mmap
object that re-stats the file and makes sure it's still
larger than the mmap size.  

- Add warnings to the mmap documentation that weirdness can
result from the file size changing etc.


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

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

Message:
Logged In: YES 
user_id=21627

I think we should special-case Windows, then. For the
mmapmodule patch proper, nothing needs to be done; for the
testsuite test, pass and fail are exactly reversed on
Windows (but then, we'd test the implementation of Windows,
so skipping that test sounds reasonable as well).

With those changes, the patch is fine.

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

Comment By: Tim Peters (tim_one)
Date: 2002-08-12 11:59

Message:
Logged In: YES 
user_id=31435

mmap() on WIndows doesn't care if you map more bytes 
than exist in the file -- if you do, it grows the file to match.

"""
If an application specifies a size for the file mapping object 
that is larger than the size of the actual named file on disk, 
the file on disk is grown to match the specified size of the 
file mapping object. If the file cannot be grown, this results 
in a failure to create the file mapping object. GetLastError 
will return ERROR_DISK_FULL.
"""

Like so:

>>> import mmap
>>> import os
>>> os.path.getsize('abc.abc')
12L
>>> f = file('abc.abc', 'r+')
>>> m = mmap.mmap(f.fileno(), 10000)
>>> m.close()
>>> os.path.getsize('abc.abc')
10000L
>>>


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-12 11:49

Message:
Logged In: YES 
user_id=33168

That last comment was supposed to be:  I don't know how
Windows behaves...

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-12 11:47

Message:
Logged In: YES 
user_id=33168

I thought the st_size was updated by the code in
new_buffersize.  It was only the position, so the comment
should go.  ValueError is fine with me.  Should I add an
entry to NEWS?  New patch attached w/NEWS and test.

There is another issue--Windows.  I how Windows behaves and
I can't test it.

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

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

Message:
Logged In: YES 
user_id=21627

I'd say it is a ValueError if the map size is larger than
the file size, instead of silently decreasing the size:
Errors should never pass silently, Unless explicitly silenced.

On the trick of new_buffersize: I'm not sure I understand
what you are referring to: we don't use stdio in mmap at all.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-12 09:30

Message:
Logged In: YES 
user_id=33168

I wasn't sure if I could change the size.  For Solaris at
least, it seems this is the right thing to do.  Is it likely
that other systems allow the file size to change?  I've
forced the size to be the max(size_arg, size_of_file).  This
has the added benefit of working for writing too.  Prior to
this patch, writing past the end crashed on Linux.

There are 2 comments in the patch:  one worrying about the
file changing, the other producing a warning message if the
size argument is larger than the file.  Do we have to worry
about the size changing?  Should we tell the user what they did?

Sorry about the old style diff.  I remembered to do the cvs
-f diff part, but forgot the -C5.  My defaults are unified.
New context patch attached.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-08-12 03:45

Message:
Logged In: NO 

Please don't even think of adding a stat call to every
access.  The whole idea of mmap is to speed up access by
eliminating system calls when you touch the file contents. 
Checking the file size at map creation is reasonable.  Some
note should also be added to the mmap doc about possible
crashes if the file size changes.

>From a Python script writer's viewpoint, the most convenient
fix is for Python to catch the bus error signal and inspect
the stack to figure out that the trap occurred in the mmap
routine, then generate and return an appropriate Python
exception.  However, doing that is pretty
platform-dependent, and attempting it in all the Python
ports that support mmap doesn't sound practical.  

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

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

Message:
Logged In: YES 
user_id=21627

Ah, an old-style diff. I assume that goes into mmap_item?

I'd rather avoid the stat call on every access, and check
the size on map creation.

The Solaris man page says this about changing files:

     If the size of the mapped file changes  after  the 
call  to
     mmap()  as  a  result  of some other operation on the
mapped
     file, the effect of references to  portions  of  the 
mapped
     region  that  correspond to added or removed portions
of the
     file is unspecified.

So it appears that this is a case of "don"t do this, then",
and that it atleast won't crash - but we might want to
perform a few experiments.



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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-11 11:05

Message:
Logged In: YES 
user_id=33168

Martin, could you please review the patch?

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-07-28 11:00

Message:
Logged In: YES 
user_id=33168

Attached is a patch which fixes this problem.  I'm not sure
this patch it correct nor appropriate.  But it stops the
crash.  I'm hoping some mmap expert can shed some light on this.

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

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


From noreply@sourceforge.net  Thu Apr 10 22:44:50 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 10 Apr 2003 14:44:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-719303 ] Icon on applets is wrong
Message-ID: <E193jqk-0002Z8-00@sc8-sf-web1.sourceforge.net>

Bugs item #719303, was opened at 2003-04-10 23:44
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=719303&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: Icon on applets is wrong

Initial Comment:
Somewhere in the process of switching to bundlebuilder for creating applets on MacOSX the generated applets have lost their icon, and in stead now have a generic application icon. This needs to be fixed.

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

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


From noreply@sourceforge.net  Thu Apr 10 22:35:36 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 10 Apr 2003 14:35:36 -0700
Subject: [Python-bugs-list] [ python-Bugs-719300 ] pimp needs to do download and untar itself
Message-ID: <E193jho-0002BW-00@sc8-sf-web1.sourceforge.net>

Bugs item #719300, was opened at 2003-04-10 23:35
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=719300&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: pimp needs to do download and untar itself

Initial Comment:
Pimp currently uses the OSX programs curl and tar to download distributions and unpack them. There is absolutely no reason not to use the urllib and tarfile modules for this.

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

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


From noreply@sourceforge.net  Thu Apr 10 22:30:15 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 10 Apr 2003 14:30:15 -0700
Subject: [Python-bugs-list] [ python-Bugs-719297 ] sys.path on MacOSX
Message-ID: <E193jcd-0001yU-00@sc8-sf-web1.sourceforge.net>

Bugs item #719297, was opened at 2003-04-10 23:30
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=719297&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: sys.path on MacOSX

Initial Comment:
On MacOSX sys.path needs to conform more to the platform standard, with extensions (read: python packages) installed in multiple places (per-user, per-machine, network-wide). We can probably ignore network-wide for the time being, and per-machine is more-or-less handled by Python's lib/site-packages, but per-user is needed.

Problem is that there are a number of reasonable places we could put these user-extensions:
- ~/Library/Python - Perl seems to do it this way.
- ~/Library/Application Support/Python - Seems like a better location
- One of the above, with "site-packages" appended - allows for more stuff in there, like IDE plugins, Package Manager packages, etc.
- One of the above, with $(VERSION)/site-packages appended - allows for installation of multiple Python versions without the binary extension modules getting in each others hair.

And only $(VERSION) isn't even good enough if this code also gets used for non-framework Pythons, because extension modules aren't compatible between framework and non-framework builds.

distutils should probably be aware of this convention, and if site-packages isn't writable to the current user fallback to the directory above (or at least give a warning explaining how to do this).

For completeness we could always add the user directory to sys.path, and add the other two (/Library, /Network/Library) only if they exist.

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

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


From noreply@sourceforge.net  Thu Apr 10 23:59:53 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 10 Apr 2003 15:59:53 -0700
Subject: [Python-bugs-list] [ python-Bugs-697220 ] string.strip implementation/doc mismatch
Message-ID: <E193l1N-0000Uo-00@sc8-sf-web3.sourceforge.net>

Bugs item #697220, was opened at 2003-03-04 07:48
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697220&group_id=5470

Category: Documentation
Group: Python 2.2.2
Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Gerhard Häring (ghaering)
Assigned to: Neal Norwitz (nnorwitz)
Summary: string.strip implementation/doc mismatch

Initial Comment:
#v+
>>> "test".strip("t")
'es'
>>> import string
>>> print string.strip("test", "t")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: strip() takes exactly 1 argument (2 given)
>>>
#v-

*But* the Python documentation says that not only the
string *method* strip() will allow a second optional
argument, but also the strip function in the string
module.
(http://www.python.org/doc/current/lib/module-string.html)

string.strip should be changed to accept the additional
 parameter.

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-10 18:59

Message:
Logged In: YES 
user_id=33168

Checked in as (updated doc slightly from Walter's patch):
 Doc/lib/libstring.tex: 1.49
 Lib/UserString.py: 1.17
 Lib/string.py: 1.68
 Lib/test/string_tests.py: 1.31
 Objects/stringobject.c: 2.208
 Objects/unicodeobject.c: 2.187

Will close after backporting changes.

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

Comment By: Walter Dörwald (doerwalter)
Date: 2003-04-02 14:39

Message:
Logged In: YES 
user_id=89016

Here are updated patches: I've renamed the arguments from
sep to chars in UserString too and I've added the
"versionchanged" info to all three functions in both patches.

I think the patches are ready now.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-30 14:54

Message:
Logged In: YES 
user_id=33168

Updated both patches to fix problem with sep--changed
docstrings to use chars.  Updated string_tests for 2.3.

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

Comment By: Walter Dörwald (doerwalter)
Date: 2003-03-20 06:36

Message:
Logged In: YES 
user_id=89016

In the patch for 2.3 a few docstrings in string.py still
mention sep instead of chars. The tests in
test/string_tests.py::MixinStrUnicodeUserStringTest.test_strip_args()
should be moved to CommonTest.test_strip() so that these
tests will be run for the string module too.

I haven't looked at the 2.2.3 patch yet.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-06 01:25

Message:
Logged In: YES 
user_id=33168

Gerhard, hopefully I've cleaned things up this time.  Could
you review both patches attached (one for 2.2.3, the other
for 2.3)?  I will send a message to python-dev to get
concurrence on the changes and hopefully more review.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-04 13:20

Message:
Logged In: YES 
user_id=33168

Thanks, you are correct.  The problem was with the string
object, not the string module.  :-(  I need to look at this
more.

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

Comment By: Gerhard Häring (ghaering)
Date: 2003-03-04 13:10

Message:
Logged In: YES 
user_id=163326

Neil, I don't think this was implemented in the 2.2
maintenance branch. That's why I'm reopening this. At least
for my 2.2 Pythons string.strip accepts one parameter only:

Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more
information.
>>> import string
>>> string.strip("test", "t")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: strip() takes exactly 1 argument (2 given)
>>>

and

Python 2.2.2 (#1, Feb  9 2003, 13:22:07)
[GCC 3.2.1 [FreeBSD] 20021119 (release)] on freebsd5
Type "help", "copyright", "credits" or "license" for more
information.
>>> import string
>>> string.strip("test", "t")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: strip() takes exactly 1 argument (2 given)

Confused.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-04 12:55

Message:
Logged In: YES 
user_id=33168

Gerhard, 2.2.2 does have 2 arguments, but 2.2.1 and before
do not.  We should really update the doc.  I thought this
was done, but apparently not.

Checked in as: libstring.tex 1.45.8.4

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

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


From noreply@sourceforge.net  Fri Apr 11 00:34:04 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 10 Apr 2003 16:34:04 -0700
Subject: [Python-bugs-list] [ python-Bugs-719367 ] string exceptions are deprecated
Message-ID: <E193lYS-0000jv-00@sc8-sf-web4.sourceforge.net>

Bugs item #719367, was opened at 2003-04-10 19:34
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=719367&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: string exceptions are deprecated

Initial Comment:
The deprecation (or at least pending deprecation) of
string exceptions should be mentioned in the doc. 
There is no mention in ref 4.2:  Doc/ref/ref4.tex.  I'm
not sure if the references to using strings should be
removed or left in with a note/warning that string
exceptions are deprecated and should be removed.  I'll
make the fix.  Just let me know how to proceed.

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

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


From noreply@sourceforge.net  Fri Apr 11 01:49:27 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 10 Apr 2003 17:49:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-706263 ] print raises exception when no console available
Message-ID: <E193mjP-0001QX-00@sc8-sf-web1.sourceforge.net>

Bugs item #706263, was opened at 2003-03-20 01:05
Message generated for change (Comment added) made by tim_evans
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706263&group_id=5470

Category: Windows
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexander Miseler (amiseler)
Assigned to: Mark Hammond (mhammond)
Summary: print raises exception when no console available

Initial Comment:
platform: win2k
testet with: 2.2.2   2.3a1   2.3a2

the test case works fine when the script is run with
python.exe. with pythonw.exe an exception is raised
after printing 4096 bytes. the exception is rather
obscure but the bytecount suggests a buffer overflow.

print (or to be more exact sys.stdout.write) should be
a noop when there is no console.


test case:
import traceback
counter = 0
try:
	for counter in range(100000):
		print 'a',
	success_file = open('success.txt', 'w')
	success_file.write('Bytes printed: %d\n' % (counter*2))
	success_file.close()
except:
	error_file = open('error.txt', 'w')
	error_file.write('Bytes printed before exception was
raised: %d\n' % (counter*2))
	traceback.print_exc(100, error_file)
	error_file.close()


output:
Bytes printed before exception was raised: 4096
Traceback (most recent call last):
  File "test_case.py", line 5, in ?
    print 'a',
IOError: [Errno 9] Bad file descriptor


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

Comment By: Tim Evans (tim_evans)
Date: 2003-04-11 12:49

Message:
Logged In: YES 
user_id=561705

Yet another alternative: when soneone writes to stdout or
stderr, open a console window and write into that.  I have
seen this used by the win32 vesion of Glade (the GTK gui
builder), so it may be a part of the win32 version of GTK or
Glib.

Personally, I would prefer just discarding the output.  This
is not inconsistant.  My gui apps on Linux are started from
the gnome panel (or an equivalent), not an xterm, so
anything they print gets discarded too.

Note that it is still posible to capture the stdout and
stderr of pythonw (at least on NT/2K/XP) by redirecting them
at the command prompt, like this: pythonw spam.pyw >
stdout.log 2> stderr.log

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

Comment By: Graham Horler (grahamh)
Date: 2003-03-27 01:59

Message:
Logged In: YES 
user_id=543663

I just submitted a bug report ([ 710041 ] sys.stdout IOError 
under Windows) with this same problem, so I closed it and will 
add some of my comments here, in the hopes they will be 
useful:

Python 2.1.2 (#31, Jan 15 2002, 17:28:11) [MSC 32 bit 
(Intel)] on win32.
Under Windoze 98, in a non-console application.

Calls to the write() methods seem to discard  the data, which 
is what I want (when running a cross-platform GUI program 
with debug print statements).

BUT, when the write() method is called with more than 
about 4KB, it raises "IOError: [Errno 9] Bad file descriptor", 
the same as if you had manually called the flush() method.

This IOError happens when write()ing even one character 
if "pythonw.exe -u" was used to start the GUI.

I work around it by defining my own bit-bucket for 
sys.std[out|err].
(NOTE: This bug was hard to track down!)


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

Comment By: Alexander Miseler (amiseler)
Date: 2003-03-21 01:40

Message:
Logged In: YES 
user_id=693638

and to say something FOR noop:
tim_one: "(nobody would write to stdout or stderr
*intending* the output be lost)"

yes, but someone would use print in an application and still
intend this application to run on any platform supported by
python.
its not really intuitive for someone programming under linux
that the print statement may limit the portability.

btw: the microsoft implementations (visual studio) of printf
and cout seem to be noops for non-console applications.
no idea how other windows compilers (mingw?) handle this.

i would consider it best, to make sys.stdout.write a noop
but to provide some other means to inquire the availability
of text output.

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

Comment By: Alexander Miseler (amiseler)
Date: 2003-03-20 21:19

Message:
Logged In: YES 
user_id=693638

then please throw a meaningful exception at first byte
written, not an obscure exception after 4096 bytes written.


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

Comment By: Tim Peters (tim_one)
Date: 2003-03-20 16:17

Message:
Logged In: YES 
user_id=31435

I can swing either way on this, or even a third:  open text 
files stdout.txt and stderr.txt in the current directory then.  
That's really aiming at a different irritation, though, that 
tracebacks end up in the bit bucket by default under 
pythonw.

BTW, making stdout and stderr /dev/null workalikes is 
least attractive to me (nobody would write to stdout or 
stderr *intending* the output be lost).  I'm (barely) OK with 
letting it stay as it is, because that just reflects Windows 
reality.

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

Comment By: Mark Hammond (mhammond)
Date: 2003-03-20 11:51

Message:
Logged In: YES 
user_id=14198

I struck this years ago, but was in a quandry.  On one hand,
sys.stdout *is* invalid, and I see no reason why Python
should mask these errors.  There may be real applications
where this failure *must* be reported to the program rather
than simply consumed.

However, I see the point that print is so basic that is
should never fail.  To my mind, the first point outweighs
the first, and the problem is fairly simply solved (see if
sys.stdout is invalid, and if so, open a file and set it to
that).

So I am afraid that, no, I don't give a rats <wink>.  Unless
conivenced otherwise (ie, by Tim or Guido) I will close this
as "not a bug" in a week or so.

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

Comment By: Tim Peters (tim_one)
Date: 2003-03-20 05:18

Message:
Logged In: YES 
user_id=31435

Mark, give a rip <wink>?

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

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


From noreply@sourceforge.net  Fri Apr 11 02:50:13 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 10 Apr 2003 18:50:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-717455 ] cygwin build failing
Message-ID: <E193ngD-0004p9-00@sc8-sf-web4.sourceforge.net>

Bugs item #717455, was opened at 2003-04-08 21:45
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=717455&group_id=5470

Category: Build
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Mark Hammond (mhammond)
Assigned to: Jason Tishler (jlt63)
Summary: cygwin build failing

Initial Comment:
Win2k, fairly recent cygwin, Python CVS trunk

configure works, build starts fine, until

gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes 
Parser/acceler.o Parser/grammar1.o Parser/listnode.o
Parser/node.o Parser/parser.o Parser/parsetok.o
Parser/bitset.o Parser/metagrammar.o Objects/obmallo
c.o Python/mysnprintf.o Parser/tokenizer_pgen.o
Parser/firstsets.o Parser/grammar.o Parser/pgen.o Pa
rser/printgrammar.o Parser/pgenmain.o  -o Parser/pgen.exe
Parser/firstsets.o(.text+0x299): In function
`calcfirstset':
/f/src/python-cvs/Parser/firstsets.c:62: undefined
reference to `__PyObject_DebugMalloc'
Parser/firstsets.o(.text+0x388):/f/src/python-cvs/Parser/firstsets.c:76:
undefined reference to `__P
yObject_DebugRealloc'
Parser/grammar.o(.text+0x24): In function `_Py_newgrammar':
/f/src/python-cvs/Parser/grammar.c:19: undefined
reference to `__PyObject_DebugMalloc'
Parser/grammar.o(.text+0xe6): In function `_Py_adddfa':
/f/src/python-cvs/Parser/grammar.c:36: undefined
reference to `__PyObject_DebugRealloc'
Parser/grammar.o(.text+0x1cb): In function `_Py_addstate':
/f/src/python-cvs/Parser/grammar.c:54: undefined
reference to `__PyObject_DebugRealloc'
Parser/grammar.o(.text+0x397): In function `_Py_addarc':
/f/src/python-cvs/Parser/grammar.c:77: undefined
reference to `__PyObject_DebugRealloc'
Parser/grammar.o(.text+0x4b1): In function `_Py_addlabel':
/f/src/python-cvs/Parser/grammar.c:96: undefined
reference to `__PyObject_DebugRealloc'

firstsetc.c:62: is a PyMem_NEW call.  The error implies
a debug build, but the flags imply release.  Configure
was done with no options.

I'm not even sure I want a pgen.exe :)  A quick scan of
python-dev and the bug list showed nothing


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

>Comment By: Mark Hammond (mhammond)
Date: 2003-04-11 11:50

Message:
Logged In: YES 
user_id=14198

Yes, pilot error of some sort.  I did a clean, but that
didn't solve the problem.  I have now found the religion of
a build directory :)  thanks.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-09 14:10

Message:
Logged In: YES 
user_id=33168

This kind of problem happens to me when I build with debug,
cvs update, then build without debug.  I suspect a make
clean will fix the problem.

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

Comment By: Jason Tishler (jlt63)
Date: 2003-04-09 01:54

Message:
Logged In: YES 
user_id=86216

Sorry, I cannot reproduce with CVS updated this morning
(ET) using my normal build procedure:

$ cvs update
...
$ mkdir build
$ cd build
$ ../configure --prefix=/usr
...
$ make
...

How did you configure? Are you building in the source tree
or a separate build tree?

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

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


From noreply@sourceforge.net  Fri Apr 11 03:51:52 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 10 Apr 2003 19:51:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-719367 ] string exceptions are deprecated
Message-ID: <E193ods-0007yk-00@sc8-sf-web3.sourceforge.net>

Bugs item #719367, was opened at 2003-04-10 19:34
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=719367&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: string exceptions are deprecated

Initial Comment:
The deprecation (or at least pending deprecation) of
string exceptions should be mentioned in the doc. 
There is no mention in ref 4.2:  Doc/ref/ref4.tex.  I'm
not sure if the references to using strings should be
removed or left in with a note/warning that string
exceptions are deprecated and should be removed.  I'll
make the fix.  Just let me know how to proceed.

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-04-10 22:51

Message:
Logged In: YES 
user_id=3066

I'll suggest this approach:

Remove all mention of string exceptions from the main text, 
and then add a child subsection (or whatever) or a "notice"** 
that describes string exceptions and their deprecated status.

The C API reference already discusses the deprecation, but 
that could stand to be updated to mention the 
PendingDeprecationWarning.

When your changes are ready, commit them to CVS; it's 
easier for me to look at them once their in.  And I'm sure 
you'll do reasonable things.  ;-)

** "notice" is a LaTeX environment in the Python styles:

\begin{notice}
  text goes here
\end{notice}

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

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


From noreply@sourceforge.net  Fri Apr 11 04:04:11 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 10 Apr 2003 20:04:11 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-719429 ] Build under Red Hat 9 requires additional include
Message-ID: <E193opn-0008L1-00@sc8-sf-web3.sourceforge.net>

Feature Requests item #719429, was opened at 2003-04-10 22:04
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=719429&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Cowles (mdcowles)
Assigned to: Nobody/Anonymous (nobody)
Summary: Build under Red Hat 9 requires additional include

Initial Comment:
In order for the socket module to build under Red Hat
9, -I/usr/kerberos/include needs to be added to the
command.

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

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


From noreply@sourceforge.net  Fri Apr 11 09:36:11 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 11 Apr 2003 01:36:11 -0700
Subject: [Python-bugs-list] [ python-Bugs-719549 ] Mac OS X painless compilation
Message-ID: <E193u15-0000bf-00@sc8-sf-web4.sourceforge.net>

Bugs item #719549, was opened at 2003-04-11 01:36
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=719549&group_id=5470

Category: Documentation
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Mac-arena the Bored Zo (boredzo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Mac OS X painless compilation

Initial Comment:
under Mac OS X 10.1, python builds without a hitch.

I'd think that it would also build under 10.2 as well, although I don't know because I've never built it on 10.2 (I don't have it).

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

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


From noreply@sourceforge.net  Fri Apr 11 09:52:48 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 11 Apr 2003 01:52:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-719549 ] Mac OS X painless compilation
Message-ID: <E193uHA-0001te-00@sc8-sf-web3.sourceforge.net>

Bugs item #719549, was opened at 2003-04-11 10:36
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=719549&group_id=5470

Category: Documentation
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Mac-arena the Bored Zo (boredzo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Mac OS X painless compilation

Initial Comment:
under Mac OS X 10.1, python builds without a hitch.

I'd think that it would also build under 10.2 as well, although I don't know because I've never built it on 10.2 (I don't have it).

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

>Comment By: Jack Jansen (jackjansen)
Date: 2003-04-11 10:52

Message:
Logged In: YES 
user_id=45365

Uhm... As this bug report bascially says "There's no problem", I assume you are referring to something in the documentation (or readme? Something else?) that states that there are problems on OSX. Could you point out where this is, or otherwise clarify your report, please?

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

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


From noreply@sourceforge.net  Fri Apr 11 09:56:43 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 11 Apr 2003 01:56:43 -0700
Subject: [Python-bugs-list] [ python-Bugs-711991 ] IDE needs easy access to builtin help()
Message-ID: <E193uKx-00023B-00@sc8-sf-web3.sourceforge.net>

Bugs item #711991, was opened at 2003-03-30 00:33
Message generated for change (Comment added) made by jvr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711991&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Just van Rossum (jvr)
Summary: IDE needs easy access to builtin help()

Initial Comment:
Just, I'm assigning this to you for feedback. Feel free to assign back after providing it.

I think we need access to the help()-style documentation in the IDE, especially when browsing objects and such it would be very helpful.

What I'm thinking of at the moment is a window called "Help for Selection" (any better ideas?), and if that window is opened it will display the help() text for the current selection. It would follow focus, i.e. when you select a different window or a different object in the same window it would change.

An alternative design would be that you would have to use a command "Show Help for Selection" which would bring up a static window with the help() contents.

A third possibility (best of both worlds?) would be a window that has a checkbox "Follow Selection", initially true. If you deselect it the window would stay open statically, and a subsequent "Show Help for Selection" command would bring up a new window with the checkbox checked.

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

>Comment By: Just van Rossum (jvr)
Date: 2003-04-11 10:56

Message:
Logged In: YES 
user_id=92689

I would just go for "Show Help for Selection". I'm not so sure how useful following the selection would be (thinking of a scenenario where you lookup some info based on the selection, then continue editing, following the help. It would be irritating if the help would disappear or change then.

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

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


From noreply@sourceforge.net  Fri Apr 11 13:52:23 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 11 Apr 2003 05:52:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-717455 ] cygwin build failing
Message-ID: <E193y11-0004wd-00@sc8-sf-web2.sourceforge.net>

Bugs item #717455, was opened at 2003-04-08 03:45
Message generated for change (Comment added) made by jlt63
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=717455&group_id=5470

Category: Build
Group: None
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Mark Hammond (mhammond)
Assigned to: Jason Tishler (jlt63)
Summary: cygwin build failing

Initial Comment:
Win2k, fairly recent cygwin, Python CVS trunk

configure works, build starts fine, until

gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes 
Parser/acceler.o Parser/grammar1.o Parser/listnode.o
Parser/node.o Parser/parser.o Parser/parsetok.o
Parser/bitset.o Parser/metagrammar.o Objects/obmallo
c.o Python/mysnprintf.o Parser/tokenizer_pgen.o
Parser/firstsets.o Parser/grammar.o Parser/pgen.o Pa
rser/printgrammar.o Parser/pgenmain.o  -o Parser/pgen.exe
Parser/firstsets.o(.text+0x299): In function
`calcfirstset':
/f/src/python-cvs/Parser/firstsets.c:62: undefined
reference to `__PyObject_DebugMalloc'
Parser/firstsets.o(.text+0x388):/f/src/python-cvs/Parser/firstsets.c:76:
undefined reference to `__P
yObject_DebugRealloc'
Parser/grammar.o(.text+0x24): In function `_Py_newgrammar':
/f/src/python-cvs/Parser/grammar.c:19: undefined
reference to `__PyObject_DebugMalloc'
Parser/grammar.o(.text+0xe6): In function `_Py_adddfa':
/f/src/python-cvs/Parser/grammar.c:36: undefined
reference to `__PyObject_DebugRealloc'
Parser/grammar.o(.text+0x1cb): In function `_Py_addstate':
/f/src/python-cvs/Parser/grammar.c:54: undefined
reference to `__PyObject_DebugRealloc'
Parser/grammar.o(.text+0x397): In function `_Py_addarc':
/f/src/python-cvs/Parser/grammar.c:77: undefined
reference to `__PyObject_DebugRealloc'
Parser/grammar.o(.text+0x4b1): In function `_Py_addlabel':
/f/src/python-cvs/Parser/grammar.c:96: undefined
reference to `__PyObject_DebugRealloc'

firstsetc.c:62: is a PyMem_NEW call.  The error implies
a debug build, but the flags imply release.  Configure
was done with no options.

I'm not even sure I want a pgen.exe :)  A quick scan of
python-dev and the bug list showed nothing


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

>Comment By: Jason Tishler (jlt63)
Date: 2003-04-11 04:52

Message:
Logged In: YES 
user_id=86216

And, the cult called "Cygwin". :,)

This bug report has piqued my interest. Why are you
fiddling with Cygwin Python? Trying to port win32com
to Cygwin, perchance? :,)

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

Comment By: Mark Hammond (mhammond)
Date: 2003-04-10 17:50

Message:
Logged In: YES 
user_id=14198

Yes, pilot error of some sort.  I did a clean, but that
didn't solve the problem.  I have now found the religion of
a build directory :)  thanks.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-08 20:10

Message:
Logged In: YES 
user_id=33168

This kind of problem happens to me when I build with debug,
cvs update, then build without debug.  I suspect a make
clean will fix the problem.

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

Comment By: Jason Tishler (jlt63)
Date: 2003-04-08 07:54

Message:
Logged In: YES 
user_id=86216

Sorry, I cannot reproduce with CVS updated this morning
(ET) using my normal build procedure:

$ cvs update
...
$ mkdir build
$ cd build
$ ../configure --prefix=/usr
...
$ make
...

How did you configure? Are you building in the source tree
or a separate build tree?

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

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


From noreply@sourceforge.net  Fri Apr 11 16:55:00 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 11 Apr 2003 08:55:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-711986 ] gensuitemodule needs to be documented
Message-ID: <E1940rk-0002bo-00@sc8-sf-web4.sourceforge.net>

Bugs item #711986, was opened at 2003-03-30 00:19
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711986&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: gensuitemodule needs to be documented

Initial Comment:
Gensuitemodule is now in the library, and it needs to be documented. Also, the old documentation in Mac/Demo probably needs an update.

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

>Comment By: Jack Jansen (jackjansen)
Date: 2003-04-11 17:54

Message:
Logged In: YES 
user_id=45365

Gensuitemodule has been documented, along with some notes on how to use it, and a description of how the Python OSA stuff works in general.

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

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


From noreply@sourceforge.net  Fri Apr 11 18:30:16 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 11 Apr 2003 10:30:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-699594 ] refcount problem involding debugger
Message-ID: <E1942Lw-0000Wq-00@sc8-sf-web2.sourceforge.net>

Bugs item #699594, was opened at 2003-03-07 14:58
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699594&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 6
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Guido van Rossum (gvanrossum)
Summary: refcount problem involding debugger

Initial Comment:
Barry and I have both seen a debug version of Python
fail when we exit an interpreter after using pdb.  The
failure in both cases is reported in line 400 of
frameobject.c on the first iteration of the loop that
frees the stack.  The object being decrefed has already
been freed.

I don't know how to reliably provoke the problem, but I
do have a core file.

(gdb) where
#0  0x42029331 in kill () from /lib/i686/libc.so.6
#1  0x40033bdb in raise () from /lib/i686/libpthread.so.0
#2  0x4202a8c2 in abort () from /lib/i686/libc.so.6
#3  0x080e4aac in Py_AtExit (func=0xbfffba80) at
../Python/pythonrun.c:1369
#4  0x0807d767 in _Py_NegativeRefcount (
    fname=0x8125884 "../Objects/frameobject.c",
lineno=400, op=0x4078e114)
    at ../Objects/object.c:104
#5  0x08105e26 in frame_dealloc (f=0x81c0d24) at
../Objects/frameobject.c:400
#6  0x08081723 in _Py_Dealloc (op=0x81c0d24) at
../Objects/object.c:1976
#7  0x080e7522 in tb_dealloc (tb=0x40788b74) at
../Python/traceback.c:41
#8  0x08081723 in _Py_Dealloc (op=0x40788b74) at
../Objects/object.c:1976
#9  0x080e74ca in tb_dealloc (tb=0x40788cb4) at
../Python/traceback.c:40
#10 0x08081723 in _Py_Dealloc (op=0x40788cb4) at
../Objects/object.c:1976
#11 0x080e74ca in tb_dealloc (tb=0x40788cf4) at
../Python/traceback.c:40
#12 0x08081723 in _Py_Dealloc (op=0x40788cf4) at
../Objects/object.c:1976
#13 0x0807a197 in PyDict_DelItem (op=0x4007f994,
key=0x4081a5e8)
    at ../Objects/dictobject.c:571
#14 0x0807d4de in PyDict_DelItemString (v=0x4007f994, 
    key=0x8119ab0 "exc_traceback") at
../Objects/dictobject.c:1973
#15 0x080e5382 in PySys_SetObject (name=0x8119ab0
"exc_traceback", v=0x0)
    at ../Python/sysmodule.c:65
#16 0x080bfa91 in reset_exc_info (tstate=0x4007c028) at
../Python/ceval.c:2750
#17 0x080be907 in eval_frame (f=0x81c058c) at
../Python/ceval.c:2367
#18 0x080bf4d3 in PyEval_EvalCodeEx (co=0x4015c9c8,
globals=0x401f2d54, 
    locals=0x0, args=0x40773898, argcount=2, kws=0x0,
kwcount=0, 
    defs=0x40162ef0, defcount=1, closure=0x0) at
../Python/ceval.c:2602
#19 0x08108877 in function_call (func=0x4016a444,
arg=0x40773884, kw=0x0)
    at ../Objects/funcobject.c:501
#20 0x0805bf67 in PyObject_Call (func=0x4016a444,
arg=0x40773884, kw=0x0)
    at ../Objects/abstract.c:1755
#21 0x08063fd6 in instancemethod_call (func=0x4016a444,
arg=0x40773884, kw=0x0)
    at ../Objects/classobject.c:2411
#22 0x0805bf67 in PyObject_Call (func=0x40730074,
arg=0x40769f4c, kw=0x0)
    at ../Objects/abstract.c:1755
#23 0x0809b4f9 in slot_tp_call (self=0x406d2d54,
args=0x40769f4c, kwds=0x0)
    at ../Objects/typeobject.c:4357
#24 0x0805bf67 in PyObject_Call (func=0x406d2d54,
arg=0x40769f4c, kw=0x0)
    at ../Objects/abstract.c:1755
#25 0x080c186d in do_call (func=0x406d2d54,
pp_stack=0xbfffc344, na=1, nk=0)
    at ../Python/ceval.c:3565
#26 0x080c1115 in call_function (pp_stack=0xbfffc344,
oparg=1)
    at ../Python/ceval.c:3381
#27 0x080bd63f in eval_frame (f=0x8178f64) at
../Python/ceval.c:2055
#28 0x080bf4d3 in PyEval_EvalCodeEx (co=0x4015f810,
globals=0x401f2d54, 
    locals=0x0, args=0x40773240, argcount=2, kws=0x0,
kwcount=0, defs=0x0, 
    defcount=0, closure=0x0) at ../Python/ceval.c:2602


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-11 13:30

Message:
Logged In: YES 
user_id=6380

I hav seen segfaults like this too, but never bothered to
debug them. :-(

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-03-07 15:57

Message:
Logged In: YES 
user_id=6380

This is going to be tricky unless we find a reliable way to
reproduce it. :-(

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

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


From noreply@sourceforge.net  Fri Apr 11 19:40:41 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 11 Apr 2003 11:40:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-697220 ] string.strip implementation/doc mismatch
Message-ID: <E1943S5-0001ru-00@sc8-sf-web3.sourceforge.net>

Bugs item #697220, was opened at 2003-03-04 07:48
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697220&group_id=5470

Category: Documentation
Group: Python 2.2.2
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Gerhard Häring (ghaering)
Assigned to: Neal Norwitz (nnorwitz)
Summary: string.strip implementation/doc mismatch

Initial Comment:
#v+
>>> "test".strip("t")
'es'
>>> import string
>>> print string.strip("test", "t")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: strip() takes exactly 1 argument (2 given)
>>>
#v-

*But* the Python documentation says that not only the
string *method* strip() will allow a second optional
argument, but also the strip function in the string
module.
(http://www.python.org/doc/current/lib/module-string.html)

string.strip should be changed to accept the additional
 parameter.

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-11 14:40

Message:
Logged In: YES 
user_id=33168

I hope this is the end of this mistake.  Let me know if
there's any other inconsistencies.  Thanks for the review
Walter!

Checked in as:
 Misc/NEWS: 1.337.2.4.2.73
 Doc/lib/libstring.tex: 1.45.8.5
 Lib/UserString.py: 1.10.18.3
 Lib/string.py: 1.60.16.5
 Objects/stringobject.c: 2.147.6.13
 Objects/unicodeobject.c: 2.124.6.21


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-10 18:59

Message:
Logged In: YES 
user_id=33168

Checked in as (updated doc slightly from Walter's patch):
 Doc/lib/libstring.tex: 1.49
 Lib/UserString.py: 1.17
 Lib/string.py: 1.68
 Lib/test/string_tests.py: 1.31
 Objects/stringobject.c: 2.208
 Objects/unicodeobject.c: 2.187

Will close after backporting changes.

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

Comment By: Walter Dörwald (doerwalter)
Date: 2003-04-02 14:39

Message:
Logged In: YES 
user_id=89016

Here are updated patches: I've renamed the arguments from
sep to chars in UserString too and I've added the
"versionchanged" info to all three functions in both patches.

I think the patches are ready now.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-30 14:54

Message:
Logged In: YES 
user_id=33168

Updated both patches to fix problem with sep--changed
docstrings to use chars.  Updated string_tests for 2.3.

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

Comment By: Walter Dörwald (doerwalter)
Date: 2003-03-20 06:36

Message:
Logged In: YES 
user_id=89016

In the patch for 2.3 a few docstrings in string.py still
mention sep instead of chars. The tests in
test/string_tests.py::MixinStrUnicodeUserStringTest.test_strip_args()
should be moved to CommonTest.test_strip() so that these
tests will be run for the string module too.

I haven't looked at the 2.2.3 patch yet.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-06 01:25

Message:
Logged In: YES 
user_id=33168

Gerhard, hopefully I've cleaned things up this time.  Could
you review both patches attached (one for 2.2.3, the other
for 2.3)?  I will send a message to python-dev to get
concurrence on the changes and hopefully more review.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-04 13:20

Message:
Logged In: YES 
user_id=33168

Thanks, you are correct.  The problem was with the string
object, not the string module.  :-(  I need to look at this
more.

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

Comment By: Gerhard Häring (ghaering)
Date: 2003-03-04 13:10

Message:
Logged In: YES 
user_id=163326

Neil, I don't think this was implemented in the 2.2
maintenance branch. That's why I'm reopening this. At least
for my 2.2 Pythons string.strip accepts one parameter only:

Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more
information.
>>> import string
>>> string.strip("test", "t")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: strip() takes exactly 1 argument (2 given)
>>>

and

Python 2.2.2 (#1, Feb  9 2003, 13:22:07)
[GCC 3.2.1 [FreeBSD] 20021119 (release)] on freebsd5
Type "help", "copyright", "credits" or "license" for more
information.
>>> import string
>>> string.strip("test", "t")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: strip() takes exactly 1 argument (2 given)

Confused.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-04 12:55

Message:
Logged In: YES 
user_id=33168

Gerhard, 2.2.2 does have 2 arguments, but 2.2.1 and before
do not.  We should really update the doc.  I thought this
was done, but apparently not.

Checked in as: libstring.tex 1.45.8.4

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

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


From noreply@sourceforge.net  Fri Apr 11 20:12:08 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 11 Apr 2003 12:12:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-719880 ] _tkinter.c doesn't build on Redhat 9
Message-ID: <E1943wW-0004mX-00@sc8-sf-web2.sourceforge.net>

Bugs item #719880, was opened at 2003-04-11 15:12
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=719880&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Martin v. Löwis (loewis)
Summary: _tkinter.c doesn't build on Redhat 9

Initial Comment:
Martin, _tkinter doesn't build on Redhat 9 because:
 _tkinter.c:92:2: #error "unsupported Tcl configuration"

TCL_UTF_MAX is defined to be 6, not 3.  I don't know
what else would be necessary to change to get this to
work.  Can you provide any ideas? 

I changed line 92 to:

    #if TCL_UTF_MAX != 3 && TCL_UTF_MAX != 6

and I was able to bring a window up with a push button.


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

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


From noreply@sourceforge.net  Fri Apr 11 20:03:02 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 11 Apr 2003 12:03:02 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-719429 ] Build under Red Hat 9 requires additional include
Message-ID: <E1943ni-0004O0-00@sc8-sf-web2.sourceforge.net>

Feature Requests item #719429, was opened at 2003-04-10 23:04
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=719429&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Cowles (mdcowles)
Assigned to: Nobody/Anonymous (nobody)
Summary: Build under Red Hat 9 requires additional include

Initial Comment:
In order for the socket module to build under Red Hat
9, -I/usr/kerberos/include needs to be added to the
command.

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-11 15:03

Message:
Logged In: YES 
user_id=33168

Attached is a patch to fix this problem.  I will check it in
for 2.3.

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

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


From noreply@sourceforge.net  Fri Apr 11 20:24:37 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 11 Apr 2003 12:24:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-719888 ] tokenize module w/ coding cookie
Message-ID: <E19448b-0003Rx-00@sc8-sf-web4.sourceforge.net>

Bugs item #719888, was opened at 2003-04-11 15:24
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=719888&group_id=5470

Category: Unicode
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Barry A. Warsaw (bwarsaw)
Assigned to: Martin v. Löwis (loewis)
Summary: tokenize module w/ coding cookie

Initial Comment:
The tokenize module should honor the coding cookie in a
file, probably so that it returns Unicode strings with
decoded characters.

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

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


From noreply@sourceforge.net  Fri Apr 11 21:08:24 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 11 Apr 2003 13:08:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-719880 ] _tkinter.c doesn't build on Redhat 9
Message-ID: <E1944oy-00037J-00@sc8-sf-web1.sourceforge.net>

Bugs item #719880, was opened at 2003-04-11 21:12
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=719880&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Martin v. Löwis (loewis)
Summary: _tkinter.c doesn't build on Redhat 9

Initial Comment:
Martin, _tkinter doesn't build on Redhat 9 because:
 _tkinter.c:92:2: #error "unsupported Tcl configuration"

TCL_UTF_MAX is defined to be 6, not 3.  I don't know
what else would be necessary to change to get this to
work.  Can you provide any ideas? 

I changed line 92 to:

    #if TCL_UTF_MAX != 3 && TCL_UTF_MAX != 6

and I was able to bring a window up with a push button.


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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-04-11 22:08

Message:
Logged In: YES 
user_id=21627

What Tcl version is that? I didn't know Tcl does UCS-4...

The comment says it all: Tcl_Unichar is expected to be two
bytes. If it isn't, and
a) Python is UCS-2: In AsObj, deal with surrogates in the
Python 
string, combining them into a single Tcl_Unichar. In
FromObj, split
non-BMP characters into two. This means that you need a copying
loop, as you cannot expect that the size of the Tcl and Python
strings will be the same.
b) Python is UCS-4. Consider also using
PyUnicode_FromUnicode in FromObj, and NewUnicodeObj in AsObj.

Alternatively, proclaim that "Tcl is UCS-4, Python is UCS-2"
is not supported, drop case a), and perform just the direct
operations in case b) (the current copying loops are still
needed for UCS-2 Tcl).

Perhaps Tcl isn't UCS-4, but uses surrogate pairs instead?
In that case, one would need to use yet other algorithms...

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

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


From noreply@sourceforge.net  Fri Apr 11 21:38:27 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 11 Apr 2003 13:38:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-707074 ] timeouts incompatible w/ line-oriented protocols
Message-ID: <E1945I3-0006bu-00@sc8-sf-web4.sourceforge.net>

Bugs item #707074, was opened at 2003-03-20 13:58
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=707074&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Skip Montanaro (montanaro)
Summary: timeouts incompatible w/ line-oriented protocols

Initial Comment:
I've come to the conclusion that, as written, the higher level line-
oriented protocols which use the socket library (httplib, ftplib,
xmlrpclib, etc) won't work with socket timeouts.  They generally do
something like:

    self.file = self.sock.makefile('rb')

then use file methods to send and receive data on the socket.

Alas, the socket docs state:

Timeout mode internally sets the socket in non-blocking mode.
The blocking and timeout modes are shared between file descriptors
and socket objects that refer to the same network endpoint.  A
consequence of this is that file objects returned by the makefile()
method should only be used when the socket is in blocking mode; in
timeout or non-blocking mode file operations that cannot be
completed immediately will fail.  

I view this state of affairs as a bug which should be fixed at some
point, as these higher level protocol modules are probably the 
predominant way sockets get used in Python programs.


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-11 16:38

Message:
Logged In: YES 
user_id=6380

Not me. I didn't even notice this was checked in! Good job.

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

Comment By: Skip Montanaro (montanaro)
Date: 2003-03-30 00:10

Message:
Logged In: YES 
user_id=44345

Okay, checked in and closed.  Let's see who screams.

Lib/socket.py 1.36
Lib/test/test_urllibnet.py 1.1
Misc/NEWS 1.705

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-29 17:55

Message:
Logged In: YES 
user_id=33168

This works for me on linux.  I don't know if there's any
issue wrt to removing _needwrapper.  Perhaps it should be
checked in and see if anyone complains?  I'm not sure who
else should review this patch.

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

Comment By: Skip Montanaro (montanaro)
Date: 2003-03-24 12:23

Message:
Logged In: YES 
user_id=44345

Jack, Any chance you can simply apply it to the source and see how it goes
on MacOS9? -Skip

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

Comment By: Jack Jansen (jackjansen)
Date: 2003-03-24 05:58

Message:
Logged In: YES 
user_id=45365

If this patch is accepted: may I request it be done soon? Changes like this often affect how things work on MacOS9 (IOW: break things on MacOS9:-), and in general changing the makefile() semantics on all non-windows platforms is something that may turn up hidden bugs, so I don't think we want this in as a last-second mod before 2.3b1 goes out.

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

Comment By: Skip Montanaro (montanaro)
Date: 2003-03-21 13:02

Message:
Logged In: YES 
user_id=44345

The attached simple patch to socket.py seems to do the trick.  No tests
fail as a result.  The new test_urllibnet test case fails on Mac OS X
without the patch and succeeds with the patch.

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

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


From noreply@sourceforge.net  Fri Apr 11 21:38:49 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 11 Apr 2003 13:38:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-719880 ] _tkinter.c doesn't build on Redhat 9
Message-ID: <E1945IP-00046w-00@sc8-sf-web1.sourceforge.net>

Bugs item #719880, was opened at 2003-04-11 15:12
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=719880&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Martin v. Löwis (loewis)
Summary: _tkinter.c doesn't build on Redhat 9

Initial Comment:
Martin, _tkinter doesn't build on Redhat 9 because:
 _tkinter.c:92:2: #error "unsupported Tcl configuration"

TCL_UTF_MAX is defined to be 6, not 3.  I don't know
what else would be necessary to change to get this to
work.  Can you provide any ideas? 

I changed line 92 to:

    #if TCL_UTF_MAX != 3 && TCL_UTF_MAX != 6

and I was able to bring a window up with a push button.


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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-11 16:38

Message:
Logged In: YES 
user_id=33168

Tcl/Tk version is 8.3.5. There were some warnings from
AsObj.  I'll look into this in more detail later.  I may ask
the redhat guys to take a look too.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-04-11 16:08

Message:
Logged In: YES 
user_id=21627

What Tcl version is that? I didn't know Tcl does UCS-4...

The comment says it all: Tcl_Unichar is expected to be two
bytes. If it isn't, and
a) Python is UCS-2: In AsObj, deal with surrogates in the
Python 
string, combining them into a single Tcl_Unichar. In
FromObj, split
non-BMP characters into two. This means that you need a copying
loop, as you cannot expect that the size of the Tcl and Python
strings will be the same.
b) Python is UCS-4. Consider also using
PyUnicode_FromUnicode in FromObj, and NewUnicodeObj in AsObj.

Alternatively, proclaim that "Tcl is UCS-4, Python is UCS-2"
is not supported, drop case a), and perform just the direct
operations in case b) (the current copying loops are still
needed for UCS-2 Tcl).

Perhaps Tcl isn't UCS-4, but uses surrogate pairs instead?
In that case, one would need to use yet other algorithms...

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

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


From noreply@sourceforge.net  Sat Apr 12 03:33:19 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 11 Apr 2003 19:33:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-717455 ] cygwin build failing
Message-ID: <E194ApT-0006HS-00@sc8-sf-web1.sourceforge.net>

Bugs item #717455, was opened at 2003-04-08 21:45
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=717455&group_id=5470

Category: Build
Group: None
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Mark Hammond (mhammond)
Assigned to: Jason Tishler (jlt63)
Summary: cygwin build failing

Initial Comment:
Win2k, fairly recent cygwin, Python CVS trunk

configure works, build starts fine, until

gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes 
Parser/acceler.o Parser/grammar1.o Parser/listnode.o
Parser/node.o Parser/parser.o Parser/parsetok.o
Parser/bitset.o Parser/metagrammar.o Objects/obmallo
c.o Python/mysnprintf.o Parser/tokenizer_pgen.o
Parser/firstsets.o Parser/grammar.o Parser/pgen.o Pa
rser/printgrammar.o Parser/pgenmain.o  -o Parser/pgen.exe
Parser/firstsets.o(.text+0x299): In function
`calcfirstset':
/f/src/python-cvs/Parser/firstsets.c:62: undefined
reference to `__PyObject_DebugMalloc'
Parser/firstsets.o(.text+0x388):/f/src/python-cvs/Parser/firstsets.c:76:
undefined reference to `__P
yObject_DebugRealloc'
Parser/grammar.o(.text+0x24): In function `_Py_newgrammar':
/f/src/python-cvs/Parser/grammar.c:19: undefined
reference to `__PyObject_DebugMalloc'
Parser/grammar.o(.text+0xe6): In function `_Py_adddfa':
/f/src/python-cvs/Parser/grammar.c:36: undefined
reference to `__PyObject_DebugRealloc'
Parser/grammar.o(.text+0x1cb): In function `_Py_addstate':
/f/src/python-cvs/Parser/grammar.c:54: undefined
reference to `__PyObject_DebugRealloc'
Parser/grammar.o(.text+0x397): In function `_Py_addarc':
/f/src/python-cvs/Parser/grammar.c:77: undefined
reference to `__PyObject_DebugRealloc'
Parser/grammar.o(.text+0x4b1): In function `_Py_addlabel':
/f/src/python-cvs/Parser/grammar.c:96: undefined
reference to `__PyObject_DebugRealloc'

firstsetc.c:62: is a PyMem_NEW call.  The error implies
a debug build, but the flags imply release.  Configure
was done with no options.

I'm not even sure I want a pgen.exe :)  A quick scan of
python-dev and the bug list showed nothing


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

>Comment By: Mark Hammond (mhammond)
Date: 2003-04-12 12:33

Message:
Logged In: YES 
user_id=14198

I think longer term, not requiring MSVC is good for Python.
 I'm also getting involed in projects where I am writing
autoconf scripts to build Python extensions on Windows - and
playing nice with cygwin makes good sense.  Are you
interested in answering autoconf questions for me? ;)

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

Comment By: Jason Tishler (jlt63)
Date: 2003-04-11 22:52

Message:
Logged In: YES 
user_id=86216

And, the cult called "Cygwin". :,)

This bug report has piqued my interest. Why are you
fiddling with Cygwin Python? Trying to port win32com
to Cygwin, perchance? :,)

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

Comment By: Mark Hammond (mhammond)
Date: 2003-04-11 11:50

Message:
Logged In: YES 
user_id=14198

Yes, pilot error of some sort.  I did a clean, but that
didn't solve the problem.  I have now found the religion of
a build directory :)  thanks.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-09 14:10

Message:
Logged In: YES 
user_id=33168

This kind of problem happens to me when I build with debug,
cvs update, then build without debug.  I suspect a make
clean will fix the problem.

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

Comment By: Jason Tishler (jlt63)
Date: 2003-04-09 01:54

Message:
Logged In: YES 
user_id=86216

Sorry, I cannot reproduce with CVS updated this morning
(ET) using my normal build procedure:

$ cvs update
...
$ mkdir build
$ cd build
$ ../configure --prefix=/usr
...
$ make
...

How did you configure? Are you building in the source tree
or a separate build tree?

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

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


From noreply@sourceforge.net  Sat Apr 12 11:36:00 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 12 Apr 2003 03:36:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-719880 ] _tkinter.c doesn't build on Redhat 9
Message-ID: <E194IMa-0002xa-00@sc8-sf-web4.sourceforge.net>

Bugs item #719880, was opened at 2003-04-11 21:12
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=719880&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Martin v. Löwis (loewis)
Summary: _tkinter.c doesn't build on Redhat 9

Initial Comment:
Martin, _tkinter doesn't build on Redhat 9 because:
 _tkinter.c:92:2: #error "unsupported Tcl configuration"

TCL_UTF_MAX is defined to be 6, not 3.  I don't know
what else would be necessary to change to get this to
work.  Can you provide any ideas? 

I changed line 92 to:

    #if TCL_UTF_MAX != 3 && TCL_UTF_MAX != 6

and I was able to bring a window up with a push button.


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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-04-12 12:36

Message:
Logged In: YES 
user_id=21627

I just looked at their source RPM, and I can't believe what
I'm seeing :-(

There is tcltk-8.3.5-ucs4-for-py.patch, which reads

--- tcl8.3.5/generic/tcl.h~	2003-02-04 10:01:20.000000000 +0900
+++ tcl8.3.5/generic/tcl.h	2003-02-04 10:01:20.000000000 +0900
@@ -1604,13 +1604,13 @@
  * Unicode character in UTF-8.
  */
 
-#define TCL_UTF_MAX		3
+#define TCL_UTF_MAX		6
 
 /*
  * This represents a Unicode character.  
  */
 
-typedef unsigned short Tcl_UniChar;
+typedef wchar_t Tcl_UniChar;
 
 /*
  * Deprecated Tcl procedures:

I'd say they have tricked themselves: Py22 would fail to
work with Tcl in UCS-4 mode. Instead of fixing this in
tkinter (as I did for Python 2.3), they just patched tcl...
However, Tcl itself seems to be prepared for that mode of
operation; atleast their UTF-8 codec knows how to convert 6
bytes into a single int.

I would suggest that we mandate UCS-4 on Redhat 9 (through
README), and fix it for this case (i.e. allow UTF_MAX to be
6 only if unicode is wide, and narrow the UNICODE_WIDE test
to && UTF_MAX==3).

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-11 22:38

Message:
Logged In: YES 
user_id=33168

Tcl/Tk version is 8.3.5. There were some warnings from
AsObj.  I'll look into this in more detail later.  I may ask
the redhat guys to take a look too.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-04-11 22:08

Message:
Logged In: YES 
user_id=21627

What Tcl version is that? I didn't know Tcl does UCS-4...

The comment says it all: Tcl_Unichar is expected to be two
bytes. If it isn't, and
a) Python is UCS-2: In AsObj, deal with surrogates in the
Python 
string, combining them into a single Tcl_Unichar. In
FromObj, split
non-BMP characters into two. This means that you need a copying
loop, as you cannot expect that the size of the Tcl and Python
strings will be the same.
b) Python is UCS-4. Consider also using
PyUnicode_FromUnicode in FromObj, and NewUnicodeObj in AsObj.

Alternatively, proclaim that "Tcl is UCS-4, Python is UCS-2"
is not supported, drop case a), and perform just the direct
operations in case b) (the current copying loops are still
needed for UCS-2 Tcl).

Perhaps Tcl isn't UCS-4, but uses surrogate pairs instead?
In that case, one would need to use yet other algorithms...

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

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


From noreply@sourceforge.net  Mon Apr 14 05:58:53 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 13 Apr 2003 21:58:53 -0700
Subject: [Python-bugs-list] [ python-Bugs-720908 ] datetime types don't work as bases
Message-ID: <E194w3R-0007sW-00@sc8-sf-web3.sourceforge.net>

Bugs item #720908, was opened at 2003-04-14 00:58
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=720908&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Guido van Rossum (gvanrossum)
Summary: datetime types don't work as bases

Initial Comment:
This is probably shallow.  Assigned to Guido in case 
it's very shallow <wink>:

>>> from datetime import *
>>> class C(date):
...     def whatever(self):
...         return "oops"
>>> c = C(2002, 1, 1)
>>> c.whatever()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
AttributeError: 'datetime.date' object has no 
attribute 'whatever'
>>> type(c)
<type 'datetime.date'>
>>>

Was reported on c.l.py.

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

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


From noreply@sourceforge.net  Mon Apr 14 13:04:45 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 14 Apr 2003 05:04:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-720908 ] datetime types don't work as bases
Message-ID: <E1952hZ-00057u-00@sc8-sf-web3.sourceforge.net>

Bugs item #720908, was opened at 2003-04-14 00:58
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=720908&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
>Assigned to: Tim Peters (tim_one)
Summary: datetime types don't work as bases

Initial Comment:
This is probably shallow.  Assigned to Guido in case 
it's very shallow <wink>:

>>> from datetime import *
>>> class C(date):
...     def whatever(self):
...         return "oops"
>>> c = C(2002, 1, 1)
>>> c.whatever()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
AttributeError: 'datetime.date' object has no 
attribute 'whatever'
>>> type(c)
<type 'datetime.date'>
>>>

Was reported on c.l.py.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-14 08:04

Message:
Logged In: YES 
user_id=6380

Well, one shallow thing becomes obvious when you write
c.__class__: it's date, not C! Back to Tim...

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

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


From noreply@sourceforge.net  Mon Apr 14 13:09:52 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 14 Apr 2003 05:09:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-717455 ] cygwin build failing
Message-ID: <E1952mW-0008Vo-00@sc8-sf-web2.sourceforge.net>

Bugs item #717455, was opened at 2003-04-08 03:45
Message generated for change (Comment added) made by jlt63
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=717455&group_id=5470

Category: Build
Group: None
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Mark Hammond (mhammond)
Assigned to: Jason Tishler (jlt63)
Summary: cygwin build failing

Initial Comment:
Win2k, fairly recent cygwin, Python CVS trunk

configure works, build starts fine, until

gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes 
Parser/acceler.o Parser/grammar1.o Parser/listnode.o
Parser/node.o Parser/parser.o Parser/parsetok.o
Parser/bitset.o Parser/metagrammar.o Objects/obmallo
c.o Python/mysnprintf.o Parser/tokenizer_pgen.o
Parser/firstsets.o Parser/grammar.o Parser/pgen.o Pa
rser/printgrammar.o Parser/pgenmain.o  -o Parser/pgen.exe
Parser/firstsets.o(.text+0x299): In function
`calcfirstset':
/f/src/python-cvs/Parser/firstsets.c:62: undefined
reference to `__PyObject_DebugMalloc'
Parser/firstsets.o(.text+0x388):/f/src/python-cvs/Parser/firstsets.c:76:
undefined reference to `__P
yObject_DebugRealloc'
Parser/grammar.o(.text+0x24): In function `_Py_newgrammar':
/f/src/python-cvs/Parser/grammar.c:19: undefined
reference to `__PyObject_DebugMalloc'
Parser/grammar.o(.text+0xe6): In function `_Py_adddfa':
/f/src/python-cvs/Parser/grammar.c:36: undefined
reference to `__PyObject_DebugRealloc'
Parser/grammar.o(.text+0x1cb): In function `_Py_addstate':
/f/src/python-cvs/Parser/grammar.c:54: undefined
reference to `__PyObject_DebugRealloc'
Parser/grammar.o(.text+0x397): In function `_Py_addarc':
/f/src/python-cvs/Parser/grammar.c:77: undefined
reference to `__PyObject_DebugRealloc'
Parser/grammar.o(.text+0x4b1): In function `_Py_addlabel':
/f/src/python-cvs/Parser/grammar.c:96: undefined
reference to `__PyObject_DebugRealloc'

firstsetc.c:62: is a PyMem_NEW call.  The error implies
a debug build, but the flags imply release.  Configure
was done with no options.

I'm not even sure I want a pgen.exe :)  A quick scan of
python-dev and the bug list showed nothing


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

>Comment By: Jason Tishler (jlt63)
Date: 2003-04-14 04:09

Message:
Logged In: YES 
user_id=86216

> I think longer term, not requiring MSVC
> is good for Python.

Agreed.  Are you referring to Gerhard
Häring's Mingw Python work above? For
example:

	http://sf.net/tracker/?
func=detail&atid=305470&aid=618791&group_id=5470

I haven't been following this very
closely.  Is the Mingw port complete?

> I'm also getting involed in projects
> where I am writing autoconf scripts to
> build Python extensions on Windows -
> and playing nice with cygwin makes
> good sense.

Agreed. BTW, I didn't mean to be
provocative -- I was just curious.

> Are you interested in answering
> autoconf questions for me? ;)

I only have limited autoconf experience,
but I'm willing to help in any way that
I can.

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

Comment By: Mark Hammond (mhammond)
Date: 2003-04-11 18:33

Message:
Logged In: YES 
user_id=14198

I think longer term, not requiring MSVC is good for Python.
 I'm also getting involed in projects where I am writing
autoconf scripts to build Python extensions on Windows - and
playing nice with cygwin makes good sense.  Are you
interested in answering autoconf questions for me? ;)

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

Comment By: Jason Tishler (jlt63)
Date: 2003-04-11 04:52

Message:
Logged In: YES 
user_id=86216

And, the cult called "Cygwin". :,)

This bug report has piqued my interest. Why are you
fiddling with Cygwin Python? Trying to port win32com
to Cygwin, perchance? :,)

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

Comment By: Mark Hammond (mhammond)
Date: 2003-04-10 17:50

Message:
Logged In: YES 
user_id=14198

Yes, pilot error of some sort.  I did a clean, but that
didn't solve the problem.  I have now found the religion of
a build directory :)  thanks.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-08 20:10

Message:
Logged In: YES 
user_id=33168

This kind of problem happens to me when I build with debug,
cvs update, then build without debug.  I suspect a make
clean will fix the problem.

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

Comment By: Jason Tishler (jlt63)
Date: 2003-04-08 07:54

Message:
Logged In: YES 
user_id=86216

Sorry, I cannot reproduce with CVS updated this morning
(ET) using my normal build procedure:

$ cvs update
...
$ mkdir build
$ cd build
$ ../configure --prefix=/usr
...
$ make
...

How did you configure? Are you building in the source tree
or a separate build tree?

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

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


From noreply@sourceforge.net  Mon Apr 14 15:47:28 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 14 Apr 2003 07:47:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-719300 ] pimp needs to do download and untar itself
Message-ID: <E1955F2-0004Nb-00@sc8-sf-web3.sourceforge.net>

Bugs item #719300, was opened at 2003-04-10 23:35
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=719300&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
>Priority: 6
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: pimp needs to do download and untar itself

Initial Comment:
Pimp currently uses the OSX programs curl and tar to download distributions and unpack them. There is absolutely no reason not to use the urllib and tarfile modules for this.

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

>Comment By: Jack Jansen (jackjansen)
Date: 2003-04-14 16:47

Message:
Logged In: YES 
user_id=45365

There is actually a very good reason to use at least the tarfile module: if we 
use that in stead of unix tar we can fiddle pathnames while we unpack. 
Thereby we can do per-user installs of packages even if the tarfile was 
created for a system-wide installation. (That is, once the details of where 
per-user packages are going to be stored have been worked out).

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

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


From noreply@sourceforge.net  Mon Apr 14 16:09:08 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 14 Apr 2003 08:09:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-721157 ] Building lib.pdf fails on MacOSX
Message-ID: <E1955a0-0004WT-00@sc8-sf-web1.sourceforge.net>

Bugs item #721157, was opened at 2003-04-14 17:09
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=721157&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Building lib.pdf fails on MacOSX

Initial Comment:
I can't build lib.pdf on MacOSX anymore. I tried both a4 and letter.
The pdflatex call fails with

Error: pdflatex: buffer overflow [125000 bytes]

The whole lib.how is attached (if I don't forget to check the 
checkmark:-).

pdflatex -version prints

pdfTeX (Web2C 7.3.3.1) 3.14159-0.14h-released-20010417

which seems to be newer than what the README lists as the minimal 
requirement.

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

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


From noreply@sourceforge.net  Mon Apr 14 16:12:21 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 14 Apr 2003 08:12:21 -0700
Subject: [Python-bugs-list] [ python-Bugs-721160 ] Acrobat Reader 5 compatibility
Message-ID: <E1955d7-0004hZ-00@sc8-sf-web1.sourceforge.net>

Bugs item #721160, was opened at 2003-04-14 17:12
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=721160&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Acrobat Reader 5 compatibility

Initial Comment:
I read the comment about Adobe admitting that it can't print the 
Python documentation is their fault, but as the bug doesn't seem to 
get fixed, is there any workaround that we could make?

Especially on MacOSX you have the problem that there is no Acrobat 4 
that you can use (unless you want to run it under Classic), and it 
seems a bit silly to have all this beautiful documentation that people 
then can't print...

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

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


From noreply@sourceforge.net  Mon Apr 14 16:32:08 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 14 Apr 2003 08:32:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-721171 ] Tkinter precision loss for doubles
Message-ID: <E1955wG-0005fu-00@sc8-sf-web1.sourceforge.net>

Bugs item #721171, was opened at 2003-04-14 11:32
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=721171&group_id=5470

Category: Tkinter
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Martin v. Löwis (loewis)
Summary: Tkinter precision loss for doubles

Initial Comment:
DoubleVar.set() (I think) goes thru PyObject_Str(), 
causing precision loss for doubles:

>>> import Tkinter
>>> import math
>>> x = Tkinter.DoubleVar(Tkinter.Tk())
>>> x.set(math.pi)
>>> x.get()
3.1415926535900001   # not good
>>> math.pi
3.1415926535897931   # original precision
>>> eval(str(math.pi))
3.1415926535900001   # reproduces Tk result
>>>

Reported on c.l.py.  Guido says you may know how to 
create a "native" Tcl/Tk double in this case instead.

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

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


From noreply@sourceforge.net  Mon Apr 14 16:44:16 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 14 Apr 2003 08:44:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-721160 ] Acrobat Reader 5 compatibility
Message-ID: <E195680-0007KY-00@sc8-sf-web3.sourceforge.net>

Bugs item #721160, was opened at 2003-04-14 17:12
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=721160&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Acrobat Reader 5 compatibility

Initial Comment:
I read the comment about Adobe admitting that it can't print the 
Python documentation is their fault, but as the bug doesn't seem to 
get fixed, is there any workaround that we could make?

Especially on MacOSX you have the problem that there is no Acrobat 4 
that you can use (unless you want to run it under Classic), and it 
seems a bit silly to have all this beautiful documentation that people 
then can't print...

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

>Comment By: Thomas Heller (theller)
Date: 2003-04-14 17:44

Message:
Logged In: YES 
user_id=11105

I have been in contact with two other people about this bug,
here is an extract from some conversation we had.  I'll be
happy to mail Fred his email adress, don't want to post it
here on the web.


> * From all I read, it seems that Fred Drake is convinced
the problem
> is an Acrobat bug, while you seem to have a good case it's
actually
> a problem in python.sty. At this point, contacting the
Python guys

Well, there is a bug in Acrobat Reader, but recent pdftex
versions
have a workaround for it. It might be that this is a different
problem.

> is appropriate - it would be great if you want to help here.

Yes, I'll do this next week.

> * About \url: actually I was suprized to see that urls
don't work
> as a link from my Acrobat (though I think I have a weblink
set up
> properly) - can that be related to the issue you describe?

It seems python.sty defines its own \url command which
apparently
used to create hyperlinks, but as it was tailored to very
specific
pdftex (and hyperref) versions, it breaks now.

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

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


From noreply@sourceforge.net  Mon Apr 14 16:45:22 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 14 Apr 2003 08:45:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-721171 ] Tkinter precision loss for doubles
Message-ID: <E195694-0001gI-00@sc8-sf-web2.sourceforge.net>

Bugs item #721171, was opened at 2003-04-14 11:32
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=721171&group_id=5470

Category: Tkinter
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Martin v. Löwis (loewis)
Summary: Tkinter precision loss for doubles

Initial Comment:
DoubleVar.set() (I think) goes thru PyObject_Str(), 
causing precision loss for doubles:

>>> import Tkinter
>>> import math
>>> x = Tkinter.DoubleVar(Tkinter.Tk())
>>> x.set(math.pi)
>>> x.get()
3.1415926535900001   # not good
>>> math.pi
3.1415926535897931   # original precision
>>> eval(str(math.pi))
3.1415926535900001   # reproduces Tk result
>>>

Reported on c.l.py.  Guido says you may know how to 
create a "native" Tcl/Tk double in this case instead.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-14 11:45

Message:
Logged In: YES 
user_id=6380

If a proper fix using Tcl float/double objects doesn't work
for some reason, maybe the attached fix (_tkinter.fix) would
work?

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

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


From noreply@sourceforge.net  Mon Apr 14 18:26:08 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 14 Apr 2003 10:26:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-720908 ] datetime types don't work as bases
Message-ID: <E1957ia-0002sa-00@sc8-sf-web1.sourceforge.net>

Bugs item #720908, was opened at 2003-04-14 00:58
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=720908&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Tim Peters (tim_one)
Summary: datetime types don't work as bases

Initial Comment:
This is probably shallow.  Assigned to Guido in case 
it's very shallow <wink>:

>>> from datetime import *
>>> class C(date):
...     def whatever(self):
...         return "oops"
>>> c = C(2002, 1, 1)
>>> c.whatever()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
AttributeError: 'datetime.date' object has no 
attribute 'whatever'
>>> type(c)
<type 'datetime.date'>
>>>

Was reported on c.l.py.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-14 13:26

Message:
Logged In: YES 
user_id=6380

Here's a strawman fix. It makes 'date' a properly
subclassable type, and makes all the other types (except
tzinfo) non-subclassable.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-14 08:04

Message:
Logged In: YES 
user_id=6380

Well, one shallow thing becomes obvious when you write
c.__class__: it's date, not C! Back to Tim...

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

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


From noreply@sourceforge.net  Mon Apr 14 21:43:24 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 14 Apr 2003 13:43:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-721402 ] Random on PPC is outside acceptable range.
Message-ID: <E195AnU-0007ES-00@sc8-sf-web2.sourceforge.net>

Bugs item #721402, was opened at 2003-04-14 15:43
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=721402&group_id=5470

Category: Extension Modules
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Kyle Wheeler (memoryhole)
Assigned to: Nobody/Anonymous (nobody)
Summary: Random on PPC is outside acceptable range.

Initial Comment:
On LinuxPPC, with gcc 2.96, python's (2.2.2) random function is outside the acceptable range. For example:

>>> import random
>>> print random.random()
1.35933812391

This random function, I believe, is supposed to produce numbers between 0 and 1.

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

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


From noreply@sourceforge.net  Mon Apr 14 22:14:14 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 14 Apr 2003 14:14:14 -0700
Subject: [Python-bugs-list] [ python-Bugs-721402 ] Random on PPC is outside acceptable range.
Message-ID: <E195BHK-0005wH-00@sc8-sf-web3.sourceforge.net>

Bugs item #721402, was opened at 2003-04-14 16:43
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=721402&group_id=5470

Category: Extension Modules
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Kyle Wheeler (memoryhole)
Assigned to: Nobody/Anonymous (nobody)
Summary: Random on PPC is outside acceptable range.

Initial Comment:
On LinuxPPC, with gcc 2.96, python's (2.2.2) random function is outside the acceptable range. For example:

>>> import random
>>> print random.random()
1.35933812391

This random function, I believe, is supposed to produce numbers between 0 and 1.

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

>Comment By: Tim Peters (tim_one)
Date: 2003-04-14 17:14

Message:
Logged In: YES 
user_id=31435

What does the following statement print under this Python:

print 1.35933812391 % 1,.0

?

Note that there's almost no chance this is a bug in Python 
(the implementation of random() hasn't changed in about 10 
years).  There's a good chance it's a bug in the specific  C 
compiler or C library release you're using.

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

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


From noreply@sourceforge.net  Mon Apr 14 22:35:36 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 14 Apr 2003 14:35:36 -0700
Subject: [Python-bugs-list] [ python-Bugs-721402 ] Random on PPC is outside acceptable range.
Message-ID: <E195Bc0-0007dl-00@sc8-sf-web4.sourceforge.net>

Bugs item #721402, was opened at 2003-04-14 16:43
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=721402&group_id=5470

Category: Extension Modules
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Kyle Wheeler (memoryhole)
Assigned to: Nobody/Anonymous (nobody)
Summary: Random on PPC is outside acceptable range.

Initial Comment:
On LinuxPPC, with gcc 2.96, python's (2.2.2) random function is outside the acceptable range. For example:

>>> import random
>>> print random.random()
1.35933812391

This random function, I believe, is supposed to produce numbers between 0 and 1.

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

>Comment By: Tim Peters (tim_one)
Date: 2003-04-14 17:35

Message:
Logged In: YES 
user_id=31435

Heh.  Sorry about the "1.,0" -- that was a typo.  "1.0" was 
intended.

For the rest, floating mod is clearly broken in this Python, 
and that's why random() is goofy (the last step in random() is 
a fload mod).   It's not broken on any platform I have, so I 
can't be much help.

First thing to try is to recompile Python with optimizations 
disabled.  If it still fails, step thru floatobject.c's float_rem 
function in a debugger and see where it's getting an insane 
result.

If you know how to write C code, it could be that printing the 
result of C

#import <math.h>
double x = fmod(1.35933812391, 1.0);

will show a bug instantly (in which case your C libm has the 
bug).

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

Comment By: Kyle Wheeler (memoryhole)
Date: 2003-04-14 17:19

Message:
Logged In: YES 
user_id=17596

Python 2.2.2 (#1, Apr 13 2003, 16:19:28) 
[GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-110)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import random
>>> print 1.35933812391 % 1,.0
1.35933812391 0.0
>>> print 1.35933812391 % 1.0
1.35933812391
>>> print 4%2                
0
>>> print 1.3%2
3.3

Any ideas?

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

Comment By: Tim Peters (tim_one)
Date: 2003-04-14 17:14

Message:
Logged In: YES 
user_id=31435

What does the following statement print under this Python:

print 1.35933812391 % 1,.0

?

Note that there's almost no chance this is a bug in Python 
(the implementation of random() hasn't changed in about 10 
years).  There's a good chance it's a bug in the specific  C 
compiler or C library release you're using.

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

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


From noreply@sourceforge.net  Mon Apr 14 22:19:16 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 14 Apr 2003 14:19:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-721402 ] Random on PPC is outside acceptable range.
Message-ID: <E195BMC-0000Pq-00@sc8-sf-web2.sourceforge.net>

Bugs item #721402, was opened at 2003-04-14 15:43
Message generated for change (Comment added) made by memoryhole
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=721402&group_id=5470

Category: Extension Modules
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Kyle Wheeler (memoryhole)
Assigned to: Nobody/Anonymous (nobody)
Summary: Random on PPC is outside acceptable range.

Initial Comment:
On LinuxPPC, with gcc 2.96, python's (2.2.2) random function is outside the acceptable range. For example:

>>> import random
>>> print random.random()
1.35933812391

This random function, I believe, is supposed to produce numbers between 0 and 1.

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

>Comment By: Kyle Wheeler (memoryhole)
Date: 2003-04-14 16:19

Message:
Logged In: YES 
user_id=17596

Python 2.2.2 (#1, Apr 13 2003, 16:19:28) 
[GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-110)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import random
>>> print 1.35933812391 % 1,.0
1.35933812391 0.0
>>> print 1.35933812391 % 1.0
1.35933812391
>>> print 4%2                
0
>>> print 1.3%2
3.3

Any ideas?

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

Comment By: Tim Peters (tim_one)
Date: 2003-04-14 16:14

Message:
Logged In: YES 
user_id=31435

What does the following statement print under this Python:

print 1.35933812391 % 1,.0

?

Note that there's almost no chance this is a bug in Python 
(the implementation of random() hasn't changed in about 10 
years).  There's a good chance it's a bug in the specific  C 
compiler or C library release you're using.

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

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


From noreply@sourceforge.net  Mon Apr 14 23:02:30 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 14 Apr 2003 15:02:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-720908 ] datetime types don't work as bases
Message-ID: <E195C22-0000Cl-00@sc8-sf-web4.sourceforge.net>

Bugs item #720908, was opened at 2003-04-14 00:58
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=720908&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: datetime types don't work as bases

Initial Comment:
This is probably shallow.  Assigned to Guido in case 
it's very shallow <wink>:

>>> from datetime import *
>>> class C(date):
...     def whatever(self):
...         return "oops"
>>> c = C(2002, 1, 1)
>>> c.whatever()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
AttributeError: 'datetime.date' object has no 
attribute 'whatever'
>>> type(c)
<type 'datetime.date'>
>>>

Was reported on c.l.py.

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

>Comment By: Tim Peters (tim_one)
Date: 2003-04-14 18:02

Message:
Logged In: YES 
user_id=31435

I think the date enhancement is fine -- check it in!  I'd leave off 
removing the basetype flag on the other types, though -- I 
expect we'll need to make them subclassable too.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-14 13:26

Message:
Logged In: YES 
user_id=6380

Here's a strawman fix. It makes 'date' a properly
subclassable type, and makes all the other types (except
tzinfo) non-subclassable.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-14 08:04

Message:
Logged In: YES 
user_id=6380

Well, one shallow thing becomes obvious when you write
c.__class__: it's date, not C! Back to Tim...

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

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


From noreply@sourceforge.net  Mon Apr 14 23:20:21 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 14 Apr 2003 15:20:21 -0700
Subject: [Python-bugs-list] [ python-Bugs-720908 ] datetime types don't work as bases
Message-ID: <E195CJJ-0008PQ-00@sc8-sf-web3.sourceforge.net>

Bugs item #720908, was opened at 2003-04-14 00:58
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=720908&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
>Assigned to: Tim Peters (tim_one)
Summary: datetime types don't work as bases

Initial Comment:
This is probably shallow.  Assigned to Guido in case 
it's very shallow <wink>:

>>> from datetime import *
>>> class C(date):
...     def whatever(self):
...         return "oops"
>>> c = C(2002, 1, 1)
>>> c.whatever()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
AttributeError: 'datetime.date' object has no 
attribute 'whatever'
>>> type(c)
<type 'datetime.date'>
>>>

Was reported on c.l.py.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-14 18:20

Message:
Logged In: YES 
user_id=6380

Done; the rest is up to you!

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

Comment By: Tim Peters (tim_one)
Date: 2003-04-14 18:02

Message:
Logged In: YES 
user_id=31435

I think the date enhancement is fine -- check it in!  I'd leave off 
removing the basetype flag on the other types, though -- I 
expect we'll need to make them subclassable too.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-14 13:26

Message:
Logged In: YES 
user_id=6380

Here's a strawman fix. It makes 'date' a properly
subclassable type, and makes all the other types (except
tzinfo) non-subclassable.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-14 08:04

Message:
Logged In: YES 
user_id=6380

Well, one shallow thing becomes obvious when you write
c.__class__: it's date, not C! Back to Tim...

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

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


From noreply@sourceforge.net  Tue Apr 15 01:36:07 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 14 Apr 2003 17:36:07 -0700
Subject: [Python-bugs-list] [ python-Bugs-718532 ] inspect, class instances and __getattr__
Message-ID: <E195EQh-0006nj-00@sc8-sf-web2.sourceforge.net>

Bugs item #718532, was opened at 2003-04-09 15:01
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=718532&group_id=5470

Category: Python Library
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Stefan Schwarzer (sschwarzer)
Assigned to: Nobody/Anonymous (nobody)
Summary: inspect, class instances and __getattr__

Initial Comment:
inspect.isclass(class_instance) fails if the
corresponding class uses a "wildcard" implementation of
__getattr__.

Example:

Python 2.2.2 (#1, Nov 13 2002, 22:53:57) 
[GCC 2.95.4 20020320 [FreeBSD]] on freebsd4
Type "help", "copyright", "credits" or "license" for
more information.
>>> import inspect
>>> class X:
...     def __getattr__(self, name):
...             if name == 'foo':
...                     return 1   
...             if name == 'bar':
...                     return 2
...             else:
...                     return "default"
... 
>>> x = X()
>>> inspect.isclass(x)
1

The problematic expression in inspect.isclass is
hasattr(object, '__bases__') which returns a true value.

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-14 19:36

Message:
Logged In: YES 
user_id=80475

Hmm.  I'm not sure that counts as a bug.  In an OO 
language, it's a feature that objects can be made to look 
like and be substituable for other types.  In this case, 
you've taught your object to be able to fake some classlike 
behavior (having a __bases__ attribute).

OTOH, inspect could have a stronger test for classhood:    
type(object) in (types.TypeType, types.ClassType)

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

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


From noreply@sourceforge.net  Tue Apr 15 09:01:09 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 15 Apr 2003 01:01:09 -0700
Subject: [Python-bugs-list] [ python-Bugs-718532 ] inspect, class instances and __getattr__
Message-ID: <E195LNN-0002Fj-00@sc8-sf-web2.sourceforge.net>

Bugs item #718532, was opened at 2003-04-09 22:01
Message generated for change (Comment added) made by sschwarzer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=718532&group_id=5470

Category: Python Library
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Stefan Schwarzer (sschwarzer)
Assigned to: Nobody/Anonymous (nobody)
Summary: inspect, class instances and __getattr__

Initial Comment:
inspect.isclass(class_instance) fails if the
corresponding class uses a "wildcard" implementation of
__getattr__.

Example:

Python 2.2.2 (#1, Nov 13 2002, 22:53:57) 
[GCC 2.95.4 20020320 [FreeBSD]] on freebsd4
Type "help", "copyright", "credits" or "license" for
more information.
>>> import inspect
>>> class X:
...     def __getattr__(self, name):
...             if name == 'foo':
...                     return 1   
...             if name == 'bar':
...                     return 2
...             else:
...                     return "default"
... 
>>> x = X()
>>> inspect.isclass(x)
1

The problematic expression in inspect.isclass is
hasattr(object, '__bases__') which returns a true value.

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

>Comment By: Stefan Schwarzer (sschwarzer)
Date: 2003-04-15 10:01

Message:
Logged In: YES 
user_id=383516

Hello Raymond, thanks for your reply. In fact, I'm also not
sure if it counts as a bug. I also suggested a patch (handle
__getattr__ requests for __bases__ with an AttributeError)
for for the SF project which causes/d the problem.

I think, if there's a better way to decide on "class-ness"
than now, the code in inspect should be changed.
Fortunately, it doesn't have to be backward-compatible,
because the module is always distributed with a certain
interpreter version.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-15 02:36

Message:
Logged In: YES 
user_id=80475

Hmm.  I'm not sure that counts as a bug.  In an OO 
language, it's a feature that objects can be made to look 
like and be substituable for other types.  In this case, 
you've taught your object to be able to fake some classlike 
behavior (having a __bases__ attribute).

OTOH, inspect could have a stronger test for classhood:    
type(object) in (types.TypeType, types.ClassType)

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

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


From noreply@sourceforge.net  Tue Apr 15 11:01:29 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 15 Apr 2003 03:01:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-718532 ] inspect, class instances and __getattr__
Message-ID: <E195NFp-00046Z-00@sc8-sf-web3.sourceforge.net>

Bugs item #718532, was opened at 2003-04-09 22:01
Message generated for change (Comment added) made by doerwalter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=718532&group_id=5470

Category: Python Library
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Stefan Schwarzer (sschwarzer)
Assigned to: Nobody/Anonymous (nobody)
Summary: inspect, class instances and __getattr__

Initial Comment:
inspect.isclass(class_instance) fails if the
corresponding class uses a "wildcard" implementation of
__getattr__.

Example:

Python 2.2.2 (#1, Nov 13 2002, 22:53:57) 
[GCC 2.95.4 20020320 [FreeBSD]] on freebsd4
Type "help", "copyright", "credits" or "license" for
more information.
>>> import inspect
>>> class X:
...     def __getattr__(self, name):
...             if name == 'foo':
...                     return 1   
...             if name == 'bar':
...                     return 2
...             else:
...                     return "default"
... 
>>> x = X()
>>> inspect.isclass(x)
1

The problematic expression in inspect.isclass is
hasattr(object, '__bases__') which returns a true value.

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

>Comment By: Walter Dörwald (doerwalter)
Date: 2003-04-15 12:01

Message:
Logged In: YES 
user_id=89016

type(object) in (types.TypeType, types.ClassType)
won't work with custom metaclasses.
isinstance(object, (type, types.ClassType))
would be better.


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

Comment By: Stefan Schwarzer (sschwarzer)
Date: 2003-04-15 10:01

Message:
Logged In: YES 
user_id=383516

Hello Raymond, thanks for your reply. In fact, I'm also not
sure if it counts as a bug. I also suggested a patch (handle
__getattr__ requests for __bases__ with an AttributeError)
for for the SF project which causes/d the problem.

I think, if there's a better way to decide on "class-ness"
than now, the code in inspect should be changed.
Fortunately, it doesn't have to be backward-compatible,
because the module is always distributed with a certain
interpreter version.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-15 02:36

Message:
Logged In: YES 
user_id=80475

Hmm.  I'm not sure that counts as a bug.  In an OO 
language, it's a feature that objects can be made to look 
like and be substituable for other types.  In this case, 
you've taught your object to be able to fake some classlike 
behavior (having a __bases__ attribute).

OTOH, inspect could have a stronger test for classhood:    
type(object) in (types.TypeType, types.ClassType)

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

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


From noreply@sourceforge.net  Tue Apr 15 11:40:13 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 15 Apr 2003 03:40:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-718532 ] inspect, class instances and __getattr__
Message-ID: <E195NrJ-0005VZ-00@sc8-sf-web3.sourceforge.net>

Bugs item #718532, was opened at 2003-04-09 15:01
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=718532&group_id=5470

Category: Python Library
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Stefan Schwarzer (sschwarzer)
>Assigned to: Ka-Ping Yee (ping)
Summary: inspect, class instances and __getattr__

Initial Comment:
inspect.isclass(class_instance) fails if the
corresponding class uses a "wildcard" implementation of
__getattr__.

Example:

Python 2.2.2 (#1, Nov 13 2002, 22:53:57) 
[GCC 2.95.4 20020320 [FreeBSD]] on freebsd4
Type "help", "copyright", "credits" or "license" for
more information.
>>> import inspect
>>> class X:
...     def __getattr__(self, name):
...             if name == 'foo':
...                     return 1   
...             if name == 'bar':
...                     return 2
...             else:
...                     return "default"
... 
>>> x = X()
>>> inspect.isclass(x)
1

The problematic expression in inspect.isclass is
hasattr(object, '__bases__') which returns a true value.

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-15 05:40

Message:
Logged In: YES 
user_id=80475

Ping, if this change is made, will isclass() still be able to 
find extension classes?

The addition of the hasattr(object, '__bases__') was made 
by you in ver 1.11 about two years ago. 


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

Comment By: Walter Dörwald (doerwalter)
Date: 2003-04-15 05:01

Message:
Logged In: YES 
user_id=89016

type(object) in (types.TypeType, types.ClassType)
won't work with custom metaclasses.
isinstance(object, (type, types.ClassType))
would be better.


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

Comment By: Stefan Schwarzer (sschwarzer)
Date: 2003-04-15 03:01

Message:
Logged In: YES 
user_id=383516

Hello Raymond, thanks for your reply. In fact, I'm also not
sure if it counts as a bug. I also suggested a patch (handle
__getattr__ requests for __bases__ with an AttributeError)
for for the SF project which causes/d the problem.

I think, if there's a better way to decide on "class-ness"
than now, the code in inspect should be changed.
Fortunately, it doesn't have to be backward-compatible,
because the module is always distributed with a certain
interpreter version.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-14 19:36

Message:
Logged In: YES 
user_id=80475

Hmm.  I'm not sure that counts as a bug.  In an OO 
language, it's a feature that objects can be made to look 
like and be substituable for other types.  In this case, 
you've taught your object to be able to fake some classlike 
behavior (having a __bases__ attribute).

OTOH, inspect could have a stronger test for classhood:    
type(object) in (types.TypeType, types.ClassType)

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

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


From noreply@sourceforge.net  Tue Apr 15 15:57:00 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 15 Apr 2003 07:57:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-721871 ] tarfile gets filenames wrong
Message-ID: <E195Rro-000120-00@sc8-sf-web1.sourceforge.net>

Bugs item #721871, was opened at 2003-04-15 16:56
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=721871&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Nobody/Anonymous (nobody)
Summary: tarfile gets filenames wrong

Initial Comment:
Tarfile seem to get filenames wrong, at least some times, at least on 
MacOSX. As an example, take the attached tar file (a distutils bdist-
dumb for OSX) and do 

>>> tf = tarfile.open(..., 'r')
>>> print tf.getnames()

Notice how for many filenames an initial bit of the pathname is 
missing.


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

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


From noreply@sourceforge.net  Tue Apr 15 16:13:25 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 15 Apr 2003 08:13:25 -0700
Subject: [Python-bugs-list] [ python-Bugs-721871 ] tarfile gets filenames wrong
Message-ID: <E195S7h-0001tD-00@sc8-sf-web1.sourceforge.net>

Bugs item #721871, was opened at 2003-04-15 16:56
Message generated for change (Comment added) made by sjoerd
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=721871&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Nobody/Anonymous (nobody)
Summary: tarfile gets filenames wrong

Initial Comment:
Tarfile seem to get filenames wrong, at least some times, at least on 
MacOSX. As an example, take the attached tar file (a distutils bdist-
dumb for OSX) and do 

>>> tf = tarfile.open(..., 'r')
>>> print tf.getnames()

Notice how for many filenames an initial bit of the pathname is 
missing.


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

Comment By: Sjoerd Mullender (sjoerd)
Date: 2003-04-15 17:13

Message:
Logged In: YES 
user_id=43607

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

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

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


From noreply@sourceforge.net  Tue Apr 15 21:54:35 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 15 Apr 2003 13:54:35 -0700
Subject: [Python-bugs-list] [ python-Bugs-721171 ] Tkinter precision loss for doubles
Message-ID: <E195XRr-000156-00@sc8-sf-web3.sourceforge.net>

Bugs item #721171, was opened at 2003-04-14 17:32
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=721171&group_id=5470

Category: Tkinter
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Martin v. Löwis (loewis)
Summary: Tkinter precision loss for doubles

Initial Comment:
DoubleVar.set() (I think) goes thru PyObject_Str(), 
causing precision loss for doubles:

>>> import Tkinter
>>> import math
>>> x = Tkinter.DoubleVar(Tkinter.Tk())
>>> x.set(math.pi)
>>> x.get()
3.1415926535900001   # not good
>>> math.pi
3.1415926535897931   # original precision
>>> eval(str(math.pi))
3.1415926535900001   # reproduces Tk result
>>>

Reported on c.l.py.  Guido says you may know how to 
create a "native" Tcl/Tk double in this case instead.

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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-04-15 22:54

Message:
Logged In: YES 
user_id=21627

I have now fixed this for _tkinter.c 1.154, by passing all
.set arguments with the same object type to Tcl, and
retrieving all Tcl variables with their native type.

This causes slight semantic changes (like the one being
reported as a bug here); most notably:

>>> y=Tkinter.StringVar(Tkinter.Tk())
>>> y.set(3.14)
>>> y.get()
3.1400000000000001

So a StringVar may not return a string anymore if .set did
not enter a string. Does that need to get fixed?

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-14 17:45

Message:
Logged In: YES 
user_id=6380

If a proper fix using Tcl float/double objects doesn't work
for some reason, maybe the attached fix (_tkinter.fix) would
work?

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

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


From noreply@sourceforge.net  Tue Apr 15 22:04:54 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 15 Apr 2003 14:04:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-721171 ] Tkinter precision loss for doubles
Message-ID: <E195Xbq-0002fr-00@sc8-sf-web1.sourceforge.net>

Bugs item #721171, was opened at 2003-04-14 11:32
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=721171&group_id=5470

Category: Tkinter
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Martin v. Löwis (loewis)
Summary: Tkinter precision loss for doubles

Initial Comment:
DoubleVar.set() (I think) goes thru PyObject_Str(), 
causing precision loss for doubles:

>>> import Tkinter
>>> import math
>>> x = Tkinter.DoubleVar(Tkinter.Tk())
>>> x.set(math.pi)
>>> x.get()
3.1415926535900001   # not good
>>> math.pi
3.1415926535897931   # original precision
>>> eval(str(math.pi))
3.1415926535900001   # reproduces Tk result
>>>

Reported on c.l.py.  Guido says you may know how to 
create a "native" Tcl/Tk double in this case instead.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-15 17:04

Message:
Logged In: YES 
user_id=6380

Thanks!

Re StringVar: I think StringVar should coerce the result to
str(), just like IntVar coerces to int(), etc. Maybe
Variable should grow get() method that does no coercion, and
it should no longer be marked as an internal class.

BTW there are a few places in Tkinter docstrings that
promise 0 or 1 where a bool is now returned.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-04-15 16:54

Message:
Logged In: YES 
user_id=21627

I have now fixed this for _tkinter.c 1.154, by passing all
.set arguments with the same object type to Tcl, and
retrieving all Tcl variables with their native type.

This causes slight semantic changes (like the one being
reported as a bug here); most notably:

>>> y=Tkinter.StringVar(Tkinter.Tk())
>>> y.set(3.14)
>>> y.get()
3.1400000000000001

So a StringVar may not return a string anymore if .set did
not enter a string. Does that need to get fixed?

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-14 11:45

Message:
Logged In: YES 
user_id=6380

If a proper fix using Tcl float/double objects doesn't work
for some reason, maybe the attached fix (_tkinter.fix) would
work?

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

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


From noreply@sourceforge.net  Wed Apr 16 10:26:52 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 16 Apr 2003 02:26:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-721871 ] tarfile gets filenames wrong
Message-ID: <E195jBs-00007u-00@sc8-sf-web3.sourceforge.net>

Bugs item #721871, was opened at 2003-04-15 16:56
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=721871&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Nobody/Anonymous (nobody)
Summary: tarfile gets filenames wrong

Initial Comment:
Tarfile seem to get filenames wrong, at least some times, at least on 
MacOSX. As an example, take the attached tar file (a distutils bdist-
dumb for OSX) and do 

>>> tf = tarfile.open(..., 'r')
>>> print tf.getnames()

Notice how for many filenames an initial bit of the pathname is 
missing.


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

>Comment By: Jack Jansen (jackjansen)
Date: 2003-04-16 11:26

Message:
Logged In: YES 
user_id=45365

Actually, I did check the box (just this once:-) but sourceforge refused the 
file, probably too big. It can be found at <http://www.cwi.nl/~jack/pimp/
Numeric-22.0.darwin-6.3-Power_Macintosh.tar.gz>.

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

Comment By: Sjoerd Mullender (sjoerd)
Date: 2003-04-15 17:13

Message:
Logged In: YES 
user_id=43607

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

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

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


From noreply@sourceforge.net  Wed Apr 16 11:54:25 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 16 Apr 2003 03:54:25 -0700
Subject: [Python-bugs-list] [ python-Bugs-722413 ] _winreg doesn't handle NULL bytes in value names
Message-ID: <E195kYb-00046G-00@sc8-sf-web4.sourceforge.net>

Bugs item #722413, was opened at 2003-04-16 20:54
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=722413&group_id=5470

Category: Windows
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Hammond (mhammond)
Assigned to: Tim Peters (tim_one)
Summary: _winreg doesn't handle NULL bytes in value names

Initial Comment:
Reported via pywin32 mailing list

>>We are trying to read all of the data under specific
registry keys.
>>Unfortunately, we cannot seem to enumerate keys or values
>>correctly if
>>the name contains Unicode or binary characters.
>>    
>>
>
>Eeek - you mean the *value* names can contain embedded
NULL characters?!
>  
>
The value names can contain NULL bytes. The NT/2K/XP
registry is all 
MBCS. The value names cannot contain MBCS character 0.
The key names



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

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


From noreply@sourceforge.net  Wed Apr 16 13:34:57 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 16 Apr 2003 05:34:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-712975 ] Cannot change the class of a list
Message-ID: <E195m7t-0000WS-00@sc8-sf-web4.sourceforge.net>

Bugs item #712975, was opened at 2003-03-31 22:00
Message generated for change (Comment added) made by jiba
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=712975&group_id=5470

Category: Type/class unification
Group: Python 2.3
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Jiba (jiba)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Cannot change the class of a list

Initial Comment:
The class of list (or dict) can no longer be changed in
Python 2.3a2 ; this was possible with Python 2.2.2 (as
long as the new class extend list and has no slot).
When doing so ([].__class__ = ...), i get this error :

TypeError: __class__ assignment: only for heap types


Not being able to change the class of non-mutable
object (e.g. int, float or tuple) is AMHO not a great
loss, but list and dict ARE mutable, and so changing
their class does have a sens !

Typically it can be used to observed a list that you
have not created yourself (see atteched script); i was
relying a lot on such observation features.

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

>Comment By: Jiba (jiba)
Date: 2003-04-16 12:34

Message:
Logged In: YES 
user_id=591223

I've submitted a patch for it (#722462), as well as a PyUnit
test case.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-07 18:29

Message:
Logged In: YES 
user_id=6380

The reason for the restriction is not (im)mutability, but
the fact that many built-in types have (or can have)
non-standard (de)allocators. A subclass of a built-in type
doesn't necessarily have the same deallocator. If someone
can come up with a patch *AND* a proof that the patch is
correct, I'll consider it, but I'd rather be safe than
sorry. Until then, I'll close this as "won't fix".

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

Comment By: Michael Hudson (mwh)
Date: 2003-04-01 10:30

Message:
Logged In: YES 
user_id=6656

IMHO, changing the class of an immutable object is, was and
always will be Right Out.

Changing the class of a mutable is dicier.  I personally
don't think it's worth the effort, but assigning to Guido
for pronouncement.

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

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


From noreply@sourceforge.net  Wed Apr 16 15:08:15 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 16 Apr 2003 07:08:15 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-722498 ] assert could raise other Exceptions
Message-ID: <E195naB-0003pH-00@sc8-sf-web3.sourceforge.net>

Feature Requests item #722498, was opened at 2003-04-16 10:08
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=722498&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregory Smith (gregsmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: assert could raise other Exceptions

Initial Comment:

how about having 'assert' check its second parameter,
and if it is an instance of Exception, raise that instead
of AssertionError:

  try:
         n = int(argv[i])
         assert 0 <= n <  10, ValueError("n out of range")
   except ValueError,e:
         print "Bad parameter:", str(e)



This is a fair bit tidier than

      if not ( 0 <= n < 10 ): raise ValueError, "n out
of range"

you could also do 'except (ValueError,
AssertionError)", but
the 'except' might not  be so close by, it would be nice to
have assert raise something else.

Having written this, I just realized that assert is
supposed
to go away when '-O' is selected (I never use that, myself)
so maybe this is not quite as useful -- but still quite
free of downside. 

I know nobody wants a new keyword, how about

     assert >> ValueError  , 0 <= n < 10 , n out of range

... which would do the same as the first example but
not be deleted by -O









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

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


From noreply@sourceforge.net  Wed Apr 16 19:07:16 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 16 Apr 2003 11:07:16 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-722647 ] lower-level API for longs
Message-ID: <E195rJU-000051-00@sc8-sf-web4.sourceforge.net>

Feature Requests item #722647, was opened at 2003-04-16 14:07
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=722647&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregory Smith (gregsmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: lower-level API for longs

Initial Comment:
something to make it a little more efficient to
build stuff on long integers; some simple things which 
are much faster to do in C than in python:

e.g.   
   n.bitwid()    1+ floor(log2(abs(n)) - # of useful bits
    n.bit(x)       (n>>x)&1
    n.bit(hi,lo)    (n>>lo) & ( (1<<(hi-lo))-1)
      n.bitrev(m)  - reverse the lower m bits of n,
return that

      n.findup( val=1, startbit=0)
        "search leftwards for a bit matching 'val',
starting at
          bit 'startbit'; -1 if none"
      n.finddown(val=1, startbit=n.bitwid())
         " search rightwards"

And some which would depend on the underlying
implementation (which appears to be pretty much
cast in cement, if not actual stone) :


   n.bitarray()   returns array.array('H') containing
raw bits

   long_fromarray(seq, neg=0)  - reverse of n.bitarray

If there's any interest in this, and no reason to shoot it
down right away, I cld write a PEP on it.

It would also be nice to have field-insertion operators,
that raises the question of wether these should return
a new long, or wether they should be built on a 
mutable 'bit-sequence' type which can act like a long.
Maybe this should be an 'array-of-bit' suggestion....


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

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


From noreply@sourceforge.net  Wed Apr 16 20:59:31 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 16 Apr 2003 12:59:31 -0700
Subject: [Python-bugs-list] [ python-Bugs-721171 ] Tkinter precision loss for doubles
Message-ID: <E195t47-0003cA-00@sc8-sf-web1.sourceforge.net>

Bugs item #721171, was opened at 2003-04-14 17:32
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=721171&group_id=5470

Category: Tkinter
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Martin v. Löwis (loewis)
Summary: Tkinter precision loss for doubles

Initial Comment:
DoubleVar.set() (I think) goes thru PyObject_Str(), 
causing precision loss for doubles:

>>> import Tkinter
>>> import math
>>> x = Tkinter.DoubleVar(Tkinter.Tk())
>>> x.set(math.pi)
>>> x.get()
3.1415926535900001   # not good
>>> math.pi
3.1415926535897931   # original precision
>>> eval(str(math.pi))
3.1415926535900001   # reproduces Tk result
>>>

Reported on c.l.py.  Guido says you may know how to 
create a "native" Tcl/Tk double in this case instead.

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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-04-16 21:59

Message:
Logged In: YES 
user_id=21627

In Tkinter.py 1.172, StringVars now always returns strings
(potentially Unicode); doc strings have been changed to
mention bools.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-15 23:04

Message:
Logged In: YES 
user_id=6380

Thanks!

Re StringVar: I think StringVar should coerce the result to
str(), just like IntVar coerces to int(), etc. Maybe
Variable should grow get() method that does no coercion, and
it should no longer be marked as an internal class.

BTW there are a few places in Tkinter docstrings that
promise 0 or 1 where a bool is now returned.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-04-15 22:54

Message:
Logged In: YES 
user_id=21627

I have now fixed this for _tkinter.c 1.154, by passing all
.set arguments with the same object type to Tcl, and
retrieving all Tcl variables with their native type.

This causes slight semantic changes (like the one being
reported as a bug here); most notably:

>>> y=Tkinter.StringVar(Tkinter.Tk())
>>> y.set(3.14)
>>> y.get()
3.1400000000000001

So a StringVar may not return a string anymore if .set did
not enter a string. Does that need to get fixed?

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-14 17:45

Message:
Logged In: YES 
user_id=6380

If a proper fix using Tcl float/double objects doesn't work
for some reason, maybe the attached fix (_tkinter.fix) would
work?

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

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


From noreply@sourceforge.net  Wed Apr 16 21:28:37 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 16 Apr 2003 13:28:37 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-722647 ] lower-level API for longs
Message-ID: <E195tWH-00068z-00@sc8-sf-web4.sourceforge.net>

Feature Requests item #722647, was opened at 2003-04-16 14:07
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=722647&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregory Smith (gregsmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: lower-level API for longs

Initial Comment:
something to make it a little more efficient to
build stuff on long integers; some simple things which 
are much faster to do in C than in python:

e.g.   
   n.bitwid()    1+ floor(log2(abs(n)) - # of useful bits
    n.bit(x)       (n>>x)&1
    n.bit(hi,lo)    (n>>lo) & ( (1<<(hi-lo))-1)
      n.bitrev(m)  - reverse the lower m bits of n,
return that

      n.findup( val=1, startbit=0)
        "search leftwards for a bit matching 'val',
starting at
          bit 'startbit'; -1 if none"
      n.finddown(val=1, startbit=n.bitwid())
         " search rightwards"

And some which would depend on the underlying
implementation (which appears to be pretty much
cast in cement, if not actual stone) :


   n.bitarray()   returns array.array('H') containing
raw bits

   long_fromarray(seq, neg=0)  - reverse of n.bitarray

If there's any interest in this, and no reason to shoot it
down right away, I cld write a PEP on it.

It would also be nice to have field-insertion operators,
that raises the question of wether these should return
a new long, or wether they should be built on a 
mutable 'bit-sequence' type which can act like a long.
Maybe this should be an 'array-of-bit' suggestion....


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

>Comment By: Tim Peters (tim_one)
Date: 2003-04-16 16:28

Message:
Logged In: YES 
user_id=31435

Go for it.  It has a better chance at acceptance if it sticks to 
inquiry methods (e.g., tie it into adding a new mutable bit 
array type too, and the odds plummet).  Note that "bitwid" is 
an egregiously un-Pythonic abbreviation -- are you trying to 
save "th" at the end?  If so, don't.  Note the same methods 
will have to be added to ints too -- Python's trying to eradicate 
the user-visible differences between ints and longs, so adding 
methods unique to one of those types would llikely be 
rejected for that reason alone.

Don't forget popcount (number of 1 bits set); there and 
elsewhere, what to do about negative inputs will be 
contentious.  Following GMP's lead is better than making 
stuff up then.

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

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


From noreply@sourceforge.net  Wed Apr 16 21:27:16 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 16 Apr 2003 13:27:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-549151 ] urllib2 POSTs on redirect
Message-ID: <E195tUy-0004rV-00@sc8-sf-web1.sourceforge.net>

Bugs item #549151, was opened at 2002-04-26 11:04
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
>Priority: 7
Submitted By: John J Lee (jjlee)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: urllib2 POSTs on redirect

Initial Comment:

urllib2 (I'm using 1.13.22 with Python 2.0, but I assume the 2.2 branch does the same) uses the 
POST method on redirect, contrary to RFC1945 section 9.3:

> 9.3  Redirection 3xx
> 
>    This class of status code indicates that further action needs to be
>    taken by the user agent in order to fulfill the request. The action
>    required may be carried out by the user agent without interaction
>    with the user if and only if the method used in the subsequent
>    request is GET or HEAD. A user agent should never automatically
>    redirect a request more than 5 times, since such redirections usually
>    indicate an infinite loop.

Can be fixed in HTTPRedirectHandler.http_error_302 by replacing
        new = Request(newurl, req.get_data())

with
        new = Request(newurl)

so that GET is done on redirect instead of POST.

I suppose the limit of 10 in the same function should be changed to 5, also.


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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-16 15:27

Message:
Logged In: YES 
user_id=80475

Do you have time to take this one back?  My head starts to 
explode when researching whether this is the right thing 
to do.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-03-07 15:57

Message:
Logged In: YES 
user_id=6380

I'll try to work on this.

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

Comment By: John J Lee (jjlee)
Date: 2003-03-05 16:03

Message:
Logged In: YES 
user_id=261020

The fix for this was set to go into 2.3, but nothing has  
happened yet. 
 
There were a couple of minor details to be fixed in the 
patches, so I've done that, and uploaded new patches for  
urllib2.py, urllib.py, and their documentation files (against  
current CVS). Well, I'm just about to upload them... 
 
Jeremy, can you apply the patches and finally close this 
one now?  Let me know if anything else needs doing. 
 
This should actually close another bug on SF, too (if it's still 
open), which deals with the urllib.py case.  I can't find it,  
though.  I did attach a comment to it (before I lost it) that 
references this bug. 
 

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

Comment By: John J Lee (jjlee)
Date: 2002-10-15 10:22

Message:
Logged In: YES 
user_id=261020

Well, when I carefully read the RFC I came to the conclusion
that 301 should be redirected to GET, not POST.  I also came
to the conclusion that the RFC was slightly ambiguous on
this point, so I guess that's why A. Flavell came to the
conclusion that 301 should redirect to POST rather than GET.
Anyway, clearly the established practice is to redirect 301
as GET, so this is all academic.

Assuming he's right about Netscape / IE etc., I suppose I'm
happy for 301 to redirect without an exception, since that's
what we've agreed to do for 302.  Obviously, the docs should
say this is contrary to the RFC (as my doc patch says for
302 already).

As for urllib.py, I see the problem.  303 should still be
added, though, since that poses no problem at all.


John


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

Comment By: Jeremy Hylton (jhylton)
Date: 2002-10-11 10:40

Message:
Logged In: YES 
user_id=31392

I'm still uncertain about what to do on 301 responses.  As
you say, there are two issues to sort out: 1) what method
should a POST be redicted to and 2) whether the user should
be asked to confirm.

There's discussion of this at:
http://ppewww.ph.gla.ac.uk/~flavell/www/post-redirect.html
The page is a bit old, but I don't know if it is out of date.
It says that IE5, Netscape 4, and Mozilla 1.0 all redirect a
301 POST to a GET without user confirmation.  That seems
like a widespread disregard for the spec that we ought to
emulate.

I agree with your interpretation that urllib2 raise an
HTTPError to signal "request confirm" because an HTTPError
is also a valid response that the user could interpret.  But
of urllib, an HTTP error doesn't contain a valid response. 
The change would make it impossible for the client to do
anything if a 301 response is returned from a POST.  That
seems worse than doing the wrong.



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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-10-09 20:27

Message:
Logged In: YES 
user_id=6380

OK, over to jeremy.

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

Comment By: John J Lee (jjlee)
Date: 2002-10-09 16:16

Message:
Logged In: YES 
user_id=261020

Ah.  Here it is.

John


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-10-08 13:23

Message:
Logged In: YES 
user_id=6380

Um, I don't see the patch for urllib.py.  Perhaps you didn't
check the box?

Jeremy, let's do this in 2.3, OK?

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

Comment By: John J Lee (jjlee)
Date: 2002-10-08 11:53

Message:
Logged In: YES 
user_id=261020

Guido mentioned that urllib.py should be fixed
too.  I've attached another patch.


John


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

Comment By: John J Lee (jjlee)
Date: 2002-10-05 12:44

Message:
Logged In: YES 
user_id=261020

Here is a patch for the minor documentation changes required
for the patch I uploaded earlier to fix this bug.  I've also
uploaded a slightly revised patch:

I renamed the `method' method to `get_method' for
consistency with the other methods of the Request class.
The reason this new method is there at all is because the
logic that decides whether or not a redirection should take
place is defined in terms of the method type
(GET/HEAD/POST).  urllib2 doesn't support HEAD ATM, but it
might in future.  OTOH, the Request class is supposed to be
generic -- not specific to HTTP -- so perhaps get_method
isn't really appropriate.  OTOOH, add_data is already
documented to only be meaningful for HTTP Requests.  I
suppose there could be a subclass HTTPRequest, but that's
less simple.  What do you think is best?

I also changed redirect_request to raise an exception
instead of returning None (because no other Handler should
handle the redirect), and changed its documented return
value / exception interface to be consistent with the rest
of urllib2.


John


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

Comment By: John J Lee (jjlee)
Date: 2002-06-23 14:23

Message:
Logged In: YES 
user_id=261020

First, can I underline the fact that there are two issues
here:

  1. What method should POST be redirected as for a
     particular 30x response?

  2. Should the user be asked to confirm the redirection
     (which presumably maps onto raising an HTTPError in
     urllib2)?

I think current client implementations go against the RFCs
on both these points for 302.  Contrastingly, RFC 2616's
note on 301 responses (section 10.3.2) implies that only a
subset of HTTP/1.0 (not 1.1, note) clients violate the RFCs
(1945, 2068, 2616) on point 1 for 301 responses, and I know
of no clients that violate the RFCs on point 2 for 301
responses (but I haven't tested).  Also, I guess the
original intent (for both 301 and 302) was that POSTs
represent an action, so it's dangerous in general to
redirect them without asking the user: I presume this is why
307 was brought in: 307 POSTs on redirected POST, so the
user must be asked:

10.3 Redirection 3xx
[...]
   The action required MAY be carried out by the user agent
   without interaction with the user if and only if the
   method used in the second request is GET or HEAD.

(and 303 is just meant to have the 'erroneous' 302
behaviour: GET on redirected POST, don't ask the user)

So, I agree with Guido that 302 should probably now be
treated the way most clients treat it: GET on redirected
POST, don't ask the user.  As for 301, if it *is* true that
only a few HTTP/1.0 clients have misinterpreted the RFCs on
301, we should stick to the safe behaviour indicated by the
RFC.

As for Guido's first question: A 307 should indeed be
redirected as a POST, but it should ask the user first (see
10.3 quote, above).  That's what my patch does (the 'return
None' in the else clause in redirect_request causes an
exception to be raised eventually -- maybe it should just
raise it itself).

I've attached a revised patch that deals with 302 (and 303)
in the 'erroneous' way (again: GET on redirected POST, don't
ask the user).

I suppose the comment about HTTPRedirectHandler also needs
to state that 301 and 307 POST requests are not
automatically redirected -- HTTPError is raised in that
case.


John


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

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

Message:
Logged In: YES 
user_id=6380

Hm, I thought that 307 should be treated differently than
303. In particular, a 307 response to POST should cause the
POST to be redirected. And I'm not sure about what a 301
response to POST should do.

(In the mean time I have been convinced that changing POST
to GET on 302 is the best thing to do given that most
browsers do that. The old urllib.py should be fixed too.)

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

Comment By: John J Lee (jjlee)
Date: 2002-06-19 16:57

Message:
Logged In: YES 
user_id=261020

I've attached a patch -- was simpler than I thought.

I think this is in compliance with RFC 2616.  It's also
simple for clients to inherit from HTTPRedirectHandler and
override redirect_request if, for example, they know they
want all 302 POSTs to be redirected as a GET, which removes
the need for mixing redirection code with normal client code
even when the server doesn't follow the RFC (if the server
expects a 302 POST to be redirected as a GET, for example).
Note that I had to add a method, named 'method', to the
Request class, for maintainability (it's possible that
urllib2 may be able to do methods other than GET and POST in
future).

Possibly redirect_request should take fewer parameters.

John


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

Comment By: John J Lee (jjlee)
Date: 2002-06-19 16:56

Message:
Logged In: YES 
user_id=261020

I've attached a patch -- was simpler than I thought.

I think this is in compliance with RFC 2616.  It's also
simple for clients to inherit from HTTPRedirectHandler and
override redirect_request if, for example, they know they
want all 302 POSTs to be redirected as a GET, which removes
the need for mixing redirection code with normal client code
even when the server doesn't follow the RFC (if the server
expects a 302 POST to be redirected as a GET, for example).
Note that I had to add a method, named 'method', to the
Request class, for maintainability (it's possible that
urllib2 may be able to do methods other than GET and POST in
future).

Possibly redirect_request should take fewer parameters.

John


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

Comment By: John J Lee (jjlee)
Date: 2002-06-06 16:25

Message:
Logged In: YES 
user_id=261020

Oh, I hadn't realised httplib uses HTTP/1.1 now -- and now I
check, I see that even RFC 1945 (HTTP/1.0) has a whole set of
restrictions on 30x for particular values of x which I missed
completely.

I guess it should do what Guido suggested -- report an error if a
POST is redirected -- until somebody gets time to do it properly.
I won't have time for a couple of months, but if nobody has done
it by then I'll upload a patch.


John


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

Comment By: Jeremy Hylton (jhylton)
Date: 2002-06-06 10:09

Message:
Logged In: YES 
user_id=31392

I think you need to review the current HTTP spec -- RFC 2616
-- and look at the section on redirection (10.3).  I think
urllib2 could improve its handling of redirection, but the
behavior you describe from lynx sounds incorrect.  I'd be
happy to review a patch the implemented the current spec.

Also, RFC 2616 removes the recommendation of a 5 redirect limit.




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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-29 13:10

Message:
Logged In: YES 
user_id=6380

Fair enough. I'll leve it to Jeremy to review the proposed
fix. (Note that he's busy though.)

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

Comment By: John J Lee (jjlee)
Date: 2002-04-29 11:29

Message:
Logged In: YES 
user_id=261020

I don't see why it shouldn't substitue a GET.  That certainly seems to be
the standard practice (well, at least that's what lynx does), and in the case
of the only site where I've encountered redirects on POST, the redirect URL
contains urlencoded stuff, so it clearly expects the user-agent to do a GET.
The site would break if this didn't happen, so I guess Netscape and IE must
do the same thing.

Clearly the RFC *does* allow this, though it doesn't require it (or specify
what should happen here in any way other than to say that a POST is not
allowed, in fact).  Since it's standard practice and allowed by the RFC, I
don't think it should be an error.

John


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-28 19:53

Message:
Logged In: YES 
user_id=6380

Hm, the way I interpret the text you quote, if the original
request is  a POST, it should probably not substitute a GET
but report the error.

Assigning to Jeremy since it's his module.

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

Comment By: John J Lee (jjlee)
Date: 2002-04-28 11:21

Message:
Logged In: YES 
user_id=261020

1. Bug is also in 2.2 branch

2. The fix (in 2.1 and 2.2) should reflect the earlier bug fix in the 2.2 branch to add the old headers:

new = Request(newurl, headers=req.headers)

3. I guess 10 should be replaced with 4, not 5.


John


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

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


From noreply@sourceforge.net  Wed Apr 16 21:35:37 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 16 Apr 2003 13:35:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-549151 ] urllib2 POSTs on redirect
Message-ID: <E195td3-00057r-00@sc8-sf-web1.sourceforge.net>

Bugs item #549151, was opened at 2002-04-26 12:04
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470

Category: Python Library
Group: None
Status: Open
>Resolution: Accepted
Priority: 7
Submitted By: John J Lee (jjlee)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: urllib2 POSTs on redirect

Initial Comment:

urllib2 (I'm using 1.13.22 with Python 2.0, but I assume the 2.2 branch does the same) uses the 
POST method on redirect, contrary to RFC1945 section 9.3:

> 9.3  Redirection 3xx
> 
>    This class of status code indicates that further action needs to be
>    taken by the user agent in order to fulfill the request. The action
>    required may be carried out by the user agent without interaction
>    with the user if and only if the method used in the subsequent
>    request is GET or HEAD. A user agent should never automatically
>    redirect a request more than 5 times, since such redirections usually
>    indicate an infinite loop.

Can be fixed in HTTPRedirectHandler.http_error_302 by replacing
        new = Request(newurl, req.get_data())

with
        new = Request(newurl)

so that GET is done on redirect instead of POST.

I suppose the limit of 10 in the same function should be changed to 5, also.


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-16 16:35

Message:
Logged In: YES 
user_id=6380

I think this is the right thing to do. Can you check it in?
 (There are several files -- urllib, urllib2, and its docs).

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-16 16:27

Message:
Logged In: YES 
user_id=80475

Do you have time to take this one back?  My head starts to 
explode when researching whether this is the right thing 
to do.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-03-07 15:57

Message:
Logged In: YES 
user_id=6380

I'll try to work on this.

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

Comment By: John J Lee (jjlee)
Date: 2003-03-05 16:03

Message:
Logged In: YES 
user_id=261020

The fix for this was set to go into 2.3, but nothing has  
happened yet. 
 
There were a couple of minor details to be fixed in the 
patches, so I've done that, and uploaded new patches for  
urllib2.py, urllib.py, and their documentation files (against  
current CVS). Well, I'm just about to upload them... 
 
Jeremy, can you apply the patches and finally close this 
one now?  Let me know if anything else needs doing. 
 
This should actually close another bug on SF, too (if it's still 
open), which deals with the urllib.py case.  I can't find it,  
though.  I did attach a comment to it (before I lost it) that 
references this bug. 
 

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

Comment By: John J Lee (jjlee)
Date: 2002-10-15 11:22

Message:
Logged In: YES 
user_id=261020

Well, when I carefully read the RFC I came to the conclusion
that 301 should be redirected to GET, not POST.  I also came
to the conclusion that the RFC was slightly ambiguous on
this point, so I guess that's why A. Flavell came to the
conclusion that 301 should redirect to POST rather than GET.
Anyway, clearly the established practice is to redirect 301
as GET, so this is all academic.

Assuming he's right about Netscape / IE etc., I suppose I'm
happy for 301 to redirect without an exception, since that's
what we've agreed to do for 302.  Obviously, the docs should
say this is contrary to the RFC (as my doc patch says for
302 already).

As for urllib.py, I see the problem.  303 should still be
added, though, since that poses no problem at all.


John


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

Comment By: Jeremy Hylton (jhylton)
Date: 2002-10-11 11:40

Message:
Logged In: YES 
user_id=31392

I'm still uncertain about what to do on 301 responses.  As
you say, there are two issues to sort out: 1) what method
should a POST be redicted to and 2) whether the user should
be asked to confirm.

There's discussion of this at:
http://ppewww.ph.gla.ac.uk/~flavell/www/post-redirect.html
The page is a bit old, but I don't know if it is out of date.
It says that IE5, Netscape 4, and Mozilla 1.0 all redirect a
301 POST to a GET without user confirmation.  That seems
like a widespread disregard for the spec that we ought to
emulate.

I agree with your interpretation that urllib2 raise an
HTTPError to signal "request confirm" because an HTTPError
is also a valid response that the user could interpret.  But
of urllib, an HTTP error doesn't contain a valid response. 
The change would make it impossible for the client to do
anything if a 301 response is returned from a POST.  That
seems worse than doing the wrong.



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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-10-09 21:27

Message:
Logged In: YES 
user_id=6380

OK, over to jeremy.

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

Comment By: John J Lee (jjlee)
Date: 2002-10-09 17:16

Message:
Logged In: YES 
user_id=261020

Ah.  Here it is.

John


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-10-08 14:23

Message:
Logged In: YES 
user_id=6380

Um, I don't see the patch for urllib.py.  Perhaps you didn't
check the box?

Jeremy, let's do this in 2.3, OK?

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

Comment By: John J Lee (jjlee)
Date: 2002-10-08 12:53

Message:
Logged In: YES 
user_id=261020

Guido mentioned that urllib.py should be fixed
too.  I've attached another patch.


John


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

Comment By: John J Lee (jjlee)
Date: 2002-10-05 13:44

Message:
Logged In: YES 
user_id=261020

Here is a patch for the minor documentation changes required
for the patch I uploaded earlier to fix this bug.  I've also
uploaded a slightly revised patch:

I renamed the `method' method to `get_method' for
consistency with the other methods of the Request class.
The reason this new method is there at all is because the
logic that decides whether or not a redirection should take
place is defined in terms of the method type
(GET/HEAD/POST).  urllib2 doesn't support HEAD ATM, but it
might in future.  OTOH, the Request class is supposed to be
generic -- not specific to HTTP -- so perhaps get_method
isn't really appropriate.  OTOOH, add_data is already
documented to only be meaningful for HTTP Requests.  I
suppose there could be a subclass HTTPRequest, but that's
less simple.  What do you think is best?

I also changed redirect_request to raise an exception
instead of returning None (because no other Handler should
handle the redirect), and changed its documented return
value / exception interface to be consistent with the rest
of urllib2.


John


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

Comment By: John J Lee (jjlee)
Date: 2002-06-23 15:23

Message:
Logged In: YES 
user_id=261020

First, can I underline the fact that there are two issues
here:

  1. What method should POST be redirected as for a
     particular 30x response?

  2. Should the user be asked to confirm the redirection
     (which presumably maps onto raising an HTTPError in
     urllib2)?

I think current client implementations go against the RFCs
on both these points for 302.  Contrastingly, RFC 2616's
note on 301 responses (section 10.3.2) implies that only a
subset of HTTP/1.0 (not 1.1, note) clients violate the RFCs
(1945, 2068, 2616) on point 1 for 301 responses, and I know
of no clients that violate the RFCs on point 2 for 301
responses (but I haven't tested).  Also, I guess the
original intent (for both 301 and 302) was that POSTs
represent an action, so it's dangerous in general to
redirect them without asking the user: I presume this is why
307 was brought in: 307 POSTs on redirected POST, so the
user must be asked:

10.3 Redirection 3xx
[...]
   The action required MAY be carried out by the user agent
   without interaction with the user if and only if the
   method used in the second request is GET or HEAD.

(and 303 is just meant to have the 'erroneous' 302
behaviour: GET on redirected POST, don't ask the user)

So, I agree with Guido that 302 should probably now be
treated the way most clients treat it: GET on redirected
POST, don't ask the user.  As for 301, if it *is* true that
only a few HTTP/1.0 clients have misinterpreted the RFCs on
301, we should stick to the safe behaviour indicated by the
RFC.

As for Guido's first question: A 307 should indeed be
redirected as a POST, but it should ask the user first (see
10.3 quote, above).  That's what my patch does (the 'return
None' in the else clause in redirect_request causes an
exception to be raised eventually -- maybe it should just
raise it itself).

I've attached a revised patch that deals with 302 (and 303)
in the 'erroneous' way (again: GET on redirected POST, don't
ask the user).

I suppose the comment about HTTPRedirectHandler also needs
to state that 301 and 307 POST requests are not
automatically redirected -- HTTPError is raised in that
case.


John


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-19 20:57

Message:
Logged In: YES 
user_id=6380

Hm, I thought that 307 should be treated differently than
303. In particular, a 307 response to POST should cause the
POST to be redirected. And I'm not sure about what a 301
response to POST should do.

(In the mean time I have been convinced that changing POST
to GET on 302 is the best thing to do given that most
browsers do that. The old urllib.py should be fixed too.)

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

Comment By: John J Lee (jjlee)
Date: 2002-06-19 17:57

Message:
Logged In: YES 
user_id=261020

I've attached a patch -- was simpler than I thought.

I think this is in compliance with RFC 2616.  It's also
simple for clients to inherit from HTTPRedirectHandler and
override redirect_request if, for example, they know they
want all 302 POSTs to be redirected as a GET, which removes
the need for mixing redirection code with normal client code
even when the server doesn't follow the RFC (if the server
expects a 302 POST to be redirected as a GET, for example).
Note that I had to add a method, named 'method', to the
Request class, for maintainability (it's possible that
urllib2 may be able to do methods other than GET and POST in
future).

Possibly redirect_request should take fewer parameters.

John


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

Comment By: John J Lee (jjlee)
Date: 2002-06-19 17:56

Message:
Logged In: YES 
user_id=261020

I've attached a patch -- was simpler than I thought.

I think this is in compliance with RFC 2616.  It's also
simple for clients to inherit from HTTPRedirectHandler and
override redirect_request if, for example, they know they
want all 302 POSTs to be redirected as a GET, which removes
the need for mixing redirection code with normal client code
even when the server doesn't follow the RFC (if the server
expects a 302 POST to be redirected as a GET, for example).
Note that I had to add a method, named 'method', to the
Request class, for maintainability (it's possible that
urllib2 may be able to do methods other than GET and POST in
future).

Possibly redirect_request should take fewer parameters.

John


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

Comment By: John J Lee (jjlee)
Date: 2002-06-06 17:25

Message:
Logged In: YES 
user_id=261020

Oh, I hadn't realised httplib uses HTTP/1.1 now -- and now I
check, I see that even RFC 1945 (HTTP/1.0) has a whole set of
restrictions on 30x for particular values of x which I missed
completely.

I guess it should do what Guido suggested -- report an error if a
POST is redirected -- until somebody gets time to do it properly.
I won't have time for a couple of months, but if nobody has done
it by then I'll upload a patch.


John


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

Comment By: Jeremy Hylton (jhylton)
Date: 2002-06-06 11:09

Message:
Logged In: YES 
user_id=31392

I think you need to review the current HTTP spec -- RFC 2616
-- and look at the section on redirection (10.3).  I think
urllib2 could improve its handling of redirection, but the
behavior you describe from lynx sounds incorrect.  I'd be
happy to review a patch the implemented the current spec.

Also, RFC 2616 removes the recommendation of a 5 redirect limit.




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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-29 14:10

Message:
Logged In: YES 
user_id=6380

Fair enough. I'll leve it to Jeremy to review the proposed
fix. (Note that he's busy though.)

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

Comment By: John J Lee (jjlee)
Date: 2002-04-29 12:29

Message:
Logged In: YES 
user_id=261020

I don't see why it shouldn't substitue a GET.  That certainly seems to be
the standard practice (well, at least that's what lynx does), and in the case
of the only site where I've encountered redirects on POST, the redirect URL
contains urlencoded stuff, so it clearly expects the user-agent to do a GET.
The site would break if this didn't happen, so I guess Netscape and IE must
do the same thing.

Clearly the RFC *does* allow this, though it doesn't require it (or specify
what should happen here in any way other than to say that a POST is not
allowed, in fact).  Since it's standard practice and allowed by the RFC, I
don't think it should be an error.

John


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-28 20:53

Message:
Logged In: YES 
user_id=6380

Hm, the way I interpret the text you quote, if the original
request is  a POST, it should probably not substitute a GET
but report the error.

Assigning to Jeremy since it's his module.

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

Comment By: John J Lee (jjlee)
Date: 2002-04-28 12:21

Message:
Logged In: YES 
user_id=261020

1. Bug is also in 2.2 branch

2. The fix (in 2.1 and 2.2) should reflect the earlier bug fix in the 2.2 branch to add the old headers:

new = Request(newurl, headers=req.headers)

3. I guess 10 should be replaced with 4, not 5.


John


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

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


From noreply@sourceforge.net  Wed Apr 16 21:55:05 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 16 Apr 2003 13:55:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-719880 ] _tkinter.c doesn't build on Redhat 9
Message-ID: <E195tvt-0007ND-00@sc8-sf-web4.sourceforge.net>

Bugs item #719880, was opened at 2003-04-11 21:12
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=719880&group_id=5470

Category: Build
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Martin v. Löwis (loewis)
Summary: _tkinter.c doesn't build on Redhat 9

Initial Comment:
Martin, _tkinter doesn't build on Redhat 9 because:
 _tkinter.c:92:2: #error "unsupported Tcl configuration"

TCL_UTF_MAX is defined to be 6, not 3.  I don't know
what else would be necessary to change to get this to
work.  Can you provide any ideas? 

I changed line 92 to:

    #if TCL_UTF_MAX != 3 && TCL_UTF_MAX != 6

and I was able to bring a window up with a push button.


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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-04-16 22:55

Message:
Logged In: YES 
user_id=21627

I have fixed this in _tkinter.c 1.155; Python must be build
with --enable-unicode=ucs4 on Redhat 8 (I haven't actually
tested it on Redhat, but on a modified Tcl installation on
SuSE).

It turns out that Tcl isn't really prepared for UCS-4, e.g.
when trying to put \N{MATHEMATICAL BOLD FRAKTUR CAPITAL A}
into a label, it crashes when attempting to convert that
character to Latin-1 (as it made a 256x256 table, but has
the first index > 256).

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-04-12 12:36

Message:
Logged In: YES 
user_id=21627

I just looked at their source RPM, and I can't believe what
I'm seeing :-(

There is tcltk-8.3.5-ucs4-for-py.patch, which reads

--- tcl8.3.5/generic/tcl.h~	2003-02-04 10:01:20.000000000 +0900
+++ tcl8.3.5/generic/tcl.h	2003-02-04 10:01:20.000000000 +0900
@@ -1604,13 +1604,13 @@
  * Unicode character in UTF-8.
  */
 
-#define TCL_UTF_MAX		3
+#define TCL_UTF_MAX		6
 
 /*
  * This represents a Unicode character.  
  */
 
-typedef unsigned short Tcl_UniChar;
+typedef wchar_t Tcl_UniChar;
 
 /*
  * Deprecated Tcl procedures:

I'd say they have tricked themselves: Py22 would fail to
work with Tcl in UCS-4 mode. Instead of fixing this in
tkinter (as I did for Python 2.3), they just patched tcl...
However, Tcl itself seems to be prepared for that mode of
operation; atleast their UTF-8 codec knows how to convert 6
bytes into a single int.

I would suggest that we mandate UCS-4 on Redhat 9 (through
README), and fix it for this case (i.e. allow UTF_MAX to be
6 only if unicode is wide, and narrow the UNICODE_WIDE test
to && UTF_MAX==3).

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-11 22:38

Message:
Logged In: YES 
user_id=33168

Tcl/Tk version is 8.3.5. There were some warnings from
AsObj.  I'll look into this in more detail later.  I may ask
the redhat guys to take a look too.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-04-11 22:08

Message:
Logged In: YES 
user_id=21627

What Tcl version is that? I didn't know Tcl does UCS-4...

The comment says it all: Tcl_Unichar is expected to be two
bytes. If it isn't, and
a) Python is UCS-2: In AsObj, deal with surrogates in the
Python 
string, combining them into a single Tcl_Unichar. In
FromObj, split
non-BMP characters into two. This means that you need a copying
loop, as you cannot expect that the size of the Tcl and Python
strings will be the same.
b) Python is UCS-4. Consider also using
PyUnicode_FromUnicode in FromObj, and NewUnicodeObj in AsObj.

Alternatively, proclaim that "Tcl is UCS-4, Python is UCS-2"
is not supported, drop case a), and perform just the direct
operations in case b) (the current copying loops are still
needed for UCS-2 Tcl).

Perhaps Tcl isn't UCS-4, but uses surrogate pairs instead?
In that case, one would need to use yet other algorithms...

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

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


From noreply@sourceforge.net  Wed Apr 16 22:49:19 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 16 Apr 2003 14:49:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-722763 ] weakref: proxy_print and proxy_repr incons.
Message-ID: <E195umN-0008SP-00@sc8-sf-web1.sourceforge.net>

Bugs item #722763, was opened at 2003-04-16 17:49
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=722763&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: weakref: proxy_print and proxy_repr incons.

Initial Comment:
For weakref.proxy, the behavior of proxy_print() in
"cooked" mode is inconsistent with the behavior of
proxy_repr(). "cooked" mode printing is used when a
value is displayed at the command line. Sample session:

>>> class C: pass
... 
>>> from weakref import proxy
>>> a = C()
>>> p = proxy(a)
>>> p
<__main__.C instance at 0x400e864c>
>>> print repr(p)
<weakproxy at 0x400e343c to instance at 0x400e864c>
>>>

The output should be the same in both cases.

(My suggestion: get rid of proxy_print. Might be a tad
slower in extreme cases, but gets this right with ease. :-)

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

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


From noreply@sourceforge.net  Thu Apr 17 14:41:32 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 17 Apr 2003 06:41:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-723136 ] Put a reference to print in the Library Refernce, please.
Message-ID: <E1969ds-0000W8-00@sc8-sf-web3.sourceforge.net>

Bugs item #723136, was opened at 2003-04-17 15:41
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723136&group_id=5470

Category: Documentation
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Laura Creighton (lcreighton)
Assigned to: Nobody/Anonymous (nobody)
Summary: Put a reference to print in the Library Refernce, please.

Initial Comment:
Often the first question a Newbie has is 'how do I
print stuff?'.
They come to the Library Reference, looking for a print
function.   They are unaware that print is an
expression, and
that they need to be looking in the Language Reference
Manual.
One line, early on telling them where to look will save
aggrevation
for them.  Thanks very much,
Laura Creighton

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

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


From noreply@sourceforge.net  Thu Apr 17 14:45:23 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 17 Apr 2003 06:45:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-723136 ] Put a reference to print in the Library Reference, please.
Message-ID: <E1969hb-0000n5-00@sc8-sf-web3.sourceforge.net>

Bugs item #723136, was opened at 2003-04-17 15:41
Message generated for change (Settings changed) made by lcreighton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723136&group_id=5470

Category: Documentation
Group: Feature Request
Status: Open
Resolution: None
>Priority: 1
Submitted By: Laura Creighton (lcreighton)
>Assigned to: Guido van Rossum (gvanrossum)
>Summary: Put a reference to print in the Library Reference, please.

Initial Comment:
Often the first question a Newbie has is 'how do I
print stuff?'.
They come to the Library Reference, looking for a print
function.   They are unaware that print is an
expression, and
that they need to be looking in the Language Reference
Manual.
One line, early on telling them where to look will save
aggrevation
for them.  Thanks very much,
Laura Creighton

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

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


From noreply@sourceforge.net  Thu Apr 17 15:49:45 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 17 Apr 2003 07:49:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-723136 ] Put a reference to print in the Library Reference, please.
Message-ID: <E196Aht-00053h-00@sc8-sf-web1.sourceforge.net>

Bugs item #723136, was opened at 2003-04-17 09:41
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723136&group_id=5470

Category: Documentation
Group: Feature Request
Status: Open
Resolution: None
>Priority: 6
Submitted By: Laura Creighton (lcreighton)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Put a reference to print in the Library Reference, please.

Initial Comment:
Often the first question a Newbie has is 'how do I
print stuff?'.
They come to the Library Reference, looking for a print
function.   They are unaware that print is an
expression, and
that they need to be looking in the Language Reference
Manual.
One line, early on telling them where to look will save
aggrevation
for them.  Thanks very much,
Laura Creighton

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-04-17 10:49

Message:
Logged In: YES 
user_id=3066

Guido wants this fixed, so bumped priority and assigned it
to me.

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

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


From noreply@sourceforge.net  Thu Apr 17 15:51:38 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 17 Apr 2003 07:51:38 -0700
Subject: [Python-bugs-list] [ python-Bugs-708205 ] math.fabs documentation is misleading
Message-ID: <E196Aji-0000X7-00@sc8-sf-web2.sourceforge.net>

Bugs item #708205, was opened at 2003-03-22 19:26
Message generated for change (Settings changed) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=708205&group_id=5470

Category: Documentation
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: George Yoshida (quiver)
>Assigned to: Tim Peters (tim_one)
Summary: math.fabs documentation is misleading

Initial Comment:
math.fabs documentation is misleading.
It says,
"Return the absolute value of the floating point number 
x. ".
but I think it should look like this:
"Return the absolute value of x as a float."

See the code below.

>>> from math import *
>>> abs(3)
3
>>> fabs(3)
3.0

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

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


From noreply@sourceforge.net  Thu Apr 17 15:53:44 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 17 Apr 2003 07:53:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-659188 ] no docs for HTMLParser.handle_pi
Message-ID: <E196Alk-0004yF-00@sc8-sf-web3.sourceforge.net>

Bugs item #659188, was opened at 2002-12-27 18:13
Message generated for change (Settings changed) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=659188&group_id=5470

Category: Documentation
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Arild Fines (arildfines)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: no docs for HTMLParser.handle_pi

Initial Comment:
The current documentation(2.2.2) has no documentation 
for the handle_pi(handle processing instruction) method 
in the HTMLParser.HTMLParser class. 

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

Comment By: Christopher Blunck (blunck2)
Date: 2003-01-04 23:11

Message:
Logged In: YES 
user_id=531881

see patch 662464

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

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


From noreply@sourceforge.net  Thu Apr 17 16:47:03 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 17 Apr 2003 08:47:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-595026 ] Support for masks in getargs.c
Message-ID: <E196BbL-0000Pr-00@sc8-sf-web1.sourceforge.net>

Bugs item #595026, was opened at 2002-08-14 14:26
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595026&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 7
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Thomas Heller (theller)
Summary: Support for masks in getargs.c

Initial Comment:
We need this implemented:

> How about the following counterproposal.  This also
changes some of
> the other format codes to be a little more regular.
>
> Code    C type          	Range check
>
> b	unsigned char		0..UCHAR_MAX
> B	unsigned char		none **
> h	unsigned short		0..USHRT_MAX
> H	unsigned short		none **
> i	int
		INT_MIN..INT_MAX
> I *	unsigned int		0..UINT_MAX
> l	long
		LONG_MIN..LONG_MAX
> k *	unsigned long		none
> L	long long		LLONG_MIN..LLONG_MAX
> K *	unsigned long long	none
>
> Notes:
>
> * New format codes.
>
> ** Changed from previous "range-and-a-half" to
"none"; the
>    range-and-a-half checking wasn't particularly useful.

Plus a C API or two, e.g. PyInt_AsLongMask() ->
unsigned long and PyInt_AsLongLongMask() -> unsigned
long long (if that exists).

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

>Comment By: Thomas Heller (theller)
Date: 2003-04-17 17:47

Message:
Logged In: YES 
user_id=11105

Patch is ready for review (although NEWS and docs are
missing, I will add them later if the patch is accepted).

getargs.patch contains a context diff for several files,
including Modules/_testcapimodule.c.
test_getargs2.py should go into Lib/test, and tests the changes.
It also documents the new behaviour.

In the complete test-suite, test_array is crashing now as a
consequence.

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

Comment By: Thomas Heller (theller)
Date: 2003-02-21 19:36

Message:
Logged In: YES 
user_id=11105

Uploading patch whcih implements the 'k' format code.  Any
comments? Is this what is needed?
I know, docs are missing, and 'K' is missing.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-21 13:58

Message:
Logged In: YES 
user_id=6380

I suggest writing on python-dev or python-list.


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

Comment By: Thomas Heller (theller)
Date: 2003-02-20 21:45

Message:
Logged In: YES 
user_id=11105

I've implemented the 'k' getargs code, and
PyInt_AsUnsignedLongMask and PyLong_AsUnsignedLongMask
functions.  Is there any facility which would help me to
test this new code?

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

Comment By: Jack Jansen (jackjansen)
Date: 2003-02-18 23:08

Message:
Logged In: YES 
user_id=45365

Guido,
I would be happy with the no-rangecheck unsigned long formatcode. One request, though: if this is implemented can it be done ASAP after 2.3a2, so there's still some time to shake out the bugs before 2.3b1 comes out? Especially the hand-written code will have to be examined to see where l needs to be turned into k.

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

Comment By: Thomas Heller (theller)
Date: 2003-02-18 21:59

Message:
Logged In: YES 
user_id=11105

Currently the h code means signed short
(SHRT_MIN..SHRT_MAX), do you really want to change that to
unsigned short (0..USHRT_MAX)?

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

Comment By: Thomas Heller (theller)
Date: 2003-02-18 21:33

Message:
Logged In: YES 
user_id=11105

Ok, I'll use your codes.

Here is my suggestion for the C api functions:

int PyInt_AsLongMask(PyObject *v, unsigned long *pval);
int PyInt_AsLongLongMask(PyObject *v, unsigned LONG_LONG *pval);

return -1 and set exception on error, return 0 otherwise and
store the result in pval. This saves the PyErr_Occurred() in
case the value is -1.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-18 21:18

Message:
Logged In: YES 
user_id=6380

A few days is fine (this doesn't need to make it into 2.3a2).

But the proposal here is not backwards compatible, is it?
Those codes already mean something different now.

I think we'll need to invent new format codes, or a new
modifier.

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

Comment By: Thomas Heller (theller)
Date: 2003-02-18 21:16

Message:
Logged In: YES 
user_id=11105

But it would probably take a few days.

What about these changes to the format codes, they are now
more in sync with the struct module (I hope the formatting
is kept):

Code    C type          	Range check

b	unsigned char		0..UCHAR_MAX
B	unsigned char		none **
h	unsigned short		0..USHRT_MAX
H	unsigned short		none **
i	int			INT_MIN..INT_MAX
I *	unsigned int		0..UINT_MAX
l	long			LONG_MIN..LONG_MAX
L *	unsigned long		none
q	long long		LLONG_MIN..LLONG_MAX
Q *	unsigned long long	none


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-18 20:50

Message:
Logged In: YES 
user_id=6380

Thomas: that would be great! (As long it isn't killed by bw
compat. :-)


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

Comment By: Thomas Heller (theller)
Date: 2003-02-18 20:18

Message:
Logged In: YES 
user_id=11105

If nobody else comes up, I can do this. I also had similar
checks for the struct module, but Tim killed it because of
backward compatibility.

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

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


From noreply@sourceforge.net  Thu Apr 17 16:49:24 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 17 Apr 2003 08:49:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-595026 ] Support for masks in getargs.c
Message-ID: <E196Bdc-00028P-00@sc8-sf-web4.sourceforge.net>

Bugs item #595026, was opened at 2002-08-14 14:26
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595026&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 7
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Thomas Heller (theller)
Summary: Support for masks in getargs.c

Initial Comment:
We need this implemented:

> How about the following counterproposal.  This also
changes some of
> the other format codes to be a little more regular.
>
> Code    C type          	Range check
>
> b	unsigned char		0..UCHAR_MAX
> B	unsigned char		none **
> h	unsigned short		0..USHRT_MAX
> H	unsigned short		none **
> i	int
		INT_MIN..INT_MAX
> I *	unsigned int		0..UINT_MAX
> l	long
		LONG_MIN..LONG_MAX
> k *	unsigned long		none
> L	long long		LLONG_MIN..LLONG_MAX
> K *	unsigned long long	none
>
> Notes:
>
> * New format codes.
>
> ** Changed from previous "range-and-a-half" to
"none"; the
>    range-and-a-half checking wasn't particularly useful.

Plus a C API or two, e.g. PyInt_AsLongMask() ->
unsigned long and PyInt_AsLongLongMask() -> unsigned
long long (if that exists).

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

>Comment By: Thomas Heller (theller)
Date: 2003-04-17 17:49

Message:
Logged In: YES 
user_id=11105

I forgot to say: kpatch.diff is obsolete, please ignore.
Hm, I'll better delete it.

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

Comment By: Thomas Heller (theller)
Date: 2003-04-17 17:47

Message:
Logged In: YES 
user_id=11105

Patch is ready for review (although NEWS and docs are
missing, I will add them later if the patch is accepted).

getargs.patch contains a context diff for several files,
including Modules/_testcapimodule.c.
test_getargs2.py should go into Lib/test, and tests the changes.
It also documents the new behaviour.

In the complete test-suite, test_array is crashing now as a
consequence.

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

Comment By: Thomas Heller (theller)
Date: 2003-02-21 19:36

Message:
Logged In: YES 
user_id=11105

Uploading patch whcih implements the 'k' format code.  Any
comments? Is this what is needed?
I know, docs are missing, and 'K' is missing.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-21 13:58

Message:
Logged In: YES 
user_id=6380

I suggest writing on python-dev or python-list.


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

Comment By: Thomas Heller (theller)
Date: 2003-02-20 21:45

Message:
Logged In: YES 
user_id=11105

I've implemented the 'k' getargs code, and
PyInt_AsUnsignedLongMask and PyLong_AsUnsignedLongMask
functions.  Is there any facility which would help me to
test this new code?

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

Comment By: Jack Jansen (jackjansen)
Date: 2003-02-18 23:08

Message:
Logged In: YES 
user_id=45365

Guido,
I would be happy with the no-rangecheck unsigned long formatcode. One request, though: if this is implemented can it be done ASAP after 2.3a2, so there's still some time to shake out the bugs before 2.3b1 comes out? Especially the hand-written code will have to be examined to see where l needs to be turned into k.

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

Comment By: Thomas Heller (theller)
Date: 2003-02-18 21:59

Message:
Logged In: YES 
user_id=11105

Currently the h code means signed short
(SHRT_MIN..SHRT_MAX), do you really want to change that to
unsigned short (0..USHRT_MAX)?

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

Comment By: Thomas Heller (theller)
Date: 2003-02-18 21:33

Message:
Logged In: YES 
user_id=11105

Ok, I'll use your codes.

Here is my suggestion for the C api functions:

int PyInt_AsLongMask(PyObject *v, unsigned long *pval);
int PyInt_AsLongLongMask(PyObject *v, unsigned LONG_LONG *pval);

return -1 and set exception on error, return 0 otherwise and
store the result in pval. This saves the PyErr_Occurred() in
case the value is -1.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-18 21:18

Message:
Logged In: YES 
user_id=6380

A few days is fine (this doesn't need to make it into 2.3a2).

But the proposal here is not backwards compatible, is it?
Those codes already mean something different now.

I think we'll need to invent new format codes, or a new
modifier.

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

Comment By: Thomas Heller (theller)
Date: 2003-02-18 21:16

Message:
Logged In: YES 
user_id=11105

But it would probably take a few days.

What about these changes to the format codes, they are now
more in sync with the struct module (I hope the formatting
is kept):

Code    C type          	Range check

b	unsigned char		0..UCHAR_MAX
B	unsigned char		none **
h	unsigned short		0..USHRT_MAX
H	unsigned short		none **
i	int			INT_MIN..INT_MAX
I *	unsigned int		0..UINT_MAX
l	long			LONG_MIN..LONG_MAX
L *	unsigned long		none
q	long long		LLONG_MIN..LLONG_MAX
Q *	unsigned long long	none


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-18 20:50

Message:
Logged In: YES 
user_id=6380

Thomas: that would be great! (As long it isn't killed by bw
compat. :-)


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

Comment By: Thomas Heller (theller)
Date: 2003-02-18 20:18

Message:
Logged In: YES 
user_id=11105

If nobody else comes up, I can do this. I also had similar
checks for the struct module, but Tim killed it because of
backward compatibility.

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

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


From noreply@sourceforge.net  Thu Apr 17 17:02:17 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 17 Apr 2003 09:02:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-654783 ] doctest and exception messages
Message-ID: <E196Bq5-0001av-00@sc8-sf-web1.sourceforge.net>

Bugs item #654783, was opened at 2002-12-16 14:23
Message generated for change (Settings changed) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654783&group_id=5470

Category: Documentation
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Aahz (aahz)
>Assigned to: Tim Peters (tim_one)
Summary: doctest and exception messages

Initial Comment:
doctest should include information something like this:

    doctest docstrings should not rely on the text of internal Python
    exceptions.  Notice the way factorial() uses its own error messages
    with the standard Python exceptions.  The internal messages can
    change even in bugfix releases (as in 2.2.1 to 2.2.2).


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

Comment By: Tim Peters (tim_one)
Date: 2002-12-16 18:39

Message:
Logged In: YES 
user_id=31435

It could, but it shouldn't:  error msgs in docs that don't match 
reality are also an insult to users.  doctest should grow some 
sort of option here, though, as its uses outgrew its original 
purposes.

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

Comment By: Neil Schemenauer (nascheme)
Date: 2002-12-16 17:01

Message:
Logged In: YES 
user_id=35752

Couldn't doctest be modified so that it only compares the
exception
name only?

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

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


From noreply@sourceforge.net  Thu Apr 17 17:12:50 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 17 Apr 2003 09:12:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-723205 ] PyThreadState_Clear() docs incorrect
Message-ID: <E196C0I-0002D1-00@sc8-sf-web1.sourceforge.net>

Bugs item #723205, was opened at 2003-04-17 18:12
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723205&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyThreadState_Clear() docs incorrect

Initial Comment:
The docs state that the GIL must be held while
PyThreadStare_Clear() is called. This seems incorrect,
at least in Python 2.2 the thread state must not be
NULL under certain conditions.

See:
http://mail.python.org/pipermail/python-dev/2003-April/034574.html


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

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


From noreply@sourceforge.net  Thu Apr 17 17:36:06 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 17 Apr 2003 09:36:06 -0700
Subject: [Python-bugs-list] [ python-Bugs-721157 ] Building lib.pdf fails on MacOSX
Message-ID: <E196CMo-0005PX-00@sc8-sf-web4.sourceforge.net>

Bugs item #721157, was opened at 2003-04-14 11:09
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=721157&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Building lib.pdf fails on MacOSX

Initial Comment:
I can't build lib.pdf on MacOSX anymore. I tried both a4 and letter.
The pdflatex call fails with

Error: pdflatex: buffer overflow [125000 bytes]

The whole lib.how is attached (if I don't forget to check the 
checkmark:-).

pdflatex -version prints

pdfTeX (Web2C 7.3.3.1) 3.14159-0.14h-released-20010417

which seems to be newer than what the README lists as the minimal 
requirement.

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-04-17 12:36

Message:
Logged In: YES 
user_id=3066

TeX systems tend to be a little weird about how memory is
allocated.
Most current distributions use a semi-static allocation
mechanism: Some large buffers are allocated once, and
everything happens within those.  The sizes are usually
configurable using a config file.

On my RedHat Linux box, which uses the "teTeX" TeX system,
there's a config file:

    /usr/share/texmf/web2c/texmf.cnf

This contains the following settings for pdfLaTeX:

TEXINPUTS.pdflatex = .;$TEXMF/{pdftex,tex}/{latex,generic,}//
main_memory.pdflatex = 1500000
hash_extra.pdflatex = 25000
pool_size.pdflatex = 750000
string_vacancies.pdflatex = 45000
max_strings.pdflatex = 55000
pool_free.pdflatex = 47500
nest_size.pdflatex = 500
param_size.pdflatex = 3000
save_size.pdflatex = 5000
stack_size.pdflatex = 3000

If you can locate the corresponding config file for your
system, please check the sizes configured and let me know
what differs. I may need to add some documentation about
this, mentioning that the Library Reference may take more
resources than are typically allocated.

Thanks!

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

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


From noreply@sourceforge.net  Thu Apr 17 17:36:51 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 17 Apr 2003 09:36:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-595026 ] Support for masks in getargs.c
Message-ID: <E196CNX-0003gk-00@sc8-sf-web1.sourceforge.net>

Bugs item #595026, was opened at 2002-08-14 08:26
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595026&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 7
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Thomas Heller (theller)
Summary: Support for masks in getargs.c

Initial Comment:
We need this implemented:

> How about the following counterproposal.  This also
changes some of
> the other format codes to be a little more regular.
>
> Code    C type          	Range check
>
> b	unsigned char		0..UCHAR_MAX
> B	unsigned char		none **
> h	unsigned short		0..USHRT_MAX
> H	unsigned short		none **
> i	int
		INT_MIN..INT_MAX
> I *	unsigned int		0..UINT_MAX
> l	long
		LONG_MIN..LONG_MAX
> k *	unsigned long		none
> L	long long		LLONG_MIN..LLONG_MAX
> K *	unsigned long long	none
>
> Notes:
>
> * New format codes.
>
> ** Changed from previous "range-and-a-half" to
"none"; the
>    range-and-a-half checking wasn't particularly useful.

Plus a C API or two, e.g. PyInt_AsLongMask() ->
unsigned long and PyInt_AsLongLongMask() -> unsigned
long long (if that exists).

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-17 12:36

Message:
Logged In: YES 
user_id=6380

Review comments:

- Where's the patch to getargs.c???

- There's a missing DECREF(io) in
PyInt_AsUnsignedLong[Long]Mask() in the block with the
"nb_int should return int object" error return. (This is
also missing from the template you used, PyInt_AsLong()!)

- I get a failure in _testcapi:

[guido@odiug linux]$ ./python ../Lib/test/test_capi.py
internal test_L_code
internal test_config
internal test_dict_iteration
internal test_k_code
Traceback (most recent call last):
  File "../Lib/test/test_capi.py", line 16, in ?
    raise test_support.TestFailed, sys.exc_info()[1]
test.test_support.TestFailed: test_k_code: k code returned
wrong value for long -0xFFF..000042
[guido@odiug linux]$ 


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

Comment By: Thomas Heller (theller)
Date: 2003-04-17 11:49

Message:
Logged In: YES 
user_id=11105

I forgot to say: kpatch.diff is obsolete, please ignore.
Hm, I'll better delete it.

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

Comment By: Thomas Heller (theller)
Date: 2003-04-17 11:47

Message:
Logged In: YES 
user_id=11105

Patch is ready for review (although NEWS and docs are
missing, I will add them later if the patch is accepted).

getargs.patch contains a context diff for several files,
including Modules/_testcapimodule.c.
test_getargs2.py should go into Lib/test, and tests the changes.
It also documents the new behaviour.

In the complete test-suite, test_array is crashing now as a
consequence.

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

Comment By: Thomas Heller (theller)
Date: 2003-02-21 13:36

Message:
Logged In: YES 
user_id=11105

Uploading patch whcih implements the 'k' format code.  Any
comments? Is this what is needed?
I know, docs are missing, and 'K' is missing.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-21 07:58

Message:
Logged In: YES 
user_id=6380

I suggest writing on python-dev or python-list.


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

Comment By: Thomas Heller (theller)
Date: 2003-02-20 15:45

Message:
Logged In: YES 
user_id=11105

I've implemented the 'k' getargs code, and
PyInt_AsUnsignedLongMask and PyLong_AsUnsignedLongMask
functions.  Is there any facility which would help me to
test this new code?

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

Comment By: Jack Jansen (jackjansen)
Date: 2003-02-18 17:08

Message:
Logged In: YES 
user_id=45365

Guido,
I would be happy with the no-rangecheck unsigned long formatcode. One request, though: if this is implemented can it be done ASAP after 2.3a2, so there's still some time to shake out the bugs before 2.3b1 comes out? Especially the hand-written code will have to be examined to see where l needs to be turned into k.

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

Comment By: Thomas Heller (theller)
Date: 2003-02-18 15:59

Message:
Logged In: YES 
user_id=11105

Currently the h code means signed short
(SHRT_MIN..SHRT_MAX), do you really want to change that to
unsigned short (0..USHRT_MAX)?

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

Comment By: Thomas Heller (theller)
Date: 2003-02-18 15:33

Message:
Logged In: YES 
user_id=11105

Ok, I'll use your codes.

Here is my suggestion for the C api functions:

int PyInt_AsLongMask(PyObject *v, unsigned long *pval);
int PyInt_AsLongLongMask(PyObject *v, unsigned LONG_LONG *pval);

return -1 and set exception on error, return 0 otherwise and
store the result in pval. This saves the PyErr_Occurred() in
case the value is -1.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-18 15:18

Message:
Logged In: YES 
user_id=6380

A few days is fine (this doesn't need to make it into 2.3a2).

But the proposal here is not backwards compatible, is it?
Those codes already mean something different now.

I think we'll need to invent new format codes, or a new
modifier.

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

Comment By: Thomas Heller (theller)
Date: 2003-02-18 15:16

Message:
Logged In: YES 
user_id=11105

But it would probably take a few days.

What about these changes to the format codes, they are now
more in sync with the struct module (I hope the formatting
is kept):

Code    C type          	Range check

b	unsigned char		0..UCHAR_MAX
B	unsigned char		none **
h	unsigned short		0..USHRT_MAX
H	unsigned short		none **
i	int			INT_MIN..INT_MAX
I *	unsigned int		0..UINT_MAX
l	long			LONG_MIN..LONG_MAX
L *	unsigned long		none
q	long long		LLONG_MIN..LLONG_MAX
Q *	unsigned long long	none


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-18 14:50

Message:
Logged In: YES 
user_id=6380

Thomas: that would be great! (As long it isn't killed by bw
compat. :-)


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

Comment By: Thomas Heller (theller)
Date: 2003-02-18 14:18

Message:
Logged In: YES 
user_id=11105

If nobody else comes up, I can do this. I also had similar
checks for the struct module, but Tim killed it because of
backward compatibility.

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

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


From noreply@sourceforge.net  Thu Apr 17 18:02:37 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 17 Apr 2003 10:02:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-595026 ] Support for masks in getargs.c
Message-ID: <E196CmT-00059I-00@sc8-sf-web1.sourceforge.net>

Bugs item #595026, was opened at 2002-08-14 14:26
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595026&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 7
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Thomas Heller (theller)
Summary: Support for masks in getargs.c

Initial Comment:
We need this implemented:

> How about the following counterproposal.  This also
changes some of
> the other format codes to be a little more regular.
>
> Code    C type          	Range check
>
> b	unsigned char		0..UCHAR_MAX
> B	unsigned char		none **
> h	unsigned short		0..USHRT_MAX
> H	unsigned short		none **
> i	int
		INT_MIN..INT_MAX
> I *	unsigned int		0..UINT_MAX
> l	long
		LONG_MIN..LONG_MAX
> k *	unsigned long		none
> L	long long		LLONG_MIN..LLONG_MAX
> K *	unsigned long long	none
>
> Notes:
>
> * New format codes.
>
> ** Changed from previous "range-and-a-half" to
"none"; the
>    range-and-a-half checking wasn't particularly useful.

Plus a C API or two, e.g. PyInt_AsLongMask() ->
unsigned long and PyInt_AsLongLongMask() -> unsigned
long long (if that exists).

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

>Comment By: Thomas Heller (theller)
Date: 2003-04-17 19:02

Message:
Logged In: YES 
user_id=11105

Oops, sorry: getargs.c.diff

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-17 18:36

Message:
Logged In: YES 
user_id=6380

Review comments:

- Where's the patch to getargs.c???

- There's a missing DECREF(io) in
PyInt_AsUnsignedLong[Long]Mask() in the block with the
"nb_int should return int object" error return. (This is
also missing from the template you used, PyInt_AsLong()!)

- I get a failure in _testcapi:

[guido@odiug linux]$ ./python ../Lib/test/test_capi.py
internal test_L_code
internal test_config
internal test_dict_iteration
internal test_k_code
Traceback (most recent call last):
  File "../Lib/test/test_capi.py", line 16, in ?
    raise test_support.TestFailed, sys.exc_info()[1]
test.test_support.TestFailed: test_k_code: k code returned
wrong value for long -0xFFF..000042
[guido@odiug linux]$ 


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

Comment By: Thomas Heller (theller)
Date: 2003-04-17 17:49

Message:
Logged In: YES 
user_id=11105

I forgot to say: kpatch.diff is obsolete, please ignore.
Hm, I'll better delete it.

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

Comment By: Thomas Heller (theller)
Date: 2003-04-17 17:47

Message:
Logged In: YES 
user_id=11105

Patch is ready for review (although NEWS and docs are
missing, I will add them later if the patch is accepted).

getargs.patch contains a context diff for several files,
including Modules/_testcapimodule.c.
test_getargs2.py should go into Lib/test, and tests the changes.
It also documents the new behaviour.

In the complete test-suite, test_array is crashing now as a
consequence.

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

Comment By: Thomas Heller (theller)
Date: 2003-02-21 19:36

Message:
Logged In: YES 
user_id=11105

Uploading patch whcih implements the 'k' format code.  Any
comments? Is this what is needed?
I know, docs are missing, and 'K' is missing.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-21 13:58

Message:
Logged In: YES 
user_id=6380

I suggest writing on python-dev or python-list.


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

Comment By: Thomas Heller (theller)
Date: 2003-02-20 21:45

Message:
Logged In: YES 
user_id=11105

I've implemented the 'k' getargs code, and
PyInt_AsUnsignedLongMask and PyLong_AsUnsignedLongMask
functions.  Is there any facility which would help me to
test this new code?

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

Comment By: Jack Jansen (jackjansen)
Date: 2003-02-18 23:08

Message:
Logged In: YES 
user_id=45365

Guido,
I would be happy with the no-rangecheck unsigned long formatcode. One request, though: if this is implemented can it be done ASAP after 2.3a2, so there's still some time to shake out the bugs before 2.3b1 comes out? Especially the hand-written code will have to be examined to see where l needs to be turned into k.

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

Comment By: Thomas Heller (theller)
Date: 2003-02-18 21:59

Message:
Logged In: YES 
user_id=11105

Currently the h code means signed short
(SHRT_MIN..SHRT_MAX), do you really want to change that to
unsigned short (0..USHRT_MAX)?

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

Comment By: Thomas Heller (theller)
Date: 2003-02-18 21:33

Message:
Logged In: YES 
user_id=11105

Ok, I'll use your codes.

Here is my suggestion for the C api functions:

int PyInt_AsLongMask(PyObject *v, unsigned long *pval);
int PyInt_AsLongLongMask(PyObject *v, unsigned LONG_LONG *pval);

return -1 and set exception on error, return 0 otherwise and
store the result in pval. This saves the PyErr_Occurred() in
case the value is -1.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-18 21:18

Message:
Logged In: YES 
user_id=6380

A few days is fine (this doesn't need to make it into 2.3a2).

But the proposal here is not backwards compatible, is it?
Those codes already mean something different now.

I think we'll need to invent new format codes, or a new
modifier.

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

Comment By: Thomas Heller (theller)
Date: 2003-02-18 21:16

Message:
Logged In: YES 
user_id=11105

But it would probably take a few days.

What about these changes to the format codes, they are now
more in sync with the struct module (I hope the formatting
is kept):

Code    C type          	Range check

b	unsigned char		0..UCHAR_MAX
B	unsigned char		none **
h	unsigned short		0..USHRT_MAX
H	unsigned short		none **
i	int			INT_MIN..INT_MAX
I *	unsigned int		0..UINT_MAX
l	long			LONG_MIN..LONG_MAX
L *	unsigned long		none
q	long long		LLONG_MIN..LLONG_MAX
Q *	unsigned long long	none


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-18 20:50

Message:
Logged In: YES 
user_id=6380

Thomas: that would be great! (As long it isn't killed by bw
compat. :-)


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

Comment By: Thomas Heller (theller)
Date: 2003-02-18 20:18

Message:
Logged In: YES 
user_id=11105

If nobody else comes up, I can do this. I also had similar
checks for the struct module, but Tim killed it because of
backward compatibility.

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

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


From noreply@sourceforge.net  Thu Apr 17 18:09:14 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 17 Apr 2003 10:09:14 -0700
Subject: [Python-bugs-list] [ python-Bugs-595026 ] Support for masks in getargs.c
Message-ID: <E196Css-0005TQ-00@sc8-sf-web1.sourceforge.net>

Bugs item #595026, was opened at 2002-08-14 14:26
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595026&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 7
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Thomas Heller (theller)
Summary: Support for masks in getargs.c

Initial Comment:
We need this implemented:

> How about the following counterproposal.  This also
changes some of
> the other format codes to be a little more regular.
>
> Code    C type          	Range check
>
> b	unsigned char		0..UCHAR_MAX
> B	unsigned char		none **
> h	unsigned short		0..USHRT_MAX
> H	unsigned short		none **
> i	int
		INT_MIN..INT_MAX
> I *	unsigned int		0..UINT_MAX
> l	long
		LONG_MIN..LONG_MAX
> k *	unsigned long		none
> L	long long		LLONG_MIN..LLONG_MAX
> K *	unsigned long long	none
>
> Notes:
>
> * New format codes.
>
> ** Changed from previous "range-and-a-half" to
"none"; the
>    range-and-a-half checking wasn't particularly useful.

Plus a C API or two, e.g. PyInt_AsLongMask() ->
unsigned long and PyInt_AsLongLongMask() -> unsigned
long long (if that exists).

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

>Comment By: Thomas Heller (theller)
Date: 2003-04-17 19:09

Message:
Logged In: YES 
user_id=11105

But wait: I'll fix the missing decrefs, and create a new,
complete patch. Takes a couple of minutes, though.

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

Comment By: Thomas Heller (theller)
Date: 2003-04-17 19:02

Message:
Logged In: YES 
user_id=11105

Oops, sorry: getargs.c.diff

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-17 18:36

Message:
Logged In: YES 
user_id=6380

Review comments:

- Where's the patch to getargs.c???

- There's a missing DECREF(io) in
PyInt_AsUnsignedLong[Long]Mask() in the block with the
"nb_int should return int object" error return. (This is
also missing from the template you used, PyInt_AsLong()!)

- I get a failure in _testcapi:

[guido@odiug linux]$ ./python ../Lib/test/test_capi.py
internal test_L_code
internal test_config
internal test_dict_iteration
internal test_k_code
Traceback (most recent call last):
  File "../Lib/test/test_capi.py", line 16, in ?
    raise test_support.TestFailed, sys.exc_info()[1]
test.test_support.TestFailed: test_k_code: k code returned
wrong value for long -0xFFF..000042
[guido@odiug linux]$ 


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

Comment By: Thomas Heller (theller)
Date: 2003-04-17 17:49

Message:
Logged In: YES 
user_id=11105

I forgot to say: kpatch.diff is obsolete, please ignore.
Hm, I'll better delete it.

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

Comment By: Thomas Heller (theller)
Date: 2003-04-17 17:47

Message:
Logged In: YES 
user_id=11105

Patch is ready for review (although NEWS and docs are
missing, I will add them later if the patch is accepted).

getargs.patch contains a context diff for several files,
including Modules/_testcapimodule.c.
test_getargs2.py should go into Lib/test, and tests the changes.
It also documents the new behaviour.

In the complete test-suite, test_array is crashing now as a
consequence.

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

Comment By: Thomas Heller (theller)
Date: 2003-02-21 19:36

Message:
Logged In: YES 
user_id=11105

Uploading patch whcih implements the 'k' format code.  Any
comments? Is this what is needed?
I know, docs are missing, and 'K' is missing.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-21 13:58

Message:
Logged In: YES 
user_id=6380

I suggest writing on python-dev or python-list.


----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-02-20 21:45

Message:
Logged In: YES 
user_id=11105

I've implemented the 'k' getargs code, and
PyInt_AsUnsignedLongMask and PyLong_AsUnsignedLongMask
functions.  Is there any facility which would help me to
test this new code?

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-02-18 23:08

Message:
Logged In: YES 
user_id=45365

Guido,
I would be happy with the no-rangecheck unsigned long formatcode. One request, though: if this is implemented can it be done ASAP after 2.3a2, so there's still some time to shake out the bugs before 2.3b1 comes out? Especially the hand-written code will have to be examined to see where l needs to be turned into k.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-02-18 21:59

Message:
Logged In: YES 
user_id=11105

Currently the h code means signed short
(SHRT_MIN..SHRT_MAX), do you really want to change that to
unsigned short (0..USHRT_MAX)?

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-02-18 21:33

Message:
Logged In: YES 
user_id=11105

Ok, I'll use your codes.

Here is my suggestion for the C api functions:

int PyInt_AsLongMask(PyObject *v, unsigned long *pval);
int PyInt_AsLongLongMask(PyObject *v, unsigned LONG_LONG *pval);

return -1 and set exception on error, return 0 otherwise and
store the result in pval. This saves the PyErr_Occurred() in
case the value is -1.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-18 21:18

Message:
Logged In: YES 
user_id=6380

A few days is fine (this doesn't need to make it into 2.3a2).

But the proposal here is not backwards compatible, is it?
Those codes already mean something different now.

I think we'll need to invent new format codes, or a new
modifier.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-02-18 21:16

Message:
Logged In: YES 
user_id=11105

But it would probably take a few days.

What about these changes to the format codes, they are now
more in sync with the struct module (I hope the formatting
is kept):

Code    C type          	Range check

b	unsigned char		0..UCHAR_MAX
B	unsigned char		none **
h	unsigned short		0..USHRT_MAX
H	unsigned short		none **
i	int			INT_MIN..INT_MAX
I *	unsigned int		0..UINT_MAX
l	long			LONG_MIN..LONG_MAX
L *	unsigned long		none
q	long long		LLONG_MIN..LLONG_MAX
Q *	unsigned long long	none


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-18 20:50

Message:
Logged In: YES 
user_id=6380

Thomas: that would be great! (As long it isn't killed by bw
compat. :-)


----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-02-18 20:18

Message:
Logged In: YES 
user_id=11105

If nobody else comes up, I can do this. I also had similar
checks for the struct module, but Tim killed it because of
backward compatibility.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595026&group_id=5470


From noreply@sourceforge.net  Thu Apr 17 18:21:44 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 17 Apr 2003 10:21:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-595026 ] Support for masks in getargs.c
Message-ID: <E196D4y-000684-00@sc8-sf-web1.sourceforge.net>

Bugs item #595026, was opened at 2002-08-14 14:26
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595026&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 7
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Thomas Heller (theller)
Summary: Support for masks in getargs.c

Initial Comment:
We need this implemented:

> How about the following counterproposal.  This also
changes some of
> the other format codes to be a little more regular.
>
> Code    C type          	Range check
>
> b	unsigned char		0..UCHAR_MAX
> B	unsigned char		none **
> h	unsigned short		0..USHRT_MAX
> H	unsigned short		none **
> i	int
		INT_MIN..INT_MAX
> I *	unsigned int		0..UINT_MAX
> l	long
		LONG_MIN..LONG_MAX
> k *	unsigned long		none
> L	long long		LLONG_MIN..LLONG_MAX
> K *	unsigned long long	none
>
> Notes:
>
> * New format codes.
>
> ** Changed from previous "range-and-a-half" to
"none"; the
>    range-and-a-half checking wasn't particularly useful.

Plus a C API or two, e.g. PyInt_AsLongMask() ->
unsigned long and PyInt_AsLongLongMask() -> unsigned
long long (if that exists).

----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2003-04-17 19:21

Message:
Logged In: YES 
user_id=11105

getargs-2.patch, hopefully complete, but test_getargs2.py
not included.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-04-17 19:09

Message:
Logged In: YES 
user_id=11105

But wait: I'll fix the missing decrefs, and create a new,
complete patch. Takes a couple of minutes, though.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-04-17 19:02

Message:
Logged In: YES 
user_id=11105

Oops, sorry: getargs.c.diff

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-17 18:36

Message:
Logged In: YES 
user_id=6380

Review comments:

- Where's the patch to getargs.c???

- There's a missing DECREF(io) in
PyInt_AsUnsignedLong[Long]Mask() in the block with the
"nb_int should return int object" error return. (This is
also missing from the template you used, PyInt_AsLong()!)

- I get a failure in _testcapi:

[guido@odiug linux]$ ./python ../Lib/test/test_capi.py
internal test_L_code
internal test_config
internal test_dict_iteration
internal test_k_code
Traceback (most recent call last):
  File "../Lib/test/test_capi.py", line 16, in ?
    raise test_support.TestFailed, sys.exc_info()[1]
test.test_support.TestFailed: test_k_code: k code returned
wrong value for long -0xFFF..000042
[guido@odiug linux]$ 


----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-04-17 17:49

Message:
Logged In: YES 
user_id=11105

I forgot to say: kpatch.diff is obsolete, please ignore.
Hm, I'll better delete it.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-04-17 17:47

Message:
Logged In: YES 
user_id=11105

Patch is ready for review (although NEWS and docs are
missing, I will add them later if the patch is accepted).

getargs.patch contains a context diff for several files,
including Modules/_testcapimodule.c.
test_getargs2.py should go into Lib/test, and tests the changes.
It also documents the new behaviour.

In the complete test-suite, test_array is crashing now as a
consequence.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-02-21 19:36

Message:
Logged In: YES 
user_id=11105

Uploading patch whcih implements the 'k' format code.  Any
comments? Is this what is needed?
I know, docs are missing, and 'K' is missing.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-21 13:58

Message:
Logged In: YES 
user_id=6380

I suggest writing on python-dev or python-list.


----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-02-20 21:45

Message:
Logged In: YES 
user_id=11105

I've implemented the 'k' getargs code, and
PyInt_AsUnsignedLongMask and PyLong_AsUnsignedLongMask
functions.  Is there any facility which would help me to
test this new code?

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-02-18 23:08

Message:
Logged In: YES 
user_id=45365

Guido,
I would be happy with the no-rangecheck unsigned long formatcode. One request, though: if this is implemented can it be done ASAP after 2.3a2, so there's still some time to shake out the bugs before 2.3b1 comes out? Especially the hand-written code will have to be examined to see where l needs to be turned into k.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-02-18 21:59

Message:
Logged In: YES 
user_id=11105

Currently the h code means signed short
(SHRT_MIN..SHRT_MAX), do you really want to change that to
unsigned short (0..USHRT_MAX)?

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-02-18 21:33

Message:
Logged In: YES 
user_id=11105

Ok, I'll use your codes.

Here is my suggestion for the C api functions:

int PyInt_AsLongMask(PyObject *v, unsigned long *pval);
int PyInt_AsLongLongMask(PyObject *v, unsigned LONG_LONG *pval);

return -1 and set exception on error, return 0 otherwise and
store the result in pval. This saves the PyErr_Occurred() in
case the value is -1.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-18 21:18

Message:
Logged In: YES 
user_id=6380

A few days is fine (this doesn't need to make it into 2.3a2).

But the proposal here is not backwards compatible, is it?
Those codes already mean something different now.

I think we'll need to invent new format codes, or a new
modifier.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-02-18 21:16

Message:
Logged In: YES 
user_id=11105

But it would probably take a few days.

What about these changes to the format codes, they are now
more in sync with the struct module (I hope the formatting
is kept):

Code    C type          	Range check

b	unsigned char		0..UCHAR_MAX
B	unsigned char		none **
h	unsigned short		0..USHRT_MAX
H	unsigned short		none **
i	int			INT_MIN..INT_MAX
I *	unsigned int		0..UINT_MAX
l	long			LONG_MIN..LONG_MAX
L *	unsigned long		none
q	long long		LLONG_MIN..LLONG_MAX
Q *	unsigned long long	none


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-18 20:50

Message:
Logged In: YES 
user_id=6380

Thomas: that would be great! (As long it isn't killed by bw
compat. :-)


----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-02-18 20:18

Message:
Logged In: YES 
user_id=11105

If nobody else comes up, I can do this. I also had similar
checks for the struct module, but Tim killed it because of
backward compatibility.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595026&group_id=5470


From noreply@sourceforge.net  Thu Apr 17 19:06:03 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 17 Apr 2003 11:06:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-595026 ] Support for masks in getargs.c
Message-ID: <E196Dlr-0007sz-00@sc8-sf-web3.sourceforge.net>

Bugs item #595026, was opened at 2002-08-14 08:26
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595026&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
>Resolution: Accepted
Priority: 7
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Thomas Heller (theller)
Summary: Support for masks in getargs.c

Initial Comment:
We need this implemented:

> How about the following counterproposal.  This also
changes some of
> the other format codes to be a little more regular.
>
> Code    C type          	Range check
>
> b	unsigned char		0..UCHAR_MAX
> B	unsigned char		none **
> h	unsigned short		0..USHRT_MAX
> H	unsigned short		none **
> i	int
		INT_MIN..INT_MAX
> I *	unsigned int		0..UINT_MAX
> l	long
		LONG_MIN..LONG_MAX
> k *	unsigned long		none
> L	long long		LLONG_MIN..LLONG_MAX
> K *	unsigned long long	none
>
> Notes:
>
> * New format codes.
>
> ** Changed from previous "range-and-a-half" to
"none"; the
>    range-and-a-half checking wasn't particularly useful.

Plus a C API or two, e.g. PyInt_AsLongMask() ->
unsigned long and PyInt_AsLongLongMask() -> unsigned
long long (if that exists).

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-17 14:06

Message:
Logged In: YES 
user_id=6380

Good enough; check it in, with docs and NEWS.

But please fix these:

- the 'h' opcode comments and error messages still refer to
it as "signed short" while it is now clearly an *unsigned*
short. (Hm... maybe 'h' should remain a signed short after
all, for backwards compatibility?)

- there's still an unused definition of AddSym in testcapi.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-04-17 13:21

Message:
Logged In: YES 
user_id=11105

getargs-2.patch, hopefully complete, but test_getargs2.py
not included.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-04-17 13:09

Message:
Logged In: YES 
user_id=11105

But wait: I'll fix the missing decrefs, and create a new,
complete patch. Takes a couple of minutes, though.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-04-17 13:02

Message:
Logged In: YES 
user_id=11105

Oops, sorry: getargs.c.diff

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-17 12:36

Message:
Logged In: YES 
user_id=6380

Review comments:

- Where's the patch to getargs.c???

- There's a missing DECREF(io) in
PyInt_AsUnsignedLong[Long]Mask() in the block with the
"nb_int should return int object" error return. (This is
also missing from the template you used, PyInt_AsLong()!)

- I get a failure in _testcapi:

[guido@odiug linux]$ ./python ../Lib/test/test_capi.py
internal test_L_code
internal test_config
internal test_dict_iteration
internal test_k_code
Traceback (most recent call last):
  File "../Lib/test/test_capi.py", line 16, in ?
    raise test_support.TestFailed, sys.exc_info()[1]
test.test_support.TestFailed: test_k_code: k code returned
wrong value for long -0xFFF..000042
[guido@odiug linux]$ 


----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-04-17 11:49

Message:
Logged In: YES 
user_id=11105

I forgot to say: kpatch.diff is obsolete, please ignore.
Hm, I'll better delete it.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-04-17 11:47

Message:
Logged In: YES 
user_id=11105

Patch is ready for review (although NEWS and docs are
missing, I will add them later if the patch is accepted).

getargs.patch contains a context diff for several files,
including Modules/_testcapimodule.c.
test_getargs2.py should go into Lib/test, and tests the changes.
It also documents the new behaviour.

In the complete test-suite, test_array is crashing now as a
consequence.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-02-21 13:36

Message:
Logged In: YES 
user_id=11105

Uploading patch whcih implements the 'k' format code.  Any
comments? Is this what is needed?
I know, docs are missing, and 'K' is missing.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-21 07:58

Message:
Logged In: YES 
user_id=6380

I suggest writing on python-dev or python-list.


----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-02-20 15:45

Message:
Logged In: YES 
user_id=11105

I've implemented the 'k' getargs code, and
PyInt_AsUnsignedLongMask and PyLong_AsUnsignedLongMask
functions.  Is there any facility which would help me to
test this new code?

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-02-18 17:08

Message:
Logged In: YES 
user_id=45365

Guido,
I would be happy with the no-rangecheck unsigned long formatcode. One request, though: if this is implemented can it be done ASAP after 2.3a2, so there's still some time to shake out the bugs before 2.3b1 comes out? Especially the hand-written code will have to be examined to see where l needs to be turned into k.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-02-18 15:59

Message:
Logged In: YES 
user_id=11105

Currently the h code means signed short
(SHRT_MIN..SHRT_MAX), do you really want to change that to
unsigned short (0..USHRT_MAX)?

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-02-18 15:33

Message:
Logged In: YES 
user_id=11105

Ok, I'll use your codes.

Here is my suggestion for the C api functions:

int PyInt_AsLongMask(PyObject *v, unsigned long *pval);
int PyInt_AsLongLongMask(PyObject *v, unsigned LONG_LONG *pval);

return -1 and set exception on error, return 0 otherwise and
store the result in pval. This saves the PyErr_Occurred() in
case the value is -1.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-18 15:18

Message:
Logged In: YES 
user_id=6380

A few days is fine (this doesn't need to make it into 2.3a2).

But the proposal here is not backwards compatible, is it?
Those codes already mean something different now.

I think we'll need to invent new format codes, or a new
modifier.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-02-18 15:16

Message:
Logged In: YES 
user_id=11105

But it would probably take a few days.

What about these changes to the format codes, they are now
more in sync with the struct module (I hope the formatting
is kept):

Code    C type          	Range check

b	unsigned char		0..UCHAR_MAX
B	unsigned char		none **
h	unsigned short		0..USHRT_MAX
H	unsigned short		none **
i	int			INT_MIN..INT_MAX
I *	unsigned int		0..UINT_MAX
l	long			LONG_MIN..LONG_MAX
L *	unsigned long		none
q	long long		LLONG_MIN..LLONG_MAX
Q *	unsigned long long	none


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-18 14:50

Message:
Logged In: YES 
user_id=6380

Thomas: that would be great! (As long it isn't killed by bw
compat. :-)


----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-02-18 14:18

Message:
Logged In: YES 
user_id=11105

If nobody else comes up, I can do this. I also had similar
checks for the struct module, but Tim killed it because of
backward compatibility.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595026&group_id=5470


From noreply@sourceforge.net  Thu Apr 17 19:08:41 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 17 Apr 2003 11:08:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-568068 ] urllib needs 303/307 handlers
Message-ID: <E196DoP-000814-00@sc8-sf-web3.sourceforge.net>

Bugs item #568068, was opened at 2002-06-12 11:36
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=568068&group_id=5470

Category: Python Library
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib needs 303/307 handlers

Initial Comment:
See

http://mail.python.org/pipermail/python-dev/2002-June/025289.htm

and

http://ppewww.ph.gla.ac.uk/~flavell/www/post-redirect.html

There is also an issue with the 302 handler (also
discussed there).


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-17 14:08

Message:
Logged In: YES 
user_id=6380

Deferring to discussion for patch 549151.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-10-21 16:42

Message:
Logged In: YES 
user_id=261020

Agreement seems to have been reached on this in the
discussion of bug #549151.  There is a patch there, but only
the change to the 303 case should be applied, not 301.  The
docs need to state that 303 is automatically handled, too.

Jeremy Hylton, from bug #549151:
> I agree with your interpretation that urllib2 raise an
> HTTPError to signal "request confirm" because an HTTPError
> is also a valid response that the user could interpret.
> But of urllib, an HTTP error doesn't contain a valid
> response.  The change would make it impossible for the
> client to do anything if a 301 response is returned from a
> POST.  That seems worse than doing the wrong.

John Lee, in reply:
> As for urllib.py, I see the problem.  303 should still be
> added, though, since that poses no problem at all.


John


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=568068&group_id=5470


From noreply@sourceforge.net  Thu Apr 17 19:10:20 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 17 Apr 2003 11:10:20 -0700
Subject: [Python-bugs-list] [ python-Bugs-723205 ] PyThreadState_Clear() docs incorrect
Message-ID: <E196Dq0-00086Q-00@sc8-sf-web3.sourceforge.net>

Bugs item #723205, was opened at 2003-04-17 12:12
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723205&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyThreadState_Clear() docs incorrect

Initial Comment:
The docs state that the GIL must be held while
PyThreadStare_Clear() is called. This seems incorrect,
at least in Python 2.2 the thread state must not be
NULL under certain conditions.

See:
http://mail.python.org/pipermail/python-dev/2003-April/034574.html


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2003-04-17 14:10

Message:
Logged In: YES 
user_id=31435

That was a confusing thread, and this is a confusing bug 
report <wink>.

Are you claiming that the GIL does not need to be held?  If 
not (and it doesn't seem that you were in the thread), it's 
unclear why you mention the GIL.

Best would be if you attached a patch incorporating what you 
think the resolution of that thread was.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723205&group_id=5470


From noreply@sourceforge.net  Thu Apr 17 19:28:02 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 17 Apr 2003 11:28:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-723287 ] add timeout support in socket using modules
Message-ID: <E196E78-0000eY-00@sc8-sf-web3.sourceforge.net>

Bugs item #723287, was opened at 2003-04-17 13:28
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723287&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: John Speno (corvus)
Assigned to: Nobody/Anonymous (nobody)
Summary: add timeout support in socket using modules

Initial Comment:
Now that Skip has fixed the socket.settimeout() issue for sockets as 
files (bug 707074), it would be nice if the higher level modules had 
options for 
setting socket timeouts. I'm thinking of httplib, smtplib, nntplib, et 
al.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723287&group_id=5470


From noreply@sourceforge.net  Thu Apr 17 19:36:53 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 17 Apr 2003 11:36:53 -0700
Subject: [Python-bugs-list] [ python-Bugs-723205 ] PyThreadState_Clear() docs incorrect
Message-ID: <E196EFh-0001BF-00@sc8-sf-web3.sourceforge.net>

Bugs item #723205, was opened at 2003-04-17 18:12
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723205&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyThreadState_Clear() docs incorrect

Initial Comment:
The docs state that the GIL must be held while
PyThreadStare_Clear() is called. This seems incorrect,
at least in Python 2.2 the thread state must not be
NULL under certain conditions.

See:
http://mail.python.org/pipermail/python-dev/2003-April/034574.html


----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2003-04-17 20:36

Message:
Logged In: YES 
user_id=11105

Sorry, that's because I'm still confused about thread
states, and I think the experts ;-) should sort this out.

No, I'm not claiming that the GIL does not need to be held,
I'm claiming that this is not sufficient: *in addition* the
current threadstate must not be NULL.

To quote from the mentioned posts:

I was doing this:

pts = PyThreadState_Swap(NULL);
PyThreadState_Clear(pts);
PyThreadState_Delete(pts);
PyEval_ReleaseLock();

and got a crash in PyThreadState_Clear(). If I understand
the current docs correctly, this should be allowed, so (my
conclusion) the docs are wrong.

I had to change the code in this way to avoid the crashes:

pts = PyThreadState_Get();
PyThreadState_Clear(pts);
pts = PyThreadState_Swap(NULL);
PyThreadState_Delete(pts);
PyEval_ReleaseLock();

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-04-17 20:10

Message:
Logged In: YES 
user_id=31435

That was a confusing thread, and this is a confusing bug 
report <wink>.

Are you claiming that the GIL does not need to be held?  If 
not (and it doesn't seem that you were in the thread), it's 
unclear why you mention the GIL.

Best would be if you attached a patch incorporating what you 
think the resolution of that thread was.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723205&group_id=5470


From noreply@sourceforge.net  Thu Apr 17 19:56:55 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 17 Apr 2003 11:56:55 -0700
Subject: [Python-bugs-list] [ python-Bugs-595026 ] Support for masks in getargs.c
Message-ID: <E196EZ5-0006Xz-00@sc8-sf-web2.sourceforge.net>

Bugs item #595026, was opened at 2002-08-14 14:26
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595026&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
>Status: Closed
Resolution: Accepted
Priority: 7
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Thomas Heller (theller)
Summary: Support for masks in getargs.c

Initial Comment:
We need this implemented:

> How about the following counterproposal.  This also
changes some of
> the other format codes to be a little more regular.
>
> Code    C type          	Range check
>
> b	unsigned char		0..UCHAR_MAX
> B	unsigned char		none **
> h	unsigned short		0..USHRT_MAX
> H	unsigned short		none **
> i	int
		INT_MIN..INT_MAX
> I *	unsigned int		0..UINT_MAX
> l	long
		LONG_MIN..LONG_MAX
> k *	unsigned long		none
> L	long long		LLONG_MIN..LLONG_MAX
> K *	unsigned long long	none
>
> Notes:
>
> * New format codes.
>
> ** Changed from previous "range-and-a-half" to
"none"; the
>    range-and-a-half checking wasn't particularly useful.

Plus a C API or two, e.g. PyInt_AsLongMask() ->
unsigned long and PyInt_AsLongLongMask() -> unsigned
long long (if that exists).

----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2003-04-17 20:56

Message:
Logged In: YES 
user_id=11105

Checked in with the changes you requested.
I left the 'h' opcode unchanged, if needed this can be fixed
later.

Will do the docs on tuesday, NEWS today, if time permits.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-17 20:06

Message:
Logged In: YES 
user_id=6380

Good enough; check it in, with docs and NEWS.

But please fix these:

- the 'h' opcode comments and error messages still refer to
it as "signed short" while it is now clearly an *unsigned*
short. (Hm... maybe 'h' should remain a signed short after
all, for backwards compatibility?)

- there's still an unused definition of AddSym in testcapi.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-04-17 19:21

Message:
Logged In: YES 
user_id=11105

getargs-2.patch, hopefully complete, but test_getargs2.py
not included.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-04-17 19:09

Message:
Logged In: YES 
user_id=11105

But wait: I'll fix the missing decrefs, and create a new,
complete patch. Takes a couple of minutes, though.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-04-17 19:02

Message:
Logged In: YES 
user_id=11105

Oops, sorry: getargs.c.diff

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-17 18:36

Message:
Logged In: YES 
user_id=6380

Review comments:

- Where's the patch to getargs.c???

- There's a missing DECREF(io) in
PyInt_AsUnsignedLong[Long]Mask() in the block with the
"nb_int should return int object" error return. (This is
also missing from the template you used, PyInt_AsLong()!)

- I get a failure in _testcapi:

[guido@odiug linux]$ ./python ../Lib/test/test_capi.py
internal test_L_code
internal test_config
internal test_dict_iteration
internal test_k_code
Traceback (most recent call last):
  File "../Lib/test/test_capi.py", line 16, in ?
    raise test_support.TestFailed, sys.exc_info()[1]
test.test_support.TestFailed: test_k_code: k code returned
wrong value for long -0xFFF..000042
[guido@odiug linux]$ 


----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-04-17 17:49

Message:
Logged In: YES 
user_id=11105

I forgot to say: kpatch.diff is obsolete, please ignore.
Hm, I'll better delete it.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-04-17 17:47

Message:
Logged In: YES 
user_id=11105

Patch is ready for review (although NEWS and docs are
missing, I will add them later if the patch is accepted).

getargs.patch contains a context diff for several files,
including Modules/_testcapimodule.c.
test_getargs2.py should go into Lib/test, and tests the changes.
It also documents the new behaviour.

In the complete test-suite, test_array is crashing now as a
consequence.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-02-21 19:36

Message:
Logged In: YES 
user_id=11105

Uploading patch whcih implements the 'k' format code.  Any
comments? Is this what is needed?
I know, docs are missing, and 'K' is missing.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-21 13:58

Message:
Logged In: YES 
user_id=6380

I suggest writing on python-dev or python-list.


----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-02-20 21:45

Message:
Logged In: YES 
user_id=11105

I've implemented the 'k' getargs code, and
PyInt_AsUnsignedLongMask and PyLong_AsUnsignedLongMask
functions.  Is there any facility which would help me to
test this new code?

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-02-18 23:08

Message:
Logged In: YES 
user_id=45365

Guido,
I would be happy with the no-rangecheck unsigned long formatcode. One request, though: if this is implemented can it be done ASAP after 2.3a2, so there's still some time to shake out the bugs before 2.3b1 comes out? Especially the hand-written code will have to be examined to see where l needs to be turned into k.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-02-18 21:59

Message:
Logged In: YES 
user_id=11105

Currently the h code means signed short
(SHRT_MIN..SHRT_MAX), do you really want to change that to
unsigned short (0..USHRT_MAX)?

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-02-18 21:33

Message:
Logged In: YES 
user_id=11105

Ok, I'll use your codes.

Here is my suggestion for the C api functions:

int PyInt_AsLongMask(PyObject *v, unsigned long *pval);
int PyInt_AsLongLongMask(PyObject *v, unsigned LONG_LONG *pval);

return -1 and set exception on error, return 0 otherwise and
store the result in pval. This saves the PyErr_Occurred() in
case the value is -1.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-18 21:18

Message:
Logged In: YES 
user_id=6380

A few days is fine (this doesn't need to make it into 2.3a2).

But the proposal here is not backwards compatible, is it?
Those codes already mean something different now.

I think we'll need to invent new format codes, or a new
modifier.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-02-18 21:16

Message:
Logged In: YES 
user_id=11105

But it would probably take a few days.

What about these changes to the format codes, they are now
more in sync with the struct module (I hope the formatting
is kept):

Code    C type          	Range check

b	unsigned char		0..UCHAR_MAX
B	unsigned char		none **
h	unsigned short		0..USHRT_MAX
H	unsigned short		none **
i	int			INT_MIN..INT_MAX
I *	unsigned int		0..UINT_MAX
l	long			LONG_MIN..LONG_MAX
L *	unsigned long		none
q	long long		LLONG_MIN..LLONG_MAX
Q *	unsigned long long	none


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-18 20:50

Message:
Logged In: YES 
user_id=6380

Thomas: that would be great! (As long it isn't killed by bw
compat. :-)


----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-02-18 20:18

Message:
Logged In: YES 
user_id=11105

If nobody else comes up, I can do this. I also had similar
checks for the struct module, but Tim killed it because of
backward compatibility.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595026&group_id=5470


From noreply@sourceforge.net  Thu Apr 17 20:03:24 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 17 Apr 2003 12:03:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-595026 ] Support for masks in getargs.c
Message-ID: <E196EfM-0005Qw-00@sc8-sf-web4.sourceforge.net>

Bugs item #595026, was opened at 2002-08-14 08:26
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595026&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Closed
Resolution: Accepted
Priority: 7
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Thomas Heller (theller)
Summary: Support for masks in getargs.c

Initial Comment:
We need this implemented:

> How about the following counterproposal.  This also
changes some of
> the other format codes to be a little more regular.
>
> Code    C type          	Range check
>
> b	unsigned char		0..UCHAR_MAX
> B	unsigned char		none **
> h	unsigned short		0..USHRT_MAX
> H	unsigned short		none **
> i	int
		INT_MIN..INT_MAX
> I *	unsigned int		0..UINT_MAX
> l	long
		LONG_MIN..LONG_MAX
> k *	unsigned long		none
> L	long long		LLONG_MIN..LLONG_MAX
> K *	unsigned long long	none
>
> Notes:
>
> * New format codes.
>
> ** Changed from previous "range-and-a-half" to
"none"; the
>    range-and-a-half checking wasn't particularly useful.

Plus a C API or two, e.g. PyInt_AsLongMask() ->
unsigned long and PyInt_AsLongLongMask() -> unsigned
long long (if that exists).

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-17 15:03

Message:
Logged In: YES 
user_id=6380

Thanks!

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-04-17 14:56

Message:
Logged In: YES 
user_id=11105

Checked in with the changes you requested.
I left the 'h' opcode unchanged, if needed this can be fixed
later.

Will do the docs on tuesday, NEWS today, if time permits.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-17 14:06

Message:
Logged In: YES 
user_id=6380

Good enough; check it in, with docs and NEWS.

But please fix these:

- the 'h' opcode comments and error messages still refer to
it as "signed short" while it is now clearly an *unsigned*
short. (Hm... maybe 'h' should remain a signed short after
all, for backwards compatibility?)

- there's still an unused definition of AddSym in testcapi.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-04-17 13:21

Message:
Logged In: YES 
user_id=11105

getargs-2.patch, hopefully complete, but test_getargs2.py
not included.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-04-17 13:09

Message:
Logged In: YES 
user_id=11105

But wait: I'll fix the missing decrefs, and create a new,
complete patch. Takes a couple of minutes, though.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-04-17 13:02

Message:
Logged In: YES 
user_id=11105

Oops, sorry: getargs.c.diff

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-17 12:36

Message:
Logged In: YES 
user_id=6380

Review comments:

- Where's the patch to getargs.c???

- There's a missing DECREF(io) in
PyInt_AsUnsignedLong[Long]Mask() in the block with the
"nb_int should return int object" error return. (This is
also missing from the template you used, PyInt_AsLong()!)

- I get a failure in _testcapi:

[guido@odiug linux]$ ./python ../Lib/test/test_capi.py
internal test_L_code
internal test_config
internal test_dict_iteration
internal test_k_code
Traceback (most recent call last):
  File "../Lib/test/test_capi.py", line 16, in ?
    raise test_support.TestFailed, sys.exc_info()[1]
test.test_support.TestFailed: test_k_code: k code returned
wrong value for long -0xFFF..000042
[guido@odiug linux]$ 


----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-04-17 11:49

Message:
Logged In: YES 
user_id=11105

I forgot to say: kpatch.diff is obsolete, please ignore.
Hm, I'll better delete it.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-04-17 11:47

Message:
Logged In: YES 
user_id=11105

Patch is ready for review (although NEWS and docs are
missing, I will add them later if the patch is accepted).

getargs.patch contains a context diff for several files,
including Modules/_testcapimodule.c.
test_getargs2.py should go into Lib/test, and tests the changes.
It also documents the new behaviour.

In the complete test-suite, test_array is crashing now as a
consequence.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-02-21 13:36

Message:
Logged In: YES 
user_id=11105

Uploading patch whcih implements the 'k' format code.  Any
comments? Is this what is needed?
I know, docs are missing, and 'K' is missing.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-21 07:58

Message:
Logged In: YES 
user_id=6380

I suggest writing on python-dev or python-list.


----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-02-20 15:45

Message:
Logged In: YES 
user_id=11105

I've implemented the 'k' getargs code, and
PyInt_AsUnsignedLongMask and PyLong_AsUnsignedLongMask
functions.  Is there any facility which would help me to
test this new code?

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-02-18 17:08

Message:
Logged In: YES 
user_id=45365

Guido,
I would be happy with the no-rangecheck unsigned long formatcode. One request, though: if this is implemented can it be done ASAP after 2.3a2, so there's still some time to shake out the bugs before 2.3b1 comes out? Especially the hand-written code will have to be examined to see where l needs to be turned into k.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-02-18 15:59

Message:
Logged In: YES 
user_id=11105

Currently the h code means signed short
(SHRT_MIN..SHRT_MAX), do you really want to change that to
unsigned short (0..USHRT_MAX)?

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-02-18 15:33

Message:
Logged In: YES 
user_id=11105

Ok, I'll use your codes.

Here is my suggestion for the C api functions:

int PyInt_AsLongMask(PyObject *v, unsigned long *pval);
int PyInt_AsLongLongMask(PyObject *v, unsigned LONG_LONG *pval);

return -1 and set exception on error, return 0 otherwise and
store the result in pval. This saves the PyErr_Occurred() in
case the value is -1.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-18 15:18

Message:
Logged In: YES 
user_id=6380

A few days is fine (this doesn't need to make it into 2.3a2).

But the proposal here is not backwards compatible, is it?
Those codes already mean something different now.

I think we'll need to invent new format codes, or a new
modifier.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-02-18 15:16

Message:
Logged In: YES 
user_id=11105

But it would probably take a few days.

What about these changes to the format codes, they are now
more in sync with the struct module (I hope the formatting
is kept):

Code    C type          	Range check

b	unsigned char		0..UCHAR_MAX
B	unsigned char		none **
h	unsigned short		0..USHRT_MAX
H	unsigned short		none **
i	int			INT_MIN..INT_MAX
I *	unsigned int		0..UINT_MAX
l	long			LONG_MIN..LONG_MAX
L *	unsigned long		none
q	long long		LLONG_MIN..LLONG_MAX
Q *	unsigned long long	none


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-18 14:50

Message:
Logged In: YES 
user_id=6380

Thomas: that would be great! (As long it isn't killed by bw
compat. :-)


----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-02-18 14:18

Message:
Logged In: YES 
user_id=11105

If nobody else comes up, I can do this. I also had similar
checks for the struct module, but Tim killed it because of
backward compatibility.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595026&group_id=5470


From noreply@sourceforge.net  Thu Apr 17 20:12:11 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 17 Apr 2003 12:12:11 -0700
Subject: [Python-bugs-list] [ python-Bugs-721157 ] Building lib.pdf fails on MacOSX
Message-ID: <E196Enr-00046o-00@sc8-sf-web1.sourceforge.net>

Bugs item #721157, was opened at 2003-04-14 17:09
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=721157&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Building lib.pdf fails on MacOSX

Initial Comment:
I can't build lib.pdf on MacOSX anymore. I tried both a4 and letter.
The pdflatex call fails with

Error: pdflatex: buffer overflow [125000 bytes]

The whole lib.how is attached (if I don't forget to check the 
checkmark:-).

pdflatex -version prints

pdfTeX (Web2C 7.3.3.1) 3.14159-0.14h-released-20010417

which seems to be newer than what the README lists as the minimal 
requirement.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2003-04-17 21:12

Message:
Logged In: YES 
user_id=45365

My texmf.cnf looks completely different. There doesn't seem to be a .pdflatex section, only the one TEXINPUTS line mentions pdflatex.

I've attached the file (name set to fink-texmf.cnf), maybe you understand it.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-04-17 18:36

Message:
Logged In: YES 
user_id=3066

TeX systems tend to be a little weird about how memory is
allocated.
Most current distributions use a semi-static allocation
mechanism: Some large buffers are allocated once, and
everything happens within those.  The sizes are usually
configurable using a config file.

On my RedHat Linux box, which uses the "teTeX" TeX system,
there's a config file:

    /usr/share/texmf/web2c/texmf.cnf

This contains the following settings for pdfLaTeX:

TEXINPUTS.pdflatex = .;$TEXMF/{pdftex,tex}/{latex,generic,}//
main_memory.pdflatex = 1500000
hash_extra.pdflatex = 25000
pool_size.pdflatex = 750000
string_vacancies.pdflatex = 45000
max_strings.pdflatex = 55000
pool_free.pdflatex = 47500
nest_size.pdflatex = 500
param_size.pdflatex = 3000
save_size.pdflatex = 5000
stack_size.pdflatex = 3000

If you can locate the corresponding config file for your
system, please check the sizes configured and let me know
what differs. I may need to add some documentation about
this, mentioning that the Library Reference may take more
resources than are typically allocated.

Thanks!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=721157&group_id=5470


From noreply@sourceforge.net  Thu Apr 17 20:25:57 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 17 Apr 2003 12:25:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-721157 ] Building lib.pdf fails on MacOSX
Message-ID: <E196F1B-0003q9-00@sc8-sf-web3.sourceforge.net>

Bugs item #721157, was opened at 2003-04-14 11:09
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=721157&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Building lib.pdf fails on MacOSX

Initial Comment:
I can't build lib.pdf on MacOSX anymore. I tried both a4 and letter.
The pdflatex call fails with

Error: pdflatex: buffer overflow [125000 bytes]

The whole lib.how is attached (if I don't forget to check the 
checkmark:-).

pdflatex -version prints

pdfTeX (Web2C 7.3.3.1) 3.14159-0.14h-released-20010417

which seems to be newer than what the README lists as the minimal 
requirement.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-04-17 15:25

Message:
Logged In: YES 
user_id=3066

Where a setting isn't specified but there is a "base"
variable (for example, main_memory is set, but not
main_memory.pdflatex), you can add the .pdflatex version if
the number is higher in the settings I included.  The
".pdflatex" suffix means that that setting applies to
pdflatex only; if such a suffixed version isn't set, the
bare "base" variable is used.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-04-17 15:12

Message:
Logged In: YES 
user_id=45365

My texmf.cnf looks completely different. There doesn't seem to be a .pdflatex section, only the one TEXINPUTS line mentions pdflatex.

I've attached the file (name set to fink-texmf.cnf), maybe you understand it.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-04-17 12:36

Message:
Logged In: YES 
user_id=3066

TeX systems tend to be a little weird about how memory is
allocated.
Most current distributions use a semi-static allocation
mechanism: Some large buffers are allocated once, and
everything happens within those.  The sizes are usually
configurable using a config file.

On my RedHat Linux box, which uses the "teTeX" TeX system,
there's a config file:

    /usr/share/texmf/web2c/texmf.cnf

This contains the following settings for pdfLaTeX:

TEXINPUTS.pdflatex = .;$TEXMF/{pdftex,tex}/{latex,generic,}//
main_memory.pdflatex = 1500000
hash_extra.pdflatex = 25000
pool_size.pdflatex = 750000
string_vacancies.pdflatex = 45000
max_strings.pdflatex = 55000
pool_free.pdflatex = 47500
nest_size.pdflatex = 500
param_size.pdflatex = 3000
save_size.pdflatex = 5000
stack_size.pdflatex = 3000

If you can locate the corresponding config file for your
system, please check the sizes configured and let me know
what differs. I may need to add some documentation about
this, mentioning that the Library Reference may take more
resources than are typically allocated.

Thanks!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=721157&group_id=5470


From noreply@sourceforge.net  Thu Apr 17 20:27:02 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 17 Apr 2003 12:27:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-621548 ] Numerous defunct threads left behind
Message-ID: <E196F2E-0004ua-00@sc8-sf-web1.sourceforge.net>

Bugs item #621548, was opened at 2002-10-10 15:25
Message generated for change (Comment added) made by jgoerzen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621548&group_id=5470

Category: Threads
Group: Python 2.3
Status: Open
Resolution: None
Priority: 3
Submitted By: Jamin W. Collins (jamincollins)
Assigned to: Nobody/Anonymous (nobody)
Summary: Numerous defunct threads left behind

Initial Comment:
I originally noticed this problem with Debian's
OfflineIMAP package and filed a report there:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=162369

The short of it is that when running offlineimap for an
extended period of time it will eventually leave a
large number of defunct threads behind that eventually
use up all available system processes.  Killing the
original offlineimap thread clears the problem for a while.

The Debian maintainer of OfflineIMAP referred this over
to the python maintainer, who in turn has asked (as you
can see from the link above) that I file a report here.

If there is any more information I can provide (beyond
that in the Debian case already) please let me know.

----------------------------------------------------------------------

Comment By: John Goerzen (jgoerzen)
Date: 2003-04-17 14:27

Message:
Logged In: YES 
user_id=491567

OfflineIMAP has only two cases where one of these things 
might happen: 
 
1) in the Curses interface module, where it does a fork at the 
very beginning to check to see if Curses will work (just a quick 
fork/exit/cleanup) 
 
2) with the preauth code, where it does a popen2 to a local 
imap daemon. 
 
Few people use preauth, and the Curses problem can easily 
be dismissed by switching to another ui (TTY.TTYUI perhaps?) 
 
I have observed that even the TTY.TTYUI leaves processes 
hanging around in Python 2.2 but not in Python 2.3. 
 
I suspect the original submitter is running the Tk interface; my 
own experimentation has shown it leaves lots of processes 
hanging around. 
 
However -- I have never seen zombie processes hanging 
around. 
 
The processes I see have blocked themselves with 
rt_sigsuspend. 

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-10-14 19:35

Message:
Logged In: YES 
user_id=6380

I agree with Martin von Loewis - this does not appear to be
a Python bug.

When a Python thread exits, it does not show up in the ps
listing as <defunct>; that to me suggests that there *is*
some forking going on, perhaps under the guise of system()
or popen(); or perhaps there's a bug in the C library's
thread support.

Lowering the priority as a result. I'll try to followup in
the Debian thread as well, if there's a web interface.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-10-13 06:05

Message:
Logged In: YES 
user_id=21627

The analysis that this is a Python bug is most likely wrong.
You write

> a number of defunct/zombie processes are spawned.

then John Goerzen writes

> It is likely, in any case, that this is a bug in Python
itself.   The 
> OfflineIMAP program does not fork 

However, John later points out that there are many threads
used in this package. Please understand that threads show up
as processes in Linux ps(1).

IOW, what you are seeing are the many threads, not any
additional processes.

It appears that the system is waiting for somebody to call
pthread_join. This should not be necessary, since Python
invokes pthread_detach for all of its threads. So if the
system does not reclaim terminated threads, it seems there
is a bug in your C library.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621548&group_id=5470


From noreply@sourceforge.net  Thu Apr 17 23:23:49 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 17 Apr 2003 15:23:49 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-719429 ] Build under Red Hat 9 requires additional include
Message-ID: <E196HnJ-0008I1-00@sc8-sf-web2.sourceforge.net>

Feature Requests item #719429, was opened at 2003-04-10 23:04
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=719429&group_id=5470

Category: Build
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Matthew Cowles (mdcowles)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: Build under Red Hat 9 requires additional include

Initial Comment:
In order for the socket module to build under Red Hat
9, -I/usr/kerberos/include needs to be added to the
command.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-17 18:23

Message:
Logged In: YES 
user_id=33168

Checked in as:
  setup.py 1.160

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-11 15:03

Message:
Logged In: YES 
user_id=33168

Attached is a patch to fix this problem.  I will check it in
for 2.3.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=719429&group_id=5470


From noreply@sourceforge.net  Thu Apr 17 23:38:53 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 17 Apr 2003 15:38:53 -0700
Subject: [Python-bugs-list] [ python-Bugs-659188 ] no docs for HTMLParser.handle_pi
Message-ID: <E196I1t-0006Mf-00@sc8-sf-web1.sourceforge.net>

Bugs item #659188, was opened at 2002-12-27 18:13
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=659188&group_id=5470

Category: Documentation
Group: Python 2.2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Arild Fines (arildfines)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: no docs for HTMLParser.handle_pi

Initial Comment:
The current documentation(2.2.2) has no documentation 
for the handle_pi(handle processing instruction) method 
in the HTMLParser.HTMLParser class. 

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-04-17 18:38

Message:
Logged In: YES 
user_id=3066

Fixed in Doc/lib/libhtmlparser.tex revisions 1.3 and 1.2.18.1.

----------------------------------------------------------------------

Comment By: Christopher Blunck (blunck2)
Date: 2003-01-04 23:11

Message:
Logged In: YES 
user_id=531881

see patch 662464

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=659188&group_id=5470


From noreply@sourceforge.net  Thu Apr 17 23:41:04 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 17 Apr 2003 15:41:04 -0700
Subject: [Python-bugs-list] [ python-Bugs-621548 ] Numerous defunct threads left behind
Message-ID: <E196I40-0006TQ-00@sc8-sf-web1.sourceforge.net>

Bugs item #621548, was opened at 2002-10-10 15:25
Message generated for change (Comment added) made by jamincollins
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621548&group_id=5470

Category: Threads
Group: Python 2.3
Status: Open
Resolution: None
Priority: 3
Submitted By: Jamin W. Collins (jamincollins)
Assigned to: Nobody/Anonymous (nobody)
Summary: Numerous defunct threads left behind

Initial Comment:
I originally noticed this problem with Debian's
OfflineIMAP package and filed a report there:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=162369

The short of it is that when running offlineimap for an
extended period of time it will eventually leave a
large number of defunct threads behind that eventually
use up all available system processes.  Killing the
original offlineimap thread clears the problem for a while.

The Debian maintainer of OfflineIMAP referred this over
to the python maintainer, who in turn has asked (as you
can see from the link above) that I file a report here.

If there is any more information I can provide (beyond
that in the Debian case already) please let me know.

----------------------------------------------------------------------

>Comment By: Jamin W. Collins (jamincollins)
Date: 2003-04-17 17:41

Message:
Logged In: YES 
user_id=88136

I used both the TK and the TTY interfaces.  In both cases
(using both Python 2.2 and 2.3) zombie threads would
accumlate over time when it was left running in daemon mode.

----------------------------------------------------------------------

Comment By: John Goerzen (jgoerzen)
Date: 2003-04-17 14:27

Message:
Logged In: YES 
user_id=491567

OfflineIMAP has only two cases where one of these things 
might happen: 
 
1) in the Curses interface module, where it does a fork at the 
very beginning to check to see if Curses will work (just a quick 
fork/exit/cleanup) 
 
2) with the preauth code, where it does a popen2 to a local 
imap daemon. 
 
Few people use preauth, and the Curses problem can easily 
be dismissed by switching to another ui (TTY.TTYUI perhaps?) 
 
I have observed that even the TTY.TTYUI leaves processes 
hanging around in Python 2.2 but not in Python 2.3. 
 
I suspect the original submitter is running the Tk interface; my 
own experimentation has shown it leaves lots of processes 
hanging around. 
 
However -- I have never seen zombie processes hanging 
around. 
 
The processes I see have blocked themselves with 
rt_sigsuspend. 

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-10-14 19:35

Message:
Logged In: YES 
user_id=6380

I agree with Martin von Loewis - this does not appear to be
a Python bug.

When a Python thread exits, it does not show up in the ps
listing as <defunct>; that to me suggests that there *is*
some forking going on, perhaps under the guise of system()
or popen(); or perhaps there's a bug in the C library's
thread support.

Lowering the priority as a result. I'll try to followup in
the Debian thread as well, if there's a web interface.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-10-13 06:05

Message:
Logged In: YES 
user_id=21627

The analysis that this is a Python bug is most likely wrong.
You write

> a number of defunct/zombie processes are spawned.

then John Goerzen writes

> It is likely, in any case, that this is a bug in Python
itself.   The 
> OfflineIMAP program does not fork 

However, John later points out that there are many threads
used in this package. Please understand that threads show up
as processes in Linux ps(1).

IOW, what you are seeing are the many threads, not any
additional processes.

It appears that the system is waiting for somebody to call
pthread_join. This should not be necessary, since Python
invokes pthread_detach for all of its threads. So if the
system does not reclaim terminated threads, it seems there
is a bug in your C library.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621548&group_id=5470


From noreply@sourceforge.net  Fri Apr 18 01:27:51 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 17 Apr 2003 17:27:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-621548 ] Numerous defunct threads left behind
Message-ID: <E196JjL-0000cN-00@sc8-sf-web3.sourceforge.net>

Bugs item #621548, was opened at 2002-10-10 16:25
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621548&group_id=5470

Category: Threads
Group: Python 2.3
Status: Open
Resolution: None
Priority: 3
Submitted By: Jamin W. Collins (jamincollins)
Assigned to: Nobody/Anonymous (nobody)
Summary: Numerous defunct threads left behind

Initial Comment:
I originally noticed this problem with Debian's
OfflineIMAP package and filed a report there:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=162369

The short of it is that when running offlineimap for an
extended period of time it will eventually leave a
large number of defunct threads behind that eventually
use up all available system processes.  Killing the
original offlineimap thread clears the problem for a while.

The Debian maintainer of OfflineIMAP referred this over
to the python maintainer, who in turn has asked (as you
can see from the link above) that I file a report here.

If there is any more information I can provide (beyond
that in the Debian case already) please let me know.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-17 20:27

Message:
Logged In: YES 
user_id=6380

I don't understand aything that is being said in the last
two comments. If anything, the bug appears to be in the
application (with which I am not familiar).

I'm going to close soon this unless someone has a bug they
can demonstrate with a small sample program that does not
involve OfflineIMAP.


----------------------------------------------------------------------

Comment By: Jamin W. Collins (jamincollins)
Date: 2003-04-17 18:41

Message:
Logged In: YES 
user_id=88136

I used both the TK and the TTY interfaces.  In both cases
(using both Python 2.2 and 2.3) zombie threads would
accumlate over time when it was left running in daemon mode.

----------------------------------------------------------------------

Comment By: John Goerzen (jgoerzen)
Date: 2003-04-17 15:27

Message:
Logged In: YES 
user_id=491567

OfflineIMAP has only two cases where one of these things 
might happen: 
 
1) in the Curses interface module, where it does a fork at the 
very beginning to check to see if Curses will work (just a quick 
fork/exit/cleanup) 
 
2) with the preauth code, where it does a popen2 to a local 
imap daemon. 
 
Few people use preauth, and the Curses problem can easily 
be dismissed by switching to another ui (TTY.TTYUI perhaps?) 
 
I have observed that even the TTY.TTYUI leaves processes 
hanging around in Python 2.2 but not in Python 2.3. 
 
I suspect the original submitter is running the Tk interface; my 
own experimentation has shown it leaves lots of processes 
hanging around. 
 
However -- I have never seen zombie processes hanging 
around. 
 
The processes I see have blocked themselves with 
rt_sigsuspend. 

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-10-14 20:35

Message:
Logged In: YES 
user_id=6380

I agree with Martin von Loewis - this does not appear to be
a Python bug.

When a Python thread exits, it does not show up in the ps
listing as <defunct>; that to me suggests that there *is*
some forking going on, perhaps under the guise of system()
or popen(); or perhaps there's a bug in the C library's
thread support.

Lowering the priority as a result. I'll try to followup in
the Debian thread as well, if there's a web interface.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-10-13 07:05

Message:
Logged In: YES 
user_id=21627

The analysis that this is a Python bug is most likely wrong.
You write

> a number of defunct/zombie processes are spawned.

then John Goerzen writes

> It is likely, in any case, that this is a bug in Python
itself.   The 
> OfflineIMAP program does not fork 

However, John later points out that there are many threads
used in this package. Please understand that threads show up
as processes in Linux ps(1).

IOW, what you are seeing are the many threads, not any
additional processes.

It appears that the system is waiting for somebody to call
pthread_join. This should not be necessary, since Python
invokes pthread_detach for all of its threads. So if the
system does not reclaim terminated threads, it seems there
is a bug in your C library.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621548&group_id=5470


From noreply@sourceforge.net  Fri Apr 18 01:55:53 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 17 Apr 2003 17:55:53 -0700
Subject: [Python-bugs-list] [ python-Bugs-621548 ] Numerous defunct threads left behind
Message-ID: <E196KAT-0005Sx-00@sc8-sf-web2.sourceforge.net>

Bugs item #621548, was opened at 2002-10-10 15:25
Message generated for change (Comment added) made by jamincollins
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621548&group_id=5470

Category: Threads
Group: Python 2.3
Status: Open
Resolution: None
Priority: 3
Submitted By: Jamin W. Collins (jamincollins)
Assigned to: Nobody/Anonymous (nobody)
Summary: Numerous defunct threads left behind

Initial Comment:
I originally noticed this problem with Debian's
OfflineIMAP package and filed a report there:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=162369

The short of it is that when running offlineimap for an
extended period of time it will eventually leave a
large number of defunct threads behind that eventually
use up all available system processes.  Killing the
original offlineimap thread clears the problem for a while.

The Debian maintainer of OfflineIMAP referred this over
to the python maintainer, who in turn has asked (as you
can see from the link above) that I file a report here.

If there is any more information I can provide (beyond
that in the Debian case already) please let me know.

----------------------------------------------------------------------

>Comment By: Jamin W. Collins (jamincollins)
Date: 2003-04-17 19:55

Message:
Logged In: YES 
user_id=88136

Go ahead and close it.  Problem still exists.  I don't know
enough about either to say which is at fault.  Nor do I know
enough about python to attempt to replicate it.  I only know
the the OfflineIMAP folks say it's not them and it would
seem now it's not Python either.

*shrug* I tried.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-17 19:27

Message:
Logged In: YES 
user_id=6380

I don't understand aything that is being said in the last
two comments. If anything, the bug appears to be in the
application (with which I am not familiar).

I'm going to close soon this unless someone has a bug they
can demonstrate with a small sample program that does not
involve OfflineIMAP.


----------------------------------------------------------------------

Comment By: Jamin W. Collins (jamincollins)
Date: 2003-04-17 17:41

Message:
Logged In: YES 
user_id=88136

I used both the TK and the TTY interfaces.  In both cases
(using both Python 2.2 and 2.3) zombie threads would
accumlate over time when it was left running in daemon mode.

----------------------------------------------------------------------

Comment By: John Goerzen (jgoerzen)
Date: 2003-04-17 14:27

Message:
Logged In: YES 
user_id=491567

OfflineIMAP has only two cases where one of these things 
might happen: 
 
1) in the Curses interface module, where it does a fork at the 
very beginning to check to see if Curses will work (just a quick 
fork/exit/cleanup) 
 
2) with the preauth code, where it does a popen2 to a local 
imap daemon. 
 
Few people use preauth, and the Curses problem can easily 
be dismissed by switching to another ui (TTY.TTYUI perhaps?) 
 
I have observed that even the TTY.TTYUI leaves processes 
hanging around in Python 2.2 but not in Python 2.3. 
 
I suspect the original submitter is running the Tk interface; my 
own experimentation has shown it leaves lots of processes 
hanging around. 
 
However -- I have never seen zombie processes hanging 
around. 
 
The processes I see have blocked themselves with 
rt_sigsuspend. 

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-10-14 19:35

Message:
Logged In: YES 
user_id=6380

I agree with Martin von Loewis - this does not appear to be
a Python bug.

When a Python thread exits, it does not show up in the ps
listing as <defunct>; that to me suggests that there *is*
some forking going on, perhaps under the guise of system()
or popen(); or perhaps there's a bug in the C library's
thread support.

Lowering the priority as a result. I'll try to followup in
the Debian thread as well, if there's a web interface.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-10-13 06:05

Message:
Logged In: YES 
user_id=21627

The analysis that this is a Python bug is most likely wrong.
You write

> a number of defunct/zombie processes are spawned.

then John Goerzen writes

> It is likely, in any case, that this is a bug in Python
itself.   The 
> OfflineIMAP program does not fork 

However, John later points out that there are many threads
used in this package. Please understand that threads show up
as processes in Linux ps(1).

IOW, what you are seeing are the many threads, not any
additional processes.

It appears that the system is waiting for somebody to call
pthread_join. This should not be necessary, since Python
invokes pthread_detach for all of its threads. So if the
system does not reclaim terminated threads, it seems there
is a bug in your C library.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621548&group_id=5470


From noreply@sourceforge.net  Fri Apr 18 02:04:48 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 17 Apr 2003 18:04:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-621548 ] Numerous defunct threads left behind
Message-ID: <E196KJ6-0005lD-00@sc8-sf-web2.sourceforge.net>

Bugs item #621548, was opened at 2002-10-10 16:25
Message generated for change (Settings changed) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621548&group_id=5470

Category: Threads
Group: Python 2.3
>Status: Closed
Resolution: None
Priority: 3
Submitted By: Jamin W. Collins (jamincollins)
Assigned to: Nobody/Anonymous (nobody)
Summary: Numerous defunct threads left behind

Initial Comment:
I originally noticed this problem with Debian's
OfflineIMAP package and filed a report there:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=162369

The short of it is that when running offlineimap for an
extended period of time it will eventually leave a
large number of defunct threads behind that eventually
use up all available system processes.  Killing the
original offlineimap thread clears the problem for a while.

The Debian maintainer of OfflineIMAP referred this over
to the python maintainer, who in turn has asked (as you
can see from the link above) that I file a report here.

If there is any more information I can provide (beyond
that in the Debian case already) please let me know.

----------------------------------------------------------------------

Comment By: Jamin W. Collins (jamincollins)
Date: 2003-04-17 20:55

Message:
Logged In: YES 
user_id=88136

Go ahead and close it.  Problem still exists.  I don't know
enough about either to say which is at fault.  Nor do I know
enough about python to attempt to replicate it.  I only know
the the OfflineIMAP folks say it's not them and it would
seem now it's not Python either.

*shrug* I tried.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-17 20:27

Message:
Logged In: YES 
user_id=6380

I don't understand aything that is being said in the last
two comments. If anything, the bug appears to be in the
application (with which I am not familiar).

I'm going to close soon this unless someone has a bug they
can demonstrate with a small sample program that does not
involve OfflineIMAP.


----------------------------------------------------------------------

Comment By: Jamin W. Collins (jamincollins)
Date: 2003-04-17 18:41

Message:
Logged In: YES 
user_id=88136

I used both the TK and the TTY interfaces.  In both cases
(using both Python 2.2 and 2.3) zombie threads would
accumlate over time when it was left running in daemon mode.

----------------------------------------------------------------------

Comment By: John Goerzen (jgoerzen)
Date: 2003-04-17 15:27

Message:
Logged In: YES 
user_id=491567

OfflineIMAP has only two cases where one of these things 
might happen: 
 
1) in the Curses interface module, where it does a fork at the 
very beginning to check to see if Curses will work (just a quick 
fork/exit/cleanup) 
 
2) with the preauth code, where it does a popen2 to a local 
imap daemon. 
 
Few people use preauth, and the Curses problem can easily 
be dismissed by switching to another ui (TTY.TTYUI perhaps?) 
 
I have observed that even the TTY.TTYUI leaves processes 
hanging around in Python 2.2 but not in Python 2.3. 
 
I suspect the original submitter is running the Tk interface; my 
own experimentation has shown it leaves lots of processes 
hanging around. 
 
However -- I have never seen zombie processes hanging 
around. 
 
The processes I see have blocked themselves with 
rt_sigsuspend. 

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-10-14 20:35

Message:
Logged In: YES 
user_id=6380

I agree with Martin von Loewis - this does not appear to be
a Python bug.

When a Python thread exits, it does not show up in the ps
listing as <defunct>; that to me suggests that there *is*
some forking going on, perhaps under the guise of system()
or popen(); or perhaps there's a bug in the C library's
thread support.

Lowering the priority as a result. I'll try to followup in
the Debian thread as well, if there's a web interface.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-10-13 07:05

Message:
Logged In: YES 
user_id=21627

The analysis that this is a Python bug is most likely wrong.
You write

> a number of defunct/zombie processes are spawned.

then John Goerzen writes

> It is likely, in any case, that this is a bug in Python
itself.   The 
> OfflineIMAP program does not fork 

However, John later points out that there are many threads
used in this package. Please understand that threads show up
as processes in Linux ps(1).

IOW, what you are seeing are the many threads, not any
additional processes.

It appears that the system is waiting for somebody to call
pthread_join. This should not be necessary, since Python
invokes pthread_detach for all of its threads. So if the
system does not reclaim terminated threads, it seems there
is a bug in your C library.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621548&group_id=5470


From noreply@sourceforge.net  Fri Apr 18 05:41:57 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 17 Apr 2003 21:41:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-723495 ] runtime_library_dirs broken under OS X
Message-ID: <E196NhF-0008OW-00@sc8-sf-web3.sourceforge.net>

Bugs item #723495, was opened at 2003-04-18 14:41
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723495&group_id=5470

Category: Distutils
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Stuart Bishop (zenzen)
Assigned to: Nobody/Anonymous (nobody)
Summary: runtime_library_dirs broken under OS X

Initial Comment:
gcc and ld on OSX don't seem to support the -R option, breaking 
runtime_library_dirs and any distutils installed extensions that require 
it.

I've only checked Python 2.2.2 so far.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723495&group_id=5470


From noreply@sourceforge.net  Fri Apr 18 08:35:29 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 18 Apr 2003 00:35:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-723540 ] __slots__ broken in 2.3a with ("__dict__", )
Message-ID: <E196QPB-0007So-00@sc8-sf-web1.sourceforge.net>

Bugs item #723540, was opened at 2003-04-18 02:35
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723540&group_id=5470

Category: Type/class unification
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Douglas Napoleone (derivin)
Assigned to: Nobody/Anonymous (nobody)
Summary: __slots__ broken in 2.3a with ("__dict__", )

Initial Comment:
I LOVE using __slots__. I love using properties.
I made my own extension and metaclass so I could 
define type safe properties in classes. I could stick 
properties on a class and have them accessed 
seperatly from slots (because they are properties and 
not attributes). The properties call setter/getters and 
store the data in __dict__ (a cheezy means of making 
pickle still work with no effort). thus I had __slots__ = 
('__dict__', ) in my base class. this worked great in 2.2 
and 2.2.2.  Im migrating all my modules to 2.3. I just 
fixed a bug in my code that was due to a typo. Thats 
when I realized that __slots__ was no longer working in 
2.3a. I cant find anything on this change in behavior.

if slots contains "__dict__" slots is turned OFF!!!
simplified version of the bug:

$ python
Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more 
information.
>>> class foo(object):
...   __slots__ = ("__dict__", )
...
>>> a = foo()
>>> a.bad = 3
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
AttributeError: 'foo' object has no attribute 'bad'
>>> ^Z

$ python23
Python 2.3a2 (#39, Feb 19 2003, 17:58:58) [MSC 
v.1200 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more 
information.
>>> class foo(object):
...   __slots__ = ("__dict__", )
...
>>> a = foo()
>>> a.bad = 3
>>> dir(a)
['__class__', '__delattr__', '__dict__', '__doc__', '__getattr
ibute__', '__hash_
_', '__init__', '__module__', '__new__', '__reduce__', '__re
duce_ex__', '__repr_
_', '__setattr__', '__slots__', '__str__', 'bad']
>>> ^Z



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723540&group_id=5470


From noreply@sourceforge.net  Fri Apr 18 09:40:52 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 18 Apr 2003 01:40:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-723562 ] app-building with Bundlebuilder for framework builds
Message-ID: <E196RQS-00033P-00@sc8-sf-web4.sourceforge.net>

Bugs item #723562, was opened at 2003-04-18 10:40
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723562&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 4
Submitted By: Jack Jansen (jackjansen)
Assigned to: Just van Rossum (jvr)
Summary: app-building with Bundlebuilder for framework builds

Initial Comment:
Just,
why can bundlebuilder build applications for non-framework Pythons but not framework Pythons?

If the problem is that relocating the framework is difficult: I just came across the tool "install_name_tool" (available if you have the developer tools installed) and the accompanying linker flag "-header-pad_max_install_names", these two should allow us to relocate frameworks.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723562&group_id=5470


From noreply@sourceforge.net  Fri Apr 18 09:58:13 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 18 Apr 2003 01:58:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-723495 ] runtime_library_dirs broken under OS X
Message-ID: <E196RhF-0002Pv-00@sc8-sf-web1.sourceforge.net>

Bugs item #723495, was opened at 2003-04-18 06:41
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723495&group_id=5470

Category: Distutils
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Stuart Bishop (zenzen)
Assigned to: Nobody/Anonymous (nobody)
Summary: runtime_library_dirs broken under OS X

Initial Comment:
gcc and ld on OSX don't seem to support the -R option, breaking 
runtime_library_dirs and any distutils installed extensions that require 
it.

I've only checked Python 2.2.2 so far.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2003-04-18 10:58

Message:
Logged In: YES 
user_id=45365

Could you elaborate a bit on what breaks, and/or give an example that breaks?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723495&group_id=5470


From noreply@sourceforge.net  Fri Apr 18 12:08:56 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 18 Apr 2003 04:08:56 -0700
Subject: [Python-bugs-list] [ python-Bugs-723495 ] runtime_library_dirs broken under OS X
Message-ID: <E196Tjk-0008Oc-00@sc8-sf-web1.sourceforge.net>

Bugs item #723495, was opened at 2003-04-18 14:41
Message generated for change (Comment added) made by zenzen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723495&group_id=5470

Category: Distutils
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Stuart Bishop (zenzen)
Assigned to: Nobody/Anonymous (nobody)
Summary: runtime_library_dirs broken under OS X

Initial Comment:
gcc and ld on OSX don't seem to support the -R option, breaking 
runtime_library_dirs and any distutils installed extensions that require 
it.

I've only checked Python 2.2.2 so far.

----------------------------------------------------------------------

>Comment By: Stuart Bishop (zenzen)
Date: 2003-04-18 21:08

Message:
Logged In: YES 
user_id=46639

Looks like this has been fixed in 2.3a2:
       if sys.platform[:6] == "darwin":
            # MacOSX's linker doesn't understand the -R flag at all
            return "-L" + dir
        elif compiler[:3] == "gcc" or compiler[:3] == "g++":
            return "-Wl,-R" + dir
        else:
            return "-R" + dir

I can't find a bug report or patch on this fix, and I don't know if it is in any 
2.2.x branch.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-04-18 18:58

Message:
Logged In: YES 
user_id=45365

Could you elaborate a bit on what breaks, and/or give an example that breaks?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723495&group_id=5470


From noreply@sourceforge.net  Fri Apr 18 12:35:39 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 18 Apr 2003 04:35:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-723495 ] runtime_library_dirs broken under OS X
Message-ID: <E196U9b-0002UB-00@sc8-sf-web4.sourceforge.net>

Bugs item #723495, was opened at 2003-04-18 06:41
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723495&group_id=5470

Category: Distutils
>Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Stuart Bishop (zenzen)
Assigned to: Nobody/Anonymous (nobody)
Summary: runtime_library_dirs broken under OS X

Initial Comment:
gcc and ld on OSX don't seem to support the -R option, breaking 
runtime_library_dirs and any distutils installed extensions that require 
it.

I've only checked Python 2.2.2 so far.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2003-04-18 13:35

Message:
Logged In: YES 
user_id=45365

It looks like backporting the rev. 1.48 fix to Lib/distutils/unixccompiler.py should do the trick. I've attached the patch that should do the trick, if you could try this that would be helpful.

----------------------------------------------------------------------

Comment By: Stuart Bishop (zenzen)
Date: 2003-04-18 13:08

Message:
Logged In: YES 
user_id=46639

Looks like this has been fixed in 2.3a2:
       if sys.platform[:6] == "darwin":
            # MacOSX's linker doesn't understand the -R flag at all
            return "-L" + dir
        elif compiler[:3] == "gcc" or compiler[:3] == "g++":
            return "-Wl,-R" + dir
        else:
            return "-R" + dir

I can't find a bug report or patch on this fix, and I don't know if it is in any 
2.2.x branch.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-04-18 10:58

Message:
Logged In: YES 
user_id=45365

Could you elaborate a bit on what breaks, and/or give an example that breaks?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723495&group_id=5470


From noreply@sourceforge.net  Fri Apr 18 17:26:09 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 18 Apr 2003 09:26:09 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-722498 ] assert could raise other Exceptions
Message-ID: <E196Ygj-00027X-00@sc8-sf-web2.sourceforge.net>

Feature Requests item #722498, was opened at 2003-04-16 16:08
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=722498&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregory Smith (gregsmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: assert could raise other Exceptions

Initial Comment:

how about having 'assert' check its second parameter,
and if it is an instance of Exception, raise that instead
of AssertionError:

  try:
         n = int(argv[i])
         assert 0 <= n <  10, ValueError("n out of range")
   except ValueError,e:
         print "Bad parameter:", str(e)



This is a fair bit tidier than

      if not ( 0 <= n < 10 ): raise ValueError, "n out
of range"

you could also do 'except (ValueError,
AssertionError)", but
the 'except' might not  be so close by, it would be nice to
have assert raise something else.

Having written this, I just realized that assert is
supposed
to go away when '-O' is selected (I never use that, myself)
so maybe this is not quite as useful -- but still quite
free of downside. 

I know nobody wants a new keyword, how about

     assert >> ValueError  , 0 <= n < 10 , n out of range

... which would do the same as the first example but
not be deleted by -O









----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-04-18 18:26

Message:
Logged In: YES 
user_id=21627

I don't like this idea. Assertions are something that you
can take out without changing the interface (and indeed -O
takes them out). They are supposed to never happen, not even
when an application uses a library incorrectly.

If you need to perform correctness checks on parameters,
those checks belong to the API of the function, and should
be documented and implemented with a proper if statement.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=722498&group_id=5470


From noreply@sourceforge.net  Fri Apr 18 17:34:17 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 18 Apr 2003 09:34:17 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-723749 ] Compilation under Tru64
Message-ID: <E196Yob-0007vI-00@sc8-sf-web1.sourceforge.net>

Feature Requests item #723749, was opened at 2003-04-18 11:34
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=723749&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Cowles (mdcowles)
Assigned to: Nobody/Anonymous (nobody)
Summary: Compilation under Tru64

Initial Comment:
[From a question sent to python-help]

For Python 2.2.2 and 2.3a2, under DEC OSFV1 True64 Unix
and gcc 3.0.4:

uname -a yields
OSF1 ms-ax1.migen.bio.example V5.1 1885 alpha

the posix module needs:

< #     define STAT _F64_stat
< #     define FSTAT _F64_fstat
---
> #     define STAT stat
> #     define FSTAT fstat
3384c3384
<       return posix_do_stat(self, args, "et:lstat",
_F64_lstat);
---
>       return posix_do_stat(self, args, "et:lstat",
lstat);


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=723749&group_id=5470


From noreply@sourceforge.net  Fri Apr 18 19:06:13 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 18 Apr 2003 11:06:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-723801 ] logging.setLoggerClass() doesn't support new-style classes
Message-ID: <E196aFZ-0006Cs-00@sc8-sf-web4.sourceforge.net>

Bugs item #723801, was opened at 2003-04-18 18:06
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723801&group_id=5470

Category: Type/class unification
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Phillip J. Eby (pje)
Assigned to: Nobody/Anonymous (nobody)
Summary: logging.setLoggerClass() doesn't support new-style classes

Initial Comment:
Trying to use 'logging.setLoggerClass(aNewStyleClass)'
raises a TypeError, "setLoggerClass is expecting a class".


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723801&group_id=5470


From noreply@sourceforge.net  Fri Apr 18 19:17:17 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 18 Apr 2003 11:17:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-723806 ] overintelligent slice() behavior on integers
Message-ID: <E196aQH-0000pk-00@sc8-sf-web3.sourceforge.net>

Bugs item #723806, was opened at 2003-04-18 11:17
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723806&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Russ Thompson (russt)
Assigned to: Nobody/Anonymous (nobody)
Summary: overintelligent slice() behavior on integers

Initial Comment:

slices such as a[:7] give a key of slice(0,7,None)
whereas a[:7.1] gives a key of slice(None,7.1,None)

Slices should not assume that the object indices
begin at zero, since that is actually a characteristic of 
the object.  The current behavior cripples an object that 
wants, say, to start its indices with negative numbers.

a[:7] should pass a key of slice(None,7,None).

Thanks!
russt@agilityfund.com


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723806&group_id=5470


From noreply@sourceforge.net  Fri Apr 18 19:44:55 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 18 Apr 2003 11:44:55 -0700
Subject: [Python-bugs-list] [ python-Bugs-723540 ] __slots__ broken in 2.3a with ("__dict__", )
Message-ID: <E196ar1-0002Ig-00@sc8-sf-web3.sourceforge.net>

Bugs item #723540, was opened at 2003-04-18 02:35
Message generated for change (Comment added) made by derivin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723540&group_id=5470

Category: Type/class unification
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Douglas Napoleone (derivin)
Assigned to: Nobody/Anonymous (nobody)
>Summary: __slots__ broken in 2.3a with ("__dict__", )

Initial Comment:
I LOVE using __slots__. I love using properties.
I made my own extension and metaclass so I could 
define type safe properties in classes. I could stick 
properties on a class and have them accessed 
seperatly from slots (because they are properties and 
not attributes). The properties call setter/getters and 
store the data in __dict__ (a cheezy means of making 
pickle still work with no effort). thus I had __slots__ = 
('__dict__', ) in my base class. this worked great in 2.2 
and 2.2.2.  Im migrating all my modules to 2.3. I just 
fixed a bug in my code that was due to a typo. Thats 
when I realized that __slots__ was no longer working in 
2.3a. I cant find anything on this change in behavior.

if slots contains "__dict__" slots is turned OFF!!!
simplified version of the bug:

$ python
Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more 
information.
>>> class foo(object):
...   __slots__ = ("__dict__", )
...
>>> a = foo()
>>> a.bad = 3
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
AttributeError: 'foo' object has no attribute 'bad'
>>> ^Z

$ python23
Python 2.3a2 (#39, Feb 19 2003, 17:58:58) [MSC 
v.1200 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more 
information.
>>> class foo(object):
...   __slots__ = ("__dict__", )
...
>>> a = foo()
>>> a.bad = 3
>>> dir(a)
['__class__', '__delattr__', '__dict__', '__doc__', '__getattr
ibute__', '__hash_
_', '__init__', '__module__', '__new__', '__reduce__', '__re
duce_ex__', '__repr_
_', '__setattr__', '__slots__', '__str__', 'bad']
>>> ^Z



----------------------------------------------------------------------

>Comment By: Douglas Napoleone (derivin)
Date: 2003-04-18 13:44

Message:
Logged In: YES 
user_id=541557

Well looking deeper at the problem, is seems that __dict__ 
and __weakref__ are called out as special in 
Objects/typeobject.c at some point after the 2.2.2 release.

looking at teh code, I would expect the followint ot be 
triggered:

   if (!may_add_dict || add_dict) { 
          PyErr_SetString(PyExc_TypeError, 
                                    "__dict__ slot disallowed: " 
                                    "we already got one"); 
          goto bad_slots; 
    }

Ignoring the attrocious goto logic in this section of code, I 
would have expected to see this triggered.
I can understand the IDEA behind always having __slots__ 
on all classes/types and setting it to contain "__dict__" as 
teh equivolent of not having slots... But the code does not 
look like it implements this, and I dont see how this is even 
working that way yet. Has anyone heard anything about 
this???

(for now in my code I am having to use __fakedict__ and 
override all the pickle handling (yuck).



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723540&group_id=5470


From noreply@sourceforge.net  Fri Apr 18 19:52:21 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 18 Apr 2003 11:52:21 -0700
Subject: [Python-bugs-list] [ python-Bugs-723831 ] urlopen(url_to_a_non-existing-domain) raises gaierror
Message-ID: <E196ayD-0008C4-00@sc8-sf-web1.sourceforge.net>

Bugs item #723831, was opened at 2003-04-18 20:52
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723831&group_id=5470

Category: Python Library
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Joachim Werner (bavarian)
Assigned to: Nobody/Anonymous (nobody)
Summary: urlopen(url_to_a_non-existing-domain) raises gaierror

Initial Comment:
In Python 2.1.3 trying to open a URL that does point 
to a non-existing domain with urlopen from urllib2 will 
raise a

urllib2.URLError: <urlopen error host not found>

That's what I'd expect Python 2.2.2 to do, too. But 
with Python 2.2.2 I get a

socket.gaierror: (-2, 'Name or service not known')

Error instead. I think this is a bug because

a) one would not expect urlopen to raise errors other 
than HTTPError and URLError (from what the docs say)

b) it breaks code that relies on the error behaviour of 
Python 2.1.3

Cheers

Joachim

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723831&group_id=5470


From noreply@sourceforge.net  Fri Apr 18 23:04:44 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 18 Apr 2003 15:04:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-723136 ] Put a reference to print in the Library Reference, please.
Message-ID: <E196dyO-0000W8-00@sc8-sf-web1.sourceforge.net>

Bugs item #723136, was opened at 2003-04-17 08:41
Message generated for change (Comment added) made by logistix
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723136&group_id=5470

Category: Documentation
Group: Feature Request
Status: Open
Resolution: None
Priority: 6
Submitted By: Laura Creighton (lcreighton)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Put a reference to print in the Library Reference, please.

Initial Comment:
Often the first question a Newbie has is 'how do I
print stuff?'.
They come to the Library Reference, looking for a print
function.   They are unaware that print is an
expression, and
that they need to be looking in the Language Reference
Manual.
One line, early on telling them where to look will save
aggrevation
for them.  Thanks very much,
Laura Creighton

----------------------------------------------------------------------

Comment By: logistix (logistix)
Date: 2003-04-18 17:04

Message:
Logged In: YES 
user_id=699438

Perhaps this could be a "builtin statements" subsection of 
section 2 that lists all statements and crossreferences the 
Language Reference.  It took me a year before it finally stuck 
that I needed to go to the Language Reference to look at try... 
syntax, etc.

It's probably my biggest usability gripe with the manuals.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-04-17 09:49

Message:
Logged In: YES 
user_id=3066

Guido wants this fixed, so bumped priority and assigned it
to me.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723136&group_id=5470


From noreply@sourceforge.net  Sat Apr 19 01:16:16 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 18 Apr 2003 17:16:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-723962 ] imaplib should convert line endings to be rfc2822 complient
Message-ID: <E196g1g-0005Lj-00@sc8-sf-web1.sourceforge.net>

Bugs item #723962, was opened at 2003-04-19 12:16
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723962&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tony Meyer (anadelonbrin)
Assigned to: Nobody/Anonymous (nobody)
Summary: imaplib should convert line endings to be rfc2822 complient

Initial Comment:
When imaplib.append is called, it should convert line 
endings from whatever they are (\r, \n or \r\n) to the 
format required by rfc2822 (in turn, required by rfc1730), 
i.e. CRLF - \r\n.

The email package generates mail with Python "internal" 
line endings (i.e. \n), and so if a message is flattened 
and then appended via imap improper line endings are 
sent.

While some imap servers are ok with this, at least one 
(Communigate Pro) mangles the message (all the 
headers become part of the body).

smtplib has an example of how to do this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723962&group_id=5470


From noreply@sourceforge.net  Sat Apr 19 05:06:11 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 18 Apr 2003 21:06:11 -0700
Subject: [Python-bugs-list] [ python-Bugs-715782 ] pydoc support for keywords
Message-ID: <E196jcB-0007LF-00@sc8-sf-web2.sourceforge.net>

Bugs item #715782, was opened at 2003-04-05 06:36
Message generated for change (Comment added) made by derivin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=715782&group_id=5470

Category: Documentation
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: pydoc support for keywords

Initial Comment:
[ from http://bugs.debian.org/186775 ]

If one uses $ man perl
one gets on a path that can lead one to eventually find
docs for the
most basic commands like 'while'

However for python one sees one is to use pydoc. But
running pydoc,
one just sees
  pydoc - the Python documentation tool

  /usr/bin/pydoc <name> ...

etc. no hint about how to learn about basics like 'while'.

BTW, I wish it would say pydoc, not /usr/bin/pydoc


----------------------------------------------------------------------

Comment By: Douglas Napoleone (derivin)
Date: 2003-04-18 23:06

Message:
Logged In: YES 
user_id=541557

Could you please include the OS, install, distro for python?

the distrobution from ActiveState has a very detailed 
manpage on linux. The cygwin distrobution (currently 
hosted/maintained by RedHat) has a poor man page (similar 
yet different from your example).

To be honest, I thought there was only a GNU info page, a 
quick find of the source tree didnt turn anything up, (but Im 
building on windows).


----------------------------------------------------------------------

Comment By: Cherniavsky Beni (cben)
Date: 2003-04-06 03:33

Message:
Logged In: YES 
user_id=36166

It should suggest to run ``python`` and type ``help()``. 
Then one can type ``topics`` and access the language
documentation itself, e.g. ``LOOPING`` would tell one that
there is a ``while`` whose specific documentation is
accessible by typing the ``while`` keyword itself.  Also
some sentences about the usefulness of the Python prompt,
`dir()` and `help()` for learning might be in order...

BTW, it would be more consistent if pydoc would support the
special topics from the command line (it would require a
non-ambiguos option to avoid shadowing modules in current
directoy that happen to have one of the special name)...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=715782&group_id=5470


From noreply@sourceforge.net  Sat Apr 19 08:32:22 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 19 Apr 2003 00:32:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-672491 ] 2.3a1 computes lastindex incorrectly
Message-ID: <E196mpi-0004sV-00@sc8-sf-web2.sourceforge.net>

Bugs item #672491, was opened at 2003-01-22 16:28
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672491&group_id=5470

Category: Regular Expressions
Group: Python 2.3
Status: Open
Resolution: None
Priority: 6
Submitted By: Martin v. Löwis (loewis)
>Assigned to: Gustavo Niemeyer (niemeyer)
Summary: 2.3a1 computes lastindex incorrectly

Initial Comment:
In Python 2.[012], the code

import re
exp = re.compile("(?P<NCName>[a-zA-Z_](\w|[_.-])*)")
print exp.match("namespace").lastgroup

prints "NCName". In Python 2.3a1, it prints "None". The
problem is that last index is 2, instead of 1, as it
should be.

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-04-19 09:32

Message:
Logged In: YES 
user_id=21627

Assigning to Gustavo, since he wrote 2.84. Gustavo, can you
confirm that your change broke this feature? Can you also
agree that it should be fixed?



----------------------------------------------------------------------

Comment By: Greg Chapman (glchapman)
Date: 2003-02-05 02:56

Message:
Logged In: YES 
user_id=86307

I believe the discrepancy was deliberately introduced in revision 2.84 of _sre.c.  I agree with you that lastindex should return the the index of the matching group with the rightmost closing parenthesis (perhaps some elaboration in the docs is also in order).  If this is the correct interpretation, two places need to be patched: 1) the handling of SRE_OP_MARK needs to be reverted to the 2.22 code and 2) the code in the lastmark_restore function needs to be tweaked so that lastindex is not accidentally set to the last matched group entered.

Thinking further though, given a (contrived) pattern like this: 

  re.match('((x))y(?:(a)b|ac)', 'xyac')

what should lastindex be?  I assume 1, given the definition above (lastindex = matching group with rightmost close parens).  In 2.22 it is 3, since group 3 matched before the branch failed at the 'b'.  In 2.3a1 it is 2, since lastindex is restored (after the branch fails) using the saved lastmark.  Anyway, if it should be 1, then I think _sre.c will have to save lastindex as well as lastmark when processing the three opcodes which may end up calling lastmark_restore.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672491&group_id=5470


From noreply@sourceforge.net  Sat Apr 19 09:14:31 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 19 Apr 2003 01:14:31 -0700
Subject: [Python-bugs-list] [ python-Bugs-690974 ] re.LOCALE, umlaut and \w
Message-ID: <E196nUV-0003Cf-00@sc8-sf-web1.sourceforge.net>

Bugs item #690974, was opened at 2003-02-22 01:06
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=690974&group_id=5470

Category: Regular Expressions
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: peter nordlund (peterno)
Assigned to: Fredrik Lundh (effbot)
Summary: re.LOCALE, umlaut and \w

Initial Comment:
I submit this problem although I am not sure it is
a real bug. It could be that I don't know how this
locale stuff works.

Anyway, I have been browsing around quite some time on
the net to find some
good examples of code demonstating how to use regexp in
python to get hold
of åäö when using \w, but I have not found any complete
examples.

If the code below behaves correctly, I suggest that the
regexp documentation
is improved by adding a complete example that shows how
to use re.LOCALE.
(The code behaves in the same way with python 2.2.2.)

#----------------------------------------
import locale
locale.setlocale(locale.LC_ALL,'swedish')
import re
reguml=re.compile(r"[a-zä]", re.LOCALE) # I expect
reguml and regw to give the same result.
regw=re.compile(r"\w", re.LOCALE)
reguml2=re.compile(r"[a-zä]+", re.LOCALE) # I expect
reguml2 and regw2 to give the same result.
regw2=re.compile(r"[\w]+", re.LOCALE)
str="abcä d\344e ä f ";

print reguml.findall(str) # Behaves as I expect.
print regw.findall(str) # Here I expect same result as
above, but I don't get it.
print reguml2.findall(str) # Behaves as I expect.
print regw2.findall(str) # Behaves as I expect.
#----------------------------------------



>>> import locale
>>> locale.setlocale(locale.LC_ALL,'swedish')
'swedish'
>>> import re
>>> reguml=re.compile(r"[a-zä]", re.LOCALE) # I expect
reguml and regw to give the same result.
>>> regw=re.compile(r"\w", re.LOCALE)
>>> reguml2=re.compile(r"[a-zä]+", re.LOCALE) # I
expect reguml2 and regw2 to give the same result.
>>> regw2=re.compile(r"[\w]+", re.LOCALE)
>>> str="abcä d\344e ä f ";
>>>
>>> print reguml.findall(str) # Behaves as I expect.
['a', 'b', 'c', '\xe4', 'd', '\xe4', 'e', '\xe4', 'f']
>>> print regw.findall(str) # Here I expect same result
as above, but I don't get it.
['a', 'b', 'c', 'd', 'e', 'f']
>>> print reguml2.findall(str) # Behaves as I expect.
['abc\xe4', 'd\xe4e', '\xe4', 'f']
>>> print regw2.findall(str) # Behaves as I expect.
['abc\xe4', 'd\xe4e', '\xe4', 'f']
---------------------------------------------------------
peternl:Python-2.3a2>>
/work1/pkg/dev-tools/python/2.3a2/bin/python -V
Python 2.3a2
peternl:Python-2.3a2>>uname -a
Linux peternl.computervision.se 2.4.18-6mdk-petern #2
Thu May 23 06:40:30 CEST 2002 i686 unknown


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-04-19 10:14

Message:
Logged In: YES 
user_id=21627

This has been fixed with Greg's patch.

----------------------------------------------------------------------

Comment By: Greg Chapman (glchapman)
Date: 2003-02-22 18:15

Message:
Logged In: YES 
user_id=86307

I believe this is fixed by this patch:

   http://www.python.org/sf/633359

At any rate, using a patched 2.22, regw behaves identically to reguml. 


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=690974&group_id=5470


From noreply@sourceforge.net  Sat Apr 19 09:41:58 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 19 Apr 2003 01:41:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-612074 ] Cannot compile escaped unicode character
Message-ID: <E196nv4-00048z-00@sc8-sf-web1.sourceforge.net>

Bugs item #612074, was opened at 2002-09-20 13:23
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=612074&group_id=5470

Category: Regular Expressions
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nathan L Miles (nathan22)
Assigned to: Fredrik Lundh (effbot)
Summary: Cannot compile escaped unicode character

Initial Comment:
The following RE fails to compile on Python 2.2/
Windows XP.

I am trying to work around this by writing my own 
version of .escape which does not escape code points > 
127.


import re

a = unichr(0x2039)
b = u"["+re.escape(a)+u"]"
re.compile(b)


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-04-19 10:41

Message:
Logged In: YES 
user_id=21627

Greg's patch has been applied as sre_parse.py 1.57, fixing
this bug.

----------------------------------------------------------------------

Comment By: Greg Chapman (glchapman)
Date: 2003-02-05 20:28

Message:
Logged In: YES 
user_id=86307

patch posted: http://www.python.org/sf/681152


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=612074&group_id=5470


From noreply@sourceforge.net  Sat Apr 19 09:55:04 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 19 Apr 2003 01:55:04 -0700
Subject: [Python-bugs-list] [ python-Bugs-723136 ] Put a reference to print in the Library Reference, please.
Message-ID: <E196o7k-0004ZE-00@sc8-sf-web1.sourceforge.net>

Bugs item #723136, was opened at 2003-04-17 15:41
Message generated for change (Comment added) made by lcreighton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723136&group_id=5470

Category: Documentation
Group: Feature Request
Status: Open
Resolution: None
Priority: 6
Submitted By: Laura Creighton (lcreighton)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Put a reference to print in the Library Reference, please.

Initial Comment:
Often the first question a Newbie has is 'how do I
print stuff?'.
They come to the Library Reference, looking for a print
function.   They are unaware that print is an
expression, and
that they need to be looking in the Language Reference
Manual.
One line, early on telling them where to look will save
aggrevation
for them.  Thanks very much,
Laura Creighton

----------------------------------------------------------------------

>Comment By: Laura Creighton (lcreighton)
Date: 2003-04-19 10:55

Message:
Logged In: YES 
user_id=376262

This is probably the best time to add a reference to the %
operator and 
what it is good for.  

----------------------------------------------------------------------

Comment By: logistix (logistix)
Date: 2003-04-19 00:04

Message:
Logged In: YES 
user_id=699438

Perhaps this could be a "builtin statements" subsection of 
section 2 that lists all statements and crossreferences the 
Language Reference.  It took me a year before it finally stuck 
that I needed to go to the Language Reference to look at try... 
syntax, etc.

It's probably my biggest usability gripe with the manuals.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-04-17 16:49

Message:
Logged In: YES 
user_id=3066

Guido wants this fixed, so bumped priority and assigned it
to me.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723136&group_id=5470


From noreply@sourceforge.net  Sat Apr 19 13:55:28 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 19 Apr 2003 05:55:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-723962 ] imaplib should convert line endings to be rfc2822 complient
Message-ID: <E196rsO-0004MG-00@sc8-sf-web4.sourceforge.net>

Bugs item #723962, was opened at 2003-04-19 10:16
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723962&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tony Meyer (anadelonbrin)
Assigned to: Nobody/Anonymous (nobody)
Summary: imaplib should convert line endings to be rfc2822 complient

Initial Comment:
When imaplib.append is called, it should convert line 
endings from whatever they are (\r, \n or \r\n) to the 
format required by rfc2822 (in turn, required by rfc1730), 
i.e. CRLF - \r\n.

The email package generates mail with Python "internal" 
line endings (i.e. \n), and so if a message is flattened 
and then appended via imap improper line endings are 
sent.

While some imap servers are ok with this, at least one 
(Communigate Pro) mangles the message (all the 
headers become part of the body).

smtplib has an example of how to do this.

----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-04-19 22:55

Message:
Logged In: YES 
user_id=29957

You may want to contact imaplib's author, (Piers Lauder
<piers@cs.su.oz.au>)
directly about this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723962&group_id=5470


From noreply@sourceforge.net  Sat Apr 19 14:44:00 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 19 Apr 2003 06:44:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-723962 ] imaplib should convert line endings to be rfc2822 complient
Message-ID: <E196sdM-0001c5-00@sc8-sf-web2.sourceforge.net>

Bugs item #723962, was opened at 2003-04-19 01:16
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723962&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tony Meyer (anadelonbrin)
>Assigned to: Piers Lauder (pierslauder)
Summary: imaplib should convert line endings to be rfc2822 complient

Initial Comment:
When imaplib.append is called, it should convert line 
endings from whatever they are (\r, \n or \r\n) to the 
format required by rfc2822 (in turn, required by rfc1730), 
i.e. CRLF - \r\n.

The email package generates mail with Python "internal" 
line endings (i.e. \n), and so if a message is flattened 
and then appended via imap improper line endings are 
sent.

While some imap servers are ok with this, at least one 
(Communigate Pro) mangles the message (all the 
headers become part of the body).

smtplib has an example of how to do this.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2003-04-19 14:44

Message:
Logged In: YES 
user_id=6656

Or just assign it to him :-)


----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-04-19 13:55

Message:
Logged In: YES 
user_id=29957

You may want to contact imaplib's author, (Piers Lauder
<piers@cs.su.oz.au>)
directly about this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723962&group_id=5470


From noreply@sourceforge.net  Sat Apr 19 19:45:24 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 19 Apr 2003 11:45:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-699312 ] builtin type inconsistency
Message-ID: <E196xL2-0002fi-00@sc8-sf-web4.sourceforge.net>

Bugs item #699312, was opened at 2003-03-07 11:59
Message generated for change (Comment added) made by aleax
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699312&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Alex Martelli (aleax)
Assigned to: Nobody/Anonymous (nobody)
Summary: builtin type inconsistency

Initial Comment:
many builtin types can be called without arguments, yielding 
the 'false' (zero/empty) instance of their type.  However, 
others can't.  why is int()==0 but calling bool() raises an 
exception rather than returning False?  I consider this 
irregularity a tiny bug.  Arguably slice() should also return 
the same result as slice(None), again for regularity, but this 
is admittedly iffier.

----------------------------------------------------------------------

>Comment By: Alex Martelli (aleax)
Date: 2003-04-19 20:45

Message:
Logged In: YES 
user_id=60314

submitted a patch for it today, an easy fix, but can't find it here on 
SF as patches -- HMMM!!!.  So I'm uploading it again here just in 
case.  No doc fixes as there is strictly speaking no NEED to 
document this regularity I think, just no reason to make it into an 
IR-regularity just for bool...

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-15 14:45

Message:
Logged In: YES 
user_id=21627

I agree this is a bug, also I personally would not care
enough to fix it.

Would you like to work on a patch? I guess if your
observation is a principle to be followed, it needs to be
documented, also.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699312&group_id=5470


From noreply@sourceforge.net  Sat Apr 19 22:03:16 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 19 Apr 2003 14:03:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-672491 ] 2.3a1 computes lastindex incorrectly
Message-ID: <E196zUS-0007yK-00@sc8-sf-web4.sourceforge.net>

Bugs item #672491, was opened at 2003-01-22 15:28
Message generated for change (Comment added) made by niemeyer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672491&group_id=5470

Category: Regular Expressions
Group: Python 2.3
Status: Open
Resolution: None
Priority: 6
Submitted By: Martin v. Löwis (loewis)
>Assigned to: Martin v. Löwis (loewis)
Summary: 2.3a1 computes lastindex incorrectly

Initial Comment:
In Python 2.[012], the code

import re
exp = re.compile("(?P<NCName>[a-zA-Z_](\w|[_.-])*)")
print exp.match("namespace").lastgroup

prints "NCName". In Python 2.3a1, it prints "None". The
problem is that last index is 2, instead of 1, as it
should be.

----------------------------------------------------------------------

>Comment By: Gustavo Niemeyer (niemeyer)
Date: 2003-04-19 21:03

Message:
Logged In: YES 
user_id=7887

Martin, the lastgroup/lastindex handling was quite broken in
Python < 2.3. We can easily see this if testing your example
in the following way:

>>> import re
>>> exp = re.compile("(?P<NCName>[a-zA-Z_](\w|[_.-])*)")
>>> match = exp.match("namespace")
>>> match.groups()
('namespace', 'e')
>>> match.groupdict()
{'NCName': 'namespace'}

This has the same result in any python you execute. This
also demonstrates that the group numbering has always been
assigned by the opening parenthesis.

About the None result, that's also correct. In the example,
we notice that the second unnamed group is correctly
matching 'e'. Accordingly to the sre module documentation,
that's how lastgroups should behave:

lastgroup
    The name of the last matched capturing group, or None if
the group didn't have a name, or if no group was matched at all.

In the case above, the group didn't have a name. If we check
lastindex, we'll see it's correctly set to "2".

Greg, your example is correctly showing one of the bugs in
lastgroup/index handling in Python < 2.3. OTOH, the current
result of 2 is right, given the "count on open" rule, which
was always used. Here's an example in 2.3:

>>> re.match('((x))y(?:(a)b|ac)', 'xyac').groups()
('x', 'x', None)
>>> re.match('((x))y(?:(a)b|ac)', 'xyac').lastindex
2

(notice that groups always start in 1, as group 0 is the
"whole match" group)

Martin, if you agree, please close the bug. If you have any
doubts, it'll be a pleasure to explain.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-04-19 07:32

Message:
Logged In: YES 
user_id=21627

Assigning to Gustavo, since he wrote 2.84. Gustavo, can you
confirm that your change broke this feature? Can you also
agree that it should be fixed?



----------------------------------------------------------------------

Comment By: Greg Chapman (glchapman)
Date: 2003-02-05 01:56

Message:
Logged In: YES 
user_id=86307

I believe the discrepancy was deliberately introduced in revision 2.84 of _sre.c.  I agree with you that lastindex should return the the index of the matching group with the rightmost closing parenthesis (perhaps some elaboration in the docs is also in order).  If this is the correct interpretation, two places need to be patched: 1) the handling of SRE_OP_MARK needs to be reverted to the 2.22 code and 2) the code in the lastmark_restore function needs to be tweaked so that lastindex is not accidentally set to the last matched group entered.

Thinking further though, given a (contrived) pattern like this: 

  re.match('((x))y(?:(a)b|ac)', 'xyac')

what should lastindex be?  I assume 1, given the definition above (lastindex = matching group with rightmost close parens).  In 2.22 it is 3, since group 3 matched before the branch failed at the 'b'.  In 2.3a1 it is 2, since lastindex is restored (after the branch fails) using the saved lastmark.  Anyway, if it should be 1, then I think _sre.c will have to save lastindex as well as lastmark when processing the three opcodes which may end up calling lastmark_restore.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672491&group_id=5470


From noreply@sourceforge.net  Sat Apr 19 22:13:57 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 19 Apr 2003 14:13:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-699312 ] builtin type inconsistency
Message-ID: <E196zen-0001rr-00@sc8-sf-web1.sourceforge.net>

Bugs item #699312, was opened at 2003-03-07 11:59
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699312&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Alex Martelli (aleax)
Assigned to: Nobody/Anonymous (nobody)
Summary: builtin type inconsistency

Initial Comment:
many builtin types can be called without arguments, yielding 
the 'false' (zero/empty) instance of their type.  However, 
others can't.  why is int()==0 but calling bool() raises an 
exception rather than returning False?  I consider this 
irregularity a tiny bug.  Arguably slice() should also return 
the same result as slice(None), again for regularity, but this 
is admittedly iffier.

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-04-19 23:13

Message:
Logged In: YES 
user_id=21627

Another remark: It is always a good idea to cross-link
patches and bug reports: When submitting a patch, indicate
what bug it fixes. On the bug patch, add a comment which
patch has been submitted.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-04-19 23:11

Message:
Logged In: YES 
user_id=21627

I see now what happened: The patch was 724135, and Guido had
checked it in, and closed it, when tried to find it. SF
should have send you an email both when telling you about
the patch submission, and when Guido was closing it.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-04-19 23:09

Message:
Logged In: YES 
user_id=21627

This was committed as 

NEWS 1.736
boolobject.c 1.6
test_types.py 1.49 
test_bool.py 1.8 

----------------------------------------------------------------------

Comment By: Alex Martelli (aleax)
Date: 2003-04-19 20:45

Message:
Logged In: YES 
user_id=60314

submitted a patch for it today, an easy fix, but can't find it here on 
SF as patches -- HMMM!!!.  So I'm uploading it again here just in 
case.  No doc fixes as there is strictly speaking no NEED to 
document this regularity I think, just no reason to make it into an 
IR-regularity just for bool...

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-15 14:45

Message:
Logged In: YES 
user_id=21627

I agree this is a bug, also I personally would not care
enough to fix it.

Would you like to work on a patch? I guess if your
observation is a principle to be followed, it needs to be
documented, also.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699312&group_id=5470


From noreply@sourceforge.net  Sat Apr 19 22:25:54 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 19 Apr 2003 14:25:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-672491 ] 2.3a1 computes lastindex incorrectly
Message-ID: <E196zqM-0000bg-00@sc8-sf-web4.sourceforge.net>

Bugs item #672491, was opened at 2003-01-22 16:28
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672491&group_id=5470

Category: Regular Expressions
Group: Python 2.3
Status: Open
Resolution: None
Priority: 6
Submitted By: Martin v. Löwis (loewis)
>Assigned to: Gustavo Niemeyer (niemeyer)
Summary: 2.3a1 computes lastindex incorrectly

Initial Comment:
In Python 2.[012], the code

import re
exp = re.compile("(?P<NCName>[a-zA-Z_](\w|[_.-])*)")
print exp.match("namespace").lastgroup

prints "NCName". In Python 2.3a1, it prints "None". The
problem is that last index is 2, instead of 1, as it
should be.

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-04-19 23:25

Message:
Logged In: YES 
user_id=21627

Gustavo, I agree that the numbering of groups is and should
be by opening parentheses, i.e. that group 1 is <NCName>,
and group 2 is unnamed.

I also agree that *if* lastindex is 2, lastgroup should be None.

I still think this value is incorrect, though. It is
illogical, unhelpful, and incompatible with earlier
versions. lastindex should be 1, and lastgroup should be
"NCName".

It is illogical because group 1 ends *after* group 2 ends,
as the closing parenthesis of group 1 is after the closing
parenthesis of group 2.

It is unhelpful because one of the primary purposes of
lastgroup is to find efficiently the entire match if you
have a list of top-level alternatives, such as you do in a
scanner. With Python <2.3, you can put named alternatives
into a regex, and use lastindex to find out the alternative.
Indeed, this is what sre.Scanner does; I believe you have
broken that class as well.

It is incompatible because earlier Python versions behaved
differently. As a result of this change, PyXML does not work
with Python 2.3.

----------------------------------------------------------------------

Comment By: Gustavo Niemeyer (niemeyer)
Date: 2003-04-19 23:03

Message:
Logged In: YES 
user_id=7887

Martin, the lastgroup/lastindex handling was quite broken in
Python < 2.3. We can easily see this if testing your example
in the following way:

>>> import re
>>> exp = re.compile("(?P<NCName>[a-zA-Z_](\w|[_.-])*)")
>>> match = exp.match("namespace")
>>> match.groups()
('namespace', 'e')
>>> match.groupdict()
{'NCName': 'namespace'}

This has the same result in any python you execute. This
also demonstrates that the group numbering has always been
assigned by the opening parenthesis.

About the None result, that's also correct. In the example,
we notice that the second unnamed group is correctly
matching 'e'. Accordingly to the sre module documentation,
that's how lastgroups should behave:

lastgroup
    The name of the last matched capturing group, or None if
the group didn't have a name, or if no group was matched at all.

In the case above, the group didn't have a name. If we check
lastindex, we'll see it's correctly set to "2".

Greg, your example is correctly showing one of the bugs in
lastgroup/index handling in Python < 2.3. OTOH, the current
result of 2 is right, given the "count on open" rule, which
was always used. Here's an example in 2.3:

>>> re.match('((x))y(?:(a)b|ac)', 'xyac').groups()
('x', 'x', None)
>>> re.match('((x))y(?:(a)b|ac)', 'xyac').lastindex
2

(notice that groups always start in 1, as group 0 is the
"whole match" group)

Martin, if you agree, please close the bug. If you have any
doubts, it'll be a pleasure to explain.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-04-19 09:32

Message:
Logged In: YES 
user_id=21627

Assigning to Gustavo, since he wrote 2.84. Gustavo, can you
confirm that your change broke this feature? Can you also
agree that it should be fixed?



----------------------------------------------------------------------

Comment By: Greg Chapman (glchapman)
Date: 2003-02-05 02:56

Message:
Logged In: YES 
user_id=86307

I believe the discrepancy was deliberately introduced in revision 2.84 of _sre.c.  I agree with you that lastindex should return the the index of the matching group with the rightmost closing parenthesis (perhaps some elaboration in the docs is also in order).  If this is the correct interpretation, two places need to be patched: 1) the handling of SRE_OP_MARK needs to be reverted to the 2.22 code and 2) the code in the lastmark_restore function needs to be tweaked so that lastindex is not accidentally set to the last matched group entered.

Thinking further though, given a (contrived) pattern like this: 

  re.match('((x))y(?:(a)b|ac)', 'xyac')

what should lastindex be?  I assume 1, given the definition above (lastindex = matching group with rightmost close parens).  In 2.22 it is 3, since group 3 matched before the branch failed at the 'b'.  In 2.3a1 it is 2, since lastindex is restored (after the branch fails) using the saved lastmark.  Anyway, if it should be 1, then I think _sre.c will have to save lastindex as well as lastmark when processing the three opcodes which may end up calling lastmark_restore.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672491&group_id=5470


From noreply@sourceforge.net  Sat Apr 19 22:11:38 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 19 Apr 2003 14:11:38 -0700
Subject: [Python-bugs-list] [ python-Bugs-699312 ] builtin type inconsistency
Message-ID: <E196zcY-0001m0-00@sc8-sf-web1.sourceforge.net>

Bugs item #699312, was opened at 2003-03-07 11:59
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699312&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Alex Martelli (aleax)
Assigned to: Nobody/Anonymous (nobody)
Summary: builtin type inconsistency

Initial Comment:
many builtin types can be called without arguments, yielding 
the 'false' (zero/empty) instance of their type.  However, 
others can't.  why is int()==0 but calling bool() raises an 
exception rather than returning False?  I consider this 
irregularity a tiny bug.  Arguably slice() should also return 
the same result as slice(None), again for regularity, but this 
is admittedly iffier.

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-04-19 23:11

Message:
Logged In: YES 
user_id=21627

I see now what happened: The patch was 724135, and Guido had
checked it in, and closed it, when tried to find it. SF
should have send you an email both when telling you about
the patch submission, and when Guido was closing it.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-04-19 23:09

Message:
Logged In: YES 
user_id=21627

This was committed as 

NEWS 1.736
boolobject.c 1.6
test_types.py 1.49 
test_bool.py 1.8 

----------------------------------------------------------------------

Comment By: Alex Martelli (aleax)
Date: 2003-04-19 20:45

Message:
Logged In: YES 
user_id=60314

submitted a patch for it today, an easy fix, but can't find it here on 
SF as patches -- HMMM!!!.  So I'm uploading it again here just in 
case.  No doc fixes as there is strictly speaking no NEED to 
document this regularity I think, just no reason to make it into an 
IR-regularity just for bool...

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-15 14:45

Message:
Logged In: YES 
user_id=21627

I agree this is a bug, also I personally would not care
enough to fix it.

Would you like to work on a patch? I guess if your
observation is a principle to be followed, it needs to be
documented, also.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699312&group_id=5470


From noreply@sourceforge.net  Sat Apr 19 22:09:18 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 19 Apr 2003 14:09:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-699312 ] builtin type inconsistency
Message-ID: <E196zaI-0004ym-00@sc8-sf-web3.sourceforge.net>

Bugs item #699312, was opened at 2003-03-07 11:59
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699312&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Alex Martelli (aleax)
Assigned to: Nobody/Anonymous (nobody)
Summary: builtin type inconsistency

Initial Comment:
many builtin types can be called without arguments, yielding 
the 'false' (zero/empty) instance of their type.  However, 
others can't.  why is int()==0 but calling bool() raises an 
exception rather than returning False?  I consider this 
irregularity a tiny bug.  Arguably slice() should also return 
the same result as slice(None), again for regularity, but this 
is admittedly iffier.

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-04-19 23:09

Message:
Logged In: YES 
user_id=21627

This was committed as 

NEWS 1.736
boolobject.c 1.6
test_types.py 1.49 
test_bool.py 1.8 

----------------------------------------------------------------------

Comment By: Alex Martelli (aleax)
Date: 2003-04-19 20:45

Message:
Logged In: YES 
user_id=60314

submitted a patch for it today, an easy fix, but can't find it here on 
SF as patches -- HMMM!!!.  So I'm uploading it again here just in 
case.  No doc fixes as there is strictly speaking no NEED to 
document this regularity I think, just no reason to make it into an 
IR-regularity just for bool...

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-15 14:45

Message:
Logged In: YES 
user_id=21627

I agree this is a bug, also I personally would not care
enough to fix it.

Would you like to work on a patch? I guess if your
observation is a principle to be followed, it needs to be
documented, also.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699312&group_id=5470


From noreply@sourceforge.net  Sat Apr 19 23:02:23 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 19 Apr 2003 15:02:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-672491 ] 2.3a1 computes lastindex incorrectly
Message-ID: <E1970Pf-00075I-00@sc8-sf-web3.sourceforge.net>

Bugs item #672491, was opened at 2003-01-22 15:28
Message generated for change (Comment added) made by niemeyer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672491&group_id=5470

Category: Regular Expressions
Group: Python 2.3
Status: Open
Resolution: None
Priority: 6
Submitted By: Martin v. Löwis (loewis)
>Assigned to: Martin v. Löwis (loewis)
Summary: 2.3a1 computes lastindex incorrectly

Initial Comment:
In Python 2.[012], the code

import re
exp = re.compile("(?P<NCName>[a-zA-Z_](\w|[_.-])*)")
print exp.match("namespace").lastgroup

prints "NCName". In Python 2.3a1, it prints "None". The
problem is that last index is 2, instead of 1, as it
should be.

----------------------------------------------------------------------

>Comment By: Gustavo Niemeyer (niemeyer)
Date: 2003-04-19 22:02

Message:
Logged In: YES 
user_id=7887

Why do you think lastindex is incorrect? Isn't 2 the lastindex?

>>> import re
>>> exp = re.compile("(?P<NCName>[a-zA-Z_](\w|[_.-])*)")
>>> match = exp.match("namespace")
>>> match.group(0)
'namespace'
>>> match.group(1)
'namespace'
>>> match.group(2)
'e'

It works like this in all Python versions. Also, if you
agree that group 2 is unnamed, shouldn't  lastindex be 2? It
actually *is* the lastindex, as you see above.

It is incompatible with old versions because old versions
were broken, and didn't follow what was documented. It was
indeed a side effect of a bug. For example, is it logical
that if we remove the second group, lastindex is still 1 (in
Python 2.2)?

>>> exp = re.compile("(?P<NCName>[a-zA-Z_])")
>>> print exp.match("namespace").lastindex
1

> It is illogical because group 1 ends *after* group 2 ends,
> as the closing parenthesis of group 1 is after the closing
> parenthesis of group 2.

How this changes anything? As we agreed, groups are numbered
by the opening parenthesis.

Hummm.. perhaps you think that the old behavior was to show
what group had the last closing parenthesis? No.. that
wasn't the case either. Look at this example, in Python 2.2:

>>> re.compile("(a(b)?)((c)d)?").match("abce").lastindex
4
>>> re.compile("(a(b)?)((c)d)?").match("abce").groups()
('ab', 'b', None, None)

In Python 2.3:

>>> re.compile("(a(b)?)((c)d)?").match("abce").lastindex
2
>>> re.compile("(a(b)?)((c)d)?").match("abce").groups()
('ab', 'b', None, None)

> It is unhelpful because one of the primary purposes of
> lastgroup is to find efficiently the entire match if you
> have a list of top-level alternatives

I don't understand this. If you want the entire match, just
use group 0. Did I misunderstand it? Can you show me some
example?

Can you show me how I've broken the Scanner?

If PyXML is broken, it trusted in an undocumented and broken
feature. Should we maintain it broken to avoid breaking PyXML?


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-04-19 21:25

Message:
Logged In: YES 
user_id=21627

Gustavo, I agree that the numbering of groups is and should
be by opening parentheses, i.e. that group 1 is <NCName>,
and group 2 is unnamed.

I also agree that *if* lastindex is 2, lastgroup should be None.

I still think this value is incorrect, though. It is
illogical, unhelpful, and incompatible with earlier
versions. lastindex should be 1, and lastgroup should be
"NCName".

It is illogical because group 1 ends *after* group 2 ends,
as the closing parenthesis of group 1 is after the closing
parenthesis of group 2.

It is unhelpful because one of the primary purposes of
lastgroup is to find efficiently the entire match if you
have a list of top-level alternatives, such as you do in a
scanner. With Python <2.3, you can put named alternatives
into a regex, and use lastindex to find out the alternative.
Indeed, this is what sre.Scanner does; I believe you have
broken that class as well.

It is incompatible because earlier Python versions behaved
differently. As a result of this change, PyXML does not work
with Python 2.3.

----------------------------------------------------------------------

Comment By: Gustavo Niemeyer (niemeyer)
Date: 2003-04-19 21:03

Message:
Logged In: YES 
user_id=7887

Martin, the lastgroup/lastindex handling was quite broken in
Python < 2.3. We can easily see this if testing your example
in the following way:

>>> import re
>>> exp = re.compile("(?P<NCName>[a-zA-Z_](\w|[_.-])*)")
>>> match = exp.match("namespace")
>>> match.groups()
('namespace', 'e')
>>> match.groupdict()
{'NCName': 'namespace'}

This has the same result in any python you execute. This
also demonstrates that the group numbering has always been
assigned by the opening parenthesis.

About the None result, that's also correct. In the example,
we notice that the second unnamed group is correctly
matching 'e'. Accordingly to the sre module documentation,
that's how lastgroups should behave:

lastgroup
    The name of the last matched capturing group, or None if
the group didn't have a name, or if no group was matched at all.

In the case above, the group didn't have a name. If we check
lastindex, we'll see it's correctly set to "2".

Greg, your example is correctly showing one of the bugs in
lastgroup/index handling in Python < 2.3. OTOH, the current
result of 2 is right, given the "count on open" rule, which
was always used. Here's an example in 2.3:

>>> re.match('((x))y(?:(a)b|ac)', 'xyac').groups()
('x', 'x', None)
>>> re.match('((x))y(?:(a)b|ac)', 'xyac').lastindex
2

(notice that groups always start in 1, as group 0 is the
"whole match" group)

Martin, if you agree, please close the bug. If you have any
doubts, it'll be a pleasure to explain.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-04-19 07:32

Message:
Logged In: YES 
user_id=21627

Assigning to Gustavo, since he wrote 2.84. Gustavo, can you
confirm that your change broke this feature? Can you also
agree that it should be fixed?



----------------------------------------------------------------------

Comment By: Greg Chapman (glchapman)
Date: 2003-02-05 01:56

Message:
Logged In: YES 
user_id=86307

I believe the discrepancy was deliberately introduced in revision 2.84 of _sre.c.  I agree with you that lastindex should return the the index of the matching group with the rightmost closing parenthesis (perhaps some elaboration in the docs is also in order).  If this is the correct interpretation, two places need to be patched: 1) the handling of SRE_OP_MARK needs to be reverted to the 2.22 code and 2) the code in the lastmark_restore function needs to be tweaked so that lastindex is not accidentally set to the last matched group entered.

Thinking further though, given a (contrived) pattern like this: 

  re.match('((x))y(?:(a)b|ac)', 'xyac')

what should lastindex be?  I assume 1, given the definition above (lastindex = matching group with rightmost close parens).  In 2.22 it is 3, since group 3 matched before the branch failed at the 'b'.  In 2.3a1 it is 2, since lastindex is restored (after the branch fails) using the saved lastmark.  Anyway, if it should be 1, then I think _sre.c will have to save lastindex as well as lastmark when processing the three opcodes which may end up calling lastmark_restore.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672491&group_id=5470


From noreply@sourceforge.net  Sat Apr 19 23:24:14 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 19 Apr 2003 15:24:14 -0700
Subject: [Python-bugs-list] [ python-Bugs-672491 ] 2.3a1 computes lastindex incorrectly
Message-ID: <E1970ko-0006jO-00@sc8-sf-web2.sourceforge.net>

Bugs item #672491, was opened at 2003-01-22 06:28
Message generated for change (Comment added) made by glchapman
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672491&group_id=5470

Category: Regular Expressions
Group: Python 2.3
Status: Open
Resolution: None
Priority: 6
Submitted By: Martin v. Löwis (loewis)
Assigned to: Martin v. Löwis (loewis)
Summary: 2.3a1 computes lastindex incorrectly

Initial Comment:
In Python 2.[012], the code

import re
exp = re.compile("(?P<NCName>[a-zA-Z_](\w|[_.-])*)")
print exp.match("namespace").lastgroup

prints "NCName". In Python 2.3a1, it prints "None". The
problem is that last index is 2, instead of 1, as it
should be.

----------------------------------------------------------------------

Comment By: Greg Chapman (glchapman)
Date: 2003-04-19 14:24

Message:
Logged In: YES 
user_id=86307

I'll just add my two cents here.  Gustavo, I think given your 
defintion of lastindex, there's no reason for the state to track a 
seperate lastindex field; the correct value could easily be 
determined by examining the mark array after matching is 
completed (in the process of initializing the Match object).  On 
the other hand, I don't think there is an obvious way of 
determining lastindex given the 2.22 definition without either 
examining the compiled pattern or tracking it as the pattern 
executes.

I also agree that it is an incompatible change.  Although the 
implementation was partly broken, I think the clear intent of the 
2.22 code was to report the matching group with the last closing 
parens.

FYI, I posted a patch here to revert back to the previous behavior:

  http://www.python.org/sf/712900

You two may want to look at it to see if it looks like it's on the right 
track.  Here is what a python with this patch reports on this 
example from Gustavo:

>>> re.compile("(a(b)?)((c)d)?").match("abce").lastindex
1

As you can see, it reports the correct value for lastindex given 
the 2.22 definition.  


----------------------------------------------------------------------

Comment By: Gustavo Niemeyer (niemeyer)
Date: 2003-04-19 14:02

Message:
Logged In: YES 
user_id=7887

Why do you think lastindex is incorrect? Isn't 2 the lastindex?

>>> import re
>>> exp = re.compile("(?P<NCName>[a-zA-Z_](\w|[_.-])*)")
>>> match = exp.match("namespace")
>>> match.group(0)
'namespace'
>>> match.group(1)
'namespace'
>>> match.group(2)
'e'

It works like this in all Python versions. Also, if you
agree that group 2 is unnamed, shouldn't  lastindex be 2? It
actually *is* the lastindex, as you see above.

It is incompatible with old versions because old versions
were broken, and didn't follow what was documented. It was
indeed a side effect of a bug. For example, is it logical
that if we remove the second group, lastindex is still 1 (in
Python 2.2)?

>>> exp = re.compile("(?P<NCName>[a-zA-Z_])")
>>> print exp.match("namespace").lastindex
1

> It is illogical because group 1 ends *after* group 2 ends,
> as the closing parenthesis of group 1 is after the closing
> parenthesis of group 2.

How this changes anything? As we agreed, groups are numbered
by the opening parenthesis.

Hummm.. perhaps you think that the old behavior was to show
what group had the last closing parenthesis? No.. that
wasn't the case either. Look at this example, in Python 2.2:

>>> re.compile("(a(b)?)((c)d)?").match("abce").lastindex
4
>>> re.compile("(a(b)?)((c)d)?").match("abce").groups()
('ab', 'b', None, None)

In Python 2.3:

>>> re.compile("(a(b)?)((c)d)?").match("abce").lastindex
2
>>> re.compile("(a(b)?)((c)d)?").match("abce").groups()
('ab', 'b', None, None)

> It is unhelpful because one of the primary purposes of
> lastgroup is to find efficiently the entire match if you
> have a list of top-level alternatives

I don't understand this. If you want the entire match, just
use group 0. Did I misunderstand it? Can you show me some
example?

Can you show me how I've broken the Scanner?

If PyXML is broken, it trusted in an undocumented and broken
feature. Should we maintain it broken to avoid breaking PyXML?


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-04-19 13:25

Message:
Logged In: YES 
user_id=21627

Gustavo, I agree that the numbering of groups is and should
be by opening parentheses, i.e. that group 1 is <NCName>,
and group 2 is unnamed.

I also agree that *if* lastindex is 2, lastgroup should be None.

I still think this value is incorrect, though. It is
illogical, unhelpful, and incompatible with earlier
versions. lastindex should be 1, and lastgroup should be
"NCName".

It is illogical because group 1 ends *after* group 2 ends,
as the closing parenthesis of group 1 is after the closing
parenthesis of group 2.

It is unhelpful because one of the primary purposes of
lastgroup is to find efficiently the entire match if you
have a list of top-level alternatives, such as you do in a
scanner. With Python <2.3, you can put named alternatives
into a regex, and use lastindex to find out the alternative.
Indeed, this is what sre.Scanner does; I believe you have
broken that class as well.

It is incompatible because earlier Python versions behaved
differently. As a result of this change, PyXML does not work
with Python 2.3.

----------------------------------------------------------------------

Comment By: Gustavo Niemeyer (niemeyer)
Date: 2003-04-19 13:03

Message:
Logged In: YES 
user_id=7887

Martin, the lastgroup/lastindex handling was quite broken in
Python < 2.3. We can easily see this if testing your example
in the following way:

>>> import re
>>> exp = re.compile("(?P<NCName>[a-zA-Z_](\w|[_.-])*)")
>>> match = exp.match("namespace")
>>> match.groups()
('namespace', 'e')
>>> match.groupdict()
{'NCName': 'namespace'}

This has the same result in any python you execute. This
also demonstrates that the group numbering has always been
assigned by the opening parenthesis.

About the None result, that's also correct. In the example,
we notice that the second unnamed group is correctly
matching 'e'. Accordingly to the sre module documentation,
that's how lastgroups should behave:

lastgroup
    The name of the last matched capturing group, or None if
the group didn't have a name, or if no group was matched at all.

In the case above, the group didn't have a name. If we check
lastindex, we'll see it's correctly set to "2".

Greg, your example is correctly showing one of the bugs in
lastgroup/index handling in Python < 2.3. OTOH, the current
result of 2 is right, given the "count on open" rule, which
was always used. Here's an example in 2.3:

>>> re.match('((x))y(?:(a)b|ac)', 'xyac').groups()
('x', 'x', None)
>>> re.match('((x))y(?:(a)b|ac)', 'xyac').lastindex
2

(notice that groups always start in 1, as group 0 is the
"whole match" group)

Martin, if you agree, please close the bug. If you have any
doubts, it'll be a pleasure to explain.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-04-18 23:32

Message:
Logged In: YES 
user_id=21627

Assigning to Gustavo, since he wrote 2.84. Gustavo, can you
confirm that your change broke this feature? Can you also
agree that it should be fixed?



----------------------------------------------------------------------

Comment By: Greg Chapman (glchapman)
Date: 2003-02-04 16:56

Message:
Logged In: YES 
user_id=86307

I believe the discrepancy was deliberately introduced in revision 2.84 of _sre.c.  I agree with you that lastindex should return the the index of the matching group with the rightmost closing parenthesis (perhaps some elaboration in the docs is also in order).  If this is the correct interpretation, two places need to be patched: 1) the handling of SRE_OP_MARK needs to be reverted to the 2.22 code and 2) the code in the lastmark_restore function needs to be tweaked so that lastindex is not accidentally set to the last matched group entered.

Thinking further though, given a (contrived) pattern like this: 

  re.match('((x))y(?:(a)b|ac)', 'xyac')

what should lastindex be?  I assume 1, given the definition above (lastindex = matching group with rightmost close parens).  In 2.22 it is 3, since group 3 matched before the branch failed at the 'b'.  In 2.3a1 it is 2, since lastindex is restored (after the branch fails) using the saved lastmark.  Anyway, if it should be 1, then I think _sre.c will have to save lastindex as well as lastmark when processing the three opcodes which may end up calling lastmark_restore.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672491&group_id=5470


From noreply@sourceforge.net  Sun Apr 20 00:26:29 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 19 Apr 2003 16:26:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-672491 ] 2.3a1 computes lastindex incorrectly
Message-ID: <E1971j3-0001XI-00@sc8-sf-web3.sourceforge.net>

Bugs item #672491, was opened at 2003-01-22 15:28
Message generated for change (Comment added) made by niemeyer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672491&group_id=5470

Category: Regular Expressions
Group: Python 2.3
Status: Open
Resolution: None
Priority: 6
Submitted By: Martin v. Löwis (loewis)
Assigned to: Martin v. Löwis (loewis)
Summary: 2.3a1 computes lastindex incorrectly

Initial Comment:
In Python 2.[012], the code

import re
exp = re.compile("(?P<NCName>[a-zA-Z_](\w|[_.-])*)")
print exp.match("namespace").lastgroup

prints "NCName". In Python 2.3a1, it prints "None". The
problem is that last index is 2, instead of 1, as it
should be.

----------------------------------------------------------------------

>Comment By: Gustavo Niemeyer (niemeyer)
Date: 2003-04-19 23:26

Message:
Logged In: YES 
user_id=7887

> As you can see, it reports the correct value for lastindex
given
> the 2.22 definition.

The problem here is defining what's the 2.2 definition.

I've checked with other examples, and it looks like your
definition is correct in all cases where the shown bug is
not acting.

If that's the case, the documentation is *very* misleading,
and should be fixed.


----------------------------------------------------------------------

Comment By: Greg Chapman (glchapman)
Date: 2003-04-19 22:24

Message:
Logged In: YES 
user_id=86307

I'll just add my two cents here.  Gustavo, I think given your 
defintion of lastindex, there's no reason for the state to track a 
seperate lastindex field; the correct value could easily be 
determined by examining the mark array after matching is 
completed (in the process of initializing the Match object).  On 
the other hand, I don't think there is an obvious way of 
determining lastindex given the 2.22 definition without either 
examining the compiled pattern or tracking it as the pattern 
executes.

I also agree that it is an incompatible change.  Although the 
implementation was partly broken, I think the clear intent of the 
2.22 code was to report the matching group with the last closing 
parens.

FYI, I posted a patch here to revert back to the previous behavior:

  http://www.python.org/sf/712900

You two may want to look at it to see if it looks like it's on the right 
track.  Here is what a python with this patch reports on this 
example from Gustavo:

>>> re.compile("(a(b)?)((c)d)?").match("abce").lastindex
1

As you can see, it reports the correct value for lastindex given 
the 2.22 definition.  


----------------------------------------------------------------------

Comment By: Gustavo Niemeyer (niemeyer)
Date: 2003-04-19 22:02

Message:
Logged In: YES 
user_id=7887

Why do you think lastindex is incorrect? Isn't 2 the lastindex?

>>> import re
>>> exp = re.compile("(?P<NCName>[a-zA-Z_](\w|[_.-])*)")
>>> match = exp.match("namespace")
>>> match.group(0)
'namespace'
>>> match.group(1)
'namespace'
>>> match.group(2)
'e'

It works like this in all Python versions. Also, if you
agree that group 2 is unnamed, shouldn't  lastindex be 2? It
actually *is* the lastindex, as you see above.

It is incompatible with old versions because old versions
were broken, and didn't follow what was documented. It was
indeed a side effect of a bug. For example, is it logical
that if we remove the second group, lastindex is still 1 (in
Python 2.2)?

>>> exp = re.compile("(?P<NCName>[a-zA-Z_])")
>>> print exp.match("namespace").lastindex
1

> It is illogical because group 1 ends *after* group 2 ends,
> as the closing parenthesis of group 1 is after the closing
> parenthesis of group 2.

How this changes anything? As we agreed, groups are numbered
by the opening parenthesis.

Hummm.. perhaps you think that the old behavior was to show
what group had the last closing parenthesis? No.. that
wasn't the case either. Look at this example, in Python 2.2:

>>> re.compile("(a(b)?)((c)d)?").match("abce").lastindex
4
>>> re.compile("(a(b)?)((c)d)?").match("abce").groups()
('ab', 'b', None, None)

In Python 2.3:

>>> re.compile("(a(b)?)((c)d)?").match("abce").lastindex
2
>>> re.compile("(a(b)?)((c)d)?").match("abce").groups()
('ab', 'b', None, None)

> It is unhelpful because one of the primary purposes of
> lastgroup is to find efficiently the entire match if you
> have a list of top-level alternatives

I don't understand this. If you want the entire match, just
use group 0. Did I misunderstand it? Can you show me some
example?

Can you show me how I've broken the Scanner?

If PyXML is broken, it trusted in an undocumented and broken
feature. Should we maintain it broken to avoid breaking PyXML?


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-04-19 21:25

Message:
Logged In: YES 
user_id=21627

Gustavo, I agree that the numbering of groups is and should
be by opening parentheses, i.e. that group 1 is <NCName>,
and group 2 is unnamed.

I also agree that *if* lastindex is 2, lastgroup should be None.

I still think this value is incorrect, though. It is
illogical, unhelpful, and incompatible with earlier
versions. lastindex should be 1, and lastgroup should be
"NCName".

It is illogical because group 1 ends *after* group 2 ends,
as the closing parenthesis of group 1 is after the closing
parenthesis of group 2.

It is unhelpful because one of the primary purposes of
lastgroup is to find efficiently the entire match if you
have a list of top-level alternatives, such as you do in a
scanner. With Python <2.3, you can put named alternatives
into a regex, and use lastindex to find out the alternative.
Indeed, this is what sre.Scanner does; I believe you have
broken that class as well.

It is incompatible because earlier Python versions behaved
differently. As a result of this change, PyXML does not work
with Python 2.3.

----------------------------------------------------------------------

Comment By: Gustavo Niemeyer (niemeyer)
Date: 2003-04-19 21:03

Message:
Logged In: YES 
user_id=7887

Martin, the lastgroup/lastindex handling was quite broken in
Python < 2.3. We can easily see this if testing your example
in the following way:

>>> import re
>>> exp = re.compile("(?P<NCName>[a-zA-Z_](\w|[_.-])*)")
>>> match = exp.match("namespace")
>>> match.groups()
('namespace', 'e')
>>> match.groupdict()
{'NCName': 'namespace'}

This has the same result in any python you execute. This
also demonstrates that the group numbering has always been
assigned by the opening parenthesis.

About the None result, that's also correct. In the example,
we notice that the second unnamed group is correctly
matching 'e'. Accordingly to the sre module documentation,
that's how lastgroups should behave:

lastgroup
    The name of the last matched capturing group, or None if
the group didn't have a name, or if no group was matched at all.

In the case above, the group didn't have a name. If we check
lastindex, we'll see it's correctly set to "2".

Greg, your example is correctly showing one of the bugs in
lastgroup/index handling in Python < 2.3. OTOH, the current
result of 2 is right, given the "count on open" rule, which
was always used. Here's an example in 2.3:

>>> re.match('((x))y(?:(a)b|ac)', 'xyac').groups()
('x', 'x', None)
>>> re.match('((x))y(?:(a)b|ac)', 'xyac').lastindex
2

(notice that groups always start in 1, as group 0 is the
"whole match" group)

Martin, if you agree, please close the bug. If you have any
doubts, it'll be a pleasure to explain.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-04-19 07:32

Message:
Logged In: YES 
user_id=21627

Assigning to Gustavo, since he wrote 2.84. Gustavo, can you
confirm that your change broke this feature? Can you also
agree that it should be fixed?



----------------------------------------------------------------------

Comment By: Greg Chapman (glchapman)
Date: 2003-02-05 01:56

Message:
Logged In: YES 
user_id=86307

I believe the discrepancy was deliberately introduced in revision 2.84 of _sre.c.  I agree with you that lastindex should return the the index of the matching group with the rightmost closing parenthesis (perhaps some elaboration in the docs is also in order).  If this is the correct interpretation, two places need to be patched: 1) the handling of SRE_OP_MARK needs to be reverted to the 2.22 code and 2) the code in the lastmark_restore function needs to be tweaked so that lastindex is not accidentally set to the last matched group entered.

Thinking further though, given a (contrived) pattern like this: 

  re.match('((x))y(?:(a)b|ac)', 'xyac')

what should lastindex be?  I assume 1, given the definition above (lastindex = matching group with rightmost close parens).  In 2.22 it is 3, since group 3 matched before the branch failed at the 'b'.  In 2.3a1 it is 2, since lastindex is restored (after the branch fails) using the saved lastmark.  Anyway, if it should be 1, then I think _sre.c will have to save lastindex as well as lastmark when processing the three opcodes which may end up calling lastmark_restore.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672491&group_id=5470


From noreply@sourceforge.net  Sun Apr 20 00:33:44 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 19 Apr 2003 16:33:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-672491 ] 2.3a1 computes lastindex incorrectly
Message-ID: <E1971q4-0004ud-00@sc8-sf-web4.sourceforge.net>

Bugs item #672491, was opened at 2003-01-22 15:28
Message generated for change (Comment added) made by niemeyer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672491&group_id=5470

Category: Regular Expressions
Group: Python 2.3
Status: Open
Resolution: None
Priority: 6
Submitted By: Martin v. Löwis (loewis)
Assigned to: Martin v. Löwis (loewis)
Summary: 2.3a1 computes lastindex incorrectly

Initial Comment:
In Python 2.[012], the code

import re
exp = re.compile("(?P<NCName>[a-zA-Z_](\w|[_.-])*)")
print exp.match("namespace").lastgroup

prints "NCName". In Python 2.3a1, it prints "None". The
problem is that last index is 2, instead of 1, as it
should be.

----------------------------------------------------------------------

>Comment By: Gustavo Niemeyer (niemeyer)
Date: 2003-04-19 23:33

Message:
Logged In: YES 
user_id=7887

Concluding:

- I agree that my implementation is uncompliant with the
previous behavior, and I think it should be modified to
behave like before.

- There was a bug which was fixed by my implementation, and
should be fixed when porting to the old behavior.

- The documentation is very misleading, and seems closer to
my implementation than the old behavior. This should be fixed.


----------------------------------------------------------------------

Comment By: Gustavo Niemeyer (niemeyer)
Date: 2003-04-19 23:26

Message:
Logged In: YES 
user_id=7887

> As you can see, it reports the correct value for lastindex
given
> the 2.22 definition.

The problem here is defining what's the 2.2 definition.

I've checked with other examples, and it looks like your
definition is correct in all cases where the shown bug is
not acting.

If that's the case, the documentation is *very* misleading,
and should be fixed.


----------------------------------------------------------------------

Comment By: Greg Chapman (glchapman)
Date: 2003-04-19 22:24

Message:
Logged In: YES 
user_id=86307

I'll just add my two cents here.  Gustavo, I think given your 
defintion of lastindex, there's no reason for the state to track a 
seperate lastindex field; the correct value could easily be 
determined by examining the mark array after matching is 
completed (in the process of initializing the Match object).  On 
the other hand, I don't think there is an obvious way of 
determining lastindex given the 2.22 definition without either 
examining the compiled pattern or tracking it as the pattern 
executes.

I also agree that it is an incompatible change.  Although the 
implementation was partly broken, I think the clear intent of the 
2.22 code was to report the matching group with the last closing 
parens.

FYI, I posted a patch here to revert back to the previous behavior:

  http://www.python.org/sf/712900

You two may want to look at it to see if it looks like it's on the right 
track.  Here is what a python with this patch reports on this 
example from Gustavo:

>>> re.compile("(a(b)?)((c)d)?").match("abce").lastindex
1

As you can see, it reports the correct value for lastindex given 
the 2.22 definition.  


----------------------------------------------------------------------

Comment By: Gustavo Niemeyer (niemeyer)
Date: 2003-04-19 22:02

Message:
Logged In: YES 
user_id=7887

Why do you think lastindex is incorrect? Isn't 2 the lastindex?

>>> import re
>>> exp = re.compile("(?P<NCName>[a-zA-Z_](\w|[_.-])*)")
>>> match = exp.match("namespace")
>>> match.group(0)
'namespace'
>>> match.group(1)
'namespace'
>>> match.group(2)
'e'

It works like this in all Python versions. Also, if you
agree that group 2 is unnamed, shouldn't  lastindex be 2? It
actually *is* the lastindex, as you see above.

It is incompatible with old versions because old versions
were broken, and didn't follow what was documented. It was
indeed a side effect of a bug. For example, is it logical
that if we remove the second group, lastindex is still 1 (in
Python 2.2)?

>>> exp = re.compile("(?P<NCName>[a-zA-Z_])")
>>> print exp.match("namespace").lastindex
1

> It is illogical because group 1 ends *after* group 2 ends,
> as the closing parenthesis of group 1 is after the closing
> parenthesis of group 2.

How this changes anything? As we agreed, groups are numbered
by the opening parenthesis.

Hummm.. perhaps you think that the old behavior was to show
what group had the last closing parenthesis? No.. that
wasn't the case either. Look at this example, in Python 2.2:

>>> re.compile("(a(b)?)((c)d)?").match("abce").lastindex
4
>>> re.compile("(a(b)?)((c)d)?").match("abce").groups()
('ab', 'b', None, None)

In Python 2.3:

>>> re.compile("(a(b)?)((c)d)?").match("abce").lastindex
2
>>> re.compile("(a(b)?)((c)d)?").match("abce").groups()
('ab', 'b', None, None)

> It is unhelpful because one of the primary purposes of
> lastgroup is to find efficiently the entire match if you
> have a list of top-level alternatives

I don't understand this. If you want the entire match, just
use group 0. Did I misunderstand it? Can you show me some
example?

Can you show me how I've broken the Scanner?

If PyXML is broken, it trusted in an undocumented and broken
feature. Should we maintain it broken to avoid breaking PyXML?


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-04-19 21:25

Message:
Logged In: YES 
user_id=21627

Gustavo, I agree that the numbering of groups is and should
be by opening parentheses, i.e. that group 1 is <NCName>,
and group 2 is unnamed.

I also agree that *if* lastindex is 2, lastgroup should be None.

I still think this value is incorrect, though. It is
illogical, unhelpful, and incompatible with earlier
versions. lastindex should be 1, and lastgroup should be
"NCName".

It is illogical because group 1 ends *after* group 2 ends,
as the closing parenthesis of group 1 is after the closing
parenthesis of group 2.

It is unhelpful because one of the primary purposes of
lastgroup is to find efficiently the entire match if you
have a list of top-level alternatives, such as you do in a
scanner. With Python <2.3, you can put named alternatives
into a regex, and use lastindex to find out the alternative.
Indeed, this is what sre.Scanner does; I believe you have
broken that class as well.

It is incompatible because earlier Python versions behaved
differently. As a result of this change, PyXML does not work
with Python 2.3.

----------------------------------------------------------------------

Comment By: Gustavo Niemeyer (niemeyer)
Date: 2003-04-19 21:03

Message:
Logged In: YES 
user_id=7887

Martin, the lastgroup/lastindex handling was quite broken in
Python < 2.3. We can easily see this if testing your example
in the following way:

>>> import re
>>> exp = re.compile("(?P<NCName>[a-zA-Z_](\w|[_.-])*)")
>>> match = exp.match("namespace")
>>> match.groups()
('namespace', 'e')
>>> match.groupdict()
{'NCName': 'namespace'}

This has the same result in any python you execute. This
also demonstrates that the group numbering has always been
assigned by the opening parenthesis.

About the None result, that's also correct. In the example,
we notice that the second unnamed group is correctly
matching 'e'. Accordingly to the sre module documentation,
that's how lastgroups should behave:

lastgroup
    The name of the last matched capturing group, or None if
the group didn't have a name, or if no group was matched at all.

In the case above, the group didn't have a name. If we check
lastindex, we'll see it's correctly set to "2".

Greg, your example is correctly showing one of the bugs in
lastgroup/index handling in Python < 2.3. OTOH, the current
result of 2 is right, given the "count on open" rule, which
was always used. Here's an example in 2.3:

>>> re.match('((x))y(?:(a)b|ac)', 'xyac').groups()
('x', 'x', None)
>>> re.match('((x))y(?:(a)b|ac)', 'xyac').lastindex
2

(notice that groups always start in 1, as group 0 is the
"whole match" group)

Martin, if you agree, please close the bug. If you have any
doubts, it'll be a pleasure to explain.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-04-19 07:32

Message:
Logged In: YES 
user_id=21627

Assigning to Gustavo, since he wrote 2.84. Gustavo, can you
confirm that your change broke this feature? Can you also
agree that it should be fixed?



----------------------------------------------------------------------

Comment By: Greg Chapman (glchapman)
Date: 2003-02-05 01:56

Message:
Logged In: YES 
user_id=86307

I believe the discrepancy was deliberately introduced in revision 2.84 of _sre.c.  I agree with you that lastindex should return the the index of the matching group with the rightmost closing parenthesis (perhaps some elaboration in the docs is also in order).  If this is the correct interpretation, two places need to be patched: 1) the handling of SRE_OP_MARK needs to be reverted to the 2.22 code and 2) the code in the lastmark_restore function needs to be tweaked so that lastindex is not accidentally set to the last matched group entered.

Thinking further though, given a (contrived) pattern like this: 

  re.match('((x))y(?:(a)b|ac)', 'xyac')

what should lastindex be?  I assume 1, given the definition above (lastindex = matching group with rightmost close parens).  In 2.22 it is 3, since group 3 matched before the branch failed at the 'b'.  In 2.3a1 it is 2, since lastindex is restored (after the branch fails) using the saved lastmark.  Anyway, if it should be 1, then I think _sre.c will have to save lastindex as well as lastmark when processing the three opcodes which may end up calling lastmark_restore.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672491&group_id=5470


From noreply@sourceforge.net  Sun Apr 20 01:59:48 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 19 Apr 2003 17:59:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-672491 ] 2.3a1 computes lastindex incorrectly
Message-ID: <E1973BM-00033Z-00@sc8-sf-web2.sourceforge.net>

Bugs item #672491, was opened at 2003-01-22 15:28
Message generated for change (Comment added) made by niemeyer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672491&group_id=5470

Category: Regular Expressions
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 6
Submitted By: Martin v. Löwis (loewis)
>Assigned to: Gustavo Niemeyer (niemeyer)
Summary: 2.3a1 computes lastindex incorrectly

Initial Comment:
In Python 2.[012], the code

import re
exp = re.compile("(?P<NCName>[a-zA-Z_](\w|[_.-])*)")
print exp.match("namespace").lastgroup

prints "NCName". In Python 2.3a1, it prints "None". The
problem is that last index is 2, instead of 1, as it
should be.

----------------------------------------------------------------------

>Comment By: Gustavo Niemeyer (niemeyer)
Date: 2003-04-20 00:59

Message:
Logged In: YES 
user_id=7887

I backed out the changes made in 2.84 which changed the
behavior, and maintained the changes which fixed the bug.
Applied as:

Modules/_sre.c: 2.90

I'm also including some examples in the lastindex
documentation, explaining how it works.

Sorry about the trouble this may have caused.


----------------------------------------------------------------------

Comment By: Gustavo Niemeyer (niemeyer)
Date: 2003-04-19 23:33

Message:
Logged In: YES 
user_id=7887

Concluding:

- I agree that my implementation is uncompliant with the
previous behavior, and I think it should be modified to
behave like before.

- There was a bug which was fixed by my implementation, and
should be fixed when porting to the old behavior.

- The documentation is very misleading, and seems closer to
my implementation than the old behavior. This should be fixed.


----------------------------------------------------------------------

Comment By: Gustavo Niemeyer (niemeyer)
Date: 2003-04-19 23:26

Message:
Logged In: YES 
user_id=7887

> As you can see, it reports the correct value for lastindex
given
> the 2.22 definition.

The problem here is defining what's the 2.2 definition.

I've checked with other examples, and it looks like your
definition is correct in all cases where the shown bug is
not acting.

If that's the case, the documentation is *very* misleading,
and should be fixed.


----------------------------------------------------------------------

Comment By: Greg Chapman (glchapman)
Date: 2003-04-19 22:24

Message:
Logged In: YES 
user_id=86307

I'll just add my two cents here.  Gustavo, I think given your 
defintion of lastindex, there's no reason for the state to track a 
seperate lastindex field; the correct value could easily be 
determined by examining the mark array after matching is 
completed (in the process of initializing the Match object).  On 
the other hand, I don't think there is an obvious way of 
determining lastindex given the 2.22 definition without either 
examining the compiled pattern or tracking it as the pattern 
executes.

I also agree that it is an incompatible change.  Although the 
implementation was partly broken, I think the clear intent of the 
2.22 code was to report the matching group with the last closing 
parens.

FYI, I posted a patch here to revert back to the previous behavior:

  http://www.python.org/sf/712900

You two may want to look at it to see if it looks like it's on the right 
track.  Here is what a python with this patch reports on this 
example from Gustavo:

>>> re.compile("(a(b)?)((c)d)?").match("abce").lastindex
1

As you can see, it reports the correct value for lastindex given 
the 2.22 definition.  


----------------------------------------------------------------------

Comment By: Gustavo Niemeyer (niemeyer)
Date: 2003-04-19 22:02

Message:
Logged In: YES 
user_id=7887

Why do you think lastindex is incorrect? Isn't 2 the lastindex?

>>> import re
>>> exp = re.compile("(?P<NCName>[a-zA-Z_](\w|[_.-])*)")
>>> match = exp.match("namespace")
>>> match.group(0)
'namespace'
>>> match.group(1)
'namespace'
>>> match.group(2)
'e'

It works like this in all Python versions. Also, if you
agree that group 2 is unnamed, shouldn't  lastindex be 2? It
actually *is* the lastindex, as you see above.

It is incompatible with old versions because old versions
were broken, and didn't follow what was documented. It was
indeed a side effect of a bug. For example, is it logical
that if we remove the second group, lastindex is still 1 (in
Python 2.2)?

>>> exp = re.compile("(?P<NCName>[a-zA-Z_])")
>>> print exp.match("namespace").lastindex
1

> It is illogical because group 1 ends *after* group 2 ends,
> as the closing parenthesis of group 1 is after the closing
> parenthesis of group 2.

How this changes anything? As we agreed, groups are numbered
by the opening parenthesis.

Hummm.. perhaps you think that the old behavior was to show
what group had the last closing parenthesis? No.. that
wasn't the case either. Look at this example, in Python 2.2:

>>> re.compile("(a(b)?)((c)d)?").match("abce").lastindex
4
>>> re.compile("(a(b)?)((c)d)?").match("abce").groups()
('ab', 'b', None, None)

In Python 2.3:

>>> re.compile("(a(b)?)((c)d)?").match("abce").lastindex
2
>>> re.compile("(a(b)?)((c)d)?").match("abce").groups()
('ab', 'b', None, None)

> It is unhelpful because one of the primary purposes of
> lastgroup is to find efficiently the entire match if you
> have a list of top-level alternatives

I don't understand this. If you want the entire match, just
use group 0. Did I misunderstand it? Can you show me some
example?

Can you show me how I've broken the Scanner?

If PyXML is broken, it trusted in an undocumented and broken
feature. Should we maintain it broken to avoid breaking PyXML?


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-04-19 21:25

Message:
Logged In: YES 
user_id=21627

Gustavo, I agree that the numbering of groups is and should
be by opening parentheses, i.e. that group 1 is <NCName>,
and group 2 is unnamed.

I also agree that *if* lastindex is 2, lastgroup should be None.

I still think this value is incorrect, though. It is
illogical, unhelpful, and incompatible with earlier
versions. lastindex should be 1, and lastgroup should be
"NCName".

It is illogical because group 1 ends *after* group 2 ends,
as the closing parenthesis of group 1 is after the closing
parenthesis of group 2.

It is unhelpful because one of the primary purposes of
lastgroup is to find efficiently the entire match if you
have a list of top-level alternatives, such as you do in a
scanner. With Python <2.3, you can put named alternatives
into a regex, and use lastindex to find out the alternative.
Indeed, this is what sre.Scanner does; I believe you have
broken that class as well.

It is incompatible because earlier Python versions behaved
differently. As a result of this change, PyXML does not work
with Python 2.3.

----------------------------------------------------------------------

Comment By: Gustavo Niemeyer (niemeyer)
Date: 2003-04-19 21:03

Message:
Logged In: YES 
user_id=7887

Martin, the lastgroup/lastindex handling was quite broken in
Python < 2.3. We can easily see this if testing your example
in the following way:

>>> import re
>>> exp = re.compile("(?P<NCName>[a-zA-Z_](\w|[_.-])*)")
>>> match = exp.match("namespace")
>>> match.groups()
('namespace', 'e')
>>> match.groupdict()
{'NCName': 'namespace'}

This has the same result in any python you execute. This
also demonstrates that the group numbering has always been
assigned by the opening parenthesis.

About the None result, that's also correct. In the example,
we notice that the second unnamed group is correctly
matching 'e'. Accordingly to the sre module documentation,
that's how lastgroups should behave:

lastgroup
    The name of the last matched capturing group, or None if
the group didn't have a name, or if no group was matched at all.

In the case above, the group didn't have a name. If we check
lastindex, we'll see it's correctly set to "2".

Greg, your example is correctly showing one of the bugs in
lastgroup/index handling in Python < 2.3. OTOH, the current
result of 2 is right, given the "count on open" rule, which
was always used. Here's an example in 2.3:

>>> re.match('((x))y(?:(a)b|ac)', 'xyac').groups()
('x', 'x', None)
>>> re.match('((x))y(?:(a)b|ac)', 'xyac').lastindex
2

(notice that groups always start in 1, as group 0 is the
"whole match" group)

Martin, if you agree, please close the bug. If you have any
doubts, it'll be a pleasure to explain.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-04-19 07:32

Message:
Logged In: YES 
user_id=21627

Assigning to Gustavo, since he wrote 2.84. Gustavo, can you
confirm that your change broke this feature? Can you also
agree that it should be fixed?



----------------------------------------------------------------------

Comment By: Greg Chapman (glchapman)
Date: 2003-02-05 01:56

Message:
Logged In: YES 
user_id=86307

I believe the discrepancy was deliberately introduced in revision 2.84 of _sre.c.  I agree with you that lastindex should return the the index of the matching group with the rightmost closing parenthesis (perhaps some elaboration in the docs is also in order).  If this is the correct interpretation, two places need to be patched: 1) the handling of SRE_OP_MARK needs to be reverted to the 2.22 code and 2) the code in the lastmark_restore function needs to be tweaked so that lastindex is not accidentally set to the last matched group entered.

Thinking further though, given a (contrived) pattern like this: 

  re.match('((x))y(?:(a)b|ac)', 'xyac')

what should lastindex be?  I assume 1, given the definition above (lastindex = matching group with rightmost close parens).  In 2.22 it is 3, since group 3 matched before the branch failed at the 'b'.  In 2.3a1 it is 2, since lastindex is restored (after the branch fails) using the saved lastmark.  Anyway, if it should be 1, then I think _sre.c will have to save lastindex as well as lastmark when processing the three opcodes which may end up calling lastmark_restore.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672491&group_id=5470


From noreply@sourceforge.net  Sun Apr 20 02:52:22 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 19 Apr 2003 18:52:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-721402 ] Random on PPC is outside acceptable range.
Message-ID: <E19740E-0002hF-00@sc8-sf-web1.sourceforge.net>

Bugs item #721402, was opened at 2003-04-14 15:43
Message generated for change (Comment added) made by memoryhole
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=721402&group_id=5470

Category: Extension Modules
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Kyle Wheeler (memoryhole)
Assigned to: Nobody/Anonymous (nobody)
Summary: Random on PPC is outside acceptable range.

Initial Comment:
On LinuxPPC, with gcc 2.96, python's (2.2.2) random function is outside the acceptable range. For example:

>>> import random
>>> print random.random()
1.35933812391

This random function, I believe, is supposed to produce numbers between 0 and 1.

----------------------------------------------------------------------

>Comment By: Kyle Wheeler (memoryhole)
Date: 2003-04-19 20:52

Message:
Logged In: YES 
user_id=17596

I'm guessing it's the compiler in some very strange way. I
recompiled python without optimization, and the problem went
away.

The optimization problem, however, must be particular to
whatever the optimization situation is in floatobject.c,
because a very simple C program using fmod() doesn't report
incorrect values no matter how much optimization I tell gcc
to perform.

Thanks for helping me! (hopefully, in the not entirely
distant future, I'll upgrade to gcc 3.2 or so, and will be
able to safely recompile python with optimization)

~Kyle

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-04-14 16:35

Message:
Logged In: YES 
user_id=31435

Heh.  Sorry about the "1.,0" -- that was a typo.  "1.0" was 
intended.

For the rest, floating mod is clearly broken in this Python, 
and that's why random() is goofy (the last step in random() is 
a fload mod).   It's not broken on any platform I have, so I 
can't be much help.

First thing to try is to recompile Python with optimizations 
disabled.  If it still fails, step thru floatobject.c's float_rem 
function in a debugger and see where it's getting an insane 
result.

If you know how to write C code, it could be that printing the 
result of C

#import <math.h>
double x = fmod(1.35933812391, 1.0);

will show a bug instantly (in which case your C libm has the 
bug).

----------------------------------------------------------------------

Comment By: Kyle Wheeler (memoryhole)
Date: 2003-04-14 16:19

Message:
Logged In: YES 
user_id=17596

Python 2.2.2 (#1, Apr 13 2003, 16:19:28) 
[GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-110)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import random
>>> print 1.35933812391 % 1,.0
1.35933812391 0.0
>>> print 1.35933812391 % 1.0
1.35933812391
>>> print 4%2                
0
>>> print 1.3%2
3.3

Any ideas?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-04-14 16:14

Message:
Logged In: YES 
user_id=31435

What does the following statement print under this Python:

print 1.35933812391 % 1,.0

?

Note that there's almost no chance this is a bug in Python 
(the implementation of random() hasn't changed in about 10 
years).  There's a good chance it's a bug in the specific  C 
compiler or C library release you're using.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=721402&group_id=5470


From noreply@sourceforge.net  Sun Apr 20 03:38:38 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 19 Apr 2003 19:38:38 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-724459 ] Add documentation about line endings in email messages.
Message-ID: <E1974j0-0006hZ-00@sc8-sf-web3.sourceforge.net>

Feature Requests item #724459, was opened at 2003-04-20 14:38
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=724459&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tony Meyer (anadelonbrin)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add documentation about line endings in email messages.

Initial Comment:
This follows from recent discussion on the spambayes 
mailing list (some of which was also on the mimelib-
devel list) about what character(s) should be used for 
line endings internally and when transmitted.  There is a 
consensus (I think) that the platform/language specific 
character(s) should be used internally, but any module 
that transmits the date should be responsible for 
converting this to the appropriate character(s) - for 
RFC2822/822 this means that all line endings *must* be 
\r\n.

smtplib currently does this, but imaplib doesn't (a bug 
has been posted about this).

To help people understand what the rules are, it would 
be nice if documentation could be added about this - 
especially for anyone developing a new module (like 
smtplib or imaplib) that transmits the data.  The 
following is from a post to the spambayes list from Paul 
Moore, which sounds good to me.  (Where it gets added 
is your problem ;)

"As a general set of rules (which aren't stated anywhere) 
it's probably fair to say that:

   1. Modules which manipulate internet-format data (like 
email) should work with line terminators of \n internally 
(just like Python strings do).
   2. Modules which transmit files across TCP/IP should 
canonicalise any form of line ending to CRLF.
   3. Modules which present data *received* from TCP/IP 
(like POP3) should convert data to \n line endings before 
returning it to the program.
   4. Reading from the filesystem should be handled like 
(3), and should support files opened in text or binary 
modes (or universal newline mode in Python 2.3)
   5. Writing to the filesystem should be done by 
assuming the data uses \n internally (the above rules 
make this true) and writing either in binary format (which 
leaves LFs in the files, ie Unix format) or in text format 
(which converts the \n characters to the platform native 
newline sequence)."

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=724459&group_id=5470


From noreply@sourceforge.net  Sun Apr 20 03:47:49 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 19 Apr 2003 19:47:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-721402 ] Random on PPC is outside acceptable range.
Message-ID: <E1974rt-0004Et-00@sc8-sf-web1.sourceforge.net>

Bugs item #721402, was opened at 2003-04-14 16:43
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=721402&group_id=5470

Category: Extension Modules
>Group: 3rd Party
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Kyle Wheeler (memoryhole)
>Assigned to: Tim Peters (tim_one)
Summary: Random on PPC is outside acceptable range.

Initial Comment:
On LinuxPPC, with gcc 2.96, python's (2.2.2) random function is outside the acceptable range. For example:

>>> import random
>>> print random.random()
1.35933812391

This random function, I believe, is supposed to produce numbers between 0 and 1.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2003-04-19 22:47

Message:
Logged In: YES 
user_id=31435

Hmm!  You could try disabling optimization *only* for 
floatobject.c.  Compiler optimization bugs are usually shy, 
and sometimes specific to one block of code that manages 
to trigger an untested endcase in the optimizer.  I wouldn't 
worry that optimization is generally unsafe.

The CONVERT_TO_DOUBLE macro in floatobject.c contains 
some pretty excruciating logic, and my bet is that the 
compiler is screwing up there.  float_rem() doesn't really do 
anything else before calling fmod().  You could play with 
that in a debugger or via inserting printfs.  If you can get a 
small failing test case out of it, I'm sure the compiler 
authors would appreciate seeing it.

Closing as 3rdParty, since there's no evidence of a Python 
bug here.

----------------------------------------------------------------------

Comment By: Kyle Wheeler (memoryhole)
Date: 2003-04-19 21:52

Message:
Logged In: YES 
user_id=17596

I'm guessing it's the compiler in some very strange way. I
recompiled python without optimization, and the problem went
away.

The optimization problem, however, must be particular to
whatever the optimization situation is in floatobject.c,
because a very simple C program using fmod() doesn't report
incorrect values no matter how much optimization I tell gcc
to perform.

Thanks for helping me! (hopefully, in the not entirely
distant future, I'll upgrade to gcc 3.2 or so, and will be
able to safely recompile python with optimization)

~Kyle

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-04-14 17:35

Message:
Logged In: YES 
user_id=31435

Heh.  Sorry about the "1.,0" -- that was a typo.  "1.0" was 
intended.

For the rest, floating mod is clearly broken in this Python, 
and that's why random() is goofy (the last step in random() is 
a fload mod).   It's not broken on any platform I have, so I 
can't be much help.

First thing to try is to recompile Python with optimizations 
disabled.  If it still fails, step thru floatobject.c's float_rem 
function in a debugger and see where it's getting an insane 
result.

If you know how to write C code, it could be that printing the 
result of C

#import <math.h>
double x = fmod(1.35933812391, 1.0);

will show a bug instantly (in which case your C libm has the 
bug).

----------------------------------------------------------------------

Comment By: Kyle Wheeler (memoryhole)
Date: 2003-04-14 17:19

Message:
Logged In: YES 
user_id=17596

Python 2.2.2 (#1, Apr 13 2003, 16:19:28) 
[GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-110)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import random
>>> print 1.35933812391 % 1,.0
1.35933812391 0.0
>>> print 1.35933812391 % 1.0
1.35933812391
>>> print 4%2                
0
>>> print 1.3%2
3.3

Any ideas?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-04-14 17:14

Message:
Logged In: YES 
user_id=31435

What does the following statement print under this Python:

print 1.35933812391 % 1,.0

?

Note that there's almost no chance this is a bug in Python 
(the implementation of random() hasn't changed in about 10 
years).  There's a good chance it's a bug in the specific  C 
compiler or C library release you're using.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=721402&group_id=5470


From noreply@sourceforge.net  Sun Apr 20 04:57:55 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 19 Apr 2003 20:57:55 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-724459 ] Add documentation about line endings in email messages.
Message-ID: <E1975xj-00066j-00@sc8-sf-web1.sourceforge.net>

Feature Requests item #724459, was opened at 2003-04-19 22:38
Message generated for change (Comment added) made by bwarsaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=724459&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tony Meyer (anadelonbrin)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Add documentation about line endings in email messages.

Initial Comment:
This follows from recent discussion on the spambayes 
mailing list (some of which was also on the mimelib-
devel list) about what character(s) should be used for 
line endings internally and when transmitted.  There is a 
consensus (I think) that the platform/language specific 
character(s) should be used internally, but any module 
that transmits the date should be responsible for 
converting this to the appropriate character(s) - for 
RFC2822/822 this means that all line endings *must* be 
\r\n.

smtplib currently does this, but imaplib doesn't (a bug 
has been posted about this).

To help people understand what the rules are, it would 
be nice if documentation could be added about this - 
especially for anyone developing a new module (like 
smtplib or imaplib) that transmits the data.  The 
following is from a post to the spambayes list from Paul 
Moore, which sounds good to me.  (Where it gets added 
is your problem ;)

"As a general set of rules (which aren't stated anywhere) 
it's probably fair to say that:

   1. Modules which manipulate internet-format data (like 
email) should work with line terminators of \n internally 
(just like Python strings do).
   2. Modules which transmit files across TCP/IP should 
canonicalise any form of line ending to CRLF.
   3. Modules which present data *received* from TCP/IP 
(like POP3) should convert data to \n line endings before 
returning it to the program.
   4. Reading from the filesystem should be handled like 
(3), and should support files opened in text or binary 
modes (or universal newline mode in Python 2.3)
   5. Writing to the filesystem should be done by 
assuming the data uses \n internally (the above rules 
make this true) and writing either in binary format (which 
leaves LFs in the files, ie Unix format) or in text format 
(which converts the \n characters to the platform native 
newline sequence)."

----------------------------------------------------------------------

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-04-19 23:57

Message:
Logged In: YES 
user_id=12800

Self-assigning

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=724459&group_id=5470


From noreply@sourceforge.net  Sun Apr 20 13:42:36 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 20 Apr 2003 05:42:36 -0700
Subject: [Python-bugs-list] [ python-Bugs-724588 ] socketmodule doesn't compile on strict POSIX systems
Message-ID: <E197E9U-0000UT-00@sc8-sf-web3.sourceforge.net>

Bugs item #724588, was opened at 2003-04-20 14:42
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724588&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Marc Recht (marc)
Assigned to: Nobody/Anonymous (nobody)
Summary: socketmodule doesn't compile on strict POSIX systems

Initial Comment:
socketmodule uses the functions: 
- hstrerror 
- inet_aton 
- inet_pton 
 
and definitions: 
- NI_MAXHOST 
- NI_MAXSERV 
 
which aren't defined by IEEE Std 1003.1, 2003 Edition 
(regarding to 
http://www.unix.org/single_unix_specification/). 
 
The attached patch changes configure.in so that configure 
tries to take the adress of the functions rather than the 
autoconf library function check. Because with the later the 
POSIX/POSIX_C_SOURCE/XOPEN etc definitions are not 
set. It also changes socketmodule.c to define NI_MAXHOST 
and NI_MAXSERV if they haven't been defined already. 
This fixes compilation of socketmodule on: 
NetBSD 1.6R i386 
 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724588&group_id=5470


From noreply@sourceforge.net  Sun Apr 20 14:43:11 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 20 Apr 2003 06:43:11 -0700
Subject: [Python-bugs-list] [ python-Bugs-724588 ] socketmodule doesn't compile on strict POSIX systems
Message-ID: <E197F67-0008DN-00@sc8-sf-web4.sourceforge.net>

Bugs item #724588, was opened at 2003-04-20 14:42
Message generated for change (Comment added) made by marc
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724588&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Marc Recht (marc)
Assigned to: Nobody/Anonymous (nobody)
Summary: socketmodule doesn't compile on strict POSIX systems

Initial Comment:
socketmodule uses the functions: 
- hstrerror 
- inet_aton 
- inet_pton 
 
and definitions: 
- NI_MAXHOST 
- NI_MAXSERV 
 
which aren't defined by IEEE Std 1003.1, 2003 Edition 
(regarding to 
http://www.unix.org/single_unix_specification/). 
 
The attached patch changes configure.in so that configure 
tries to take the adress of the functions rather than the 
autoconf library function check. Because with the later the 
POSIX/POSIX_C_SOURCE/XOPEN etc definitions are not 
set. It also changes socketmodule.c to define NI_MAXHOST 
and NI_MAXSERV if they haven't been defined already. 
This fixes compilation of socketmodule on: 
NetBSD 1.6R i386 
 

----------------------------------------------------------------------

>Comment By: Marc Recht (marc)
Date: 2003-04-20 15:43

Message:
Logged In: YES 
user_id=205

This is for Python 2.3/CVS (20.04.2003). 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724588&group_id=5470


From noreply@sourceforge.net  Sun Apr 20 16:36:55 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 20 Apr 2003 08:36:55 -0700
Subject: [Python-bugs-list] [ python-Bugs-724621 ] email/quopriMIME.py exception on int (lstrip)
Message-ID: <E197GsB-0008Iz-00@sc8-sf-web2.sourceforge.net>

Bugs item #724621, was opened at 2003-04-20 10:36
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724621&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Moshe Yudkowsky (myudkowsky)
Assigned to: Nobody/Anonymous (nobody)
Summary: email/quopriMIME.py exception on int (lstrip)

Initial Comment:
Python 2.3a2+, Debian

Summary: when I use the as_string() method on a
multipart, multilevel message, I get an exception from
email/quopriMIME.py, line 84,  complaining about
lstrip() of an integer.

Initial condtions:

I have a script that reads an email message, extracts
some information, encapsulates the message and then
forwards it with some commentary. This script works
under Python 2.2.2.

Failure: This script does not run under 2.3a2+ -- it
fails on the as_string() method. In particular, at the
file/lineno given above.

Using the debugger, I see that in fact there *is* an
integer at that point, the digit "1" to be exact.
Looking up in the stack, I see that this function was
called by the method _encode_chunks in Headers.py, and
that the "newchunks" was [ (1, us-ascii ) ].

Please let me know if you need copies of the scripts,
email messages, etc.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724621&group_id=5470


From noreply@sourceforge.net  Sun Apr 20 21:44:24 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 20 Apr 2003 13:44:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-549151 ] urllib2 POSTs on redirect
Message-ID: <E197Lfk-0004Cp-00@sc8-sf-web2.sourceforge.net>

Bugs item #549151, was opened at 2002-04-26 17:04
Message generated for change (Comment added) made by jjlee
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: Accepted
Priority: 7
Submitted By: John J Lee (jjlee)
Assigned to: Raymond Hettinger (rhettinger)
Summary: urllib2 POSTs on redirect

Initial Comment:

urllib2 (I'm using 1.13.22 with Python 2.0, but I assume the 2.2 branch does the same) uses the 
POST method on redirect, contrary to RFC1945 section 9.3:

> 9.3  Redirection 3xx
> 
>    This class of status code indicates that further action needs to be
>    taken by the user agent in order to fulfill the request. The action
>    required may be carried out by the user agent without interaction
>    with the user if and only if the method used in the subsequent
>    request is GET or HEAD. A user agent should never automatically
>    redirect a request more than 5 times, since such redirections usually
>    indicate an infinite loop.

Can be fixed in HTTPRedirectHandler.http_error_302 by replacing
        new = Request(newurl, req.get_data())

with
        new = Request(newurl)

so that GET is done on redirect instead of POST.

I suppose the limit of 10 in the same function should be changed to 5, also.


----------------------------------------------------------------------

>Comment By: John J Lee (jjlee)
Date: 2003-04-20 21:44

Message:
Logged In: YES 
user_id=261020

Just noticed that I forgot to upload one of the doc patches 
on 2003-03-05.  Here it is. 
 
The patches that need to be applied are the three I 
uploaded on 2003-03-05 (urllib.py.patch, urllib2.py.patch 
and liburllib2.tex.patch), and the liburllib.tex.patch I just 
uploaded. 
 

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-16 21:35

Message:
Logged In: YES 
user_id=6380

I think this is the right thing to do. Can you check it in?
 (There are several files -- urllib, urllib2, and its docs).

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-16 21:27

Message:
Logged In: YES 
user_id=80475

Do you have time to take this one back?  My head starts to 
explode when researching whether this is the right thing 
to do.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-03-07 20:57

Message:
Logged In: YES 
user_id=6380

I'll try to work on this.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2003-03-05 21:03

Message:
Logged In: YES 
user_id=261020

The fix for this was set to go into 2.3, but nothing has  
happened yet. 
 
There were a couple of minor details to be fixed in the 
patches, so I've done that, and uploaded new patches for  
urllib2.py, urllib.py, and their documentation files (against  
current CVS). Well, I'm just about to upload them... 
 
Jeremy, can you apply the patches and finally close this 
one now?  Let me know if anything else needs doing. 
 
This should actually close another bug on SF, too (if it's still 
open), which deals with the urllib.py case.  I can't find it,  
though.  I did attach a comment to it (before I lost it) that 
references this bug. 
 

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-10-15 16:22

Message:
Logged In: YES 
user_id=261020

Well, when I carefully read the RFC I came to the conclusion
that 301 should be redirected to GET, not POST.  I also came
to the conclusion that the RFC was slightly ambiguous on
this point, so I guess that's why A. Flavell came to the
conclusion that 301 should redirect to POST rather than GET.
Anyway, clearly the established practice is to redirect 301
as GET, so this is all academic.

Assuming he's right about Netscape / IE etc., I suppose I'm
happy for 301 to redirect without an exception, since that's
what we've agreed to do for 302.  Obviously, the docs should
say this is contrary to the RFC (as my doc patch says for
302 already).

As for urllib.py, I see the problem.  303 should still be
added, though, since that poses no problem at all.


John


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-10-11 16:40

Message:
Logged In: YES 
user_id=31392

I'm still uncertain about what to do on 301 responses.  As
you say, there are two issues to sort out: 1) what method
should a POST be redicted to and 2) whether the user should
be asked to confirm.

There's discussion of this at:
http://ppewww.ph.gla.ac.uk/~flavell/www/post-redirect.html
The page is a bit old, but I don't know if it is out of date.
It says that IE5, Netscape 4, and Mozilla 1.0 all redirect a
301 POST to a GET without user confirmation.  That seems
like a widespread disregard for the spec that we ought to
emulate.

I agree with your interpretation that urllib2 raise an
HTTPError to signal "request confirm" because an HTTPError
is also a valid response that the user could interpret.  But
of urllib, an HTTP error doesn't contain a valid response. 
The change would make it impossible for the client to do
anything if a 301 response is returned from a POST.  That
seems worse than doing the wrong.



----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-10-10 02:27

Message:
Logged In: YES 
user_id=6380

OK, over to jeremy.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-10-09 22:16

Message:
Logged In: YES 
user_id=261020

Ah.  Here it is.

John


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-10-08 19:23

Message:
Logged In: YES 
user_id=6380

Um, I don't see the patch for urllib.py.  Perhaps you didn't
check the box?

Jeremy, let's do this in 2.3, OK?

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-10-08 17:53

Message:
Logged In: YES 
user_id=261020

Guido mentioned that urllib.py should be fixed
too.  I've attached another patch.


John


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-10-05 18:44

Message:
Logged In: YES 
user_id=261020

Here is a patch for the minor documentation changes required
for the patch I uploaded earlier to fix this bug.  I've also
uploaded a slightly revised patch:

I renamed the `method' method to `get_method' for
consistency with the other methods of the Request class.
The reason this new method is there at all is because the
logic that decides whether or not a redirection should take
place is defined in terms of the method type
(GET/HEAD/POST).  urllib2 doesn't support HEAD ATM, but it
might in future.  OTOH, the Request class is supposed to be
generic -- not specific to HTTP -- so perhaps get_method
isn't really appropriate.  OTOOH, add_data is already
documented to only be meaningful for HTTP Requests.  I
suppose there could be a subclass HTTPRequest, but that's
less simple.  What do you think is best?

I also changed redirect_request to raise an exception
instead of returning None (because no other Handler should
handle the redirect), and changed its documented return
value / exception interface to be consistent with the rest
of urllib2.


John


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-06-23 20:23

Message:
Logged In: YES 
user_id=261020

First, can I underline the fact that there are two issues
here:

  1. What method should POST be redirected as for a
     particular 30x response?

  2. Should the user be asked to confirm the redirection
     (which presumably maps onto raising an HTTPError in
     urllib2)?

I think current client implementations go against the RFCs
on both these points for 302.  Contrastingly, RFC 2616's
note on 301 responses (section 10.3.2) implies that only a
subset of HTTP/1.0 (not 1.1, note) clients violate the RFCs
(1945, 2068, 2616) on point 1 for 301 responses, and I know
of no clients that violate the RFCs on point 2 for 301
responses (but I haven't tested).  Also, I guess the
original intent (for both 301 and 302) was that POSTs
represent an action, so it's dangerous in general to
redirect them without asking the user: I presume this is why
307 was brought in: 307 POSTs on redirected POST, so the
user must be asked:

10.3 Redirection 3xx
[...]
   The action required MAY be carried out by the user agent
   without interaction with the user if and only if the
   method used in the second request is GET or HEAD.

(and 303 is just meant to have the 'erroneous' 302
behaviour: GET on redirected POST, don't ask the user)

So, I agree with Guido that 302 should probably now be
treated the way most clients treat it: GET on redirected
POST, don't ask the user.  As for 301, if it *is* true that
only a few HTTP/1.0 clients have misinterpreted the RFCs on
301, we should stick to the safe behaviour indicated by the
RFC.

As for Guido's first question: A 307 should indeed be
redirected as a POST, but it should ask the user first (see
10.3 quote, above).  That's what my patch does (the 'return
None' in the else clause in redirect_request causes an
exception to be raised eventually -- maybe it should just
raise it itself).

I've attached a revised patch that deals with 302 (and 303)
in the 'erroneous' way (again: GET on redirected POST, don't
ask the user).

I suppose the comment about HTTPRedirectHandler also needs
to state that 301 and 307 POST requests are not
automatically redirected -- HTTPError is raised in that
case.


John


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-20 01:57

Message:
Logged In: YES 
user_id=6380

Hm, I thought that 307 should be treated differently than
303. In particular, a 307 response to POST should cause the
POST to be redirected. And I'm not sure about what a 301
response to POST should do.

(In the mean time I have been convinced that changing POST
to GET on 302 is the best thing to do given that most
browsers do that. The old urllib.py should be fixed too.)

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-06-19 22:57

Message:
Logged In: YES 
user_id=261020

I've attached a patch -- was simpler than I thought.

I think this is in compliance with RFC 2616.  It's also
simple for clients to inherit from HTTPRedirectHandler and
override redirect_request if, for example, they know they
want all 302 POSTs to be redirected as a GET, which removes
the need for mixing redirection code with normal client code
even when the server doesn't follow the RFC (if the server
expects a 302 POST to be redirected as a GET, for example).
Note that I had to add a method, named 'method', to the
Request class, for maintainability (it's possible that
urllib2 may be able to do methods other than GET and POST in
future).

Possibly redirect_request should take fewer parameters.

John


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-06-19 22:56

Message:
Logged In: YES 
user_id=261020

I've attached a patch -- was simpler than I thought.

I think this is in compliance with RFC 2616.  It's also
simple for clients to inherit from HTTPRedirectHandler and
override redirect_request if, for example, they know they
want all 302 POSTs to be redirected as a GET, which removes
the need for mixing redirection code with normal client code
even when the server doesn't follow the RFC (if the server
expects a 302 POST to be redirected as a GET, for example).
Note that I had to add a method, named 'method', to the
Request class, for maintainability (it's possible that
urllib2 may be able to do methods other than GET and POST in
future).

Possibly redirect_request should take fewer parameters.

John


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-06-06 22:25

Message:
Logged In: YES 
user_id=261020

Oh, I hadn't realised httplib uses HTTP/1.1 now -- and now I
check, I see that even RFC 1945 (HTTP/1.0) has a whole set of
restrictions on 30x for particular values of x which I missed
completely.

I guess it should do what Guido suggested -- report an error if a
POST is redirected -- until somebody gets time to do it properly.
I won't have time for a couple of months, but if nobody has done
it by then I'll upload a patch.


John


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-06-06 16:09

Message:
Logged In: YES 
user_id=31392

I think you need to review the current HTTP spec -- RFC 2616
-- and look at the section on redirection (10.3).  I think
urllib2 could improve its handling of redirection, but the
behavior you describe from lynx sounds incorrect.  I'd be
happy to review a patch the implemented the current spec.

Also, RFC 2616 removes the recommendation of a 5 redirect limit.




----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-29 19:10

Message:
Logged In: YES 
user_id=6380

Fair enough. I'll leve it to Jeremy to review the proposed
fix. (Note that he's busy though.)

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-04-29 17:29

Message:
Logged In: YES 
user_id=261020

I don't see why it shouldn't substitue a GET.  That certainly seems to be
the standard practice (well, at least that's what lynx does), and in the case
of the only site where I've encountered redirects on POST, the redirect URL
contains urlencoded stuff, so it clearly expects the user-agent to do a GET.
The site would break if this didn't happen, so I guess Netscape and IE must
do the same thing.

Clearly the RFC *does* allow this, though it doesn't require it (or specify
what should happen here in any way other than to say that a POST is not
allowed, in fact).  Since it's standard practice and allowed by the RFC, I
don't think it should be an error.

John


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-29 01:53

Message:
Logged In: YES 
user_id=6380

Hm, the way I interpret the text you quote, if the original
request is  a POST, it should probably not substitute a GET
but report the error.

Assigning to Jeremy since it's his module.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-04-28 17:21

Message:
Logged In: YES 
user_id=261020

1. Bug is also in 2.2 branch

2. The fix (in 2.1 and 2.2) should reflect the earlier bug fix in the 2.2 branch to add the old headers:

new = Request(newurl, headers=req.headers)

3. I guess 10 should be replaced with 4, not 5.


John


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470


From noreply@sourceforge.net  Sun Apr 20 22:18:32 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 20 Apr 2003 14:18:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-724751 ] urllib.urlparse has inverse in cgi module
Message-ID: <E197MCm-0001eN-00@sc8-sf-web4.sourceforge.net>

Bugs item #724751, was opened at 2003-04-20 22:18
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724751&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: John J Lee (jjlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib.urlparse has inverse in cgi module

Initial Comment:
The fact that urllib.urlparse has its inverse in the 
cgi module is not mentioned in the urllib docs. 
 
The patch adds a link to the cgi module, pointing out 
that the cgi.parse_qs and cgi.parse_qsl functions 
are the inverse of urllib.urlparse (if you ignore the 
precise types involved -- urllib.urlparse is many-to-one 
in that respect, so there isn't really a proper inverse 
function). 
 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724751&group_id=5470


From noreply@sourceforge.net  Sun Apr 20 22:20:46 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 20 Apr 2003 14:20:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-724751 ] urllib.urlparse has inverse in cgi module
Message-ID: <E197MEw-0001tM-00@sc8-sf-web1.sourceforge.net>

Bugs item #724751, was opened at 2003-04-20 22:18
Message generated for change (Comment added) made by jjlee
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724751&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: John J Lee (jjlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib.urlparse has inverse in cgi module

Initial Comment:
The fact that urllib.urlparse has its inverse in the 
cgi module is not mentioned in the urllib docs. 
 
The patch adds a link to the cgi module, pointing out 
that the cgi.parse_qs and cgi.parse_qsl functions 
are the inverse of urllib.urlparse (if you ignore the 
precise types involved -- urllib.urlparse is many-to-one 
in that respect, so there isn't really a proper inverse 
function). 
 

----------------------------------------------------------------------

>Comment By: John J Lee (jjlee)
Date: 2003-04-20 22:20

Message:
Logged In: YES 
user_id=261020

Oops, forgot to attach patch. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724751&group_id=5470


From noreply@sourceforge.net  Sun Apr 20 23:09:40 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 20 Apr 2003 15:09:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-724767 ] Minor /Tools/Scripts/crlf.py bugs
Message-ID: <E197N0G-0004hC-00@sc8-sf-web3.sourceforge.net>

Bugs item #724767, was opened at 2003-04-20 17:09
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724767&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: logistix (logistix)
Assigned to: Nobody/Anonymous (nobody)
Summary: Minor /Tools/Scripts/crlf.py bugs

Initial Comment:
Caught these when I tried to cut-and-paste the code.

crlf.py uses the variable name file, which it shouldn't 
anymore.  I've attached a patch to fix this problem.

It also looks like the method of determining if a file is 
text or binary isn't unicode safe.  Am I right?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724767&group_id=5470


From noreply@sourceforge.net  Sun Apr 20 23:13:51 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 20 Apr 2003 15:13:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-724771 ] test_grp failing
Message-ID: <E197N4J-000477-00@sc8-sf-web1.sourceforge.net>

Bugs item #724771, was opened at 2003-04-21 00:13
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724771&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_grp failing

Initial Comment:
Adding this just so it doesn't fall by the roadside (it's been discussed 
on python-dev): test_grp is failing on MacOSX, probably because
there are multiple groups with the same numeric id (didn't 
investigate, though).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724771&group_id=5470


From noreply@sourceforge.net  Sun Apr 20 23:14:33 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 20 Apr 2003 15:14:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-724774 ] test_getargs2 failing
Message-ID: <E197N4z-00049S-00@sc8-sf-web1.sourceforge.net>

Bugs item #724774, was opened at 2003-04-21 00:14
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724774&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_getargs2 failing

Initial Comment:
Adding this just so it doesn't fall by the roadside (it's been discussed 
on python-dev): test_getargs2 is currently failing, at least on MacOSX.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724774&group_id=5470


From noreply@sourceforge.net  Mon Apr 21 00:01:27 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 20 Apr 2003 16:01:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-724621 ] email/quopriMIME.py exception on int (lstrip)
Message-ID: <E197NoN-0005l3-00@sc8-sf-web1.sourceforge.net>

Bugs item #724621, was opened at 2003-04-20 11:36
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724621&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Moshe Yudkowsky (myudkowsky)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: email/quopriMIME.py exception on int (lstrip)

Initial Comment:
Python 2.3a2+, Debian

Summary: when I use the as_string() method on a
multipart, multilevel message, I get an exception from
email/quopriMIME.py, line 84,  complaining about
lstrip() of an integer.

Initial condtions:

I have a script that reads an email message, extracts
some information, encapsulates the message and then
forwards it with some commentary. This script works
under Python 2.2.2.

Failure: This script does not run under 2.3a2+ -- it
fails on the as_string() method. In particular, at the
file/lineno given above.

Using the debugger, I see that in fact there *is* an
integer at that point, the digit "1" to be exact.
Looking up in the stack, I see that this function was
called by the method _encode_chunks in Headers.py, and
that the "newchunks" was [ (1, us-ascii ) ].

Please let me know if you need copies of the scripts,
email messages, etc.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724621&group_id=5470


From noreply@sourceforge.net  Mon Apr 21 03:33:22 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 20 Apr 2003 19:33:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-659604 ] optparse store_true uses 1 and 0
Message-ID: <E197R7S-0003hv-00@sc8-sf-web1.sourceforge.net>

Bugs item #659604, was opened at 2002-12-29 02:37
Message generated for change (Comment added) made by gward
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=659604&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Brian Lenihan (brianl)
Assigned to: Greg Ward (gward)
Summary: optparse store_true uses 1 and 0

Initial Comment:
When using store_true and store_false actions, the
optparse module sets the values to 1 and 0, rather than
True and False.

--- optparse.py 14 Nov 2002 22:00:19 -0000      1.1
+++ optparse.py 29 Dec 2002 07:34:06 -0000
@@ -609,9 +609,9 @@
         elif action == "store_const":
             setattr(values, dest, self.const)
         elif action == "store_true":
-            setattr(values, dest, 1)
+            setattr(values, dest, True)
         elif action == "store_false":
-            setattr(values, dest, 0)
+            setattr(values, dest, False)
         elif action == "append":
             values.ensure_value(dest, []).append(value)
         elif action == "count":

----------------------------------------------------------------------

>Comment By: Greg Ward (gward)
Date: 2003-04-20 22:33

Message:
Logged In: YES 
user_id=14422

Problems with optparse.py should be addressed via Optik's
project page, CVS archive, etc.  I've fixed Optik to use
True/False when available; that fix made it into Optik1.4.1.
 I'll be checking in a revised optparse.py based on Optik
1.4.1 real soon now (as soon as it passes its test suite).


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-12-29 10:09

Message:
Logged In: YES 
user_id=33168

Greg, any problem with making this change?  Assign to me, if
you want me to do it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=659604&group_id=5470


From noreply@sourceforge.net  Mon Apr 21 03:42:59 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 20 Apr 2003 19:42:59 -0700
Subject: [Python-bugs-list] [ python-Bugs-659604 ] optparse store_true uses 1 and 0
Message-ID: <E197RGl-0008Up-00@sc8-sf-web2.sourceforge.net>

Bugs item #659604, was opened at 2002-12-29 02:37
Message generated for change (Comment added) made by gward
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=659604&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Brian Lenihan (brianl)
Assigned to: Greg Ward (gward)
Summary: optparse store_true uses 1 and 0

Initial Comment:
When using store_true and store_false actions, the
optparse module sets the values to 1 and 0, rather than
True and False.

--- optparse.py 14 Nov 2002 22:00:19 -0000      1.1
+++ optparse.py 29 Dec 2002 07:34:06 -0000
@@ -609,9 +609,9 @@
         elif action == "store_const":
             setattr(values, dest, self.const)
         elif action == "store_true":
-            setattr(values, dest, 1)
+            setattr(values, dest, True)
         elif action == "store_false":
-            setattr(values, dest, 0)
+            setattr(values, dest, False)
         elif action == "append":
             values.ensure_value(dest, []).append(value)
         elif action == "count":

----------------------------------------------------------------------

>Comment By: Greg Ward (gward)
Date: 2003-04-20 22:42

Message:
Logged In: YES 
user_id=14422

OK, fixed in rev 1.3 of optparse.py.

----------------------------------------------------------------------

Comment By: Greg Ward (gward)
Date: 2003-04-20 22:33

Message:
Logged In: YES 
user_id=14422

Problems with optparse.py should be addressed via Optik's
project page, CVS archive, etc.  I've fixed Optik to use
True/False when available; that fix made it into Optik1.4.1.
 I'll be checking in a revised optparse.py based on Optik
1.4.1 real soon now (as soon as it passes its test suite).


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-12-29 10:09

Message:
Logged In: YES 
user_id=33168

Greg, any problem with making this change?  Assign to me, if
you want me to do it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=659604&group_id=5470


From noreply@sourceforge.net  Mon Apr 21 03:43:23 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 20 Apr 2003 19:43:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-659604 ] optparse store_true uses 1 and 0
Message-ID: <E197RH9-0008W4-00@sc8-sf-web2.sourceforge.net>

Bugs item #659604, was opened at 2002-12-29 02:37
Message generated for change (Settings changed) made by gward
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=659604&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Brian Lenihan (brianl)
Assigned to: Greg Ward (gward)
Summary: optparse store_true uses 1 and 0

Initial Comment:
When using store_true and store_false actions, the
optparse module sets the values to 1 and 0, rather than
True and False.

--- optparse.py 14 Nov 2002 22:00:19 -0000      1.1
+++ optparse.py 29 Dec 2002 07:34:06 -0000
@@ -609,9 +609,9 @@
         elif action == "store_const":
             setattr(values, dest, self.const)
         elif action == "store_true":
-            setattr(values, dest, 1)
+            setattr(values, dest, True)
         elif action == "store_false":
-            setattr(values, dest, 0)
+            setattr(values, dest, False)
         elif action == "append":
             values.ensure_value(dest, []).append(value)
         elif action == "count":

----------------------------------------------------------------------

Comment By: Greg Ward (gward)
Date: 2003-04-20 22:42

Message:
Logged In: YES 
user_id=14422

OK, fixed in rev 1.3 of optparse.py.

----------------------------------------------------------------------

Comment By: Greg Ward (gward)
Date: 2003-04-20 22:33

Message:
Logged In: YES 
user_id=14422

Problems with optparse.py should be addressed via Optik's
project page, CVS archive, etc.  I've fixed Optik to use
True/False when available; that fix made it into Optik1.4.1.
 I'll be checking in a revised optparse.py based on Optik
1.4.1 real soon now (as soon as it passes its test suite).


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-12-29 10:09

Message:
Logged In: YES 
user_id=33168

Greg, any problem with making this change?  Assign to me, if
you want me to do it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=659604&group_id=5470


From noreply@sourceforge.net  Mon Apr 21 16:12:44 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 21 Apr 2003 08:12:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-725026 ] Possible OSX module location bug
Message-ID: <E197cyK-0003Pi-00@sc8-sf-web2.sourceforge.net>

Bugs item #725026, was opened at 2003-04-21 10:12
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=725026&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: logistix (logistix)
Assigned to: Jack Jansen (jackjansen)
Summary: Possible OSX module location bug

Initial Comment:
I have an app with a testfile 'os.py' that was designed to 
see if I was searching pythonpath properly (if it found my 
os.py, it didn't)

Running scripts from the directory containing this file 
has been working fine on Windows, BSD, Linux.

An OSX user reported an error trying to run the scripts.  
Output indicated that site.py was trying to load my 
os.py instead of the proper one.

I can't reproduce it since I don't have OSX, but if 
someone wants to try:

Create a subdirectory under site-packages
Create a dummy os.py file
Create a dummy test.py file
with this directory as the pwd, issue 'python -v test.py'

User didn't appear to have anything too funky in sys.path

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=725026&group_id=5470


From noreply@sourceforge.net  Mon Apr 21 18:16:52 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 21 Apr 2003 10:16:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-725106 ] SRE bug with capturing groups in alternatives in repeats
Message-ID: <E197euS-0006pW-00@sc8-sf-web3.sourceforge.net>

Bugs item #725106, was opened at 2003-04-21 09:16
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=725106&group_id=5470

Category: Regular Expressions
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Fredrik Lundh (effbot)
Summary: SRE bug with capturing groups in alternatives in repeats

Initial Comment:
SRE does not always correctly handle groups in 
alternatives in repeats.  For example:

>>> re.match('((a)|b)*', 'abc').groups()
('b', '')

Group 2 should obviously never be an empty string.  As I 
understand it, the rule for groups inside a repeat is that 
they should have the last value they matched during the 
iterations of the repeat (or None if they never match), so 
in the above case Group 2 should be 'a'.  To fix this, it 
appears that (when inside a repeat) the BRANCH 
opcode must call mark_save before trying an alternative 
and then call mark_restore if the alternative fails.  The 
attached patch does this.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=725106&group_id=5470


From noreply@sourceforge.net  Mon Apr 21 18:42:03 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 21 Apr 2003 10:42:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-724774 ] test_getargs2 failing
Message-ID: <E197fIp-0008HU-00@sc8-sf-web3.sourceforge.net>

Bugs item #724774, was opened at 2003-04-20 18:14
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724774&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_getargs2 failing

Initial Comment:
Adding this just so it doesn't fall by the roadside (it's been discussed 
on python-dev): test_getargs2 is currently failing, at least on MacOSX.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-21 13:42

Message:
Logged In: YES 
user_id=33168

This is failling on several other architectures in the snake
farm:  http://www.lysator.liu.se/xenofarm/python/latest.html

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724774&group_id=5470


From noreply@sourceforge.net  Mon Apr 21 18:42:31 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 21 Apr 2003 10:42:31 -0700
Subject: [Python-bugs-list] [ python-Bugs-724771 ] test_grp failing
Message-ID: <E197fJH-0008JJ-00@sc8-sf-web3.sourceforge.net>

Bugs item #724771, was opened at 2003-04-20 18:13
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724771&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_grp failing

Initial Comment:
Adding this just so it doesn't fall by the roadside (it's been discussed 
on python-dev): test_grp is failing on MacOSX, probably because
there are multiple groups with the same numeric id (didn't 
investigate, though).

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-21 13:42

Message:
Logged In: YES 
user_id=33168

This is failling on several other architectures in the snake
farm:  http://www.lysator.liu.se/xenofarm/python/latest.html

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724771&group_id=5470


From noreply@sourceforge.net  Mon Apr 21 19:22:01 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 21 Apr 2003 11:22:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-725149 ] SRE bugs with capturing groups in negative assertions
Message-ID: <E197fvV-0002Bf-00@sc8-sf-web4.sourceforge.net>

Bugs item #725149, was opened at 2003-04-21 10:22
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=725149&group_id=5470

Category: Regular Expressions
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Fredrik Lundh (effbot)
Summary: SRE bugs with capturing groups in negative assertions

Initial Comment:
SRE is broken in some subtle ways when you combine 
capturing groups with assertions.  For example:

>>> re.match('((?!(a)c)[ab])*', 'abc').groups()
('b', '')

In the above '(a)' has matched an empty string.  Or 
worse:

>>> re.match('(a)((?!(b)*))*', 'abb').groups()
('b', None, None)

Here '(a)' matches 'b'.

Although Perl reports matches for groups in negative 
assertions, I think it is better to adopt the PCRE rule 
that these groups are always reported as unmatched 
outside the assertion (inside the assertion, if used with 
backreferences, they should behave as normal).  This 
would make the handling of subpatterns in negative 
assertions consistent with that of subpatterns in 
branches:

>>> re.match('(a)c|ab', 'ab').groups()
(None,)

In the above, although '(a)' matches before the branch 
fails, the failure of the branch means '(a)' is considered 
not to have matched.

Anyway, the attached patch is an effort to fix this 
problem by saving the values of marks before calling the 
assertion, and then restoring them afterwards (thus 
undoing whatever might have been done in the assertion).


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=725149&group_id=5470


From noreply@sourceforge.net  Mon Apr 21 19:31:35 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 21 Apr 2003 11:31:35 -0700
Subject: [Python-bugs-list] [ python-Bugs-723540 ] __slots__ broken in 2.3a with ("__dict__", )
Message-ID: <E197g4l-0002k7-00@sc8-sf-web1.sourceforge.net>

Bugs item #723540, was opened at 2003-04-18 02:35
Message generated for change (Comment added) made by derivin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723540&group_id=5470

Category: Type/class unification
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Douglas Napoleone (derivin)
Assigned to: Nobody/Anonymous (nobody)
>Summary: __slots__ broken in 2.3a with ("__dict__", )

Initial Comment:
I LOVE using __slots__. I love using properties.
I made my own extension and metaclass so I could 
define type safe properties in classes. I could stick 
properties on a class and have them accessed 
seperatly from slots (because they are properties and 
not attributes). The properties call setter/getters and 
store the data in __dict__ (a cheezy means of making 
pickle still work with no effort). thus I had __slots__ = 
('__dict__', ) in my base class. this worked great in 2.2 
and 2.2.2.  Im migrating all my modules to 2.3. I just 
fixed a bug in my code that was due to a typo. Thats 
when I realized that __slots__ was no longer working in 
2.3a. I cant find anything on this change in behavior.

if slots contains "__dict__" slots is turned OFF!!!
simplified version of the bug:

$ python
Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more 
information.
>>> class foo(object):
...   __slots__ = ("__dict__", )
...
>>> a = foo()
>>> a.bad = 3
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
AttributeError: 'foo' object has no attribute 'bad'
>>> ^Z

$ python23
Python 2.3a2 (#39, Feb 19 2003, 17:58:58) [MSC 
v.1200 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more 
information.
>>> class foo(object):
...   __slots__ = ("__dict__", )
...
>>> a = foo()
>>> a.bad = 3
>>> dir(a)
['__class__', '__delattr__', '__dict__', '__doc__', '__getattr
ibute__', '__hash_
_', '__init__', '__module__', '__new__', '__reduce__', '__re
duce_ex__', '__repr_
_', '__setattr__', '__slots__', '__str__', 'bad']
>>> ^Z



----------------------------------------------------------------------

>Comment By: Douglas Napoleone (derivin)
Date: 2003-04-21 13:31

Message:
Logged In: YES 
user_id=541557

from that followup of mine, you can clearly see why I use 
__slots__; sorry for the bad spelling and worse grammar.

I *think* I have a solution, but I an not really sure if it is the 
proper behavior for __slots__.

I can not find any documentation, PEP, bug, request, or 
discussion on how __slots__ should behave in boundry 
cases such as "__dict__", "__weakref__", etc. 

Should these be an error if used?
Are they assumed?
what behavior does having __dict__ as an allowed attribute 
have? (Does it allow access to the proxy __dict__ and use 
proper __slots__ conventions and attribute checking? does it 
circumvent __slots__, i.e. a back door?)

__slots__ and inheritance is not clearly specified either.
If these things are documented, please flame me with the 
links.


----------------------------------------------------------------------

Comment By: Douglas Napoleone (derivin)
Date: 2003-04-18 13:44

Message:
Logged In: YES 
user_id=541557

Well looking deeper at the problem, is seems that __dict__ 
and __weakref__ are called out as special in 
Objects/typeobject.c at some point after the 2.2.2 release.

looking at teh code, I would expect the followint ot be 
triggered:

   if (!may_add_dict || add_dict) { 
          PyErr_SetString(PyExc_TypeError, 
                                    "__dict__ slot disallowed: " 
                                    "we already got one"); 
          goto bad_slots; 
    }

Ignoring the attrocious goto logic in this section of code, I 
would have expected to see this triggered.
I can understand the IDEA behind always having __slots__ 
on all classes/types and setting it to contain "__dict__" as 
teh equivolent of not having slots... But the code does not 
look like it implements this, and I dont see how this is even 
working that way yet. Has anyone heard anything about 
this???

(for now in my code I am having to use __fakedict__ and 
override all the pickle handling (yuck).



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723540&group_id=5470


From noreply@sourceforge.net  Mon Apr 21 19:33:30 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 21 Apr 2003 11:33:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-672035 ] Py_Main() does not perform to spec
Message-ID: <E197g6c-0002pZ-00@sc8-sf-web1.sourceforge.net>

Bugs item #672035, was opened at 2003-01-21 15:42
Message generated for change (Comment added) made by derivin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672035&group_id=5470

Category: Extension Modules
Group: Python 2.2.2
Status: Open
>Resolution: Fixed
Priority: 5
Submitted By: Douglas Napoleone (derivin)
Assigned to: Nobody/Anonymous (nobody)
Summary: Py_Main() does not perform to spec

Initial Comment:
I consider this a code bug, not a documentation issue 
as the documentation is the behavior we want.

>From 
http://www.python.org/doc/current/api/veryhigh.html#l2h-
47  :
int Py_Main(int argc, char **argv) 
The main program for the standard interpreter. This is 
made available for programs which embed Python. The 
argc and argv parameters should be prepared exactly as 
those which are passed to a C program's main() 
function. It is important to note that the argument list 
may be modified (but the contents of the strings pointed 
to by the argument list are not). The return value will be 
the integer passed to the sys.exit() function, 1 if the 
interpreter exits due to an exception, or 2 if the 
parameter list does not represent a valid Python 
command line. 

I have checked the code for 2.2, 2.2.1, 2.2.2, and r2.3al
In all cases the code will call exit(2) in C when an 
improper commandline is given instead of returning 2.
ALL exit() calls should be removed from this module. 
The return value should be passed to exit or returned 
from main() by the caller of Py_Main() and NOT from 
within this call.

python.c's main() would not need to be changed as it 
already does this.


----------------------------------------------------------------------

>Comment By: Douglas Napoleone (derivin)
Date: 2003-04-21 13:33

Message:
Logged In: YES 
user_id=541557

Patch was applied, just closing

----------------------------------------------------------------------

Comment By: Douglas Napoleone (derivin)
Date: 2003-01-21 15:50

Message:
Logged In: YES 
user_id=541557

The max recursion limit problem in the re module is well-known.  
Until this limitation in the implementation is removed, to work 
around it check

http://www.python.org/dev/doc/devel/lib/module-re.html
http://python/org/sf/493252

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672035&group_id=5470


From noreply@sourceforge.net  Mon Apr 21 21:23:22 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 21 Apr 2003 13:23:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-725026 ] Possible OSX module location bug
Message-ID: <E197how-00014b-00@sc8-sf-web3.sourceforge.net>

Bugs item #725026, was opened at 2003-04-21 17:12
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=725026&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: logistix (logistix)
Assigned to: Jack Jansen (jackjansen)
Summary: Possible OSX module location bug

Initial Comment:
I have an app with a testfile 'os.py' that was designed to 
see if I was searching pythonpath properly (if it found my 
os.py, it didn't)

Running scripts from the directory containing this file 
has been working fine on Windows, BSD, Linux.

An OSX user reported an error trying to run the scripts.  
Output indicated that site.py was trying to load my 
os.py instead of the proper one.

I can't reproduce it since I don't have OSX, but if 
someone wants to try:

Create a subdirectory under site-packages
Create a dummy os.py file
Create a dummy test.py file
with this directory as the pwd, issue 'python -v test.py'

User didn't appear to have anything too funky in sys.path

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2003-04-21 22:23

Message:
Logged In: YES 
user_id=45365

I tried this with all three of
- Apple's /usr/bin/python 2.2
- Python 2.3a2+ from CVS
- MacPython-OS9 2.3a2+ from CVS

None of these see os.py in the current directory. The only thing I can
imagine, because you talk about a subdirectory of site-packages, is that
the user has a .pth file in site-packages listing the subdirectory.

If this isn't the case, ask for the following:
- Complete version info (python startup banner)
- sys.path value
- output of 'python -v test.py'.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=725026&group_id=5470


From noreply@sourceforge.net  Mon Apr 21 21:49:37 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 21 Apr 2003 13:49:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-725265 ] urlopen object's read() doesn't read to EOF
Message-ID: <E197iEL-00062p-00@sc8-sf-web2.sourceforge.net>

Bugs item #725265, was opened at 2003-04-21 15:49
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=725265&group_id=5470

Category: Documentation
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher Smith (smichr)
Assigned to: Nobody/Anonymous (nobody)
Summary: urlopen object's read() doesn't read to EOF

Initial Comment:
On http://python.org/doc/current/lib/module-urllib.html it says that 
the object returned by urlopen supports the read()method and that 
this and other methods "have the same interface as for file objects 
-- see section 2.2.8".  In that section on page 
http://python.org/doc/current/lib/bltin-file-objects.html it says about 
the read() method that "if the size argument is negative or omitted, 
[read should] read all data until EOF is reached."

I was a bit surprised when a project that students of mine were 
working on were failing when they tried to process the data 
obtained by the read() method on a connection made to a web 
page.  The problem, apparently, is that the read may not obtain all 
of the data requested in the first request and the total response 
has to be built up someting like follows:

import urllib
c=urllib.urlopen("http://www.blakeschool.org")
data = ''
while 1:
	packet=c.read()
	if packet == '': break
	data+=packet
	
I'm not sure if this is a feature or a bug.  Could a file's read method 
fail to obtain the whole file in one read(), too?  It seems that either 
the documentation should be changed or the read() method for at 
least urllib objects should be changed.

/c

Christopher P. Smith
The Blake School
Minneapolis, MN


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=725265&group_id=5470


From noreply@sourceforge.net  Mon Apr 21 21:56:38 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 21 Apr 2003 13:56:38 -0700
Subject: [Python-bugs-list] [ python-Bugs-725026 ] Possible OSX module location bug
Message-ID: <E197iL8-00035y-00@sc8-sf-web1.sourceforge.net>

Bugs item #725026, was opened at 2003-04-21 10:12
Message generated for change (Comment added) made by logistix
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=725026&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: logistix (logistix)
Assigned to: Jack Jansen (jackjansen)
Summary: Possible OSX module location bug

Initial Comment:
I have an app with a testfile 'os.py' that was designed to 
see if I was searching pythonpath properly (if it found my 
os.py, it didn't)

Running scripts from the directory containing this file 
has been working fine on Windows, BSD, Linux.

An OSX user reported an error trying to run the scripts.  
Output indicated that site.py was trying to load my 
os.py instead of the proper one.

I can't reproduce it since I don't have OSX, but if 
someone wants to try:

Create a subdirectory under site-packages
Create a dummy os.py file
Create a dummy test.py file
with this directory as the pwd, issue 'python -v test.py'

User didn't appear to have anything too funky in sys.path

----------------------------------------------------------------------

>Comment By: logistix (logistix)
Date: 2003-04-21 15:56

Message:
Logged In: YES 
user_id=699438

Here's what he sent me before.  
Actually, '/Volumes/Other/dev/python' might be the culprit.  
I'm not sure what working directory the commands were run 
under.

I'll go ahead and forward a link to this bug to him.  Unless he 
has any input, I guess it's "Works for Me".

  python -v buildWeb.py
# /usr/lib/python2.2/site.pyc 
matches /usr/lib/python2.2/site.py import site # precompiled 
from /usr/lib/python2.2/site.pyc # ./os.pyc matches ./os.py 
import os # precompiled from ./os.pyc Ugh! 'import site' failed; 
traceback: Traceback (most recent call last):
   File "/usr/lib/python2.2/site.py", line 69, in ?
     m.__file__ = os.path.abspath(m.__file__)
AttributeError: 'module' object has no attribute 'path'
Python 2.2 (#1, 07/14/02, 23:25:09)
[GCC Apple cpp-precomp 6.14] on darwin
Type "help", "copyright", "credits" or "license" for more 
information. ...


% python -c "import sys;print sys.path"
['', '/Volumes/Other/dev/python', '/usr/lib/python2.2', 
'/usr/lib/python2.2/plat-darwin', '/usr/lib/python2.2/lib-tk', 
'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-
packages']

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-04-21 15:23

Message:
Logged In: YES 
user_id=45365

I tried this with all three of
- Apple's /usr/bin/python 2.2
- Python 2.3a2+ from CVS
- MacPython-OS9 2.3a2+ from CVS

None of these see os.py in the current directory. The only thing I can
imagine, because you talk about a subdirectory of site-packages, is that
the user has a .pth file in site-packages listing the subdirectory.

If this isn't the case, ask for the following:
- Complete version info (python startup banner)
- sys.path value
- output of 'python -v test.py'.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=725026&group_id=5470


From noreply@sourceforge.net  Tue Apr 22 12:05:33 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 22 Apr 2003 04:05:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-557704 ] netrc module can't handle all passwords
Message-ID: <E197vaf-0003o5-00@sc8-sf-web4.sourceforge.net>

Bugs item #557704, was opened at 2002-05-18 19:18
Message generated for change (Comment added) made by vimboss
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=557704&group_id=5470

Category: Python Library
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Bram Moolenaar (vimboss)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: netrc module can't handle all passwords

Initial Comment:
When a ~/.netrc file has a password with non-word
characters parsing fails.  Since it is recommended to
use punctuation characters in passwords, this means
most netrc files can't be parsed. An example of a line
in ~/.netrc that fails:

machine piet.puk.com  	login foo 	password bar!

Additionally, entries in netrc may not have a login
name (e.g., for mail servers).  These entries should be
silently skipped. An example of a line that fails:

machine mail          password fruit

The included diff is a partial solution.  It allows all
ASCII punctuation characters to be used in passwords. 
Non-ASCII characters should probably also be allowed.

----------------------------------------------------------------------

>Comment By: Bram Moolenaar (vimboss)
Date: 2003-04-22 13:05

Message:
Logged In: YES 
user_id=57665

Can someone please do something about this bug?  It has been
open for almost a year now and it still can't handle my
netrc file.  At least include a temporary fix!  My patch
plus the remarks from rhettinger should be sufficient.

----------------------------------------------------------------------

Comment By: Bram Moolenaar (vimboss)
Date: 2002-11-08 12:46

Message:
Logged In: YES 
user_id=57665

Note that the old Netrc class in the ftplib module has a
different approach at parsing the .netrc file.  This might
actually work much better.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-05 20:43

Message:
Logged In: YES 
user_id=6380

I think Fred knows this code.

I think Eric Raymond (the original author) wrote this as an 
example of his shlex. :-)

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-06-02 14:48

Message:
Logged In: YES 
user_id=44345

I think a better solution would be to not use shlex to parse netrc files.  
Netrc files aren't shells.  The whitespace is significant if it occurs inside a 
password.  I'd just use re.split(r'(\s+)') and restore the password when I 
encounterd the "password" keyword.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-19 03:56

Message:
Logged In: YES 
user_id=80475

Expanding keyspace is generally a good idea; however, the 
significance of meta-characters is bound to bite someone in 
the behind with a hard to find error.  So, please 
reconsider single-quote, double-quote, backslash, 
greaterthan, lessthan, and pipe.

Looking at first part of the patch, consider:
- removing the TODO on line 31
- wrapping the character list in triple-quotes on line 32
- using the r'' form on line 32 to eliminate backslashes in 
the character list

Looking at the second part of the patch, I don't follow (am 
perhaps being daft) why expanding the keyspace necessitates 
changing the login logic.

The idea of allowing non-ASCII characters would be cool if 
the world had already universally accepted Latin-1 coding.  
That conflict is the reason that site.py defaults to ASCII 
encoding instead of handling non-US codings out of the box.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=557704&group_id=5470


From noreply@sourceforge.net  Tue Apr 22 12:09:44 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 22 Apr 2003 04:09:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-724771 ] test_grp failing
Message-ID: <E197vei-0005iI-00@sc8-sf-web2.sourceforge.net>

Bugs item #724771, was opened at 2003-04-21 00:13
Message generated for change (Comment added) made by doerwalter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724771&group_id=5470

Category: None
Group: None
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Jack Jansen (jackjansen)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: test_grp failing

Initial Comment:
Adding this just so it doesn't fall by the roadside (it's been discussed 
on python-dev): test_grp is failing on MacOSX, probably because
there are multiple groups with the same numeric id (didn't 
investigate, though).

----------------------------------------------------------------------

>Comment By: Walter Dörwald (doerwalter)
Date: 2003-04-22 13:09

Message:
Logged In: YES 
user_id=89016

According to
http://www.lysator.liu.se/xenofarm/python/files/579_3/python-testlog.txt
the problem is not duplicate ids, but duplicate names. I've
changed
test_pwd and test_grp, so that they handle names in the same
way as ids. (test_pwd.py 1.15, test_grp.py 1.14). Does this
fix the problem?


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-21 19:42

Message:
Logged In: YES 
user_id=33168

This is failling on several other architectures in the snake
farm:  http://www.lysator.liu.se/xenofarm/python/latest.html

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724771&group_id=5470


From noreply@sourceforge.net  Tue Apr 22 13:04:33 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 22 Apr 2003 05:04:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-721871 ] tarfile gets filenames wrong
Message-ID: <E197wVl-0007QQ-00@sc8-sf-web3.sourceforge.net>

Bugs item #721871, was opened at 2003-04-15 16:56
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=721871&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
>Priority: 7
Submitted By: Jack Jansen (jackjansen)
>Assigned to: Jack Jansen (jackjansen)
Summary: tarfile gets filenames wrong

Initial Comment:
Tarfile seem to get filenames wrong, at least some times, at least on 
MacOSX. As an example, take the attached tar file (a distutils bdist-
dumb for OSX) and do 

>>> tf = tarfile.open(..., 'r')
>>> print tf.getnames()

Notice how for many filenames an initial bit of the pathname is 
missing.


----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2003-04-22 14:04

Message:
Logged In: YES 
user_id=45365

After some digging the problem turns out that the prefix field in the file 
header is not completely zero-filled, the very last byte is a '('. Your code 
specifically checks for it being zero-filled. However, if I look up the tar 
standard (www.opengroup.org, unix standard, utilities, pax, somewhere half 
way down is the ustar file format standard) it says the data in the prefix field 
is NUL-terminated, it says nothing about having to be NUL-filled
.

A possible fix would be to simply take prefix up to the first NUL, but I'm 
contacting Lars first to see if he has an opinion.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-04-16 11:26

Message:
Logged In: YES 
user_id=45365

Actually, I did check the box (just this once:-) but sourceforge refused the 
file, probably too big. It can be found at <http://www.cwi.nl/~jack/pimp/
Numeric-22.0.darwin-6.3-Power_Macintosh.tar.gz>.

----------------------------------------------------------------------

Comment By: Sjoerd Mullender (sjoerd)
Date: 2003-04-15 17:13

Message:
Logged In: YES 
user_id=43607

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=721871&group_id=5470


From noreply@sourceforge.net  Tue Apr 22 13:28:51 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 22 Apr 2003 05:28:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-557704 ] netrc module can't handle all passwords
Message-ID: <E197wtH-0001sU-00@sc8-sf-web2.sourceforge.net>

Bugs item #557704, was opened at 2002-05-18 13:18
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=557704&group_id=5470

Category: Python Library
Group: Python 2.2.1
Status: Open
Resolution: None
>Priority: 7
Submitted By: Bram Moolenaar (vimboss)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: netrc module can't handle all passwords

Initial Comment:
When a ~/.netrc file has a password with non-word
characters parsing fails.  Since it is recommended to
use punctuation characters in passwords, this means
most netrc files can't be parsed. An example of a line
in ~/.netrc that fails:

machine piet.puk.com  	login foo 	password bar!

Additionally, entries in netrc may not have a login
name (e.g., for mail servers).  These entries should be
silently skipped. An example of a line that fails:

machine mail          password fruit

The included diff is a partial solution.  It allows all
ASCII punctuation characters to be used in passwords. 
Non-ASCII characters should probably also be allowed.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-22 08:28

Message:
Logged In: YES 
user_id=6380

Raymond, can you deal with this or find someone else? (Maybe
the fellow who last patched shlex.py?)

----------------------------------------------------------------------

Comment By: Bram Moolenaar (vimboss)
Date: 2003-04-22 07:05

Message:
Logged In: YES 
user_id=57665

Can someone please do something about this bug?  It has been
open for almost a year now and it still can't handle my
netrc file.  At least include a temporary fix!  My patch
plus the remarks from rhettinger should be sufficient.

----------------------------------------------------------------------

Comment By: Bram Moolenaar (vimboss)
Date: 2002-11-08 06:46

Message:
Logged In: YES 
user_id=57665

Note that the old Netrc class in the ftplib module has a
different approach at parsing the .netrc file.  This might
actually work much better.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-05 14:43

Message:
Logged In: YES 
user_id=6380

I think Fred knows this code.

I think Eric Raymond (the original author) wrote this as an 
example of his shlex. :-)

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-06-02 08:48

Message:
Logged In: YES 
user_id=44345

I think a better solution would be to not use shlex to parse netrc files.  
Netrc files aren't shells.  The whitespace is significant if it occurs inside a 
password.  I'd just use re.split(r'(\s+)') and restore the password when I 
encounterd the "password" keyword.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-18 21:56

Message:
Logged In: YES 
user_id=80475

Expanding keyspace is generally a good idea; however, the 
significance of meta-characters is bound to bite someone in 
the behind with a hard to find error.  So, please 
reconsider single-quote, double-quote, backslash, 
greaterthan, lessthan, and pipe.

Looking at first part of the patch, consider:
- removing the TODO on line 31
- wrapping the character list in triple-quotes on line 32
- using the r'' form on line 32 to eliminate backslashes in 
the character list

Looking at the second part of the patch, I don't follow (am 
perhaps being daft) why expanding the keyspace necessitates 
changing the login logic.

The idea of allowing non-ASCII characters would be cool if 
the world had already universally accepted Latin-1 coding.  
That conflict is the reason that site.py defaults to ASCII 
encoding instead of handling non-US codings out of the box.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=557704&group_id=5470


From noreply@sourceforge.net  Tue Apr 22 14:29:33 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 22 Apr 2003 06:29:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-724771 ] test_grp failing
Message-ID: <E197xq1-0004sd-00@sc8-sf-web4.sourceforge.net>

Bugs item #724771, was opened at 2003-04-21 00:13
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724771&group_id=5470

Category: None
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Neal Norwitz (nnorwitz)
Summary: test_grp failing

Initial Comment:
Adding this just so it doesn't fall by the roadside (it's been discussed 
on python-dev): test_grp is failing on MacOSX, probably because
there are multiple groups with the same numeric id (didn't 
investigate, though).

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2003-04-22 15:28

Message:
Logged In: YES 
user_id=45365

Still fails:
  File "/Users/jack/src/python/Lib/test/test_grp.py", line 37, in test_values
    self.assert_(grp.getgrgid(e.gr_gid) in entriesbygid[e.gr_gid])
  File "/Users/jack/src/python/Lib/unittest.py", line 268, in failUnless
    if not expr: raise self.failureException, msg


----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2003-04-22 13:09

Message:
Logged In: YES 
user_id=89016

According to
http://www.lysator.liu.se/xenofarm/python/files/579_3/python-testlog.txt
the problem is not duplicate ids, but duplicate names. I've
changed
test_pwd and test_grp, so that they handle names in the same
way as ids. (test_pwd.py 1.15, test_grp.py 1.14). Does this
fix the problem?


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-21 19:42

Message:
Logged In: YES 
user_id=33168

This is failling on several other architectures in the snake
farm:  http://www.lysator.liu.se/xenofarm/python/latest.html

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724771&group_id=5470


From noreply@sourceforge.net  Tue Apr 22 14:46:13 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 22 Apr 2003 06:46:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-719297 ] sys.path on MacOSX
Message-ID: <E197y69-0005lo-00@sc8-sf-web3.sourceforge.net>

Bugs item #719297, was opened at 2003-04-10 23:30
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=719297&group_id=5470

Category: Macintosh
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: sys.path on MacOSX

Initial Comment:
On MacOSX sys.path needs to conform more to the platform standard, with extensions (read: python packages) installed in multiple places (per-user, per-machine, network-wide). We can probably ignore network-wide for the time being, and per-machine is more-or-less handled by Python's lib/site-packages, but per-user is needed.

Problem is that there are a number of reasonable places we could put these user-extensions:
- ~/Library/Python - Perl seems to do it this way.
- ~/Library/Application Support/Python - Seems like a better location
- One of the above, with "site-packages" appended - allows for more stuff in there, like IDE plugins, Package Manager packages, etc.
- One of the above, with $(VERSION)/site-packages appended - allows for installation of multiple Python versions without the binary extension modules getting in each others hair.

And only $(VERSION) isn't even good enough if this code also gets used for non-framework Pythons, because extension modules aren't compatible between framework and non-framework builds.

distutils should probably be aware of this convention, and if site-packages isn't writable to the current user fallback to the directory above (or at least give a warning explaining how to do this).

For completeness we could always add the user directory to sys.path, and add the other two (/Library, /Network/Library) only if they exist.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2003-04-22 15:46

Message:
Logged In: YES 
user_id=45365

Implemented in site.py ref. 1.49, for per-user only: ~/Library/Python/2.3/
site-packages is added to sys.path.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=719297&group_id=5470


From noreply@sourceforge.net  Tue Apr 22 14:49:41 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 22 Apr 2003 06:49:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-721157 ] Building lib.pdf fails on MacOSX
Message-ID: <E197y9V-0006Ah-00@sc8-sf-web3.sourceforge.net>

Bugs item #721157, was opened at 2003-04-14 17:09
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=721157&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Building lib.pdf fails on MacOSX

Initial Comment:
I can't build lib.pdf on MacOSX anymore. I tried both a4 and letter.
The pdflatex call fails with

Error: pdflatex: buffer overflow [125000 bytes]

The whole lib.how is attached (if I don't forget to check the 
checkmark:-).

pdflatex -version prints

pdfTeX (Web2C 7.3.3.1) 3.14159-0.14h-released-20010417

which seems to be newer than what the README lists as the minimal 
requirement.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2003-04-22 15:49

Message:
Logged In: YES 
user_id=45365

That seems to work. I added the configuration lines to the end of /sw/share/
texmf/web2c/texmf.cnf and everything proceeds smoothly.

Could you add a note to the documentation readme file? The "/sw" location 
is specific to people who have installed the whole TeX circus with fink, but I 
assume that will be the common case for MacOS users.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-04-17 21:25

Message:
Logged In: YES 
user_id=3066

Where a setting isn't specified but there is a "base"
variable (for example, main_memory is set, but not
main_memory.pdflatex), you can add the .pdflatex version if
the number is higher in the settings I included.  The
".pdflatex" suffix means that that setting applies to
pdflatex only; if such a suffixed version isn't set, the
bare "base" variable is used.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-04-17 21:12

Message:
Logged In: YES 
user_id=45365

My texmf.cnf looks completely different. There doesn't seem to be a .pdflatex section, only the one TEXINPUTS line mentions pdflatex.

I've attached the file (name set to fink-texmf.cnf), maybe you understand it.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-04-17 18:36

Message:
Logged In: YES 
user_id=3066

TeX systems tend to be a little weird about how memory is
allocated.
Most current distributions use a semi-static allocation
mechanism: Some large buffers are allocated once, and
everything happens within those.  The sizes are usually
configurable using a config file.

On my RedHat Linux box, which uses the "teTeX" TeX system,
there's a config file:

    /usr/share/texmf/web2c/texmf.cnf

This contains the following settings for pdfLaTeX:

TEXINPUTS.pdflatex = .;$TEXMF/{pdftex,tex}/{latex,generic,}//
main_memory.pdflatex = 1500000
hash_extra.pdflatex = 25000
pool_size.pdflatex = 750000
string_vacancies.pdflatex = 45000
max_strings.pdflatex = 55000
pool_free.pdflatex = 47500
nest_size.pdflatex = 500
param_size.pdflatex = 3000
save_size.pdflatex = 5000
stack_size.pdflatex = 3000

If you can locate the corresponding config file for your
system, please check the sizes configured and let me know
what differs. I may need to add some documentation about
this, mentioning that the Library Reference may take more
resources than are typically allocated.

Thanks!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=721157&group_id=5470


From noreply@sourceforge.net  Tue Apr 22 14:58:17 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 22 Apr 2003 06:58:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-719300 ] pimp needs to do download itself
Message-ID: <E197yHp-0004ae-00@sc8-sf-web2.sourceforge.net>

Bugs item #719300, was opened at 2003-04-10 23:35
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=719300&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
>Priority: 3
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
>Summary: pimp needs to do download itself

Initial Comment:
Pimp currently uses the OSX programs curl and tar to download distributions and unpack them. There is absolutely no reason not to use the urllib and tarfile modules for this.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2003-04-22 15:58

Message:
Logged In: YES 
user_id=45365

Unpack has been implemented, downloading isn't that important, leaving 
that for later.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-04-14 16:47

Message:
Logged In: YES 
user_id=45365

There is actually a very good reason to use at least the tarfile module: if we 
use that in stead of unix tar we can fiddle pathnames while we unpack. 
Thereby we can do per-user installs of packages even if the tarfile was 
created for a system-wide installation. (That is, once the details of where 
per-user packages are going to be stored have been worked out).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=719300&group_id=5470


From noreply@sourceforge.net  Tue Apr 22 15:14:24 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 22 Apr 2003 07:14:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-724771 ] test_grp failing
Message-ID: <E197yXQ-0005Tp-00@sc8-sf-web1.sourceforge.net>

Bugs item #724771, was opened at 2003-04-21 00:13
Message generated for change (Comment added) made by doerwalter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724771&group_id=5470

Category: None
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Neal Norwitz (nnorwitz)
Summary: test_grp failing

Initial Comment:
Adding this just so it doesn't fall by the roadside (it's been discussed 
on python-dev): test_grp is failing on MacOSX, probably because
there are multiple groups with the same numeric id (didn't 
investigate, though).

----------------------------------------------------------------------

>Comment By: Walter Dörwald (doerwalter)
Date: 2003-04-22 16:14

Message:
Logged In: YES 
user_id=89016

Could you try the attached patch and post the output?

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-04-22 15:28

Message:
Logged In: YES 
user_id=45365

Still fails:
  File "/Users/jack/src/python/Lib/test/test_grp.py", line 37, in test_values
    self.assert_(grp.getgrgid(e.gr_gid) in entriesbygid[e.gr_gid])
  File "/Users/jack/src/python/Lib/unittest.py", line 268, in failUnless
    if not expr: raise self.failureException, msg


----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2003-04-22 13:09

Message:
Logged In: YES 
user_id=89016

According to
http://www.lysator.liu.se/xenofarm/python/files/579_3/python-testlog.txt
the problem is not duplicate ids, but duplicate names. I've
changed
test_pwd and test_grp, so that they handle names in the same
way as ids. (test_pwd.py 1.15, test_grp.py 1.14). Does this
fix the problem?


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-21 19:42

Message:
Logged In: YES 
user_id=33168

This is failling on several other architectures in the snake
farm:  http://www.lysator.liu.se/xenofarm/python/latest.html

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724771&group_id=5470


From noreply@sourceforge.net  Tue Apr 22 15:16:19 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 22 Apr 2003 07:16:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-724774 ] test_getargs2 failing
Message-ID: <E197yZH-0005c1-00@sc8-sf-web1.sourceforge.net>

Bugs item #724774, was opened at 2003-04-20 18:14
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724774&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_getargs2 failing

Initial Comment:
Adding this just so it doesn't fall by the roadside (it's been discussed 
on python-dev): test_getargs2 is currently failing, at least on MacOSX.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-22 10:16

Message:
Logged In: YES 
user_id=33168

This is fixed on all the snake-farm machines AFAIK.  Jack,
are you still having the problems?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-21 13:42

Message:
Logged In: YES 
user_id=33168

This is failling on several other architectures in the snake
farm:  http://www.lysator.liu.se/xenofarm/python/latest.html

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724774&group_id=5470


From noreply@sourceforge.net  Tue Apr 22 15:17:32 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 22 Apr 2003 07:17:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-724771 ] test_grp failing
Message-ID: <E197yaS-0000Ai-00@sc8-sf-web4.sourceforge.net>

Bugs item #724771, was opened at 2003-04-20 18:13
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724771&group_id=5470

Category: None
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Jack Jansen (jackjansen)
>Assigned to: Jack Jansen (jackjansen)
Summary: test_grp failing

Initial Comment:
Adding this just so it doesn't fall by the roadside (it's been discussed 
on python-dev): test_grp is failing on MacOSX, probably because
there are multiple groups with the same numeric id (didn't 
investigate, though).

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-22 10:17

Message:
Logged In: YES 
user_id=33168

I believe this problem was fixed on all the snake-farm
machines after Walter's last checkins.  Thanks Walter.

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2003-04-22 10:14

Message:
Logged In: YES 
user_id=89016

Could you try the attached patch and post the output?

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-04-22 09:28

Message:
Logged In: YES 
user_id=45365

Still fails:
  File "/Users/jack/src/python/Lib/test/test_grp.py", line 37, in test_values
    self.assert_(grp.getgrgid(e.gr_gid) in entriesbygid[e.gr_gid])
  File "/Users/jack/src/python/Lib/unittest.py", line 268, in failUnless
    if not expr: raise self.failureException, msg


----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2003-04-22 07:09

Message:
Logged In: YES 
user_id=89016

According to
http://www.lysator.liu.se/xenofarm/python/files/579_3/python-testlog.txt
the problem is not duplicate ids, but duplicate names. I've
changed
test_pwd and test_grp, so that they handle names in the same
way as ids. (test_pwd.py 1.15, test_grp.py 1.14). Does this
fix the problem?


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-21 13:42

Message:
Logged In: YES 
user_id=33168

This is failling on several other architectures in the snake
farm:  http://www.lysator.liu.se/xenofarm/python/latest.html

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724771&group_id=5470


From noreply@sourceforge.net  Tue Apr 22 15:34:04 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 22 Apr 2003 07:34:04 -0700
Subject: [Python-bugs-list] [ python-Bugs-719303 ] Icon on applets is wrong
Message-ID: <E197yqS-0006hm-00@sc8-sf-web2.sourceforge.net>

Bugs item #719303, was opened at 2003-04-10 23:44
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=719303&group_id=5470

Category: Macintosh
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: Icon on applets is wrong

Initial Comment:
Somewhere in the process of switching to bundlebuilder for creating applets on MacOSX the generated applets have lost their icon, and in stead now have a generic application icon. This needs to be fixed.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2003-04-22 16:34

Message:
Logged In: YES 
user_id=45365

Fixed in buildtools.py ref 1.10.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=719303&group_id=5470


From noreply@sourceforge.net  Tue Apr 22 19:46:19 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 22 Apr 2003 11:46:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-725149 ] SRE bugs with capturing groups in negative assertions
Message-ID: <E1982mZ-0008MJ-00@sc8-sf-web4.sourceforge.net>

Bugs item #725149, was opened at 2003-04-21 10:22
Message generated for change (Comment added) made by glchapman
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=725149&group_id=5470

Category: Regular Expressions
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Fredrik Lundh (effbot)
Summary: SRE bugs with capturing groups in negative assertions

Initial Comment:
SRE is broken in some subtle ways when you combine 
capturing groups with assertions.  For example:

>>> re.match('((?!(a)c)[ab])*', 'abc').groups()
('b', '')

In the above '(a)' has matched an empty string.  Or 
worse:

>>> re.match('(a)((?!(b)*))*', 'abb').groups()
('b', None, None)

Here '(a)' matches 'b'.

Although Perl reports matches for groups in negative 
assertions, I think it is better to adopt the PCRE rule 
that these groups are always reported as unmatched 
outside the assertion (inside the assertion, if used with 
backreferences, they should behave as normal).  This 
would make the handling of subpatterns in negative 
assertions consistent with that of subpatterns in 
branches:

>>> re.match('(a)c|ab', 'ab').groups()
(None,)

In the above, although '(a)' matches before the branch 
fails, the failure of the branch means '(a)' is considered 
not to have matched.

Anyway, the attached patch is an effort to fix this 
problem by saving the values of marks before calling the 
assertion, and then restoring them afterwards (thus 
undoing whatever might have been done in the assertion).


----------------------------------------------------------------------

>Comment By: Greg Chapman (glchapman)
Date: 2003-04-22 10:46

Message:
Logged In: YES 
user_id=86307

In thinking further, I realized that positive assertions are also 
affected by the second problem.  E.g.:

>>> re.match('(a)(?:(?=(b)*)c)*', 'abb').groups()
('b', None)

The problem here is that a successful match in an assertion 
can leave marks at the top of the mark stack which then get 
popped in the wrong place.  Attaching a new patch which 
should catch this problem for both kinds of assertions (and 
which also should "unmark" groups in negative assertions).


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=725149&group_id=5470


From noreply@sourceforge.net  Tue Apr 22 22:30:02 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 22 Apr 2003 14:30:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-581080 ] Provoking infinite scanner loops
Message-ID: <E1985L0-0000gv-00@sc8-sf-web3.sourceforge.net>

Bugs item #581080, was opened at 2002-07-13 12:32
Message generated for change (Comment added) made by dschnepper
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=581080&group_id=5470

Category: Regular Expressions
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Fredrik Lundh (effbot)
Summary: Provoking infinite scanner loops

Initial Comment:
>From c.l.py:

"""
From: Jane Austine
Sent: Saturday, July 13, 2002 6:01 AM
To: python-list@python.org
Subject: sre.finditer break down: is this a bug?

Newly added function sre.finditer and 
(matchedObject.)finditer break down and the system 
crushes on win32 when requested for next() after 
StopIteration.

see:
>> import sre
>> fi=sre.finditer(r'\s','a b')
>> fi.next()
>> fi.next()
>> fi.next() #system halts for ever.
-- 
"""

The semantics of the underlying calliterobject aren't 
clear to me in this endcase, and I've raised that issue 
on c.l.py.

But regardless of how that's resolved,  it's easy to 
provoke the bad behavior without using finditer, and 
that should be fixed:

>>> import re
>>> s = re.compile(r'\s').scanner
>>> t = s('a b').search
>>> t()
<_sre.SRE_Match object at 0x00679F70>
>>> t()
>>> t()
>>> t()

and there it's hung.

----------------------------------------------------------------------

Comment By: David Schnepper (dschnepper)
Date: 2003-04-22 14:30

Message:
Logged In: YES 
user_id=72348

This fix needs backporting to the release-maint22 branch

----------------------------------------------------------------------

Comment By: Gustavo Niemeyer (niemeyer)
Date: 2002-11-06 19:30

Message:
Logged In: YES 
user_id=7887

Fixed in the following CVS revisions: 
 
Misc/NEWS: 1.515->1.516 
Modules/_sre.c: 2.84->2.85 
 
Thank you, Tim! 

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-07-13 12:35

Message:
Logged In: YES 
user_id=31435

Oops -- I meant I raised the calliterobject issue on Python-
Dev, not on c.l.py.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=581080&group_id=5470


From noreply@sourceforge.net  Tue Apr 22 23:03:26 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 22 Apr 2003 15:03:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-721871 ] tarfile gets filenames wrong
Message-ID: <E1985rK-0003El-00@sc8-sf-web4.sourceforge.net>

Bugs item #721871, was opened at 2003-04-15 16:56
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=721871&group_id=5470

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: tarfile gets filenames wrong

Initial Comment:
Tarfile seem to get filenames wrong, at least some times, at least on 
MacOSX. As an example, take the attached tar file (a distutils bdist-
dumb for OSX) and do 

>>> tf = tarfile.open(..., 'r')
>>> print tf.getnames()

Notice how for many filenames an initial bit of the pathname is 
missing.


----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2003-04-23 00:03

Message:
Logged In: YES 
user_id=45365

Fixed in tarfile.py ref 1.8

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-04-22 14:04

Message:
Logged In: YES 
user_id=45365

After some digging the problem turns out that the prefix field in the file 
header is not completely zero-filled, the very last byte is a '('. Your code 
specifically checks for it being zero-filled. However, if I look up the tar 
standard (www.opengroup.org, unix standard, utilities, pax, somewhere half 
way down is the ustar file format standard) it says the data in the prefix field 
is NUL-terminated, it says nothing about having to be NUL-filled
.

A possible fix would be to simply take prefix up to the first NUL, but I'm 
contacting Lars first to see if he has an opinion.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-04-16 11:26

Message:
Logged In: YES 
user_id=45365

Actually, I did check the box (just this once:-) but sourceforge refused the 
file, probably too big. It can be found at <http://www.cwi.nl/~jack/pimp/
Numeric-22.0.darwin-6.3-Power_Macintosh.tar.gz>.

----------------------------------------------------------------------

Comment By: Sjoerd Mullender (sjoerd)
Date: 2003-04-15 17:13

Message:
Logged In: YES 
user_id=43607

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=721871&group_id=5470


From noreply@sourceforge.net  Tue Apr 22 23:16:04 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 22 Apr 2003 15:16:04 -0700
Subject: [Python-bugs-list] [ python-Bugs-724771 ] test_grp failing
Message-ID: <E19863Y-0008DW-00@sc8-sf-web2.sourceforge.net>

Bugs item #724771, was opened at 2003-04-21 00:13
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724771&group_id=5470

Category: None
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Jack Jansen (jackjansen)
>Assigned to: Walter Dörwald (doerwalter)
Summary: test_grp failing

Initial Comment:
Adding this just so it doesn't fall by the roadside (it's been discussed 
on python-dev): test_grp is failing on MacOSX, probably because
there are multiple groups with the same numeric id (didn't 
investigate, though).

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2003-04-23 00:16

Message:
Logged In: YES 
user_id=45365

It stil fails, sigh.

I've added the output, maybe that tells you more?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-22 16:17

Message:
Logged In: YES 
user_id=33168

I believe this problem was fixed on all the snake-farm
machines after Walter's last checkins.  Thanks Walter.

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2003-04-22 16:14

Message:
Logged In: YES 
user_id=89016

Could you try the attached patch and post the output?

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-04-22 15:28

Message:
Logged In: YES 
user_id=45365

Still fails:
  File "/Users/jack/src/python/Lib/test/test_grp.py", line 37, in test_values
    self.assert_(grp.getgrgid(e.gr_gid) in entriesbygid[e.gr_gid])
  File "/Users/jack/src/python/Lib/unittest.py", line 268, in failUnless
    if not expr: raise self.failureException, msg


----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2003-04-22 13:09

Message:
Logged In: YES 
user_id=89016

According to
http://www.lysator.liu.se/xenofarm/python/files/579_3/python-testlog.txt
the problem is not duplicate ids, but duplicate names. I've
changed
test_pwd and test_grp, so that they handle names in the same
way as ids. (test_pwd.py 1.15, test_grp.py 1.14). Does this
fix the problem?


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-21 19:42

Message:
Logged In: YES 
user_id=33168

This is failling on several other architectures in the snake
farm:  http://www.lysator.liu.se/xenofarm/python/latest.html

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724771&group_id=5470


From noreply@sourceforge.net  Wed Apr 23 00:01:37 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 22 Apr 2003 16:01:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-725916 ] Tkinter.DoubleVar data corruption
Message-ID: <E1986ld-0002nR-00@sc8-sf-web1.sourceforge.net>

Bugs item #725916, was opened at 2003-04-22 16:01
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=725916&group_id=5470

Category: Tkinter
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Lonnie Princehouse (caprice_of_mind)
Assigned to: Nobody/Anonymous (nobody)
Summary: Tkinter.DoubleVar data corruption

Initial Comment:
Tkinter.DoubleVar is performing the equivalent of float(str
(x)), resulting in the unnecessary amputation of a few 
siginificant digits because str() does not return enough 
digits to represent the full range of a 64-bit float.

Example:

x = 0.33333333333333098
from Tkinter import *
y = DoubleVar(Tk())
y.set(x)

# x == 0.33333333333333098
# y.get() == 0.33333333333300003

if y.get() == x:
  print "Good!"
else:
  print "Bad!"



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=725916&group_id=5470


From noreply@sourceforge.net  Wed Apr 23 02:33:30 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 22 Apr 2003 18:33:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-725916 ] Tkinter.DoubleVar data corruption
Message-ID: <E19898c-00072a-00@sc8-sf-web2.sourceforge.net>

Bugs item #725916, was opened at 2003-04-22 19:01
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=725916&group_id=5470

Category: Tkinter
Group: None
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Lonnie Princehouse (caprice_of_mind)
Assigned to: Nobody/Anonymous (nobody)
Summary: Tkinter.DoubleVar data corruption

Initial Comment:
Tkinter.DoubleVar is performing the equivalent of float(str
(x)), resulting in the unnecessary amputation of a few 
siginificant digits because str() does not return enough 
digits to represent the full range of a 64-bit float.

Example:

x = 0.33333333333333098
from Tkinter import *
y = DoubleVar(Tk())
y.set(x)

# x == 0.33333333333333098
# y.get() == 0.33333333333300003

if y.get() == x:
  print "Good!"
else:
  print "Bad!"



----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2003-04-22 21:33

Message:
Logged In: YES 
user_id=31435

This is a duplicate of bug 721171, already fixed for 2.3.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=725916&group_id=5470


From noreply@sourceforge.net  Wed Apr 23 04:55:58 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 22 Apr 2003 20:55:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-726017 ] Calling empty C function repeatedly causes 'aborted'
Message-ID: <E198BMU-0004cO-00@sc8-sf-web1.sourceforge.net>

Bugs item #726017, was opened at 2003-04-23 03:55
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=726017&group_id=5470

Category: Extension Modules
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Tyson Whitehead (twhitehead)
Assigned to: Nobody/Anonymous (nobody)
Summary: Calling empty C function repeatedly causes 'aborted'

Initial Comment:
Python code... 
 
#!/usr/bin/python 
 
import TestC 
 
print 'The mighty attack...', 
for lItr in range(10000): 
  print lItr, 
  TestC.TestC() 
print '...was survived' 
 
...with C code... 
static PyObject *Test(PyObject *iSelf,PyObject *iArgs){ 
  return Py_None; 
} 
 
...results in... 
The mighty attack... 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 
19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 
40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 
61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 
82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 
102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 
117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 
132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 
147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 
162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 
177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 
192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 
207 208 209 210 211Aborted 
 
.. on both Intel and Alpha architectures (Debian unstable, lastest 
packages, kernel 2.4.20)  (don't know about other configurations), 
adding more python code above the loop changes how many it 
manages to count before 'aborting'. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=726017&group_id=5470


From noreply@sourceforge.net  Wed Apr 23 05:13:37 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 22 Apr 2003 21:13:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-726017 ] Calling empty C function repeatedly causes 'aborted'
Message-ID: <E198BdZ-00041t-00@sc8-sf-web2.sourceforge.net>

Bugs item #726017, was opened at 2003-04-22 23:55
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=726017&group_id=5470

Category: Extension Modules
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Tyson Whitehead (twhitehead)
Assigned to: Nobody/Anonymous (nobody)
Summary: Calling empty C function repeatedly causes 'aborted'

Initial Comment:
Python code... 
 
#!/usr/bin/python 
 
import TestC 
 
print 'The mighty attack...', 
for lItr in range(10000): 
  print lItr, 
  TestC.TestC() 
print '...was survived' 
 
...with C code... 
static PyObject *Test(PyObject *iSelf,PyObject *iArgs){ 
  return Py_None; 
} 
 
...results in... 
The mighty attack... 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 
19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 
40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 
61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 
82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 
102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 
117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 
132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 
147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 
162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 
177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 
192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 
207 208 209 210 211Aborted 
 
.. on both Intel and Alpha architectures (Debian unstable, lastest 
packages, kernel 2.4.20)  (don't know about other configurations), 
adding more python code above the loop changes how many it 
manages to count before 'aborting'. 

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2003-04-23 00:13

Message:
Logged In: YES 
user_id=31435

The C code uses the Python C API incorrectly.  Add

Py_INCREF(Py_None);

before you return, and then see what happens.

In addition, get in the habit of running your extensions 
under a debug build.  If you had tried that here, the 
program would have died with a well-behaved "negative 
refcount" error message.  That's too expensive to bother 
checking for in the release build.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=726017&group_id=5470


From noreply@sourceforge.net  Wed Apr 23 05:56:14 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 22 Apr 2003 21:56:14 -0700
Subject: [Python-bugs-list] [ python-Bugs-726017 ] Ignore... my stupidity...
Message-ID: <E198CIo-0000H9-00@sc8-sf-web3.sourceforge.net>

Bugs item #726017, was opened at 2003-04-23 03:55
Message generated for change (Settings changed) made by twhitehead
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=726017&group_id=5470

Category: Extension Modules
Group: Python 2.2.2
>Status: Deleted
>Resolution: Invalid
Priority: 5
Submitted By: Tyson Whitehead (twhitehead)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Ignore... my stupidity...

Initial Comment:
Python code... 
 
#!/usr/bin/python 
 
import TestC 
 
print 'The mighty attack...', 
for lItr in range(10000): 
  print lItr, 
  TestC.TestC() 
print '...was survived' 
 
...with C code... 
static PyObject *Test(PyObject *iSelf,PyObject *iArgs){ 
  return Py_None; 
} 
 
...results in... 
The mighty attack... 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 
19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 
40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 
61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 
82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 
102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 
117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 
132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 
147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 
162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 
177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 
192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 
207 208 209 210 211Aborted 
 
.. on both Intel and Alpha architectures (Debian unstable, lastest 
packages, kernel 2.4.20)  (don't know about other configurations), 
adding more python code above the loop changes how many it 
manages to count before 'aborting'. 

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-04-23 04:13

Message:
Logged In: YES 
user_id=31435

The C code uses the Python C API incorrectly.  Add

Py_INCREF(Py_None);

before you return, and then see what happens.

In addition, get in the habit of running your extensions 
under a debug build.  If you had tried that here, the 
program would have died with a well-behaved "negative 
refcount" error message.  That's too expensive to bother 
checking for in the release build.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=726017&group_id=5470


From noreply@sourceforge.net  Wed Apr 23 10:33:58 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 23 Apr 2003 02:33:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-726150 ] Broken links
Message-ID: <E198Gda-00062u-00@sc8-sf-web4.sourceforge.net>

Bugs item #726150, was opened at 2003-04-23 04:33
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=726150&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: David Abrahams (david_abrahams)
Assigned to: Nobody/Anonymous (nobody)
Summary: Broken links

Initial Comment:
The "test" and "testlist" links at
http://www.python.org/dev/doc/devel/ref/lists.html#tok-
listmaker point
into space.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=726150&group_id=5470


From noreply@sourceforge.net  Wed Apr 23 10:35:54 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 23 Apr 2003 02:35:54 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-726152 ] Website request
Message-ID: <E198GfS-00069g-00@sc8-sf-web4.sourceforge.net>

Feature Requests item #726152, was opened at 2003-04-23 04:35
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=726152&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: David Abrahams (david_abrahams)
Assigned to: Nobody/Anonymous (nobody)
Summary: Website request

Initial Comment:
A link to the SourceForge project page on the website 
would be a big help, especially to those of us who keep 
getting told to "submit a bug report to the SF tracker" ;-)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=726152&group_id=5470


From noreply@sourceforge.net  Wed Apr 23 11:39:58 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 23 Apr 2003 03:39:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-724774 ] test_getargs2 failing
Message-ID: <E198HfS-0004gW-00@sc8-sf-web2.sourceforge.net>

Bugs item #724774, was opened at 2003-04-21 00:14
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724774&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_getargs2 failing

Initial Comment:
Adding this just so it doesn't fall by the roadside (it's been discussed 
on python-dev): test_getargs2 is currently failing, at least on MacOSX.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2003-04-23 12:39

Message:
Logged In: YES 
user_id=45365

Yes, I still have the problem. The test output is attached.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-22 16:16

Message:
Logged In: YES 
user_id=33168

This is fixed on all the snake-farm machines AFAIK.  Jack,
are you still having the problems?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-21 19:42

Message:
Logged In: YES 
user_id=33168

This is failling on several other architectures in the snake
farm:  http://www.lysator.liu.se/xenofarm/python/latest.html

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724774&group_id=5470


From noreply@sourceforge.net  Wed Apr 23 12:29:30 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 23 Apr 2003 04:29:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-724774 ] test_getargs2 failing
Message-ID: <E198IRO-0005KS-00@sc8-sf-web1.sourceforge.net>

Bugs item #724774, was opened at 2003-04-21 00:14
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724774&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_getargs2 failing

Initial Comment:
Adding this just so it doesn't fall by the roadside (it's been discussed 
on python-dev): test_getargs2 is currently failing, at least on MacOSX.

----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2003-04-23 13:29

Message:
Logged In: YES 
user_id=11105

Strange, since 196608 == 0x30000, and 50331648 == 0x3000000.
Even stranger (to me) is that the test for upper case i
works, and it uses nearly the same code.

Does it help the test_H case to change line 485 of getargs.c
from 'long ival;' to 'unsigned short ival;', but I'm only
guessing?

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-04-23 12:39

Message:
Logged In: YES 
user_id=45365

Yes, I still have the problem. The test output is attached.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-22 16:16

Message:
Logged In: YES 
user_id=33168

This is fixed on all the snake-farm machines AFAIK.  Jack,
are you still having the problems?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-21 19:42

Message:
Logged In: YES 
user_id=33168

This is failling on several other architectures in the snake
farm:  http://www.lysator.liu.se/xenofarm/python/latest.html

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724774&group_id=5470


From noreply@sourceforge.net  Wed Apr 23 12:49:56 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 23 Apr 2003 04:49:56 -0700
Subject: [Python-bugs-list] [ python-Bugs-724774 ] test_getargs2 failing
Message-ID: <E198IlA-00062z-00@sc8-sf-web4.sourceforge.net>

Bugs item #724774, was opened at 2003-04-21 00:14
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724774&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_getargs2 failing

Initial Comment:
Adding this just so it doesn't fall by the roadside (it's been discussed 
on python-dev): test_getargs2 is currently failing, at least on MacOSX.

----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2003-04-23 13:49

Message:
Logged In: YES 
user_id=11105

Um, I think I found the reason. test_getargs2 uses
getargs_ul (in _testcapimodule.c) to call
PyArg_ParseTuple(), and this always passes a pointer to an
unsigned long, even for H and B format codes. On little
endian machines casting this pointer into a unsigned short
pointer works ok, but not on big endian machines. Makes sense?

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-04-23 13:29

Message:
Logged In: YES 
user_id=11105

Strange, since 196608 == 0x30000, and 50331648 == 0x3000000.
Even stranger (to me) is that the test for upper case i
works, and it uses nearly the same code.

Does it help the test_H case to change line 485 of getargs.c
from 'long ival;' to 'unsigned short ival;', but I'm only
guessing?

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-04-23 12:39

Message:
Logged In: YES 
user_id=45365

Yes, I still have the problem. The test output is attached.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-22 16:16

Message:
Logged In: YES 
user_id=33168

This is fixed on all the snake-farm machines AFAIK.  Jack,
are you still having the problems?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-21 19:42

Message:
Logged In: YES 
user_id=33168

This is failling on several other architectures in the snake
farm:  http://www.lysator.liu.se/xenofarm/python/latest.html

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724774&group_id=5470


From noreply@sourceforge.net  Wed Apr 23 14:13:05 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 23 Apr 2003 06:13:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-723801 ] logging.setLoggerClass() doesn't support new-style classes
Message-ID: <E198K3d-0007vP-00@sc8-sf-web3.sourceforge.net>

Bugs item #723801, was opened at 2003-04-18 14:06
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723801&group_id=5470

>Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Phillip J. Eby (pje)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: logging.setLoggerClass() doesn't support new-style classes

Initial Comment:
Trying to use 'logging.setLoggerClass(aNewStyleClass)'
raises a TypeError, "setLoggerClass is expecting a class".


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-23 09:13

Message:
Logged In: YES 
user_id=33168

Vinay said this change was acceptable in mail.

Checked in as:
  * Lib/logging/__init__.py 1.10

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723801&group_id=5470


From noreply@sourceforge.net  Wed Apr 23 18:33:01 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 23 Apr 2003 10:33:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-680789 ] repr() of large array objects takes quadratic time
Message-ID: <E198O7B-00049C-00@sc8-sf-web2.sourceforge.net>

Bugs item #680789, was opened at 2003-02-05 06:00
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=680789&group_id=5470

Category: Python Library
Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jurjen N.E. Bos (jneb)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: repr() of large array objects takes quadratic time

Initial Comment:
This is a bug and a partial patch.

If I debug a program that contains a ridiculously large array (8M entries in my case), the debugger takes forever.
It happens in Mac OS X, Python 2.2, but I found the bug in is the repr module, so it is probably universal.
The thing is, that after the fix below, it still doesn't work!
Did I miss something trivial (like repr is builtin, or something like that?). Would someone with Mac OS X experience help out here, please (Jack?).

Here's the diff to make repr.repr work with large arrays:
13a14
>       self.maxarray = 5
50a52,62
>     def repr_array(self, x, level):
>         n = len(x)
>       header = "array('"+x.typecode+"', ["
>         if n == 0: return header+"])"
>         if level <= 0: return header+"...])"
>         s = ''
>         for i in range(min(n, self.maxarray)):
>             if s: s = s + ', '
>             s = s + self.repr1(x[i], level-1)
>         if n > self.maxarray: s = s + ', ...'
>         return header + s + "])"

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-23 12:33

Message:
Logged In: YES 
user_id=80475

Fixed this up by converting the array to a list and then 
using the list object's efficient repr().

See Modules/arraymodule.c 2.87.

Since I categorize this as a performance issue and not a 
bug, I've applied the fix to Py2.3 but am not 
recommending for backport.

----------------------------------------------------------------------

Comment By: logistix (logistix)
Date: 2003-02-11 20:43

Message:
Logged In: YES 
user_id=699438

arraymodule's repr used "string += ',' + el" for each element in 
the array.  Lists and dicts did a string.join to build the repr.

Attached patch builds a tuple of array elements and then 
joins them.  (actually for some reason I can't attach now, I'll 
post the patch in patch manager)

This fixes the time issue, but I don't know enough about how 
you guys manage memory in each case to tell what impact 
that'll have on really, really big arrays (although I imagine it 
takes more memory).



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-02-06 20:40

Message:
Logged In: YES 
user_id=31435

I can't make time for this, so unassigned it.  It would make 
a good, brief project for someone -- the list and dict 
tp_reprs are linear-time, and tp_repr for array.array 
objects shouldn't be any harder than they were.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-02-06 16:37

Message:
Logged In: YES 
user_id=45365

Okay, so the real bug is that tp_repr of array objects takes quadratic time.

I'm changing the summary of this report then, and assigning back to you (Tim), on the basis that you did more checkins on arraymodule than I did. Feel free to pass the potato on:-)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-02-05 18:08

Message:
Logged In: YES 
user_id=31435

pdb does import repr.py, but probably doesn't use it in 
whatever way Jurjen is using to display his big array.

WRT that, note that Jurjen is using array.array objects, not 
lists.  The internal array.array tp_repr slot is quadratic-time in 
the size of the array, while list's tp_repr is linear time.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-02-05 17:40

Message:
Logged In: YES 
user_id=45365

The fix is fine (it works for me the same way as for Tim), but I think we're shooting past the problem here.

First, pdb doesn't use repr.repr(), it uses the normal builtin repr().

Second, I don't see any sluggishness in pdb with large arrays. I tried
debugging
def foo():
    a = range(8000000)
and there was no problem. Allocating the object took a bit of time, yes, and if you actually try to print it you'll stare at about 800K lines filled with digits scrolling over your screen, but that is to be expected.

Could it be your sluggishness is coming from something else? For example, MacOSX starts behaving *very* badly if your root disk is full, because then it can't allocate swap space, and due to its optimistic behaviour it comes to a grinding halt.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-02-05 13:36

Message:
Logged In: YES 
user_id=31435

Nice to see you, Jurgen!  I checked this into current CVS, 
and it works fine for me in isolation:

>>> len(a)
11055060
>>> repr.repr(a)
"array('i', [0, 1, 2, 3, 4, ...])"
>>>

That goes in an eyeblink.  So more detail is needed about 
what "it still doesn't work!" means.  Assigned to Jack, and he 
can use current CVS to try it.

Lib/repr.py; new revision: 1.15
Lib/test/test_repr.py; new revision: 1.16
Misc/NEWS; new revision: 1.642

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=680789&group_id=5470


From noreply@sourceforge.net  Wed Apr 23 19:04:30 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 23 Apr 2003 11:04:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-724774 ] test_getargs2 failing
Message-ID: <E198Obe-0008TC-00@sc8-sf-web3.sourceforge.net>

Bugs item #724774, was opened at 2003-04-20 18:14
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724774&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
>Assigned to: Thomas Heller (theller)
Summary: test_getargs2 failing

Initial Comment:
Adding this just so it doesn't fall by the roadside (it's been discussed 
on python-dev): test_getargs2 is currently failing, at least on MacOSX.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-23 14:04

Message:
Logged In: YES 
user_id=6380

Yes, that makes sense, and I remember seeing that and
thinking, "hmm, that's not right". You probably need
separate C functions for each C data type to test. :-(

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-04-23 07:49

Message:
Logged In: YES 
user_id=11105

Um, I think I found the reason. test_getargs2 uses
getargs_ul (in _testcapimodule.c) to call
PyArg_ParseTuple(), and this always passes a pointer to an
unsigned long, even for H and B format codes. On little
endian machines casting this pointer into a unsigned short
pointer works ok, but not on big endian machines. Makes sense?

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-04-23 07:29

Message:
Logged In: YES 
user_id=11105

Strange, since 196608 == 0x30000, and 50331648 == 0x3000000.
Even stranger (to me) is that the test for upper case i
works, and it uses nearly the same code.

Does it help the test_H case to change line 485 of getargs.c
from 'long ival;' to 'unsigned short ival;', but I'm only
guessing?

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-04-23 06:39

Message:
Logged In: YES 
user_id=45365

Yes, I still have the problem. The test output is attached.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-22 10:16

Message:
Logged In: YES 
user_id=33168

This is fixed on all the snake-farm machines AFAIK.  Jack,
are you still having the problems?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-21 13:42

Message:
Logged In: YES 
user_id=33168

This is failling on several other architectures in the snake
farm:  http://www.lysator.liu.se/xenofarm/python/latest.html

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724774&group_id=5470


From noreply@sourceforge.net  Wed Apr 23 19:59:16 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 23 Apr 2003 11:59:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-726446 ] textwrap.wrap infinite loop
Message-ID: <E198PSe-0001Bq-00@sc8-sf-web2.sourceforge.net>

Bugs item #726446, was opened at 2003-04-23 14:59
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=726446&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason Petrone (jpetrone)
Assigned to: Nobody/Anonymous (nobody)
Summary: textwrap.wrap infinite loop

Initial Comment:
textwrap.wrap appears to go into an infinite loop
when called with a width <= 0.  I don't know what the
correct 
behavior  here should be, but I'm guessing this isn't it.

Maybe it should be throwing an exception?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=726446&group_id=5470


From noreply@sourceforge.net  Wed Apr 23 20:00:19 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 23 Apr 2003 12:00:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-557704 ] netrc module can't handle all passwords
Message-ID: <E198PTf-00074M-00@sc8-sf-web1.sourceforge.net>

Bugs item #557704, was opened at 2002-05-18 12:18
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=557704&group_id=5470

Category: Python Library
Group: Python 2.2.1
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Bram Moolenaar (vimboss)
Assigned to: Raymond Hettinger (rhettinger)
Summary: netrc module can't handle all passwords

Initial Comment:
When a ~/.netrc file has a password with non-word
characters parsing fails.  Since it is recommended to
use punctuation characters in passwords, this means
most netrc files can't be parsed. An example of a line
in ~/.netrc that fails:

machine piet.puk.com  	login foo 	password bar!

Additionally, entries in netrc may not have a login
name (e.g., for mail servers).  These entries should be
silently skipped. An example of a line that fails:

machine mail          password fruit

The included diff is a partial solution.  It allows all
ASCII punctuation characters to be used in passwords. 
Non-ASCII characters should probably also be allowed.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-23 14:00

Message:
Logged In: YES 
user_id=80475

Revised netrc.py to include the additional ascii punctuation 
characters.  Omitted the other logic changes.  See 
Lib/netrc.py 1.17.

Since this is more of a feature request than a bug, 
including in Py2.3 but not recommending for backporting.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-22 07:28

Message:
Logged In: YES 
user_id=6380

Raymond, can you deal with this or find someone else? (Maybe
the fellow who last patched shlex.py?)

----------------------------------------------------------------------

Comment By: Bram Moolenaar (vimboss)
Date: 2003-04-22 06:05

Message:
Logged In: YES 
user_id=57665

Can someone please do something about this bug?  It has been
open for almost a year now and it still can't handle my
netrc file.  At least include a temporary fix!  My patch
plus the remarks from rhettinger should be sufficient.

----------------------------------------------------------------------

Comment By: Bram Moolenaar (vimboss)
Date: 2002-11-08 06:46

Message:
Logged In: YES 
user_id=57665

Note that the old Netrc class in the ftplib module has a
different approach at parsing the .netrc file.  This might
actually work much better.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-05 13:43

Message:
Logged In: YES 
user_id=6380

I think Fred knows this code.

I think Eric Raymond (the original author) wrote this as an 
example of his shlex. :-)

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-06-02 07:48

Message:
Logged In: YES 
user_id=44345

I think a better solution would be to not use shlex to parse netrc files.  
Netrc files aren't shells.  The whitespace is significant if it occurs inside a 
password.  I'd just use re.split(r'(\s+)') and restore the password when I 
encounterd the "password" keyword.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-18 20:56

Message:
Logged In: YES 
user_id=80475

Expanding keyspace is generally a good idea; however, the 
significance of meta-characters is bound to bite someone in 
the behind with a hard to find error.  So, please 
reconsider single-quote, double-quote, backslash, 
greaterthan, lessthan, and pipe.

Looking at first part of the patch, consider:
- removing the TODO on line 31
- wrapping the character list in triple-quotes on line 32
- using the r'' form on line 32 to eliminate backslashes in 
the character list

Looking at the second part of the patch, I don't follow (am 
perhaps being daft) why expanding the keyspace necessitates 
changing the login logic.

The idea of allowing non-ASCII characters would be cool if 
the world had already universally accepted Latin-1 coding.  
That conflict is the reason that site.py defaults to ASCII 
encoding instead of handling non-US codings out of the box.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=557704&group_id=5470


From noreply@sourceforge.net  Wed Apr 23 20:12:46 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 23 Apr 2003 12:12:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-557704 ] netrc module can't handle all passwords
Message-ID: <E198Pfi-0004GO-00@sc8-sf-web3.sourceforge.net>

Bugs item #557704, was opened at 2002-05-18 13:18
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=557704&group_id=5470

Category: Python Library
Group: Python 2.2.1
>Status: Open
Resolution: Fixed
Priority: 7
Submitted By: Bram Moolenaar (vimboss)
Assigned to: Raymond Hettinger (rhettinger)
Summary: netrc module can't handle all passwords

Initial Comment:
When a ~/.netrc file has a password with non-word
characters parsing fails.  Since it is recommended to
use punctuation characters in passwords, this means
most netrc files can't be parsed. An example of a line
in ~/.netrc that fails:

machine piet.puk.com  	login foo 	password bar!

Additionally, entries in netrc may not have a login
name (e.g., for mail servers).  These entries should be
silently skipped. An example of a line that fails:

machine mail          password fruit

The included diff is a partial solution.  It allows all
ASCII punctuation characters to be used in passwords. 
Non-ASCII characters should probably also be allowed.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-23 15:12

Message:
Logged In: YES 
user_id=6380

Given the size and nature of the patch I have no problem
with a 2.2.3 backport.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-23 15:00

Message:
Logged In: YES 
user_id=80475

Revised netrc.py to include the additional ascii punctuation 
characters.  Omitted the other logic changes.  See 
Lib/netrc.py 1.17.

Since this is more of a feature request than a bug, 
including in Py2.3 but not recommending for backporting.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-22 08:28

Message:
Logged In: YES 
user_id=6380

Raymond, can you deal with this or find someone else? (Maybe
the fellow who last patched shlex.py?)

----------------------------------------------------------------------

Comment By: Bram Moolenaar (vimboss)
Date: 2003-04-22 07:05

Message:
Logged In: YES 
user_id=57665

Can someone please do something about this bug?  It has been
open for almost a year now and it still can't handle my
netrc file.  At least include a temporary fix!  My patch
plus the remarks from rhettinger should be sufficient.

----------------------------------------------------------------------

Comment By: Bram Moolenaar (vimboss)
Date: 2002-11-08 06:46

Message:
Logged In: YES 
user_id=57665

Note that the old Netrc class in the ftplib module has a
different approach at parsing the .netrc file.  This might
actually work much better.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-05 14:43

Message:
Logged In: YES 
user_id=6380

I think Fred knows this code.

I think Eric Raymond (the original author) wrote this as an 
example of his shlex. :-)

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-06-02 08:48

Message:
Logged In: YES 
user_id=44345

I think a better solution would be to not use shlex to parse netrc files.  
Netrc files aren't shells.  The whitespace is significant if it occurs inside a 
password.  I'd just use re.split(r'(\s+)') and restore the password when I 
encounterd the "password" keyword.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-18 21:56

Message:
Logged In: YES 
user_id=80475

Expanding keyspace is generally a good idea; however, the 
significance of meta-characters is bound to bite someone in 
the behind with a hard to find error.  So, please 
reconsider single-quote, double-quote, backslash, 
greaterthan, lessthan, and pipe.

Looking at first part of the patch, consider:
- removing the TODO on line 31
- wrapping the character list in triple-quotes on line 32
- using the r'' form on line 32 to eliminate backslashes in 
the character list

Looking at the second part of the patch, I don't follow (am 
perhaps being daft) why expanding the keyspace necessitates 
changing the login logic.

The idea of allowing non-ASCII characters would be cool if 
the world had already universally accepted Latin-1 coding.  
That conflict is the reason that site.py defaults to ASCII 
encoding instead of handling non-US codings out of the box.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=557704&group_id=5470


From noreply@sourceforge.net  Wed Apr 23 20:17:24 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 23 Apr 2003 12:17:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-724774 ] test_getargs2 failing
Message-ID: <E198PkC-0007Dd-00@sc8-sf-web4.sourceforge.net>

Bugs item #724774, was opened at 2003-04-21 00:14
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724774&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Thomas Heller (theller)
Summary: test_getargs2 failing

Initial Comment:
Adding this just so it doesn't fall by the roadside (it's been discussed 
on python-dev): test_getargs2 is currently failing, at least on MacOSX.

----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2003-04-23 21:17

Message:
Logged In: YES 
user_id=11105

Jack, if I try to fix this (by implementing the C functions
needed) would you be able to test this, or should we simply
comment out the failing tests and do this after the release? 

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-23 20:04

Message:
Logged In: YES 
user_id=6380

Yes, that makes sense, and I remember seeing that and
thinking, "hmm, that's not right". You probably need
separate C functions for each C data type to test. :-(

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-04-23 13:49

Message:
Logged In: YES 
user_id=11105

Um, I think I found the reason. test_getargs2 uses
getargs_ul (in _testcapimodule.c) to call
PyArg_ParseTuple(), and this always passes a pointer to an
unsigned long, even for H and B format codes. On little
endian machines casting this pointer into a unsigned short
pointer works ok, but not on big endian machines. Makes sense?

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-04-23 13:29

Message:
Logged In: YES 
user_id=11105

Strange, since 196608 == 0x30000, and 50331648 == 0x3000000.
Even stranger (to me) is that the test for upper case i
works, and it uses nearly the same code.

Does it help the test_H case to change line 485 of getargs.c
from 'long ival;' to 'unsigned short ival;', but I'm only
guessing?

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-04-23 12:39

Message:
Logged In: YES 
user_id=45365

Yes, I still have the problem. The test output is attached.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-22 16:16

Message:
Logged In: YES 
user_id=33168

This is fixed on all the snake-farm machines AFAIK.  Jack,
are you still having the problems?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-21 19:42

Message:
Logged In: YES 
user_id=33168

This is failling on several other architectures in the snake
farm:  http://www.lysator.liu.se/xenofarm/python/latest.html

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724774&group_id=5470


From noreply@sourceforge.net  Wed Apr 23 20:31:42 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 23 Apr 2003 12:31:42 -0700
Subject: [Python-bugs-list] [ python-Bugs-726446 ] textwrap.wrap infinite loop
Message-ID: <E198Py2-0007xG-00@sc8-sf-web4.sourceforge.net>

Bugs item #726446, was opened at 2003-04-23 13:59
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=726446&group_id=5470

Category: Python Library
>Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason Petrone (jpetrone)
>Assigned to: Greg Ward (gward)
Summary: textwrap.wrap infinite loop

Initial Comment:
textwrap.wrap appears to go into an infinite loop
when called with a width <= 0.  I don't know what the
correct 
behavior  here should be, but I'm guessing this isn't it.

Maybe it should be throwing an exception?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=726446&group_id=5470


From noreply@sourceforge.net  Wed Apr 23 20:38:42 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 23 Apr 2003 12:38:42 -0700
Subject: [Python-bugs-list] [ python-Bugs-557704 ] netrc module can't handle all passwords
Message-ID: <E198Q4o-0008N8-00@sc8-sf-web4.sourceforge.net>

Bugs item #557704, was opened at 2002-05-18 12:18
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=557704&group_id=5470

Category: Python Library
Group: Python 2.2.1
>Status: Closed
Resolution: Fixed
Priority: 7
Submitted By: Bram Moolenaar (vimboss)
Assigned to: Raymond Hettinger (rhettinger)
Summary: netrc module can't handle all passwords

Initial Comment:
When a ~/.netrc file has a password with non-word
characters parsing fails.  Since it is recommended to
use punctuation characters in passwords, this means
most netrc files can't be parsed. An example of a line
in ~/.netrc that fails:

machine piet.puk.com  	login foo 	password bar!

Additionally, entries in netrc may not have a login
name (e.g., for mail servers).  These entries should be
silently skipped. An example of a line that fails:

machine mail          password fruit

The included diff is a partial solution.  It allows all
ASCII punctuation characters to be used in passwords. 
Non-ASCII characters should probably also be allowed.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-23 14:38

Message:
Logged In: YES 
user_id=80475

Backported for 2.2.3.
Closing bug.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-23 14:12

Message:
Logged In: YES 
user_id=6380

Given the size and nature of the patch I have no problem
with a 2.2.3 backport.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-23 14:00

Message:
Logged In: YES 
user_id=80475

Revised netrc.py to include the additional ascii punctuation 
characters.  Omitted the other logic changes.  See 
Lib/netrc.py 1.17.

Since this is more of a feature request than a bug, 
including in Py2.3 but not recommending for backporting.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-22 07:28

Message:
Logged In: YES 
user_id=6380

Raymond, can you deal with this or find someone else? (Maybe
the fellow who last patched shlex.py?)

----------------------------------------------------------------------

Comment By: Bram Moolenaar (vimboss)
Date: 2003-04-22 06:05

Message:
Logged In: YES 
user_id=57665

Can someone please do something about this bug?  It has been
open for almost a year now and it still can't handle my
netrc file.  At least include a temporary fix!  My patch
plus the remarks from rhettinger should be sufficient.

----------------------------------------------------------------------

Comment By: Bram Moolenaar (vimboss)
Date: 2002-11-08 06:46

Message:
Logged In: YES 
user_id=57665

Note that the old Netrc class in the ftplib module has a
different approach at parsing the .netrc file.  This might
actually work much better.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-05 13:43

Message:
Logged In: YES 
user_id=6380

I think Fred knows this code.

I think Eric Raymond (the original author) wrote this as an 
example of his shlex. :-)

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-06-02 07:48

Message:
Logged In: YES 
user_id=44345

I think a better solution would be to not use shlex to parse netrc files.  
Netrc files aren't shells.  The whitespace is significant if it occurs inside a 
password.  I'd just use re.split(r'(\s+)') and restore the password when I 
encounterd the "password" keyword.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-18 20:56

Message:
Logged In: YES 
user_id=80475

Expanding keyspace is generally a good idea; however, the 
significance of meta-characters is bound to bite someone in 
the behind with a hard to find error.  So, please 
reconsider single-quote, double-quote, backslash, 
greaterthan, lessthan, and pipe.

Looking at first part of the patch, consider:
- removing the TODO on line 31
- wrapping the character list in triple-quotes on line 32
- using the r'' form on line 32 to eliminate backslashes in 
the character list

Looking at the second part of the patch, I don't follow (am 
perhaps being daft) why expanding the keyspace necessitates 
changing the login logic.

The idea of allowing non-ASCII characters would be cool if 
the world had already universally accepted Latin-1 coding.  
That conflict is the reason that site.py defaults to ASCII 
encoding instead of handling non-US codings out of the box.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=557704&group_id=5470


From noreply@sourceforge.net  Wed Apr 23 20:52:18 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 23 Apr 2003 12:52:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-557704 ] netrc module can't handle all passwords
Message-ID: <E198QHy-0000l6-00@sc8-sf-web4.sourceforge.net>

Bugs item #557704, was opened at 2002-05-18 12:18
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=557704&group_id=5470

Category: Python Library
Group: Python 2.2.1
Status: Closed
Resolution: Fixed
Priority: 7
Submitted By: Bram Moolenaar (vimboss)
Assigned to: Raymond Hettinger (rhettinger)
Summary: netrc module can't handle all passwords

Initial Comment:
When a ~/.netrc file has a password with non-word
characters parsing fails.  Since it is recommended to
use punctuation characters in passwords, this means
most netrc files can't be parsed. An example of a line
in ~/.netrc that fails:

machine piet.puk.com  	login foo 	password bar!

Additionally, entries in netrc may not have a login
name (e.g., for mail servers).  These entries should be
silently skipped. An example of a line that fails:

machine mail          password fruit

The included diff is a partial solution.  It allows all
ASCII punctuation characters to be used in passwords. 
Non-ASCII characters should probably also be allowed.

----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2003-04-23 14:52

Message:
Logged In: YES 
user_id=44345

This is still not correct, as passwords in .netrc files can't contain spaces.
The netrc module is perhaps a good demonstration of the shlex module,
but I wouldn't rely on it for actual use.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-23 14:38

Message:
Logged In: YES 
user_id=80475

Backported for 2.2.3.
Closing bug.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-23 14:12

Message:
Logged In: YES 
user_id=6380

Given the size and nature of the patch I have no problem
with a 2.2.3 backport.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-23 14:00

Message:
Logged In: YES 
user_id=80475

Revised netrc.py to include the additional ascii punctuation 
characters.  Omitted the other logic changes.  See 
Lib/netrc.py 1.17.

Since this is more of a feature request than a bug, 
including in Py2.3 but not recommending for backporting.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-22 07:28

Message:
Logged In: YES 
user_id=6380

Raymond, can you deal with this or find someone else? (Maybe
the fellow who last patched shlex.py?)

----------------------------------------------------------------------

Comment By: Bram Moolenaar (vimboss)
Date: 2003-04-22 06:05

Message:
Logged In: YES 
user_id=57665

Can someone please do something about this bug?  It has been
open for almost a year now and it still can't handle my
netrc file.  At least include a temporary fix!  My patch
plus the remarks from rhettinger should be sufficient.

----------------------------------------------------------------------

Comment By: Bram Moolenaar (vimboss)
Date: 2002-11-08 05:46

Message:
Logged In: YES 
user_id=57665

Note that the old Netrc class in the ftplib module has a
different approach at parsing the .netrc file.  This might
actually work much better.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-05 13:43

Message:
Logged In: YES 
user_id=6380

I think Fred knows this code.

I think Eric Raymond (the original author) wrote this as an 
example of his shlex. :-)

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-06-02 07:48

Message:
Logged In: YES 
user_id=44345

I think a better solution would be to not use shlex to parse netrc files.  
Netrc files aren't shells.  The whitespace is significant if it occurs inside a 
password.  I'd just use re.split(r'(\s+)') and restore the password when I 
encounterd the "password" keyword.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-18 20:56

Message:
Logged In: YES 
user_id=80475

Expanding keyspace is generally a good idea; however, the 
significance of meta-characters is bound to bite someone in 
the behind with a hard to find error.  So, please 
reconsider single-quote, double-quote, backslash, 
greaterthan, lessthan, and pipe.

Looking at first part of the patch, consider:
- removing the TODO on line 31
- wrapping the character list in triple-quotes on line 32
- using the r'' form on line 32 to eliminate backslashes in 
the character list

Looking at the second part of the patch, I don't follow (am 
perhaps being daft) why expanding the keyspace necessitates 
changing the login logic.

The idea of allowing non-ASCII characters would be cool if 
the world had already universally accepted Latin-1 coding.  
That conflict is the reason that site.py defaults to ASCII 
encoding instead of handling non-US codings out of the box.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=557704&group_id=5470


From noreply@sourceforge.net  Wed Apr 23 20:55:16 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 23 Apr 2003 12:55:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-724771 ] test_grp failing
Message-ID: <E198QKq-0006ck-00@sc8-sf-web3.sourceforge.net>

Bugs item #724771, was opened at 2003-04-21 00:13
Message generated for change (Comment added) made by doerwalter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724771&group_id=5470

Category: None
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Jack Jansen (jackjansen)
>Assigned to: Jack Jansen (jackjansen)
Summary: test_grp failing

Initial Comment:
Adding this just so it doesn't fall by the roadside (it's been discussed 
on python-dev): test_grp is failing on MacOSX, probably because
there are multiple groups with the same numeric id (didn't 
investigate, though).

----------------------------------------------------------------------

>Comment By: Walter Dörwald (doerwalter)
Date: 2003-04-23 21:55

Message:
Logged In: YES 
user_id=89016

I checked in test_grp.py 1.15, which will hopefully fix the
problem: Mac OS X returns "*" as the password in
grp.getgrall() and "" in grp.getgrgid(). Does test_grp work
now? Should the same fix be done for test_pwd?

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-04-23 00:16

Message:
Logged In: YES 
user_id=45365

It stil fails, sigh.

I've added the output, maybe that tells you more?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-22 16:17

Message:
Logged In: YES 
user_id=33168

I believe this problem was fixed on all the snake-farm
machines after Walter's last checkins.  Thanks Walter.

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2003-04-22 16:14

Message:
Logged In: YES 
user_id=89016

Could you try the attached patch and post the output?

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-04-22 15:28

Message:
Logged In: YES 
user_id=45365

Still fails:
  File "/Users/jack/src/python/Lib/test/test_grp.py", line 37, in test_values
    self.assert_(grp.getgrgid(e.gr_gid) in entriesbygid[e.gr_gid])
  File "/Users/jack/src/python/Lib/unittest.py", line 268, in failUnless
    if not expr: raise self.failureException, msg


----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2003-04-22 13:09

Message:
Logged In: YES 
user_id=89016

According to
http://www.lysator.liu.se/xenofarm/python/files/579_3/python-testlog.txt
the problem is not duplicate ids, but duplicate names. I've
changed
test_pwd and test_grp, so that they handle names in the same
way as ids. (test_pwd.py 1.15, test_grp.py 1.14). Does this
fix the problem?


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-21 19:42

Message:
Logged In: YES 
user_id=33168

This is failling on several other architectures in the snake
farm:  http://www.lysator.liu.se/xenofarm/python/latest.html

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724771&group_id=5470


From noreply@sourceforge.net  Wed Apr 23 21:14:49 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 23 Apr 2003 13:14:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-646592 ] netrc & special chars in passwords
Message-ID: <E198Qdl-00025n-00@sc8-sf-web4.sourceforge.net>

Bugs item #646592, was opened at 2002-12-01 14:11
Message generated for change (Settings changed) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=646592&group_id=5470

Category: Python Library
Group: Python 2.2.2
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: netrc & special chars in passwords

Initial Comment:
[ from http://bugs.debian.org/168426 ]

checked with 2.2.2 and CVS HEAD

 $ cat  ~/.netrc
machine localhost login ftp password my[pass

>>> import netrc
>>> n=netrc.netrc()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.2/netrc.py", line 80, in __init__
    file, lexer.lineno)
netrc.NetrcParseError: bad follower token '['
(/home/doko/.netrc, line 1)

$ cat  ~/.netrc
machine localhost login ftp password "my[pass"

is a workaround. Although on the netrc(5) "BSD File
Formats Manual" page, I cannot find anything that
enforces the quotes.


----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2003-04-23 15:14

Message:
Logged In: YES 
user_id=44345

Closing - duplicate of 557704 which was just closed.  The fix
there was backported to the 2.2 maintenance branch, so 2.2.3
should have the fix.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=646592&group_id=5470


From noreply@sourceforge.net  Wed Apr 23 22:02:51 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 23 Apr 2003 14:02:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-557704 ] netrc module can't handle all passwords
Message-ID: <E198ROF-00007c-00@sc8-sf-web2.sourceforge.net>

Bugs item #557704, was opened at 2002-05-18 19:18
Message generated for change (Comment added) made by vimboss
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=557704&group_id=5470

Category: Python Library
Group: Python 2.2.1
>Status: Open
Resolution: Fixed
Priority: 7
Submitted By: Bram Moolenaar (vimboss)
Assigned to: Raymond Hettinger (rhettinger)
Summary: netrc module can't handle all passwords

Initial Comment:
When a ~/.netrc file has a password with non-word
characters parsing fails.  Since it is recommended to
use punctuation characters in passwords, this means
most netrc files can't be parsed. An example of a line
in ~/.netrc that fails:

machine piet.puk.com  	login foo 	password bar!

Additionally, entries in netrc may not have a login
name (e.g., for mail servers).  These entries should be
silently skipped. An example of a line that fails:

machine mail          password fruit

The included diff is a partial solution.  It allows all
ASCII punctuation characters to be used in passwords. 
Non-ASCII characters should probably also be allowed.

----------------------------------------------------------------------

>Comment By: Bram Moolenaar (vimboss)
Date: 2003-04-23 23:02

Message:
Logged In: YES 
user_id=57665

I am glad the special characters in passwords are now
accepted.  But that is only half a fix!  My ~/.netrc
contains entries without a "login" field, thus I still
cannot use the netrc module, it bails out at the first line.  
Therefore I have re-opened this issue.
All other programs work just fine with this .netrc file. 
Please at least do not produce the NetrcParseError when the
"login" field is omitted.  This can be done by changing the
"else:" above "malformed %s entry" to "elif not password:".
 That is the minimal change to make this module work on my
system.

Note to montanaro: I have not seen a .netrc file that has a
space in the password.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-04-23 21:52

Message:
Logged In: YES 
user_id=44345

This is still not correct, as passwords in .netrc files can't contain spaces.
The netrc module is perhaps a good demonstration of the shlex module,
but I wouldn't rely on it for actual use.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-23 21:38

Message:
Logged In: YES 
user_id=80475

Backported for 2.2.3.
Closing bug.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-23 21:12

Message:
Logged In: YES 
user_id=6380

Given the size and nature of the patch I have no problem
with a 2.2.3 backport.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-23 21:00

Message:
Logged In: YES 
user_id=80475

Revised netrc.py to include the additional ascii punctuation 
characters.  Omitted the other logic changes.  See 
Lib/netrc.py 1.17.

Since this is more of a feature request than a bug, 
including in Py2.3 but not recommending for backporting.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-22 14:28

Message:
Logged In: YES 
user_id=6380

Raymond, can you deal with this or find someone else? (Maybe
the fellow who last patched shlex.py?)

----------------------------------------------------------------------

Comment By: Bram Moolenaar (vimboss)
Date: 2003-04-22 13:05

Message:
Logged In: YES 
user_id=57665

Can someone please do something about this bug?  It has been
open for almost a year now and it still can't handle my
netrc file.  At least include a temporary fix!  My patch
plus the remarks from rhettinger should be sufficient.

----------------------------------------------------------------------

Comment By: Bram Moolenaar (vimboss)
Date: 2002-11-08 12:46

Message:
Logged In: YES 
user_id=57665

Note that the old Netrc class in the ftplib module has a
different approach at parsing the .netrc file.  This might
actually work much better.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-05 20:43

Message:
Logged In: YES 
user_id=6380

I think Fred knows this code.

I think Eric Raymond (the original author) wrote this as an 
example of his shlex. :-)

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-06-02 14:48

Message:
Logged In: YES 
user_id=44345

I think a better solution would be to not use shlex to parse netrc files.  
Netrc files aren't shells.  The whitespace is significant if it occurs inside a 
password.  I'd just use re.split(r'(\s+)') and restore the password when I 
encounterd the "password" keyword.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-19 03:56

Message:
Logged In: YES 
user_id=80475

Expanding keyspace is generally a good idea; however, the 
significance of meta-characters is bound to bite someone in 
the behind with a hard to find error.  So, please 
reconsider single-quote, double-quote, backslash, 
greaterthan, lessthan, and pipe.

Looking at first part of the patch, consider:
- removing the TODO on line 31
- wrapping the character list in triple-quotes on line 32
- using the r'' form on line 32 to eliminate backslashes in 
the character list

Looking at the second part of the patch, I don't follow (am 
perhaps being daft) why expanding the keyspace necessitates 
changing the login logic.

The idea of allowing non-ASCII characters would be cool if 
the world had already universally accepted Latin-1 coding.  
That conflict is the reason that site.py defaults to ASCII 
encoding instead of handling non-US codings out of the box.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=557704&group_id=5470


From noreply@sourceforge.net  Wed Apr 23 22:14:18 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 23 Apr 2003 14:14:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-557704 ] netrc module can't handle all passwords
Message-ID: <E198RZK-0000n7-00@sc8-sf-web2.sourceforge.net>

Bugs item #557704, was opened at 2002-05-18 12:18
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=557704&group_id=5470

Category: Python Library
Group: Python 2.2.1
Status: Open
Resolution: Fixed
Priority: 7
Submitted By: Bram Moolenaar (vimboss)
Assigned to: Raymond Hettinger (rhettinger)
Summary: netrc module can't handle all passwords

Initial Comment:
When a ~/.netrc file has a password with non-word
characters parsing fails.  Since it is recommended to
use punctuation characters in passwords, this means
most netrc files can't be parsed. An example of a line
in ~/.netrc that fails:

machine piet.puk.com  	login foo 	password bar!

Additionally, entries in netrc may not have a login
name (e.g., for mail servers).  These entries should be
silently skipped. An example of a line that fails:

machine mail          password fruit

The included diff is a partial solution.  It allows all
ASCII punctuation characters to be used in passwords. 
Non-ASCII characters should probably also be allowed.

----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2003-04-23 16:14

Message:
Logged In: YES 
user_id=44345

Passwords with spaces are valid, however I confirmed that the ftp program
which comes with Redhat Linux also gripes about passwords containing 
spaces, so my complaint is probably moot.


----------------------------------------------------------------------

Comment By: Bram Moolenaar (vimboss)
Date: 2003-04-23 16:02

Message:
Logged In: YES 
user_id=57665

I am glad the special characters in passwords are now
accepted.  But that is only half a fix!  My ~/.netrc
contains entries without a "login" field, thus I still
cannot use the netrc module, it bails out at the first line.  
Therefore I have re-opened this issue.
All other programs work just fine with this .netrc file. 
Please at least do not produce the NetrcParseError when the
"login" field is omitted.  This can be done by changing the
"else:" above "malformed %s entry" to "elif not password:".
 That is the minimal change to make this module work on my
system.

Note to montanaro: I have not seen a .netrc file that has a
space in the password.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-04-23 14:52

Message:
Logged In: YES 
user_id=44345

This is still not correct, as passwords in .netrc files can't contain spaces.
The netrc module is perhaps a good demonstration of the shlex module,
but I wouldn't rely on it for actual use.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-23 14:38

Message:
Logged In: YES 
user_id=80475

Backported for 2.2.3.
Closing bug.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-23 14:12

Message:
Logged In: YES 
user_id=6380

Given the size and nature of the patch I have no problem
with a 2.2.3 backport.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-23 14:00

Message:
Logged In: YES 
user_id=80475

Revised netrc.py to include the additional ascii punctuation 
characters.  Omitted the other logic changes.  See 
Lib/netrc.py 1.17.

Since this is more of a feature request than a bug, 
including in Py2.3 but not recommending for backporting.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-22 07:28

Message:
Logged In: YES 
user_id=6380

Raymond, can you deal with this or find someone else? (Maybe
the fellow who last patched shlex.py?)

----------------------------------------------------------------------

Comment By: Bram Moolenaar (vimboss)
Date: 2003-04-22 06:05

Message:
Logged In: YES 
user_id=57665

Can someone please do something about this bug?  It has been
open for almost a year now and it still can't handle my
netrc file.  At least include a temporary fix!  My patch
plus the remarks from rhettinger should be sufficient.

----------------------------------------------------------------------

Comment By: Bram Moolenaar (vimboss)
Date: 2002-11-08 05:46

Message:
Logged In: YES 
user_id=57665

Note that the old Netrc class in the ftplib module has a
different approach at parsing the .netrc file.  This might
actually work much better.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-05 13:43

Message:
Logged In: YES 
user_id=6380

I think Fred knows this code.

I think Eric Raymond (the original author) wrote this as an 
example of his shlex. :-)

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-06-02 07:48

Message:
Logged In: YES 
user_id=44345

I think a better solution would be to not use shlex to parse netrc files.  
Netrc files aren't shells.  The whitespace is significant if it occurs inside a 
password.  I'd just use re.split(r'(\s+)') and restore the password when I 
encounterd the "password" keyword.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-18 20:56

Message:
Logged In: YES 
user_id=80475

Expanding keyspace is generally a good idea; however, the 
significance of meta-characters is bound to bite someone in 
the behind with a hard to find error.  So, please 
reconsider single-quote, double-quote, backslash, 
greaterthan, lessthan, and pipe.

Looking at first part of the patch, consider:
- removing the TODO on line 31
- wrapping the character list in triple-quotes on line 32
- using the r'' form on line 32 to eliminate backslashes in 
the character list

Looking at the second part of the patch, I don't follow (am 
perhaps being daft) why expanding the keyspace necessitates 
changing the login logic.

The idea of allowing non-ASCII characters would be cool if 
the world had already universally accepted Latin-1 coding.  
That conflict is the reason that site.py defaults to ASCII 
encoding instead of handling non-US codings out of the box.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=557704&group_id=5470


From noreply@sourceforge.net  Thu Apr 24 00:06:32 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 23 Apr 2003 16:06:32 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-494854 ] add platform.py
Message-ID: <E198TJw-0004P8-00@sc8-sf-web1.sourceforge.net>

Feature Requests item #494854, was opened at 2001-12-18 18:16
Message generated for change (Comment added) made by jasonrm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=494854&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 7
Submitted By: Jason R. Mastaler (jasonrm)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: add platform.py

Initial Comment:
Here's a request to add Marc-Andre Lemburg's
platform.py to the Python standard library.

It provides more complete platform information
than either sys.platform or
distutils.util.get_platform()

For more info, see:
http://www.lemburg.com/files/python/platform.py


----------------------------------------------------------------------

>Comment By: Jason R. Mastaler (jasonrm)
Date: 2003-04-23 17:06

Message:
Logged In: YES 
user_id=85984

I'm assigning this to Guido, so it can be looked
at before 2.3b1 is released.

This issue seems like a no brainer to me, yet it has
been open for almost 3 years now.  I'd really
like to be able to use platform.py in Python 2.3.

----------------------------------------------------------------------

Comment By: Jason R. Mastaler (jasonrm)
Date: 2003-04-01 17:37

Message:
Logged In: YES 
user_id=85984

How about adding platform.py to the 
distribution even if there is no docs 
forthcoming?  It's not like this would be 
the first undocumented module. 
 

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-29 08:14

Message:
Logged In: YES 
user_id=21627

Is there any hope of getting documentation?

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-03-05 09:51

Message:
Logged In: YES 
user_id=38388

Guido has already approved the addition; so it's basically
just the docs that are currently missing...

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-12-19 02:27

Message:
Logged In: YES 
user_id=38388

No problem from here :-)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=494854&group_id=5470


From noreply@sourceforge.net  Thu Apr 24 00:59:32 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 23 Apr 2003 16:59:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-726600 ] pdb ignores EOF
Message-ID: <E198U9E-0002bP-00@sc8-sf-web3.sourceforge.net>

Bugs item #726600, was opened at 2003-04-23 23:59
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=726600&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Neil Schemenauer (nascheme)
Assigned to: Guido van Rossum (gvanrossum)
Summary: pdb ignores EOF

Initial Comment:
pdb does not exit on EOF.  This has always annoyed me
since I'm used to using Control-D to get out of Python
(and interactive Unix programs in general).  Today I
found an even better reason for pdb to exit on EOF.  We
have script that runs nightly.  Someone added code to
use pdb.pm() in an error occured (it is also used
interactively).  I just found a 2 GB log file filled
with PDB prompts.  I fixed the code but I still think
pdb should exit on EOF.

The fix is simple.  Change the do_EOF command in pdb.py
to do the same thing as do_quit.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=726600&group_id=5470


From noreply@sourceforge.net  Thu Apr 24 01:42:01 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 23 Apr 2003 17:42:01 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-494854 ] add platform.py
Message-ID: <E198UoL-0006KG-00@sc8-sf-web4.sourceforge.net>

Feature Requests item #494854, was opened at 2001-12-18 20:16
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=494854&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 7
Submitted By: Jason R. Mastaler (jasonrm)
>Assigned to: M.-A. Lemburg (lemburg)
Summary: add platform.py

Initial Comment:
Here's a request to add Marc-Andre Lemburg's
platform.py to the Python standard library.

It provides more complete platform information
than either sys.platform or
distutils.util.get_platform()

For more info, see:
http://www.lemburg.com/files/python/platform.py


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-23 20:42

Message:
Logged In: YES 
user_id=6380

OK, I have no problem with this. MAL, can you check it in
yourself? Maybe you can remove the history from the docstring?

----------------------------------------------------------------------

Comment By: Jason R. Mastaler (jasonrm)
Date: 2003-04-23 19:06

Message:
Logged In: YES 
user_id=85984

I'm assigning this to Guido, so it can be looked
at before 2.3b1 is released.

This issue seems like a no brainer to me, yet it has
been open for almost 3 years now.  I'd really
like to be able to use platform.py in Python 2.3.

----------------------------------------------------------------------

Comment By: Jason R. Mastaler (jasonrm)
Date: 2003-04-01 19:37

Message:
Logged In: YES 
user_id=85984

How about adding platform.py to the 
distribution even if there is no docs 
forthcoming?  It's not like this would be 
the first undocumented module. 
 

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-29 10:14

Message:
Logged In: YES 
user_id=21627

Is there any hope of getting documentation?

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-03-05 11:51

Message:
Logged In: YES 
user_id=38388

Guido has already approved the addition; so it's basically
just the docs that are currently missing...

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-12-19 04:27

Message:
Logged In: YES 
user_id=38388

No problem from here :-)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=494854&group_id=5470


From noreply@sourceforge.net  Thu Apr 24 01:44:16 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 23 Apr 2003 17:44:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-726600 ] pdb ignores EOF
Message-ID: <E198UqW-0006Ol-00@sc8-sf-web4.sourceforge.net>

Bugs item #726600, was opened at 2003-04-23 19:59
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=726600&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Duplicate
Priority: 3
Submitted By: Neil Schemenauer (nascheme)
Assigned to: Guido van Rossum (gvanrossum)
Summary: pdb ignores EOF

Initial Comment:
pdb does not exit on EOF.  This has always annoyed me
since I'm used to using Control-D to get out of Python
(and interactive Unix programs in general).  Today I
found an even better reason for pdb to exit on EOF.  We
have script that runs nightly.  Someone added code to
use pdb.pm() in an error occured (it is also used
interactively).  I just found a 2 GB log file filled
with PDB prompts.  I fixed the code but I still think
pdb should exit on EOF.

The fix is simple.  Change the do_EOF command in pdb.py
to do the same thing as do_quit.


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-23 20:44

Message:
Logged In: YES 
user_id=6380

Um, have you tried it recently? I fixed this in 2.3,  2.2.3
and even 2.1.4, last February.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=726600&group_id=5470


From noreply@sourceforge.net  Thu Apr 24 03:04:29 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 23 Apr 2003 19:04:29 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-723749 ] Compilation under Tru64
Message-ID: <E198W69-0000eP-00@sc8-sf-web4.sourceforge.net>

Feature Requests item #723749, was opened at 2003-04-18 12:34
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=723749&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Cowles (mdcowles)
Assigned to: Nobody/Anonymous (nobody)
Summary: Compilation under Tru64

Initial Comment:
[From a question sent to python-help]

For Python 2.2.2 and 2.3a2, under DEC OSFV1 True64 Unix
and gcc 3.0.4:

uname -a yields
OSF1 ms-ax1.migen.bio.example V5.1 1885 alpha

the posix module needs:

< #     define STAT _F64_stat
< #     define FSTAT _F64_fstat
---
> #     define STAT stat
> #     define FSTAT fstat
3384c3384
<       return posix_do_stat(self, args, "et:lstat",
_F64_lstat);
---
>       return posix_do_stat(self, args, "et:lstat",
lstat);


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-23 22:04

Message:
Logged In: YES 
user_id=33168

I don't recognize the code you are referring to in either
2.2.3 or 2.3.  Is it possible this has been fixed in CVS?  I
was able to build fine on Tru64 5.1 w/cc.  I don't have gcc
on the box though.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=723749&group_id=5470


From noreply@sourceforge.net  Thu Apr 24 06:41:56 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 23 Apr 2003 22:41:56 -0700
Subject: [Python-bugs-list] [ python-Bugs-723495 ] runtime_library_dirs broken under OS X
Message-ID: <E198ZUa-0007Wf-00@sc8-sf-web4.sourceforge.net>

Bugs item #723495, was opened at 2003-04-18 14:41
Message generated for change (Comment added) made by zenzen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723495&group_id=5470

Category: Distutils
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Stuart Bishop (zenzen)
Assigned to: Nobody/Anonymous (nobody)
Summary: runtime_library_dirs broken under OS X

Initial Comment:
gcc and ld on OSX don't seem to support the -R option, breaking 
runtime_library_dirs and any distutils installed extensions that require 
it.

I've only checked Python 2.2.2 so far.

----------------------------------------------------------------------

>Comment By: Stuart Bishop (zenzen)
Date: 2003-04-24 15:41

Message:
Logged In: YES 
user_id=46639

Yup - that looks like all that is needed to be done.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-04-18 21:35

Message:
Logged In: YES 
user_id=45365

It looks like backporting the rev. 1.48 fix to Lib/distutils/unixccompiler.py should do the trick. I've attached the patch that should do the trick, if you could try this that would be helpful.

----------------------------------------------------------------------

Comment By: Stuart Bishop (zenzen)
Date: 2003-04-18 21:08

Message:
Logged In: YES 
user_id=46639

Looks like this has been fixed in 2.3a2:
       if sys.platform[:6] == "darwin":
            # MacOSX's linker doesn't understand the -R flag at all
            return "-L" + dir
        elif compiler[:3] == "gcc" or compiler[:3] == "g++":
            return "-Wl,-R" + dir
        else:
            return "-R" + dir

I can't find a bug report or patch on this fix, and I don't know if it is in any 
2.2.x branch.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-04-18 18:58

Message:
Logged In: YES 
user_id=45365

Could you elaborate a bit on what breaks, and/or give an example that breaks?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723495&group_id=5470


From noreply@sourceforge.net  Thu Apr 24 09:49:10 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 24 Apr 2003 01:49:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-557704 ] netrc module can't handle all passwords
Message-ID: <E198cPm-00055f-00@sc8-sf-web3.sourceforge.net>

Bugs item #557704, was opened at 2002-05-18 12:18
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=557704&group_id=5470

Category: Python Library
Group: Python 2.2.1
Status: Open
Resolution: Fixed
>Priority: 5
Submitted By: Bram Moolenaar (vimboss)
>Assigned to: Nobody/Anonymous (nobody)
Summary: netrc module can't handle all passwords

Initial Comment:
When a ~/.netrc file has a password with non-word
characters parsing fails.  Since it is recommended to
use punctuation characters in passwords, this means
most netrc files can't be parsed. An example of a line
in ~/.netrc that fails:

machine piet.puk.com  	login foo 	password bar!

Additionally, entries in netrc may not have a login
name (e.g., for mail servers).  These entries should be
silently skipped. An example of a line that fails:

machine mail          password fruit

The included diff is a partial solution.  It allows all
ASCII punctuation characters to be used in passwords. 
Non-ASCII characters should probably also be allowed.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-24 03:49

Message:
Logged In: YES 
user_id=80475

Unassigning, in case someone else wants to explore the 
handling of spaces.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-04-23 16:14

Message:
Logged In: YES 
user_id=44345

Passwords with spaces are valid, however I confirmed that the ftp program
which comes with Redhat Linux also gripes about passwords containing 
spaces, so my complaint is probably moot.


----------------------------------------------------------------------

Comment By: Bram Moolenaar (vimboss)
Date: 2003-04-23 16:02

Message:
Logged In: YES 
user_id=57665

I am glad the special characters in passwords are now
accepted.  But that is only half a fix!  My ~/.netrc
contains entries without a "login" field, thus I still
cannot use the netrc module, it bails out at the first line.  
Therefore I have re-opened this issue.
All other programs work just fine with this .netrc file. 
Please at least do not produce the NetrcParseError when the
"login" field is omitted.  This can be done by changing the
"else:" above "malformed %s entry" to "elif not password:".
 That is the minimal change to make this module work on my
system.

Note to montanaro: I have not seen a .netrc file that has a
space in the password.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-04-23 14:52

Message:
Logged In: YES 
user_id=44345

This is still not correct, as passwords in .netrc files can't contain spaces.
The netrc module is perhaps a good demonstration of the shlex module,
but I wouldn't rely on it for actual use.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-23 14:38

Message:
Logged In: YES 
user_id=80475

Backported for 2.2.3.
Closing bug.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-23 14:12

Message:
Logged In: YES 
user_id=6380

Given the size and nature of the patch I have no problem
with a 2.2.3 backport.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-23 14:00

Message:
Logged In: YES 
user_id=80475

Revised netrc.py to include the additional ascii punctuation 
characters.  Omitted the other logic changes.  See 
Lib/netrc.py 1.17.

Since this is more of a feature request than a bug, 
including in Py2.3 but not recommending for backporting.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-22 07:28

Message:
Logged In: YES 
user_id=6380

Raymond, can you deal with this or find someone else? (Maybe
the fellow who last patched shlex.py?)

----------------------------------------------------------------------

Comment By: Bram Moolenaar (vimboss)
Date: 2003-04-22 06:05

Message:
Logged In: YES 
user_id=57665

Can someone please do something about this bug?  It has been
open for almost a year now and it still can't handle my
netrc file.  At least include a temporary fix!  My patch
plus the remarks from rhettinger should be sufficient.

----------------------------------------------------------------------

Comment By: Bram Moolenaar (vimboss)
Date: 2002-11-08 06:46

Message:
Logged In: YES 
user_id=57665

Note that the old Netrc class in the ftplib module has a
different approach at parsing the .netrc file.  This might
actually work much better.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-05 13:43

Message:
Logged In: YES 
user_id=6380

I think Fred knows this code.

I think Eric Raymond (the original author) wrote this as an 
example of his shlex. :-)

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-06-02 07:48

Message:
Logged In: YES 
user_id=44345

I think a better solution would be to not use shlex to parse netrc files.  
Netrc files aren't shells.  The whitespace is significant if it occurs inside a 
password.  I'd just use re.split(r'(\s+)') and restore the password when I 
encounterd the "password" keyword.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-18 20:56

Message:
Logged In: YES 
user_id=80475

Expanding keyspace is generally a good idea; however, the 
significance of meta-characters is bound to bite someone in 
the behind with a hard to find error.  So, please 
reconsider single-quote, double-quote, backslash, 
greaterthan, lessthan, and pipe.

Looking at first part of the patch, consider:
- removing the TODO on line 31
- wrapping the character list in triple-quotes on line 32
- using the r'' form on line 32 to eliminate backslashes in 
the character list

Looking at the second part of the patch, I don't follow (am 
perhaps being daft) why expanding the keyspace necessitates 
changing the login logic.

The idea of allowing non-ASCII characters would be cool if 
the world had already universally accepted Latin-1 coding.  
That conflict is the reason that site.py defaults to ASCII 
encoding instead of handling non-US codings out of the box.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=557704&group_id=5470


From noreply@sourceforge.net  Thu Apr 24 11:48:28 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 24 Apr 2003 03:48:28 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-686323 ] Minor array module enhancements
Message-ID: <E198eHE-0004rQ-00@sc8-sf-web4.sourceforge.net>

Feature Requests item #686323, was opened at 2003-02-13 20:13
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=686323&group_id=5470

Category: Extension Modules
Group: None
Status: Open
>Resolution: Later
Priority: 4
Submitted By: paul rubin (phr)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Minor array module enhancements

Initial Comment:
1) I notice that array('B', (2,3,4)) throws an error
saying the
2nd arg must be a list or string.  That is, array('B',
[2,3,4]) is
legal but using the tuple (2,3,4) is not.  The
limitation doesn't
seem harmful, but I also don't see any good reason for
it.  May
as well remove it.

2) Of more usefulness (and maybe of more controversy), I
think the byte array methods should accept string
arguments,
for example
   a = array('B', 'abc')
   a.append('def')
should do the obvious thing.  That gives a natural way to
build up a string in pieces instead of making a list of
strings
and doing the counterintuitive ''.join(x) maneuver. 
Appending
to byte arrays is the usual way to build up a string in
Java,
if that matters.  So I favor this change too.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-24 05:48

Message:
Logged In: YES 
user_id=80475

Added the first request as
  arraymodule.c 2.88

I'm passing on the second request for now.
Auto-promoting the argument entails attempting
to construct a new array object of the same type
as that being extended.  That is a bit cumbersome
but doable.  It also requires that any array creation
errors be trapped and re-explained the context of
array.extend().

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2003-02-13 23:42

Message:
Logged In: YES 
user_id=72053

You're correct, second request should be for extend rather
than append.

That is,

a = array('B', 'abc')
a.extend('def')

should do the obvious thing.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-02-13 23:34

Message:
Logged In: YES 
user_id=80475

The first request is reasonable.

The second is not the natural meaning of append().  In 
python, multiple appends are handled with extend().  The 
array module already provides extend.  So, for the 
example given above, the code is:

>>> a = array('B', 'abc')
>>> a.extend(array('B', 'def'))
>>> a
array('B', [97, 98, 99, 100, 101, 102])

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=686323&group_id=5470


From noreply@sourceforge.net  Thu Apr 24 14:12:25 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 24 Apr 2003 06:12:25 -0700
Subject: [Python-bugs-list] [ python-Bugs-724774 ] test_getargs2 failing
Message-ID: <E198gWX-0002VY-00@sc8-sf-web3.sourceforge.net>

Bugs item #724774, was opened at 2003-04-21 00:14
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724774&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Thomas Heller (theller)
Summary: test_getargs2 failing

Initial Comment:
Adding this just so it doesn't fall by the roadside (it's been discussed 
on python-dev): test_getargs2 is currently failing, at least on MacOSX.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2003-04-24 15:12

Message:
Logged In: YES 
user_id=45365

Yes, I will be able to test it. But it will have to be tomorrow.

BTW: does this mean that there are *no* bigendian machines in the 
snakefarm? That surprises me, I seem to remember than almost all machines 
except intels (i.e. suns, hps, sgi's) are big-endian...

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-04-23 21:17

Message:
Logged In: YES 
user_id=11105

Jack, if I try to fix this (by implementing the C functions
needed) would you be able to test this, or should we simply
comment out the failing tests and do this after the release? 

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-23 20:04

Message:
Logged In: YES 
user_id=6380

Yes, that makes sense, and I remember seeing that and
thinking, "hmm, that's not right". You probably need
separate C functions for each C data type to test. :-(

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-04-23 13:49

Message:
Logged In: YES 
user_id=11105

Um, I think I found the reason. test_getargs2 uses
getargs_ul (in _testcapimodule.c) to call
PyArg_ParseTuple(), and this always passes a pointer to an
unsigned long, even for H and B format codes. On little
endian machines casting this pointer into a unsigned short
pointer works ok, but not on big endian machines. Makes sense?

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-04-23 13:29

Message:
Logged In: YES 
user_id=11105

Strange, since 196608 == 0x30000, and 50331648 == 0x3000000.
Even stranger (to me) is that the test for upper case i
works, and it uses nearly the same code.

Does it help the test_H case to change line 485 of getargs.c
from 'long ival;' to 'unsigned short ival;', but I'm only
guessing?

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-04-23 12:39

Message:
Logged In: YES 
user_id=45365

Yes, I still have the problem. The test output is attached.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-22 16:16

Message:
Logged In: YES 
user_id=33168

This is fixed on all the snake-farm machines AFAIK.  Jack,
are you still having the problems?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-21 19:42

Message:
Logged In: YES 
user_id=33168

This is failling on several other architectures in the snake
farm:  http://www.lysator.liu.se/xenofarm/python/latest.html

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724774&group_id=5470


From noreply@sourceforge.net  Thu Apr 24 14:15:22 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 24 Apr 2003 06:15:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-723495 ] runtime_library_dirs broken under OS X
Message-ID: <E198gZO-0002ge-00@sc8-sf-web3.sourceforge.net>

Bugs item #723495, was opened at 2003-04-18 06:41
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723495&group_id=5470

Category: Distutils
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Stuart Bishop (zenzen)
>Assigned to: Jack Jansen (jackjansen)
Summary: runtime_library_dirs broken under OS X

Initial Comment:
gcc and ld on OSX don't seem to support the -R option, breaking 
runtime_library_dirs and any distutils installed extensions that require 
it.

I've only checked Python 2.2.2 so far.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2003-04-24 15:15

Message:
Logged In: YES 
user_id=45365

Ok, I'll fix if there's a 2.2.3 release upcoming. Thanks for the report!

----------------------------------------------------------------------

Comment By: Stuart Bishop (zenzen)
Date: 2003-04-24 07:41

Message:
Logged In: YES 
user_id=46639

Yup - that looks like all that is needed to be done.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-04-18 13:35

Message:
Logged In: YES 
user_id=45365

It looks like backporting the rev. 1.48 fix to Lib/distutils/unixccompiler.py should do the trick. I've attached the patch that should do the trick, if you could try this that would be helpful.

----------------------------------------------------------------------

Comment By: Stuart Bishop (zenzen)
Date: 2003-04-18 13:08

Message:
Logged In: YES 
user_id=46639

Looks like this has been fixed in 2.3a2:
       if sys.platform[:6] == "darwin":
            # MacOSX's linker doesn't understand the -R flag at all
            return "-L" + dir
        elif compiler[:3] == "gcc" or compiler[:3] == "g++":
            return "-Wl,-R" + dir
        else:
            return "-R" + dir

I can't find a bug report or patch on this fix, and I don't know if it is in any 
2.2.x branch.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-04-18 10:58

Message:
Logged In: YES 
user_id=45365

Could you elaborate a bit on what breaks, and/or give an example that breaks?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723495&group_id=5470


From noreply@sourceforge.net  Thu Apr 24 15:20:29 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 24 Apr 2003 07:20:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-715782 ] pydoc support for keywords
Message-ID: <E198haP-000467-00@sc8-sf-web2.sourceforge.net>

Bugs item #715782, was opened at 2003-04-05 06:36
Message generated for change (Settings changed) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=715782&group_id=5470

Category: Documentation
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
>Assigned to: Tim Peters (tim_one)
Summary: pydoc support for keywords

Initial Comment:
[ from http://bugs.debian.org/186775 ]

If one uses $ man perl
one gets on a path that can lead one to eventually find
docs for the
most basic commands like 'while'

However for python one sees one is to use pydoc. But
running pydoc,
one just sees
  pydoc - the Python documentation tool

  /usr/bin/pydoc <name> ...

etc. no hint about how to learn about basics like 'while'.

BTW, I wish it would say pydoc, not /usr/bin/pydoc


----------------------------------------------------------------------

Comment By: Douglas Napoleone (derivin)
Date: 2003-04-19 00:06

Message:
Logged In: YES 
user_id=541557

Could you please include the OS, install, distro for python?

the distrobution from ActiveState has a very detailed 
manpage on linux. The cygwin distrobution (currently 
hosted/maintained by RedHat) has a poor man page (similar 
yet different from your example).

To be honest, I thought there was only a GNU info page, a 
quick find of the source tree didnt turn anything up, (but Im 
building on windows).


----------------------------------------------------------------------

Comment By: Cherniavsky Beni (cben)
Date: 2003-04-06 04:33

Message:
Logged In: YES 
user_id=36166

It should suggest to run ``python`` and type ``help()``. 
Then one can type ``topics`` and access the language
documentation itself, e.g. ``LOOPING`` would tell one that
there is a ``while`` whose specific documentation is
accessible by typing the ``while`` keyword itself.  Also
some sentences about the usefulness of the Python prompt,
`dir()` and `help()` for learning might be in order...

BTW, it would be more consistent if pydoc would support the
special topics from the command line (it would require a
non-ambiguos option to avoid shadowing modules in current
directoy that happen to have one of the special name)...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=715782&group_id=5470


From noreply@sourceforge.net  Thu Apr 24 15:22:33 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 24 Apr 2003 07:22:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-726911 ] platform module needs docs (LaTeX)
Message-ID: <E198hcP-0001dB-00@sc8-sf-web4.sourceforge.net>

Bugs item #726911, was opened at 2003-04-24 10:22
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=726911&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: M.-A. Lemburg (lemburg)
Summary: platform module needs docs (LaTeX)

Initial Comment:
The platform module needs to be documented in the
Library Reference.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=726911&group_id=5470


From noreply@sourceforge.net  Thu Apr 24 15:23:08 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 24 Apr 2003 07:23:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-726911 ] platform module needs docs (LaTeX)
Message-ID: <E198hcy-00077G-00@sc8-sf-web3.sourceforge.net>

Bugs item #726911, was opened at 2003-04-24 10:22
Message generated for change (Settings changed) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=726911&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
>Priority: 6
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: M.-A. Lemburg (lemburg)
Summary: platform module needs docs (LaTeX)

Initial Comment:
The platform module needs to be documented in the
Library Reference.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=726911&group_id=5470


From noreply@sourceforge.net  Thu Apr 24 15:24:03 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 24 Apr 2003 07:24:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-726150 ] Broken links
Message-ID: <E198hdr-0007E5-00@sc8-sf-web3.sourceforge.net>

Bugs item #726150, was opened at 2003-04-23 05:33
Message generated for change (Settings changed) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=726150&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: David Abrahams (david_abrahams)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Broken links

Initial Comment:
The "test" and "testlist" links at
http://www.python.org/dev/doc/devel/ref/lists.html#tok-
listmaker point
into space.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=726150&group_id=5470


From noreply@sourceforge.net  Thu Apr 24 15:29:24 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 24 Apr 2003 07:29:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-715782 ] pydoc support for keywords
Message-ID: <E198hj2-0007ea-00@sc8-sf-web3.sourceforge.net>

Bugs item #715782, was opened at 2003-04-05 06:36
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=715782&group_id=5470

Category: Documentation
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
>Assigned to: Nobody/Anonymous (nobody)
Summary: pydoc support for keywords

Initial Comment:
[ from http://bugs.debian.org/186775 ]

If one uses $ man perl
one gets on a path that can lead one to eventually find
docs for the
most basic commands like 'while'

However for python one sees one is to use pydoc. But
running pydoc,
one just sees
  pydoc - the Python documentation tool

  /usr/bin/pydoc <name> ...

etc. no hint about how to learn about basics like 'while'.

BTW, I wish it would say pydoc, not /usr/bin/pydoc


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2003-04-24 10:29

Message:
Logged In: YES 
user_id=31435

Unassigned (I can't make time for this).

----------------------------------------------------------------------

Comment By: Douglas Napoleone (derivin)
Date: 2003-04-19 00:06

Message:
Logged In: YES 
user_id=541557

Could you please include the OS, install, distro for python?

the distrobution from ActiveState has a very detailed 
manpage on linux. The cygwin distrobution (currently 
hosted/maintained by RedHat) has a poor man page (similar 
yet different from your example).

To be honest, I thought there was only a GNU info page, a 
quick find of the source tree didnt turn anything up, (but Im 
building on windows).


----------------------------------------------------------------------

Comment By: Cherniavsky Beni (cben)
Date: 2003-04-06 04:33

Message:
Logged In: YES 
user_id=36166

It should suggest to run ``python`` and type ``help()``. 
Then one can type ``topics`` and access the language
documentation itself, e.g. ``LOOPING`` would tell one that
there is a ``while`` whose specific documentation is
accessible by typing the ``while`` keyword itself.  Also
some sentences about the usefulness of the Python prompt,
`dir()` and `help()` for learning might be in order...

BTW, it would be more consistent if pydoc would support the
special topics from the command line (it would require a
non-ambiguos option to avoid shadowing modules in current
directoy that happen to have one of the special name)...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=715782&group_id=5470


From noreply@sourceforge.net  Thu Apr 24 16:34:35 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 24 Apr 2003 08:34:35 -0700
Subject: [Python-bugs-list] [ python-Bugs-549151 ] urllib2 POSTs on redirect
Message-ID: <E198ik7-00045w-00@sc8-sf-web3.sourceforge.net>

Bugs item #549151, was opened at 2002-04-26 11:04
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: Accepted
Priority: 7
Submitted By: John J Lee (jjlee)
Assigned to: Raymond Hettinger (rhettinger)
Summary: urllib2 POSTs on redirect

Initial Comment:

urllib2 (I'm using 1.13.22 with Python 2.0, but I assume the 2.2 branch does the same) uses the 
POST method on redirect, contrary to RFC1945 section 9.3:

> 9.3  Redirection 3xx
> 
>    This class of status code indicates that further action needs to be
>    taken by the user agent in order to fulfill the request. The action
>    required may be carried out by the user agent without interaction
>    with the user if and only if the method used in the subsequent
>    request is GET or HEAD. A user agent should never automatically
>    redirect a request more than 5 times, since such redirections usually
>    indicate an infinite loop.

Can be fixed in HTTPRedirectHandler.http_error_302 by replacing
        new = Request(newurl, req.get_data())

with
        new = Request(newurl)

so that GET is done on redirect instead of POST.

I suppose the limit of 10 in the same function should be changed to 5, also.


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-24 10:34

Message:
Logged In: YES 
user_id=80475

Committed as:

Lib/urllib.py 1.157
Lib/urllib2.py 1.39
Doc/lib/liburllib.tex 1.47
Doc/lib/liburllib2.tex 1.7


Guido, would you like this backported to 2.2.3?

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2003-04-20 15:44

Message:
Logged In: YES 
user_id=261020

Just noticed that I forgot to upload one of the doc patches 
on 2003-03-05.  Here it is. 
 
The patches that need to be applied are the three I 
uploaded on 2003-03-05 (urllib.py.patch, urllib2.py.patch 
and liburllib2.tex.patch), and the liburllib.tex.patch I just 
uploaded. 
 

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-16 15:35

Message:
Logged In: YES 
user_id=6380

I think this is the right thing to do. Can you check it in?
 (There are several files -- urllib, urllib2, and its docs).

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-16 15:27

Message:
Logged In: YES 
user_id=80475

Do you have time to take this one back?  My head starts to 
explode when researching whether this is the right thing 
to do.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-03-07 15:57

Message:
Logged In: YES 
user_id=6380

I'll try to work on this.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2003-03-05 16:03

Message:
Logged In: YES 
user_id=261020

The fix for this was set to go into 2.3, but nothing has  
happened yet. 
 
There were a couple of minor details to be fixed in the 
patches, so I've done that, and uploaded new patches for  
urllib2.py, urllib.py, and their documentation files (against  
current CVS). Well, I'm just about to upload them... 
 
Jeremy, can you apply the patches and finally close this 
one now?  Let me know if anything else needs doing. 
 
This should actually close another bug on SF, too (if it's still 
open), which deals with the urllib.py case.  I can't find it,  
though.  I did attach a comment to it (before I lost it) that 
references this bug. 
 

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-10-15 10:22

Message:
Logged In: YES 
user_id=261020

Well, when I carefully read the RFC I came to the conclusion
that 301 should be redirected to GET, not POST.  I also came
to the conclusion that the RFC was slightly ambiguous on
this point, so I guess that's why A. Flavell came to the
conclusion that 301 should redirect to POST rather than GET.
Anyway, clearly the established practice is to redirect 301
as GET, so this is all academic.

Assuming he's right about Netscape / IE etc., I suppose I'm
happy for 301 to redirect without an exception, since that's
what we've agreed to do for 302.  Obviously, the docs should
say this is contrary to the RFC (as my doc patch says for
302 already).

As for urllib.py, I see the problem.  303 should still be
added, though, since that poses no problem at all.


John


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-10-11 10:40

Message:
Logged In: YES 
user_id=31392

I'm still uncertain about what to do on 301 responses.  As
you say, there are two issues to sort out: 1) what method
should a POST be redicted to and 2) whether the user should
be asked to confirm.

There's discussion of this at:
http://ppewww.ph.gla.ac.uk/~flavell/www/post-redirect.html
The page is a bit old, but I don't know if it is out of date.
It says that IE5, Netscape 4, and Mozilla 1.0 all redirect a
301 POST to a GET without user confirmation.  That seems
like a widespread disregard for the spec that we ought to
emulate.

I agree with your interpretation that urllib2 raise an
HTTPError to signal "request confirm" because an HTTPError
is also a valid response that the user could interpret.  But
of urllib, an HTTP error doesn't contain a valid response. 
The change would make it impossible for the client to do
anything if a 301 response is returned from a POST.  That
seems worse than doing the wrong.



----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-10-09 20:27

Message:
Logged In: YES 
user_id=6380

OK, over to jeremy.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-10-09 16:16

Message:
Logged In: YES 
user_id=261020

Ah.  Here it is.

John


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-10-08 13:23

Message:
Logged In: YES 
user_id=6380

Um, I don't see the patch for urllib.py.  Perhaps you didn't
check the box?

Jeremy, let's do this in 2.3, OK?

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-10-08 11:53

Message:
Logged In: YES 
user_id=261020

Guido mentioned that urllib.py should be fixed
too.  I've attached another patch.


John


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-10-05 12:44

Message:
Logged In: YES 
user_id=261020

Here is a patch for the minor documentation changes required
for the patch I uploaded earlier to fix this bug.  I've also
uploaded a slightly revised patch:

I renamed the `method' method to `get_method' for
consistency with the other methods of the Request class.
The reason this new method is there at all is because the
logic that decides whether or not a redirection should take
place is defined in terms of the method type
(GET/HEAD/POST).  urllib2 doesn't support HEAD ATM, but it
might in future.  OTOH, the Request class is supposed to be
generic -- not specific to HTTP -- so perhaps get_method
isn't really appropriate.  OTOOH, add_data is already
documented to only be meaningful for HTTP Requests.  I
suppose there could be a subclass HTTPRequest, but that's
less simple.  What do you think is best?

I also changed redirect_request to raise an exception
instead of returning None (because no other Handler should
handle the redirect), and changed its documented return
value / exception interface to be consistent with the rest
of urllib2.


John


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-06-23 14:23

Message:
Logged In: YES 
user_id=261020

First, can I underline the fact that there are two issues
here:

  1. What method should POST be redirected as for a
     particular 30x response?

  2. Should the user be asked to confirm the redirection
     (which presumably maps onto raising an HTTPError in
     urllib2)?

I think current client implementations go against the RFCs
on both these points for 302.  Contrastingly, RFC 2616's
note on 301 responses (section 10.3.2) implies that only a
subset of HTTP/1.0 (not 1.1, note) clients violate the RFCs
(1945, 2068, 2616) on point 1 for 301 responses, and I know
of no clients that violate the RFCs on point 2 for 301
responses (but I haven't tested).  Also, I guess the
original intent (for both 301 and 302) was that POSTs
represent an action, so it's dangerous in general to
redirect them without asking the user: I presume this is why
307 was brought in: 307 POSTs on redirected POST, so the
user must be asked:

10.3 Redirection 3xx
[...]
   The action required MAY be carried out by the user agent
   without interaction with the user if and only if the
   method used in the second request is GET or HEAD.

(and 303 is just meant to have the 'erroneous' 302
behaviour: GET on redirected POST, don't ask the user)

So, I agree with Guido that 302 should probably now be
treated the way most clients treat it: GET on redirected
POST, don't ask the user.  As for 301, if it *is* true that
only a few HTTP/1.0 clients have misinterpreted the RFCs on
301, we should stick to the safe behaviour indicated by the
RFC.

As for Guido's first question: A 307 should indeed be
redirected as a POST, but it should ask the user first (see
10.3 quote, above).  That's what my patch does (the 'return
None' in the else clause in redirect_request causes an
exception to be raised eventually -- maybe it should just
raise it itself).

I've attached a revised patch that deals with 302 (and 303)
in the 'erroneous' way (again: GET on redirected POST, don't
ask the user).

I suppose the comment about HTTPRedirectHandler also needs
to state that 301 and 307 POST requests are not
automatically redirected -- HTTPError is raised in that
case.


John


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-19 19:57

Message:
Logged In: YES 
user_id=6380

Hm, I thought that 307 should be treated differently than
303. In particular, a 307 response to POST should cause the
POST to be redirected. And I'm not sure about what a 301
response to POST should do.

(In the mean time I have been convinced that changing POST
to GET on 302 is the best thing to do given that most
browsers do that. The old urllib.py should be fixed too.)

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-06-19 16:57

Message:
Logged In: YES 
user_id=261020

I've attached a patch -- was simpler than I thought.

I think this is in compliance with RFC 2616.  It's also
simple for clients to inherit from HTTPRedirectHandler and
override redirect_request if, for example, they know they
want all 302 POSTs to be redirected as a GET, which removes
the need for mixing redirection code with normal client code
even when the server doesn't follow the RFC (if the server
expects a 302 POST to be redirected as a GET, for example).
Note that I had to add a method, named 'method', to the
Request class, for maintainability (it's possible that
urllib2 may be able to do methods other than GET and POST in
future).

Possibly redirect_request should take fewer parameters.

John


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-06-19 16:56

Message:
Logged In: YES 
user_id=261020

I've attached a patch -- was simpler than I thought.

I think this is in compliance with RFC 2616.  It's also
simple for clients to inherit from HTTPRedirectHandler and
override redirect_request if, for example, they know they
want all 302 POSTs to be redirected as a GET, which removes
the need for mixing redirection code with normal client code
even when the server doesn't follow the RFC (if the server
expects a 302 POST to be redirected as a GET, for example).
Note that I had to add a method, named 'method', to the
Request class, for maintainability (it's possible that
urllib2 may be able to do methods other than GET and POST in
future).

Possibly redirect_request should take fewer parameters.

John


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-06-06 16:25

Message:
Logged In: YES 
user_id=261020

Oh, I hadn't realised httplib uses HTTP/1.1 now -- and now I
check, I see that even RFC 1945 (HTTP/1.0) has a whole set of
restrictions on 30x for particular values of x which I missed
completely.

I guess it should do what Guido suggested -- report an error if a
POST is redirected -- until somebody gets time to do it properly.
I won't have time for a couple of months, but if nobody has done
it by then I'll upload a patch.


John


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-06-06 10:09

Message:
Logged In: YES 
user_id=31392

I think you need to review the current HTTP spec -- RFC 2616
-- and look at the section on redirection (10.3).  I think
urllib2 could improve its handling of redirection, but the
behavior you describe from lynx sounds incorrect.  I'd be
happy to review a patch the implemented the current spec.

Also, RFC 2616 removes the recommendation of a 5 redirect limit.




----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-29 13:10

Message:
Logged In: YES 
user_id=6380

Fair enough. I'll leve it to Jeremy to review the proposed
fix. (Note that he's busy though.)

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-04-29 11:29

Message:
Logged In: YES 
user_id=261020

I don't see why it shouldn't substitue a GET.  That certainly seems to be
the standard practice (well, at least that's what lynx does), and in the case
of the only site where I've encountered redirects on POST, the redirect URL
contains urlencoded stuff, so it clearly expects the user-agent to do a GET.
The site would break if this didn't happen, so I guess Netscape and IE must
do the same thing.

Clearly the RFC *does* allow this, though it doesn't require it (or specify
what should happen here in any way other than to say that a POST is not
allowed, in fact).  Since it's standard practice and allowed by the RFC, I
don't think it should be an error.

John


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-28 19:53

Message:
Logged In: YES 
user_id=6380

Hm, the way I interpret the text you quote, if the original
request is  a POST, it should probably not substitute a GET
but report the error.

Assigning to Jeremy since it's his module.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-04-28 11:21

Message:
Logged In: YES 
user_id=261020

1. Bug is also in 2.2 branch

2. The fix (in 2.1 and 2.2) should reflect the earlier bug fix in the 2.2 branch to add the old headers:

new = Request(newurl, headers=req.headers)

3. I guess 10 should be replaced with 4, not 5.


John


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470


From noreply@sourceforge.net  Thu Apr 24 16:49:21 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 24 Apr 2003 08:49:21 -0700
Subject: [Python-bugs-list] [ python-Bugs-549151 ] urllib2 POSTs on redirect
Message-ID: <E198iyP-0008J2-00@sc8-sf-web1.sourceforge.net>

Bugs item #549151, was opened at 2002-04-26 12:04
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: Accepted
Priority: 7
Submitted By: John J Lee (jjlee)
Assigned to: Raymond Hettinger (rhettinger)
Summary: urllib2 POSTs on redirect

Initial Comment:

urllib2 (I'm using 1.13.22 with Python 2.0, but I assume the 2.2 branch does the same) uses the 
POST method on redirect, contrary to RFC1945 section 9.3:

> 9.3  Redirection 3xx
> 
>    This class of status code indicates that further action needs to be
>    taken by the user agent in order to fulfill the request. The action
>    required may be carried out by the user agent without interaction
>    with the user if and only if the method used in the subsequent
>    request is GET or HEAD. A user agent should never automatically
>    redirect a request more than 5 times, since such redirections usually
>    indicate an infinite loop.

Can be fixed in HTTPRedirectHandler.http_error_302 by replacing
        new = Request(newurl, req.get_data())

with
        new = Request(newurl)

so that GET is done on redirect instead of POST.

I suppose the limit of 10 in the same function should be changed to 5, also.


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-24 11:49

Message:
Logged In: YES 
user_id=6380

Yes, I think that would be a good idea.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-24 11:34

Message:
Logged In: YES 
user_id=80475

Committed as:

Lib/urllib.py 1.157
Lib/urllib2.py 1.39
Doc/lib/liburllib.tex 1.47
Doc/lib/liburllib2.tex 1.7


Guido, would you like this backported to 2.2.3?

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2003-04-20 16:44

Message:
Logged In: YES 
user_id=261020

Just noticed that I forgot to upload one of the doc patches 
on 2003-03-05.  Here it is. 
 
The patches that need to be applied are the three I 
uploaded on 2003-03-05 (urllib.py.patch, urllib2.py.patch 
and liburllib2.tex.patch), and the liburllib.tex.patch I just 
uploaded. 
 

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-16 16:35

Message:
Logged In: YES 
user_id=6380

I think this is the right thing to do. Can you check it in?
 (There are several files -- urllib, urllib2, and its docs).

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-16 16:27

Message:
Logged In: YES 
user_id=80475

Do you have time to take this one back?  My head starts to 
explode when researching whether this is the right thing 
to do.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-03-07 15:57

Message:
Logged In: YES 
user_id=6380

I'll try to work on this.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2003-03-05 16:03

Message:
Logged In: YES 
user_id=261020

The fix for this was set to go into 2.3, but nothing has  
happened yet. 
 
There were a couple of minor details to be fixed in the 
patches, so I've done that, and uploaded new patches for  
urllib2.py, urllib.py, and their documentation files (against  
current CVS). Well, I'm just about to upload them... 
 
Jeremy, can you apply the patches and finally close this 
one now?  Let me know if anything else needs doing. 
 
This should actually close another bug on SF, too (if it's still 
open), which deals with the urllib.py case.  I can't find it,  
though.  I did attach a comment to it (before I lost it) that 
references this bug. 
 

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-10-15 11:22

Message:
Logged In: YES 
user_id=261020

Well, when I carefully read the RFC I came to the conclusion
that 301 should be redirected to GET, not POST.  I also came
to the conclusion that the RFC was slightly ambiguous on
this point, so I guess that's why A. Flavell came to the
conclusion that 301 should redirect to POST rather than GET.
Anyway, clearly the established practice is to redirect 301
as GET, so this is all academic.

Assuming he's right about Netscape / IE etc., I suppose I'm
happy for 301 to redirect without an exception, since that's
what we've agreed to do for 302.  Obviously, the docs should
say this is contrary to the RFC (as my doc patch says for
302 already).

As for urllib.py, I see the problem.  303 should still be
added, though, since that poses no problem at all.


John


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-10-11 11:40

Message:
Logged In: YES 
user_id=31392

I'm still uncertain about what to do on 301 responses.  As
you say, there are two issues to sort out: 1) what method
should a POST be redicted to and 2) whether the user should
be asked to confirm.

There's discussion of this at:
http://ppewww.ph.gla.ac.uk/~flavell/www/post-redirect.html
The page is a bit old, but I don't know if it is out of date.
It says that IE5, Netscape 4, and Mozilla 1.0 all redirect a
301 POST to a GET without user confirmation.  That seems
like a widespread disregard for the spec that we ought to
emulate.

I agree with your interpretation that urllib2 raise an
HTTPError to signal "request confirm" because an HTTPError
is also a valid response that the user could interpret.  But
of urllib, an HTTP error doesn't contain a valid response. 
The change would make it impossible for the client to do
anything if a 301 response is returned from a POST.  That
seems worse than doing the wrong.



----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-10-09 21:27

Message:
Logged In: YES 
user_id=6380

OK, over to jeremy.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-10-09 17:16

Message:
Logged In: YES 
user_id=261020

Ah.  Here it is.

John


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-10-08 14:23

Message:
Logged In: YES 
user_id=6380

Um, I don't see the patch for urllib.py.  Perhaps you didn't
check the box?

Jeremy, let's do this in 2.3, OK?

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-10-08 12:53

Message:
Logged In: YES 
user_id=261020

Guido mentioned that urllib.py should be fixed
too.  I've attached another patch.


John


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-10-05 13:44

Message:
Logged In: YES 
user_id=261020

Here is a patch for the minor documentation changes required
for the patch I uploaded earlier to fix this bug.  I've also
uploaded a slightly revised patch:

I renamed the `method' method to `get_method' for
consistency with the other methods of the Request class.
The reason this new method is there at all is because the
logic that decides whether or not a redirection should take
place is defined in terms of the method type
(GET/HEAD/POST).  urllib2 doesn't support HEAD ATM, but it
might in future.  OTOH, the Request class is supposed to be
generic -- not specific to HTTP -- so perhaps get_method
isn't really appropriate.  OTOOH, add_data is already
documented to only be meaningful for HTTP Requests.  I
suppose there could be a subclass HTTPRequest, but that's
less simple.  What do you think is best?

I also changed redirect_request to raise an exception
instead of returning None (because no other Handler should
handle the redirect), and changed its documented return
value / exception interface to be consistent with the rest
of urllib2.


John


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-06-23 15:23

Message:
Logged In: YES 
user_id=261020

First, can I underline the fact that there are two issues
here:

  1. What method should POST be redirected as for a
     particular 30x response?

  2. Should the user be asked to confirm the redirection
     (which presumably maps onto raising an HTTPError in
     urllib2)?

I think current client implementations go against the RFCs
on both these points for 302.  Contrastingly, RFC 2616's
note on 301 responses (section 10.3.2) implies that only a
subset of HTTP/1.0 (not 1.1, note) clients violate the RFCs
(1945, 2068, 2616) on point 1 for 301 responses, and I know
of no clients that violate the RFCs on point 2 for 301
responses (but I haven't tested).  Also, I guess the
original intent (for both 301 and 302) was that POSTs
represent an action, so it's dangerous in general to
redirect them without asking the user: I presume this is why
307 was brought in: 307 POSTs on redirected POST, so the
user must be asked:

10.3 Redirection 3xx
[...]
   The action required MAY be carried out by the user agent
   without interaction with the user if and only if the
   method used in the second request is GET or HEAD.

(and 303 is just meant to have the 'erroneous' 302
behaviour: GET on redirected POST, don't ask the user)

So, I agree with Guido that 302 should probably now be
treated the way most clients treat it: GET on redirected
POST, don't ask the user.  As for 301, if it *is* true that
only a few HTTP/1.0 clients have misinterpreted the RFCs on
301, we should stick to the safe behaviour indicated by the
RFC.

As for Guido's first question: A 307 should indeed be
redirected as a POST, but it should ask the user first (see
10.3 quote, above).  That's what my patch does (the 'return
None' in the else clause in redirect_request causes an
exception to be raised eventually -- maybe it should just
raise it itself).

I've attached a revised patch that deals with 302 (and 303)
in the 'erroneous' way (again: GET on redirected POST, don't
ask the user).

I suppose the comment about HTTPRedirectHandler also needs
to state that 301 and 307 POST requests are not
automatically redirected -- HTTPError is raised in that
case.


John


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-19 20:57

Message:
Logged In: YES 
user_id=6380

Hm, I thought that 307 should be treated differently than
303. In particular, a 307 response to POST should cause the
POST to be redirected. And I'm not sure about what a 301
response to POST should do.

(In the mean time I have been convinced that changing POST
to GET on 302 is the best thing to do given that most
browsers do that. The old urllib.py should be fixed too.)

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-06-19 17:57

Message:
Logged In: YES 
user_id=261020

I've attached a patch -- was simpler than I thought.

I think this is in compliance with RFC 2616.  It's also
simple for clients to inherit from HTTPRedirectHandler and
override redirect_request if, for example, they know they
want all 302 POSTs to be redirected as a GET, which removes
the need for mixing redirection code with normal client code
even when the server doesn't follow the RFC (if the server
expects a 302 POST to be redirected as a GET, for example).
Note that I had to add a method, named 'method', to the
Request class, for maintainability (it's possible that
urllib2 may be able to do methods other than GET and POST in
future).

Possibly redirect_request should take fewer parameters.

John


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-06-19 17:56

Message:
Logged In: YES 
user_id=261020

I've attached a patch -- was simpler than I thought.

I think this is in compliance with RFC 2616.  It's also
simple for clients to inherit from HTTPRedirectHandler and
override redirect_request if, for example, they know they
want all 302 POSTs to be redirected as a GET, which removes
the need for mixing redirection code with normal client code
even when the server doesn't follow the RFC (if the server
expects a 302 POST to be redirected as a GET, for example).
Note that I had to add a method, named 'method', to the
Request class, for maintainability (it's possible that
urllib2 may be able to do methods other than GET and POST in
future).

Possibly redirect_request should take fewer parameters.

John


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-06-06 17:25

Message:
Logged In: YES 
user_id=261020

Oh, I hadn't realised httplib uses HTTP/1.1 now -- and now I
check, I see that even RFC 1945 (HTTP/1.0) has a whole set of
restrictions on 30x for particular values of x which I missed
completely.

I guess it should do what Guido suggested -- report an error if a
POST is redirected -- until somebody gets time to do it properly.
I won't have time for a couple of months, but if nobody has done
it by then I'll upload a patch.


John


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-06-06 11:09

Message:
Logged In: YES 
user_id=31392

I think you need to review the current HTTP spec -- RFC 2616
-- and look at the section on redirection (10.3).  I think
urllib2 could improve its handling of redirection, but the
behavior you describe from lynx sounds incorrect.  I'd be
happy to review a patch the implemented the current spec.

Also, RFC 2616 removes the recommendation of a 5 redirect limit.




----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-29 14:10

Message:
Logged In: YES 
user_id=6380

Fair enough. I'll leve it to Jeremy to review the proposed
fix. (Note that he's busy though.)

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-04-29 12:29

Message:
Logged In: YES 
user_id=261020

I don't see why it shouldn't substitue a GET.  That certainly seems to be
the standard practice (well, at least that's what lynx does), and in the case
of the only site where I've encountered redirects on POST, the redirect URL
contains urlencoded stuff, so it clearly expects the user-agent to do a GET.
The site would break if this didn't happen, so I guess Netscape and IE must
do the same thing.

Clearly the RFC *does* allow this, though it doesn't require it (or specify
what should happen here in any way other than to say that a POST is not
allowed, in fact).  Since it's standard practice and allowed by the RFC, I
don't think it should be an error.

John


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-28 20:53

Message:
Logged In: YES 
user_id=6380

Hm, the way I interpret the text you quote, if the original
request is  a POST, it should probably not substitute a GET
but report the error.

Assigning to Jeremy since it's his module.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-04-28 12:21

Message:
Logged In: YES 
user_id=261020

1. Bug is also in 2.2 branch

2. The fix (in 2.1 and 2.2) should reflect the earlier bug fix in the 2.2 branch to add the old headers:

new = Request(newurl, headers=req.headers)

3. I guess 10 should be replaced with 4, not 5.


John


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470


From noreply@sourceforge.net  Thu Apr 24 16:52:17 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 24 Apr 2003 08:52:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-678519 ] StringIO self-iterator
Message-ID: <E198j1F-0007vN-00@sc8-sf-web2.sourceforge.net>

Bugs item #678519, was opened at 2003-01-31 21:26
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678519&group_id=5470

Category: Python Library
Group: Feature Request
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Brett Cannon (bcannon)
Assigned to: Raymond Hettinger (rhettinger)
Summary: StringIO self-iterator

Initial Comment:
As requested by Guido at http://mail.python.org/pipermail/python-dev/2003-January/032629.html , this is a feature request to make both cStringIO and StringIO self-iterators (``__iter__()`` returns self and the class defines ``next()``).  This is so they can be more like files.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-24 10:52

Message:
Logged In: YES 
user_id=80475

Applied 695710 as:

Modules\cStringIO.c 2.40
Lib\test\test_StringIO.py 1.15

----------------------------------------------------------------------

Comment By: Michael Stone (mbrierst)
Date: 2003-03-01 14:52

Message:
Logged In: YES 
user_id=670441

StringIO.StringIO already appears to be a self-iterator.
Patch 695710 will make cStringIO.StringIO a self-iterator
as well.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678519&group_id=5470


From noreply@sourceforge.net  Thu Apr 24 16:56:11 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 24 Apr 2003 08:56:11 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-723749 ] Compilation under Tru64
Message-ID: <E198j51-0008EN-00@sc8-sf-web2.sourceforge.net>

Feature Requests item #723749, was opened at 2003-04-18 11:34
Message generated for change (Comment added) made by mdcowles
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=723749&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Cowles (mdcowles)
Assigned to: Nobody/Anonymous (nobody)
Summary: Compilation under Tru64

Initial Comment:
[From a question sent to python-help]

For Python 2.2.2 and 2.3a2, under DEC OSFV1 True64 Unix
and gcc 3.0.4:

uname -a yields
OSF1 ms-ax1.migen.bio.example V5.1 1885 alpha

the posix module needs:

< #     define STAT _F64_stat
< #     define FSTAT _F64_fstat
---
> #     define STAT stat
> #     define FSTAT fstat
3384c3384
<       return posix_do_stat(self, args, "et:lstat",
_F64_lstat);
---
>       return posix_do_stat(self, args, "et:lstat",
lstat);


----------------------------------------------------------------------

>Comment By: Matthew Cowles (mdcowles)
Date: 2003-04-24 10:56

Message:
Logged In: YES 
user_id=198518

Yes, it's quite possible that it has been fixed in CVS. The
patch is from the original poster to python-help and if it
won't apply, I think it's likely that it has been fixed.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-23 21:04

Message:
Logged In: YES 
user_id=33168

I don't recognize the code you are referring to in either
2.2.3 or 2.3.  Is it possible this has been fixed in CVS?  I
was able to build fine on Tru64 5.1 w/cc.  I don't have gcc
on the box though.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=723749&group_id=5470


From noreply@sourceforge.net  Thu Apr 24 17:20:31 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 24 Apr 2003 09:20:31 -0700
Subject: [Python-bugs-list] [ python-Bugs-724774 ] test_getargs2 failing
Message-ID: <E198jSZ-00072E-00@sc8-sf-web3.sourceforge.net>

Bugs item #724774, was opened at 2003-04-21 00:14
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724774&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Thomas Heller (theller)
Summary: test_getargs2 failing

Initial Comment:
Adding this just so it doesn't fall by the roadside (it's been discussed 
on python-dev): test_getargs2 is currently failing, at least on MacOSX.

----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2003-04-24 18:20

Message:
Logged In: YES 
user_id=11105

I've commited changes to Modules/_testcapimodule.c and
Lib/test/test_getargs2.py which will hopefully fix the problems.

Since this is only test code, I've checked it in without
asking ;-)

Re Big endian: I've got this impression simply by reading
the code. But I've never programmed on such a machine.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-04-24 15:12

Message:
Logged In: YES 
user_id=45365

Yes, I will be able to test it. But it will have to be tomorrow.

BTW: does this mean that there are *no* bigendian machines in the 
snakefarm? That surprises me, I seem to remember than almost all machines 
except intels (i.e. suns, hps, sgi's) are big-endian...

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-04-23 21:17

Message:
Logged In: YES 
user_id=11105

Jack, if I try to fix this (by implementing the C functions
needed) would you be able to test this, or should we simply
comment out the failing tests and do this after the release? 

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-23 20:04

Message:
Logged In: YES 
user_id=6380

Yes, that makes sense, and I remember seeing that and
thinking, "hmm, that's not right". You probably need
separate C functions for each C data type to test. :-(

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-04-23 13:49

Message:
Logged In: YES 
user_id=11105

Um, I think I found the reason. test_getargs2 uses
getargs_ul (in _testcapimodule.c) to call
PyArg_ParseTuple(), and this always passes a pointer to an
unsigned long, even for H and B format codes. On little
endian machines casting this pointer into a unsigned short
pointer works ok, but not on big endian machines. Makes sense?

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-04-23 13:29

Message:
Logged In: YES 
user_id=11105

Strange, since 196608 == 0x30000, and 50331648 == 0x3000000.
Even stranger (to me) is that the test for upper case i
works, and it uses nearly the same code.

Does it help the test_H case to change line 485 of getargs.c
from 'long ival;' to 'unsigned short ival;', but I'm only
guessing?

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-04-23 12:39

Message:
Logged In: YES 
user_id=45365

Yes, I still have the problem. The test output is attached.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-22 16:16

Message:
Logged In: YES 
user_id=33168

This is fixed on all the snake-farm machines AFAIK.  Jack,
are you still having the problems?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-21 19:42

Message:
Logged In: YES 
user_id=33168

This is failling on several other architectures in the snake
farm:  http://www.lysator.liu.se/xenofarm/python/latest.html

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724774&group_id=5470


From noreply@sourceforge.net  Thu Apr 24 17:26:18 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 24 Apr 2003 09:26:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-724751 ] urllib.urlparse has inverse in cgi module
Message-ID: <E198jYA-0001F6-00@sc8-sf-web4.sourceforge.net>

Bugs item #724751, was opened at 2003-04-20 17:18
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724751&group_id=5470

Category: Documentation
>Group: Python 2.2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: John J Lee (jjlee)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: urllib.urlparse has inverse in cgi module

Initial Comment:
The fact that urllib.urlparse has its inverse in the 
cgi module is not mentioned in the urllib docs. 
 
The patch adds a link to the cgi module, pointing out 
that the cgi.parse_qs and cgi.parse_qsl functions 
are the inverse of urllib.urlparse (if you ignore the 
precise types involved -- urllib.urlparse is many-to-one 
in that respect, so there isn't really a proper inverse 
function). 
 

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-04-24 12:26

Message:
Logged In: YES 
user_id=3066

Looking at the patch, I see you mean the urllib.urlencode()
function.
I've commited a modified version of your patch and added a
reference to urllib.urlencode() from cgi.parse_qsl().

Fixed for Python 2.2.3, 2.3:

Doc/lib/libcgi.tex 1.39, 1.35.4.4
Doc/lib/liburllib.tex 1.48, 1.40.8.3

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2003-04-20 17:20

Message:
Logged In: YES 
user_id=261020

Oops, forgot to attach patch. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724751&group_id=5470


From noreply@sourceforge.net  Thu Apr 24 17:53:34 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 24 Apr 2003 09:53:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-665835 ] filter() treatment of str and tuple inconsistent
Message-ID: <E198jyY-00030Z-00@sc8-sf-web4.sourceforge.net>

Bugs item #665835, was opened at 2003-01-10 11:36
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665835&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Walter Dörwald (doerwalter)
Assigned to: Raymond Hettinger (rhettinger)
Summary: filter() treatment of str and tuple inconsistent

Initial Comment:
class tuple2(tuple):
·  def __getitem__(self, index):
·  ·  return 2*tuple.__getitem__(self, index)

class str2(str):
·  def __getitem__(self, index):
·  ·  return chr(ord(str.__getitem__(self, index))+1)

print filter(lambda x: x>1, tuple2((1, 2)))
print filter(lambda x: x>"a", str2("ab"))

this prints:
(2,)
bc

i.e. the overwritten __getitem__ is ignored in the
first case, but honored in the second.


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-24 11:53

Message:
Logged In: YES 
user_id=80475

Committed changes as:

Objects/listobject.c 2.149
Objects/tupleobject.c 2.79
Lib/test/test_types.py 1.50

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-02-10 12:52

Message:
Logged In: YES 
user_id=80475

I'm still working on fixing the iterators so that __getitem__ 
overrides are recognized by __iter__.

Hope that simplifies your changes.

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2003-02-10 12:44

Message:
Logged In: YES 
user_id=89016

Checked in as:
Lib/test/test_builtin.py 1.13
Python/bltinmodule.c 2.280


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-10 10:20

Message:
Logged In: YES 
user_id=6380

Feel free to fix filtertuple() too. Just note that
tp_as_sequence might be NULL, or ...->sq_item might be NULL.
I'm not 100% sure that those can never be NULL for a tuple
subclass.

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2003-02-10 08:27

Message:
Logged In: YES 
user_id=89016

OK, this has been fixed: function==None and function==lambda x:x
now behave the same (for str and unicode, for tuples it's
still broken, because PyTuple_GetItem() is used. (Checked in
as Python/bltinmodule.c 2.278 and  Lib/test/test_builtin.py
1.12)

Why can't we simply replace PyTuple_GetItem() with
tp_as_sequence->sq_item in filtertuple()?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-04 16:06

Message:
Logged In: YES 
user_id=6380

So it does. I guess the special shortcut for None should
only be taken
when it's a proper str instance.

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2003-02-04 15:34

Message:
Logged In: YES 
user_id=89016

The subclass problem has been fixed in:
Python/bltinmodule.c 2.275
Lib/test/test_builtin.py 1.9

But now something strange happens:
---
class badstr(str):
···def __getitem__(self, index):
······return str.__getitem__(self, index).upper()

print filter(None, badstr("abc"))
print filter(lambda x: x, badstr("abc"))
---
This prints
---
abc
ABC
---
although according to the filter docstring they should be
the same.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-04 12:33

Message:
Logged In: YES 
user_id=6380

Yes, the special treatment of tuple, str and unicode is
problematic. :-(
I wish filter() had always returned a list for all input types.
But it's too late to change that.

However, I don't think that filter() should ever return a
*subclass* of tuple, str or unicode. Note that slicing a
subclass of these also doesn't return a subclass instance,
unless the subclass specifically overrides __getslice__.

I note that filter() of a tuple *almost* implements what I
think it should, except that if it receives an empty tuple
subclass, it returns it unchanged. The slicing and other
methods (e.g. lower()) have all been modified to make a copy
whose type is the base class; I think filter() should follow
suit.

Similar for filter() of strings and unicode.

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2003-02-04 12:15

Message:
Logged In: YES 
user_id=89016

OK, the problem of __getitem__ not returning str or unicode
is fixed. Unfortunately the result is rather ugly. With the
following class:

class u(unicode):
   def __getitem__(self, index):
      return u(2*unicode.__getitem__(self, index))

filter neither returns a list nor an u object, but a unicode
object, defeating the whole purpose of the special treatment
of str/unicode. If we remove the special treatment this
problem would go away, furthermore __getitem__ returning
objects that are not str/unicode instances wouldn't be
problem any longer.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-03 17:36

Message:
Logged In: YES 
user_id=6380

Walter: if you can fix the bug in your latest message here,
go ahead and check it in. Seems like a case of a missing test.

Raymond: it turns out that the iterator in Python 2.2 has
the same problem with lists -- it special-cases lists. But
for tuples, the iterator uses PySequence_GetItem; the fast
tuple iterator in Python 2.3 introduces the problem for
tuples though.

I actually don't think there would be much disagreement that
this behavior (ignoring __getitem__) is a bug. There may be
disagreement over how important it is to fix it. Personally,
I've generally been on the side of "it needn't be fixed if
it slows down the common case", as long as a workaround
(like overriding __iter__ alongside the __getitem__
override) exists.

But I draw the line at being backwards incompatible with
Python 2.2. There fore I think the tuple iterator (and
probably also the string iterator) needs to be fixed, and I
still think that it would be best if the list iterator were
also fixed. One way to do this would be for the tp_iter
implementation to check whether
self->ob_type->tp_as_sequence->sq_item is not equal to the
list_item function (this is a good check to detect a
__getitem__ override) and then return an instance of the
generic sequence iterator instead of the list-specific iterator.

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2003-01-27 07:24

Message:
Logged In: YES 
user_id=89016

Another problem with filter() is that filterstring() (and
the new filterunicode()) blindly assume that
tp_as_sequence->sq_item returns a str or unicode object with
len==1. This might fail with str or unicode subclasses:
----
class badstr(str):
   def __getitem__(self, index):
      return 42

s = filter(lambda x: x>=42, badstr("1234"))
print len(s), repr(s)
----
This prints
4 '\x00\x00\x00\x00'

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-26 20:13

Message:
Logged In: YES 
user_id=80475

One other thought:  A major reason for implementing 
__iter__ in the first place is that objects were overriding 
__getitem__ and disregarding the index -- the __getitem__ 
interface just didn't make sense for iteration in some 
situations.  __iter__ was supposed to provide enormous 
flexibility in various ways to loop over a collection (inorder, 
preorder, postorder, priorityorder, sortedorder, hashorder, 
randomorder, etc).  Making iter() default to using 
__getitem__ was only supposed to be an expedient for 
backwards compatability.  Always using __getitem__ 
diminishes the flexibility and speed advantages.

Maybe the discussion belongs on python-dev. I'm sure a 
number of people feel strongly one way or the other.  The 
question might as well be addressed head-on before 2.3 
goes out the door. 

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-26 19:54

Message:
Logged In: YES 
user_id=80475

I understand.  Ideally, *all* methods would respond to a 
single overridden method, but I think this is just a fact of 
life in object oriented programming.

I can't remember where you gave an example of a 
d.__getitem__() subclass override, but you were careful to 
point out that other methods, like d.get() also needed to 
be overridden so that the modified access applied 
everywhere.  Likewise, __iter__() or any other object 
access method must be assumed to access the underlying 
data structure directly and must be overridden.   For 
instance, creating a dictionary with case insensitive 
lookups entails overriding __getitem__(k), get(k,default), 
and pop(k) -- no one of them can be presumed to inform 
the others.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-26 19:17

Message:
Logged In: YES 
user_id=6380

Hm... that means that iter() of *amy* built-in type subclass
overriding __getitem__ bypasses the override, unless the
subclass also overrides __iter__. This sounds like a step in
the wrong direction. I think the built-in iterators should
be aware of subclasses overriding __getitem__ one way or
another. I hadn't realized this when we started the trend of
creating faster iterators for built-in types. :-(

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-25 11:45

Message:
Logged In: YES 
user_id=80475

None of the existing iterators (incl dicts, lists, tuples, and 
files) use __getitem__.  Most likely, user defined iterators 
also access the data structure directly (for flexiblity and 
speed). Also, anything that uses PyTuple_GET_ITEM 
bypasses __getitem__.

If string/unicode iterators are added, they should also go
directly to the underlying data; otherwise, there is no point 
to it.

Also, the proposal to change filtertuple(), doesn't solve
inconsistencies within filterstring() which uses __getitem__ 
when there is a function call, but bypasses it when the 
function parameter is Py_None.

I think the right answer is to change filterstring() to use an 
iterator and to implement string/unicode iterators that 
access the data directly (not using __getitem__).

FYI for Tim:  MvL noticed and fixed the unicode vs string 
difference.  His patch, SF #636005, has not been applied 
yet.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-25 08:51

Message:
Logged In: YES 
user_id=6380

(But in addition th that, I don't mind having a custom
string iterator -- as long as it calls __getitem__ properly.
Hm, shouldn't the tuple iterator call __getitem__ properly too?)


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-01-25 08:45

Message:
Logged In: YES 
user_id=31435

Just noting that filter() is unique in special-casing the type 
of the input.  It's always been surprising that way, and, 
e.g., filtering a string produces a string, but filtering a 
Unicode string produces a list.

map() and reduce() don't play games like that, and always 
use the iteration protocol to march over their inputs.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-25 08:36

Message:
Logged In: YES 
user_id=6380

I don't know which Python sources Raymond has been reading,
but in the sources I've got in front of me, there are
special cases for strings and tuples, and these *don't* use
iter(). It so happens that the tuple special-case calls
PyTuple_GetItem(), which doesn't call your __getitem__,
while the string special-case calls the sq_item slot
function, which (in your case) will be a wrapper that calls
your __getitem__.

A minimal fix would be to only call filtertuple for strict
tuples -- although this changes the output type, but I don't
think one should count on filter() of a tuple subclass
returning a tuple (and it can't be made to return an
instance of the subclass either -- we don't know the
constructor signature).

Similar fixes probably need to be made to map() and maybe
reduce().

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-24 22:47

Message:
Logged In: YES 
user_id=80475

The problem isn't with filter() which correctly calls iter() in 
both cases.

Tuple object have their own iterator which loops over 
elements directly and has no intervening calls to 
__getitem__().

String objects do not define a custom iterator, so iter() 
wraps itself around consecutive calls to __getitem__().

The resolution is to provide string objects with their own 
iterator. As a side benefit, iteration will run just a tiny bit 
faster.  The same applies to unicode objects.

Guido, do you care about this and want me to fix it or 
would you like to close it as "won't fix".


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665835&group_id=5470


From noreply@sourceforge.net  Thu Apr 24 18:49:48 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 24 Apr 2003 10:49:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-727051 ] valgrind python fails
Message-ID: <E198kqy-0006Ir-00@sc8-sf-web4.sourceforge.net>

Bugs item #727051, was opened at 2003-04-24 10:49
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727051&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ralf W. Grosse-Kunstleve (rwgk)
Assigned to: Nobody/Anonymous (nobody)
Summary: valgrind python fails

Initial Comment:
Platform:
  Redhat 7.3 on Intel Xeon

Packages involved:
  valgrind-1.9.5 (http://developer.kde.org/~sewardj/)
  Python CVS snapshot Thu Apr 24 10:00:00 PDT 2003

valgrind python fails with the following message:

% valgrind python
python: relocation error: /lib/librt.so.1: symbol 
__pthread_clock_settime, version GLIBC_PRIVATE not 
defined in file libpthread.so.0 with link time reference

This is with:

% python
Python 2.3b1 (#1, Apr 24 2003, 10:20:26) 
[GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-113)] on 
linux2
Type "help", "copyright", "credits" or "license" for more 
information.
>>> 

I observed the same problem with Python 2.3a2.

There are no problems when using Python 2.2.1 on the 
exact same platform with the same valgrind installation.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727051&group_id=5470


From noreply@sourceforge.net  Thu Apr 24 20:10:25 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 24 Apr 2003 12:10:25 -0700
Subject: [Python-bugs-list] [ python-Bugs-724774 ] test_getargs2 failing
Message-ID: <E198m6z-0000ql-00@sc8-sf-web3.sourceforge.net>

Bugs item #724774, was opened at 2003-04-20 18:14
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724774&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
>Assigned to: Jack Jansen (jackjansen)
Summary: test_getargs2 failing

Initial Comment:
Adding this just so it doesn't fall by the roadside (it's been discussed 
on python-dev): test_getargs2 is currently failing, at least on MacOSX.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-24 15:10

Message:
Logged In: YES 
user_id=33168

I think HPs and Alphas are not big-endian, but Sun's are. 
The Sun was the only one failling.  With the last checkin,
the Sun is now working.  Hopefully, it works on OS X too.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-04-24 12:20

Message:
Logged In: YES 
user_id=11105

I've commited changes to Modules/_testcapimodule.c and
Lib/test/test_getargs2.py which will hopefully fix the problems.

Since this is only test code, I've checked it in without
asking ;-)

Re Big endian: I've got this impression simply by reading
the code. But I've never programmed on such a machine.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-04-24 09:12

Message:
Logged In: YES 
user_id=45365

Yes, I will be able to test it. But it will have to be tomorrow.

BTW: does this mean that there are *no* bigendian machines in the 
snakefarm? That surprises me, I seem to remember than almost all machines 
except intels (i.e. suns, hps, sgi's) are big-endian...

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-04-23 15:17

Message:
Logged In: YES 
user_id=11105

Jack, if I try to fix this (by implementing the C functions
needed) would you be able to test this, or should we simply
comment out the failing tests and do this after the release? 

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-23 14:04

Message:
Logged In: YES 
user_id=6380

Yes, that makes sense, and I remember seeing that and
thinking, "hmm, that's not right". You probably need
separate C functions for each C data type to test. :-(

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-04-23 07:49

Message:
Logged In: YES 
user_id=11105

Um, I think I found the reason. test_getargs2 uses
getargs_ul (in _testcapimodule.c) to call
PyArg_ParseTuple(), and this always passes a pointer to an
unsigned long, even for H and B format codes. On little
endian machines casting this pointer into a unsigned short
pointer works ok, but not on big endian machines. Makes sense?

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-04-23 07:29

Message:
Logged In: YES 
user_id=11105

Strange, since 196608 == 0x30000, and 50331648 == 0x3000000.
Even stranger (to me) is that the test for upper case i
works, and it uses nearly the same code.

Does it help the test_H case to change line 485 of getargs.c
from 'long ival;' to 'unsigned short ival;', but I'm only
guessing?

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-04-23 06:39

Message:
Logged In: YES 
user_id=45365

Yes, I still have the problem. The test output is attached.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-22 10:16

Message:
Logged In: YES 
user_id=33168

This is fixed on all the snake-farm machines AFAIK.  Jack,
are you still having the problems?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-21 13:42

Message:
Logged In: YES 
user_id=33168

This is failling on several other architectures in the snake
farm:  http://www.lysator.liu.se/xenofarm/python/latest.html

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724774&group_id=5470


From noreply@sourceforge.net  Thu Apr 24 20:14:37 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 24 Apr 2003 12:14:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-727051 ] valgrind python fails
Message-ID: <E198mB3-0003Hv-00@sc8-sf-web2.sourceforge.net>

Bugs item #727051, was opened at 2003-04-24 13:49
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727051&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ralf W. Grosse-Kunstleve (rwgk)
Assigned to: Nobody/Anonymous (nobody)
Summary: valgrind python fails

Initial Comment:
Platform:
  Redhat 7.3 on Intel Xeon

Packages involved:
  valgrind-1.9.5 (http://developer.kde.org/~sewardj/)
  Python CVS snapshot Thu Apr 24 10:00:00 PDT 2003

valgrind python fails with the following message:

% valgrind python
python: relocation error: /lib/librt.so.1: symbol 
__pthread_clock_settime, version GLIBC_PRIVATE not 
defined in file libpthread.so.0 with link time reference

This is with:

% python
Python 2.3b1 (#1, Apr 24 2003, 10:20:26) 
[GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-113)] on 
linux2
Type "help", "copyright", "credits" or "license" for more 
information.
>>> 

I observed the same problem with Python 2.3a2.

There are no problems when using Python 2.2.1 on the 
exact same platform with the same valgrind installation.


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-24 15:14

Message:
Logged In: YES 
user_id=33168

I think I got around this problem by adding:

  void __pthread_clock_settime() { }

I think this may be mentioned in the valgrind FAQ/doc.  Or
perhaps, it's something similar which I am confusing.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727051&group_id=5470


From noreply@sourceforge.net  Thu Apr 24 20:17:06 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 24 Apr 2003 12:17:06 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-723749 ] Compilation under Tru64
Message-ID: <E198mDS-0003Rj-00@sc8-sf-web2.sourceforge.net>

Feature Requests item #723749, was opened at 2003-04-18 12:34
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=723749&group_id=5470

Category: Build
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Matthew Cowles (mdcowles)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: Compilation under Tru64

Initial Comment:
[From a question sent to python-help]

For Python 2.2.2 and 2.3a2, under DEC OSFV1 True64 Unix
and gcc 3.0.4:

uname -a yields
OSF1 ms-ax1.migen.bio.example V5.1 1885 alpha

the posix module needs:

< #     define STAT _F64_stat
< #     define FSTAT _F64_fstat
---
> #     define STAT stat
> #     define FSTAT fstat
3384c3384
<       return posix_do_stat(self, args, "et:lstat",
_F64_lstat);
---
>       return posix_do_stat(self, args, "et:lstat",
lstat);


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-24 15:17

Message:
Logged In: YES 
user_id=33168

Ok, I'm closing this as fixed.  BTW there is a known problem
(patch or bug report) with Tru64 and their implementation of
assert.  The problem appears when building --with-pydebug on
Tru64 and cc (not gcc I think).  I hope to get around to
fixing that someday.

----------------------------------------------------------------------

Comment By: Matthew Cowles (mdcowles)
Date: 2003-04-24 11:56

Message:
Logged In: YES 
user_id=198518

Yes, it's quite possible that it has been fixed in CVS. The
patch is from the original poster to python-help and if it
won't apply, I think it's likely that it has been fixed.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-23 22:04

Message:
Logged In: YES 
user_id=33168

I don't recognize the code you are referring to in either
2.2.3 or 2.3.  Is it possible this has been fixed in CVS?  I
was able to build fine on Tru64 5.1 w/cc.  I don't have gcc
on the box though.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=723749&group_id=5470


From noreply@sourceforge.net  Thu Apr 24 20:56:20 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 24 Apr 2003 12:56:20 -0700
Subject: [Python-bugs-list] [ python-Bugs-727137 ] use bsddb185 if necessary in dbhash
Message-ID: <E198mpQ-0006ir-00@sc8-sf-web1.sourceforge.net>

Bugs item #727137, was opened at 2003-04-24 14:56
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727137&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: use bsddb185 if necessary in dbhash

Initial Comment:
I've had this patch sitting around for awhile.  I think if the new
bsddb stuff can't be built and the user enables the bsddb185
module in Modules/Setup that dbhash should also try that
module when setting things up.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727137&group_id=5470


From noreply@sourceforge.net  Thu Apr 24 21:12:11 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 24 Apr 2003 13:12:11 -0700
Subject: [Python-bugs-list] [ python-Bugs-557704 ] netrc module can't handle all passwords
Message-ID: <E198n4l-0004li-00@sc8-sf-web3.sourceforge.net>

Bugs item #557704, was opened at 2002-05-18 12:18
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=557704&group_id=5470

Category: Python Library
Group: Python 2.2.1
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Bram Moolenaar (vimboss)
Assigned to: Nobody/Anonymous (nobody)
Summary: netrc module can't handle all passwords

Initial Comment:
When a ~/.netrc file has a password with non-word
characters parsing fails.  Since it is recommended to
use punctuation characters in passwords, this means
most netrc files can't be parsed. An example of a line
in ~/.netrc that fails:

machine piet.puk.com  	login foo 	password bar!

Additionally, entries in netrc may not have a login
name (e.g., for mail servers).  These entries should be
silently skipped. An example of a line that fails:

machine mail          password fruit

The included diff is a partial solution.  It allows all
ASCII punctuation characters to be used in passwords. 
Non-ASCII characters should probably also be allowed.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-24 15:12

Message:
Logged In: YES 
user_id=80475

Instead of skipping lines without login info, write a record 
with login=''.

See netrc.py 1.18.

Will backport to Py2.2.3

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-24 03:49

Message:
Logged In: YES 
user_id=80475

Unassigning, in case someone else wants to explore the 
handling of spaces.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-04-23 16:14

Message:
Logged In: YES 
user_id=44345

Passwords with spaces are valid, however I confirmed that the ftp program
which comes with Redhat Linux also gripes about passwords containing 
spaces, so my complaint is probably moot.


----------------------------------------------------------------------

Comment By: Bram Moolenaar (vimboss)
Date: 2003-04-23 16:02

Message:
Logged In: YES 
user_id=57665

I am glad the special characters in passwords are now
accepted.  But that is only half a fix!  My ~/.netrc
contains entries without a "login" field, thus I still
cannot use the netrc module, it bails out at the first line.  
Therefore I have re-opened this issue.
All other programs work just fine with this .netrc file. 
Please at least do not produce the NetrcParseError when the
"login" field is omitted.  This can be done by changing the
"else:" above "malformed %s entry" to "elif not password:".
 That is the minimal change to make this module work on my
system.

Note to montanaro: I have not seen a .netrc file that has a
space in the password.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-04-23 14:52

Message:
Logged In: YES 
user_id=44345

This is still not correct, as passwords in .netrc files can't contain spaces.
The netrc module is perhaps a good demonstration of the shlex module,
but I wouldn't rely on it for actual use.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-23 14:38

Message:
Logged In: YES 
user_id=80475

Backported for 2.2.3.
Closing bug.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-23 14:12

Message:
Logged In: YES 
user_id=6380

Given the size and nature of the patch I have no problem
with a 2.2.3 backport.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-23 14:00

Message:
Logged In: YES 
user_id=80475

Revised netrc.py to include the additional ascii punctuation 
characters.  Omitted the other logic changes.  See 
Lib/netrc.py 1.17.

Since this is more of a feature request than a bug, 
including in Py2.3 but not recommending for backporting.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-22 07:28

Message:
Logged In: YES 
user_id=6380

Raymond, can you deal with this or find someone else? (Maybe
the fellow who last patched shlex.py?)

----------------------------------------------------------------------

Comment By: Bram Moolenaar (vimboss)
Date: 2003-04-22 06:05

Message:
Logged In: YES 
user_id=57665

Can someone please do something about this bug?  It has been
open for almost a year now and it still can't handle my
netrc file.  At least include a temporary fix!  My patch
plus the remarks from rhettinger should be sufficient.

----------------------------------------------------------------------

Comment By: Bram Moolenaar (vimboss)
Date: 2002-11-08 06:46

Message:
Logged In: YES 
user_id=57665

Note that the old Netrc class in the ftplib module has a
different approach at parsing the .netrc file.  This might
actually work much better.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-05 13:43

Message:
Logged In: YES 
user_id=6380

I think Fred knows this code.

I think Eric Raymond (the original author) wrote this as an 
example of his shlex. :-)

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-06-02 07:48

Message:
Logged In: YES 
user_id=44345

I think a better solution would be to not use shlex to parse netrc files.  
Netrc files aren't shells.  The whitespace is significant if it occurs inside a 
password.  I'd just use re.split(r'(\s+)') and restore the password when I 
encounterd the "password" keyword.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-18 20:56

Message:
Logged In: YES 
user_id=80475

Expanding keyspace is generally a good idea; however, the 
significance of meta-characters is bound to bite someone in 
the behind with a hard to find error.  So, please 
reconsider single-quote, double-quote, backslash, 
greaterthan, lessthan, and pipe.

Looking at first part of the patch, consider:
- removing the TODO on line 31
- wrapping the character list in triple-quotes on line 32
- using the r'' form on line 32 to eliminate backslashes in 
the character list

Looking at the second part of the patch, I don't follow (am 
perhaps being daft) why expanding the keyspace necessitates 
changing the login logic.

The idea of allowing non-ASCII characters would be cool if 
the world had already universally accepted Latin-1 coding.  
That conflict is the reason that site.py defaults to ASCII 
encoding instead of handling non-US codings out of the box.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=557704&group_id=5470


From noreply@sourceforge.net  Thu Apr 24 23:16:20 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 24 Apr 2003 15:16:20 -0700
Subject: [Python-bugs-list] [ python-Bugs-727241 ] Core Dumps : Python2.2.2
Message-ID: <E198p0u-0005JY-00@sc8-sf-web4.sourceforge.net>

Bugs item #727241, was opened at 2003-04-24 22:16
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727241&group_id=5470

Category: None
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Eli Rosenberg (elirosenberg)
Assigned to: Nobody/Anonymous (nobody)
Summary: Core Dumps : Python2.2.2 

Initial Comment:

Hello,
I am able to cause python to core dump on IRIX
6.5.18 and above with the code listed below.  I have
compiled with 3 versions of gcc as well as MIPSpro.

Running this code with a valid host and a port
that will cause a connection refused socket error
produces a core dump with the the stack trace below.

>>> import socket
>>> x=socket.socket()
>>> x.connect(('www.google.com', 1234))


>  0 realfree(0x10162e98, 0x0, 0x200000, 0x65637469,
0x17dd4, 0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":527,
0xfb245fc]
   1 cleanfree(0x0, 0x0, 0x200000, 0x65637469, 0x17dd4,
0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":945,
0xfb24e44]
   2 __malloc(0x28, 0x0, 0x200000, 0x65637469, 0x17dd4,
0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":230,
0xfb24078]
   3 _malloc(0x28, 0x0, 0x200000, 0x65637469, 0x17dd4,
0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":186,
0xfb23ee4]
   4 _PyObject_GC_Malloc(tp = 0x1013fbe0, nitems = 0)
["/usr/people/eli/Python-2.2.2/Modules/gcmodule.c":868,
0x10092244]
   5 _PyObject_GC_New(tp = 0x1013fbe0)
["/usr/people/eli/Python-2.2.2/Modules/gcmodule.c":895,
0x10092368]
   6 newtracebackobject(next = (nil), frame =
0x1016b670, lasti = 21, lineno = 1)
["/usr/people/eli/Python-2.2.2/Python/traceback.c":115,
0x100c6684]
   7 PyTraceBack_Here(frame = 0x1016b670)
["/usr/people/eli/Python-2.2.2/Python/traceback.c":133,
0x100c67f4]
   8 eval_frame(f = 0x1016b670)
["/usr/people/eli/Python-2.2.2/Python/ceval.c":2238,
0x1004e894]
   9 PyEval_EvalCodeEx(co = 0x1016e990, globals =
0x1016a5d0, locals = 0x1016a5d0, args = (nil), argcount
= 0, kws = (nil), kwcount = 0, defs = (nil), defcount =
0, closure = (nil))
["/usr/people/eli/Python-2.2.2/Python/ceval.c":2595,
0x1004ffe0
   10 PyEval_EvalCode(co = 0x1016e990, globals =
0x1016a5d0, locals = 0x1016a5d0)
["/usr/people/eli/Python-2.2.2/Python/ceval.c":481,
0x10047ea0]
   11 run_node(n = 0x101a5b28, filename = 0x1014e978 =
"<stdin>", globals = 0x1016a5d0, locals = 0x1016a5d0,
flags = 0x7fff2e2c)
["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":1079,
0x1006f380]
   12 PyRun_InteractiveOneFlags(fp = 0xfb53680,
filename = 0x1014e978 = "<stdin>", flags = 0x7fff2e2c)
["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":590,
0x1006d57c]
   13 PyRun_InteractiveLoopFlags(fp = 0xfb53680,
filename = 0x1014e978 = "<stdin>", flags = 0x7fff2e2c)
["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":526,
0x1006d198]
   14 PyRun_AnyFileExFlags(fp = 0xfb53680, filename =
0x1014e978 = "<stdin>", closeit = 0, flags =
0x7fff2e2c)
["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":489,
0x1006cf48]
   15 Py_Main(argc = 1, argv = 0x7fff2f24)
["/usr/people/eli/Python-2.2.2/Modules/main.c":364,
0x1000fa44]
   16 main(argc = 1, argv = 0x7fff2f24)
["/usr/people/eli/Python-2.2.2/Modules/python.c":10,
0x1000ecdc]
   17 __start()
["/xlv55/kudzu-apr12/work/irix/lib/libc/libc_n32_M4/csu/crt1text.s":177,
0x1000ec78]

I compiled Python 64-bit and the code above appears
not to cause a segfault but the code below will
bus error after a few iterations.

import socket
import time

def doit():
          s = socket.socket()
          start = time.time()
          
          try:
               s.connect(('www.cnn.com', 80))
          except socket.error,e:
               print repr(e),str(e)
          finish = time.time()
          time.sleep(.5)
          print str(finish-start),"\n"
          s.close()

for x in xrange(10):
     doit()

Here is the stack trace:

>  0 realfree(0x10162e98, 0x0, 0x200000, 0x65637469,
0x17dd4, 0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":527,
0xfb245fc]
   1 cleanfree(0x0, 0x0, 0x200000, 0x65637469, 0x17dd4,
0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":945,
0xfb24e44]
   2 __malloc(0x28, 0x0, 0x200000, 0x65637469, 0x17dd4,
0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":230,
0xfb24078]
   3 _malloc(0x28, 0x0, 0x200000, 0x65637469, 0x17dd4,
0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":186,
0xfb23ee4]
   4 _PyObject_GC_Malloc(tp = 0x1013fbe0, nitems = 0)
["/usr/people/eli/Python-2.2.2/Modules/gcmodule.c":868,
0x10092244]
   5 _PyObject_GC_New(tp = 0x1013fbe0)
["/usr/people/eli/Python-2.2.2/Modules/gcmodule.c":895,
0x10092368]
   6 newtracebackobject(next = (nil), frame =
0x1016b670, lasti = 21, lineno = 1)
["/usr/people/eli/Python-2.2.2/Python/traceback.c":115,
0x100c6684]
   7 PyTraceBack_Here(frame = 0x1016b670)
["/usr/people/eli/Python-2.2.2/Python/traceback.c":133,
0x100c67f4]
   8 eval_frame(f = 0x1016b670)
["/usr/people/eli/Python-2.2.2/Python/ceval.c":2238,
0x1004e894]
   9 PyEval_EvalCodeEx(co = 0x1016e990, globals =
0x1016a5d0, locals = 0x1016a5d0, args = (nil), argcount
= 0, kws = (nil), kwcount = 0, defs = (nil), defcount =
0, closure = (nil))
["/usr/people/eli/Python-2.2.2/Python/ceval.c":2595,
0x1004ffe0
   10 PyEval_EvalCode(co = 0x1016e990, globals =
0x1016a5d0, locals = 0x1016a5d0)
["/usr/people/eli/Python-2.2.2/Python/ceval.c":481,
0x10047ea0]
   11 run_node(n = 0x101a5b28, filename = 0x1014e978 =
"<stdin>", globals = 0x1016a5d0, locals = 0x1016a5d0,
flags = 0x7fff2e2c)
["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":1079,
0x1006f380]
   12 PyRun_InteractiveOneFlags(fp = 0xfb53680,
filename = 0x1014e978 = "<stdin>", flags = 0x7fff2e2c)
["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":590,
0x1006d57c]
   13 PyRun_InteractiveLoopFlags(fp = 0xfb53680,
filename = 0x1014e978 = "<stdin>", flags = 0x7fff2e2c)
["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":526,
0x1006d198]
   14 PyRun_AnyFileExFlags(fp = 0xfb53680, filename =
0x1014e978 = "<stdin>", closeit = 0, flags =
0x7fff2e2c)
["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":489,
0x1006cf48]
   15 Py_Main(argc = 1, argv = 0x7fff2f24)
["/usr/people/eli/Python-2.2.2/Modules/main.c":364,
0x1000fa44]
   16 main(argc = 1, argv = 0x7fff2f24)
["/usr/people/eli/Python-2.2.2/Modules/python.c":10,
0x1000ecdc]
   17 __start()
["/xlv55/kudzu-apr12/work/irix/lib/libc/libc_n32_M4/csu/crt1text.s":177,
0x1000ec78]

Any help would be appreciated. thanks.
-Eli

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727241&group_id=5470


From noreply@sourceforge.net  Fri Apr 25 09:21:30 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 25 Apr 2003 01:21:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-549151 ] urllib2 POSTs on redirect
Message-ID: <E198ySY-0007gF-00@sc8-sf-web3.sourceforge.net>

Bugs item #549151, was opened at 2002-04-26 11:04
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: John J Lee (jjlee)
Assigned to: Raymond Hettinger (rhettinger)
Summary: urllib2 POSTs on redirect

Initial Comment:

urllib2 (I'm using 1.13.22 with Python 2.0, but I assume the 2.2 branch does the same) uses the 
POST method on redirect, contrary to RFC1945 section 9.3:

> 9.3  Redirection 3xx
> 
>    This class of status code indicates that further action needs to be
>    taken by the user agent in order to fulfill the request. The action
>    required may be carried out by the user agent without interaction
>    with the user if and only if the method used in the subsequent
>    request is GET or HEAD. A user agent should never automatically
>    redirect a request more than 5 times, since such redirections usually
>    indicate an infinite loop.

Can be fixed in HTTPRedirectHandler.http_error_302 by replacing
        new = Request(newurl, req.get_data())

with
        new = Request(newurl)

so that GET is done on redirect instead of POST.

I suppose the limit of 10 in the same function should be changed to 5, also.


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-25 03:21

Message:
Logged In: YES 
user_id=80475

Backported to 2.2.3.
Closing bug.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-24 10:49

Message:
Logged In: YES 
user_id=6380

Yes, I think that would be a good idea.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-24 10:34

Message:
Logged In: YES 
user_id=80475

Committed as:

Lib/urllib.py 1.157
Lib/urllib2.py 1.39
Doc/lib/liburllib.tex 1.47
Doc/lib/liburllib2.tex 1.7


Guido, would you like this backported to 2.2.3?

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2003-04-20 15:44

Message:
Logged In: YES 
user_id=261020

Just noticed that I forgot to upload one of the doc patches 
on 2003-03-05.  Here it is. 
 
The patches that need to be applied are the three I 
uploaded on 2003-03-05 (urllib.py.patch, urllib2.py.patch 
and liburllib2.tex.patch), and the liburllib.tex.patch I just 
uploaded. 
 

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-16 15:35

Message:
Logged In: YES 
user_id=6380

I think this is the right thing to do. Can you check it in?
 (There are several files -- urllib, urllib2, and its docs).

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-16 15:27

Message:
Logged In: YES 
user_id=80475

Do you have time to take this one back?  My head starts to 
explode when researching whether this is the right thing 
to do.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-03-07 15:57

Message:
Logged In: YES 
user_id=6380

I'll try to work on this.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2003-03-05 16:03

Message:
Logged In: YES 
user_id=261020

The fix for this was set to go into 2.3, but nothing has  
happened yet. 
 
There were a couple of minor details to be fixed in the 
patches, so I've done that, and uploaded new patches for  
urllib2.py, urllib.py, and their documentation files (against  
current CVS). Well, I'm just about to upload them... 
 
Jeremy, can you apply the patches and finally close this 
one now?  Let me know if anything else needs doing. 
 
This should actually close another bug on SF, too (if it's still 
open), which deals with the urllib.py case.  I can't find it,  
though.  I did attach a comment to it (before I lost it) that 
references this bug. 
 

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-10-15 10:22

Message:
Logged In: YES 
user_id=261020

Well, when I carefully read the RFC I came to the conclusion
that 301 should be redirected to GET, not POST.  I also came
to the conclusion that the RFC was slightly ambiguous on
this point, so I guess that's why A. Flavell came to the
conclusion that 301 should redirect to POST rather than GET.
Anyway, clearly the established practice is to redirect 301
as GET, so this is all academic.

Assuming he's right about Netscape / IE etc., I suppose I'm
happy for 301 to redirect without an exception, since that's
what we've agreed to do for 302.  Obviously, the docs should
say this is contrary to the RFC (as my doc patch says for
302 already).

As for urllib.py, I see the problem.  303 should still be
added, though, since that poses no problem at all.


John


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-10-11 10:40

Message:
Logged In: YES 
user_id=31392

I'm still uncertain about what to do on 301 responses.  As
you say, there are two issues to sort out: 1) what method
should a POST be redicted to and 2) whether the user should
be asked to confirm.

There's discussion of this at:
http://ppewww.ph.gla.ac.uk/~flavell/www/post-redirect.html
The page is a bit old, but I don't know if it is out of date.
It says that IE5, Netscape 4, and Mozilla 1.0 all redirect a
301 POST to a GET without user confirmation.  That seems
like a widespread disregard for the spec that we ought to
emulate.

I agree with your interpretation that urllib2 raise an
HTTPError to signal "request confirm" because an HTTPError
is also a valid response that the user could interpret.  But
of urllib, an HTTP error doesn't contain a valid response. 
The change would make it impossible for the client to do
anything if a 301 response is returned from a POST.  That
seems worse than doing the wrong.



----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-10-09 20:27

Message:
Logged In: YES 
user_id=6380

OK, over to jeremy.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-10-09 16:16

Message:
Logged In: YES 
user_id=261020

Ah.  Here it is.

John


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-10-08 13:23

Message:
Logged In: YES 
user_id=6380

Um, I don't see the patch for urllib.py.  Perhaps you didn't
check the box?

Jeremy, let's do this in 2.3, OK?

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-10-08 11:53

Message:
Logged In: YES 
user_id=261020

Guido mentioned that urllib.py should be fixed
too.  I've attached another patch.


John


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-10-05 12:44

Message:
Logged In: YES 
user_id=261020

Here is a patch for the minor documentation changes required
for the patch I uploaded earlier to fix this bug.  I've also
uploaded a slightly revised patch:

I renamed the `method' method to `get_method' for
consistency with the other methods of the Request class.
The reason this new method is there at all is because the
logic that decides whether or not a redirection should take
place is defined in terms of the method type
(GET/HEAD/POST).  urllib2 doesn't support HEAD ATM, but it
might in future.  OTOH, the Request class is supposed to be
generic -- not specific to HTTP -- so perhaps get_method
isn't really appropriate.  OTOOH, add_data is already
documented to only be meaningful for HTTP Requests.  I
suppose there could be a subclass HTTPRequest, but that's
less simple.  What do you think is best?

I also changed redirect_request to raise an exception
instead of returning None (because no other Handler should
handle the redirect), and changed its documented return
value / exception interface to be consistent with the rest
of urllib2.


John


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-06-23 14:23

Message:
Logged In: YES 
user_id=261020

First, can I underline the fact that there are two issues
here:

  1. What method should POST be redirected as for a
     particular 30x response?

  2. Should the user be asked to confirm the redirection
     (which presumably maps onto raising an HTTPError in
     urllib2)?

I think current client implementations go against the RFCs
on both these points for 302.  Contrastingly, RFC 2616's
note on 301 responses (section 10.3.2) implies that only a
subset of HTTP/1.0 (not 1.1, note) clients violate the RFCs
(1945, 2068, 2616) on point 1 for 301 responses, and I know
of no clients that violate the RFCs on point 2 for 301
responses (but I haven't tested).  Also, I guess the
original intent (for both 301 and 302) was that POSTs
represent an action, so it's dangerous in general to
redirect them without asking the user: I presume this is why
307 was brought in: 307 POSTs on redirected POST, so the
user must be asked:

10.3 Redirection 3xx
[...]
   The action required MAY be carried out by the user agent
   without interaction with the user if and only if the
   method used in the second request is GET or HEAD.

(and 303 is just meant to have the 'erroneous' 302
behaviour: GET on redirected POST, don't ask the user)

So, I agree with Guido that 302 should probably now be
treated the way most clients treat it: GET on redirected
POST, don't ask the user.  As for 301, if it *is* true that
only a few HTTP/1.0 clients have misinterpreted the RFCs on
301, we should stick to the safe behaviour indicated by the
RFC.

As for Guido's first question: A 307 should indeed be
redirected as a POST, but it should ask the user first (see
10.3 quote, above).  That's what my patch does (the 'return
None' in the else clause in redirect_request causes an
exception to be raised eventually -- maybe it should just
raise it itself).

I've attached a revised patch that deals with 302 (and 303)
in the 'erroneous' way (again: GET on redirected POST, don't
ask the user).

I suppose the comment about HTTPRedirectHandler also needs
to state that 301 and 307 POST requests are not
automatically redirected -- HTTPError is raised in that
case.


John


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-19 19:57

Message:
Logged In: YES 
user_id=6380

Hm, I thought that 307 should be treated differently than
303. In particular, a 307 response to POST should cause the
POST to be redirected. And I'm not sure about what a 301
response to POST should do.

(In the mean time I have been convinced that changing POST
to GET on 302 is the best thing to do given that most
browsers do that. The old urllib.py should be fixed too.)

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-06-19 16:57

Message:
Logged In: YES 
user_id=261020

I've attached a patch -- was simpler than I thought.

I think this is in compliance with RFC 2616.  It's also
simple for clients to inherit from HTTPRedirectHandler and
override redirect_request if, for example, they know they
want all 302 POSTs to be redirected as a GET, which removes
the need for mixing redirection code with normal client code
even when the server doesn't follow the RFC (if the server
expects a 302 POST to be redirected as a GET, for example).
Note that I had to add a method, named 'method', to the
Request class, for maintainability (it's possible that
urllib2 may be able to do methods other than GET and POST in
future).

Possibly redirect_request should take fewer parameters.

John


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-06-19 16:56

Message:
Logged In: YES 
user_id=261020

I've attached a patch -- was simpler than I thought.

I think this is in compliance with RFC 2616.  It's also
simple for clients to inherit from HTTPRedirectHandler and
override redirect_request if, for example, they know they
want all 302 POSTs to be redirected as a GET, which removes
the need for mixing redirection code with normal client code
even when the server doesn't follow the RFC (if the server
expects a 302 POST to be redirected as a GET, for example).
Note that I had to add a method, named 'method', to the
Request class, for maintainability (it's possible that
urllib2 may be able to do methods other than GET and POST in
future).

Possibly redirect_request should take fewer parameters.

John


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-06-06 16:25

Message:
Logged In: YES 
user_id=261020

Oh, I hadn't realised httplib uses HTTP/1.1 now -- and now I
check, I see that even RFC 1945 (HTTP/1.0) has a whole set of
restrictions on 30x for particular values of x which I missed
completely.

I guess it should do what Guido suggested -- report an error if a
POST is redirected -- until somebody gets time to do it properly.
I won't have time for a couple of months, but if nobody has done
it by then I'll upload a patch.


John


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-06-06 10:09

Message:
Logged In: YES 
user_id=31392

I think you need to review the current HTTP spec -- RFC 2616
-- and look at the section on redirection (10.3).  I think
urllib2 could improve its handling of redirection, but the
behavior you describe from lynx sounds incorrect.  I'd be
happy to review a patch the implemented the current spec.

Also, RFC 2616 removes the recommendation of a 5 redirect limit.




----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-29 13:10

Message:
Logged In: YES 
user_id=6380

Fair enough. I'll leve it to Jeremy to review the proposed
fix. (Note that he's busy though.)

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-04-29 11:29

Message:
Logged In: YES 
user_id=261020

I don't see why it shouldn't substitue a GET.  That certainly seems to be
the standard practice (well, at least that's what lynx does), and in the case
of the only site where I've encountered redirects on POST, the redirect URL
contains urlencoded stuff, so it clearly expects the user-agent to do a GET.
The site would break if this didn't happen, so I guess Netscape and IE must
do the same thing.

Clearly the RFC *does* allow this, though it doesn't require it (or specify
what should happen here in any way other than to say that a POST is not
allowed, in fact).  Since it's standard practice and allowed by the RFC, I
don't think it should be an error.

John


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-28 19:53

Message:
Logged In: YES 
user_id=6380

Hm, the way I interpret the text you quote, if the original
request is  a POST, it should probably not substitute a GET
but report the error.

Assigning to Jeremy since it's his module.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-04-28 11:21

Message:
Logged In: YES 
user_id=261020

1. Bug is also in 2.2 branch

2. The fix (in 2.1 and 2.2) should reflect the earlier bug fix in the 2.2 branch to add the old headers:

new = Request(newurl, headers=req.headers)

3. I guess 10 should be replaced with 4, not 5.


John


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470


From noreply@sourceforge.net  Fri Apr 25 09:27:18 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 25 Apr 2003 01:27:18 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-686323 ] Minor array module enhancements
Message-ID: <E198yYA-0007ye-00@sc8-sf-web3.sourceforge.net>

Feature Requests item #686323, was opened at 2003-02-13 20:13
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=686323&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: Later
Priority: 4
Submitted By: paul rubin (phr)
>Assigned to: Nobody/Anonymous (nobody)
Summary: Minor array module enhancements

Initial Comment:
1) I notice that array('B', (2,3,4)) throws an error
saying the
2nd arg must be a list or string.  That is, array('B',
[2,3,4]) is
legal but using the tuple (2,3,4) is not.  The
limitation doesn't
seem harmful, but I also don't see any good reason for
it.  May
as well remove it.

2) Of more usefulness (and maybe of more controversy), I
think the byte array methods should accept string
arguments,
for example
   a = array('B', 'abc')
   a.append('def')
should do the obvious thing.  That gives a natural way to
build up a string in pieces instead of making a list of
strings
and doing the counterintuitive ''.join(x) maneuver. 
Appending
to byte arrays is the usual way to build up a string in
Java,
if that matters.  So I favor this change too.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-24 05:48

Message:
Logged In: YES 
user_id=80475

Added the first request as
  arraymodule.c 2.88

I'm passing on the second request for now.
Auto-promoting the argument entails attempting
to construct a new array object of the same type
as that being extended.  That is a bit cumbersome
but doable.  It also requires that any array creation
errors be trapped and re-explained the context of
array.extend().

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2003-02-13 23:42

Message:
Logged In: YES 
user_id=72053

You're correct, second request should be for extend rather
than append.

That is,

a = array('B', 'abc')
a.extend('def')

should do the obvious thing.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-02-13 23:34

Message:
Logged In: YES 
user_id=80475

The first request is reasonable.

The second is not the natural meaning of append().  In 
python, multiple appends are handled with extend().  The 
array module already provides extend.  So, for the 
example given above, the code is:

>>> a = array('B', 'abc')
>>> a.extend(array('B', 'def'))
>>> a
array('B', [97, 98, 99, 100, 101, 102])

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=686323&group_id=5470


From noreply@sourceforge.net  Fri Apr 25 09:55:32 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 25 Apr 2003 01:55:32 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-674689 ] enhancements for doctest
Message-ID: <E198yzU-00044q-00@sc8-sf-web1.sourceforge.net>

Feature Requests item #674689, was opened at 2003-01-25 14:44
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=674689&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 4
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Tim Peters (tim_one)
Summary: enhancements for doctest

Initial Comment:
1) Add a method, doctest.regen(outputfile, 
module=None), which creates a copy of the module 
but with the test results unconditionally updated.  
This is similar in spirit to the -g option for regrtest.py.

The principal use case is to handle a situation where 
only the output formatting has changed, but the 
internal logic is unchanged (suppose, for instance, 
that L stopped appearing at the end of long integers).


2) Add options for sloppy test matches: 
doctest.testmod(mymod, strictdictorder=False, 
exactfloats=False).  The default should continue to be 
strict.

The goal is to make doctest easier to use and 
produce more readable documentation by eliminating 
the gyrations to avoid dependencies on dictionary 
order or exact floating point results.  Replace this:

>>> r = mydict.items()
>>> r.sort()  
>>> r
[('eggs',1), ('spam', 2)]
>>> round(1./7, 5)
0.14285999999999999

with this:

>>> mydict.items()
[('eggs',1), ('spam', 2)]
>>> 1./7
0.14285714285714285


3) Since the interactive session may have been 
produced in IDLE instead of the command line, don't 
depend on PS2 being equal to "...". 

If the first line after '>>>' startswith('...'), then 
continue to use '...', but if it doesn't, then continue to 
read input until a black line is encountered (i.e. match 
the logic used by IDLE). 

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-25 03:55

Message:
Logged In: YES 
user_id=80475

These don't all seem like a great idea anymore.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=674689&group_id=5470


From noreply@sourceforge.net  Fri Apr 25 10:03:44 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 25 Apr 2003 02:03:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-724774 ] test_getargs2 failing
Message-ID: <E198z7Q-0002w0-00@sc8-sf-web4.sourceforge.net>

Bugs item #724774, was opened at 2003-04-21 00:14
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724774&group_id=5470

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: test_getargs2 failing

Initial Comment:
Adding this just so it doesn't fall by the roadside (it's been discussed 
on python-dev): test_getargs2 is currently failing, at least on MacOSX.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2003-04-25 11:03

Message:
Logged In: YES 
user_id=45365

It works!

Thanks everyone!

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-24 21:10

Message:
Logged In: YES 
user_id=33168

I think HPs and Alphas are not big-endian, but Sun's are. 
The Sun was the only one failling.  With the last checkin,
the Sun is now working.  Hopefully, it works on OS X too.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-04-24 18:20

Message:
Logged In: YES 
user_id=11105

I've commited changes to Modules/_testcapimodule.c and
Lib/test/test_getargs2.py which will hopefully fix the problems.

Since this is only test code, I've checked it in without
asking ;-)

Re Big endian: I've got this impression simply by reading
the code. But I've never programmed on such a machine.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-04-24 15:12

Message:
Logged In: YES 
user_id=45365

Yes, I will be able to test it. But it will have to be tomorrow.

BTW: does this mean that there are *no* bigendian machines in the 
snakefarm? That surprises me, I seem to remember than almost all machines 
except intels (i.e. suns, hps, sgi's) are big-endian...

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-04-23 21:17

Message:
Logged In: YES 
user_id=11105

Jack, if I try to fix this (by implementing the C functions
needed) would you be able to test this, or should we simply
comment out the failing tests and do this after the release? 

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-23 20:04

Message:
Logged In: YES 
user_id=6380

Yes, that makes sense, and I remember seeing that and
thinking, "hmm, that's not right". You probably need
separate C functions for each C data type to test. :-(

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-04-23 13:49

Message:
Logged In: YES 
user_id=11105

Um, I think I found the reason. test_getargs2 uses
getargs_ul (in _testcapimodule.c) to call
PyArg_ParseTuple(), and this always passes a pointer to an
unsigned long, even for H and B format codes. On little
endian machines casting this pointer into a unsigned short
pointer works ok, but not on big endian machines. Makes sense?

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-04-23 13:29

Message:
Logged In: YES 
user_id=11105

Strange, since 196608 == 0x30000, and 50331648 == 0x3000000.
Even stranger (to me) is that the test for upper case i
works, and it uses nearly the same code.

Does it help the test_H case to change line 485 of getargs.c
from 'long ival;' to 'unsigned short ival;', but I'm only
guessing?

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-04-23 12:39

Message:
Logged In: YES 
user_id=45365

Yes, I still have the problem. The test output is attached.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-22 16:16

Message:
Logged In: YES 
user_id=33168

This is fixed on all the snake-farm machines AFAIK.  Jack,
are you still having the problems?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-21 19:42

Message:
Logged In: YES 
user_id=33168

This is failling on several other architectures in the snake
farm:  http://www.lysator.liu.se/xenofarm/python/latest.html

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724774&group_id=5470


From noreply@sourceforge.net  Fri Apr 25 10:32:32 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 25 Apr 2003 02:32:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-680789 ] repr() of large array objects takes quadratic time
Message-ID: <E198zZI-000657-00@sc8-sf-web1.sourceforge.net>

Bugs item #680789, was opened at 2003-02-05 11:00
Message generated for change (Comment added) made by jneb
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=680789&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Jurjen N.E. Bos (jneb)
Assigned to: Raymond Hettinger (rhettinger)
Summary: repr() of large array objects takes quadratic time

Initial Comment:
This is a bug and a partial patch.

If I debug a program that contains a ridiculously large array (8M entries in my case), the debugger takes forever.
It happens in Mac OS X, Python 2.2, but I found the bug in is the repr module, so it is probably universal.
The thing is, that after the fix below, it still doesn't work!
Did I miss something trivial (like repr is builtin, or something like that?). Would someone with Mac OS X experience help out here, please (Jack?).

Here's the diff to make repr.repr work with large arrays:
13a14
>       self.maxarray = 5
50a52,62
>     def repr_array(self, x, level):
>         n = len(x)
>       header = "array('"+x.typecode+"', ["
>         if n == 0: return header+"])"
>         if level <= 0: return header+"...])"
>         s = ''
>         for i in range(min(n, self.maxarray)):
>             if s: s = s + ', '
>             s = s + self.repr1(x[i], level-1)
>         if n > self.maxarray: s = s + ', ...'
>         return header + s + "])"

----------------------------------------------------------------------

>Comment By: Jurjen N.E. Bos (jneb)
Date: 2003-04-25 09:32

Message:
Logged In: YES 
user_id=446428

The debugger I use, is not pdb, but the Mac only IDE debugger. I thought 
this was only a front end on pdb, but it apparently is not.
It seems that it is still slow in 2.3. (I can't check it at the moment, I am 
running a multiple hour computation...)
May it will automatically be fixed if Jack manages to get IDLE working on the 
Mac...


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-23 17:33

Message:
Logged In: YES 
user_id=80475

Fixed this up by converting the array to a list and then 
using the list object's efficient repr().

See Modules/arraymodule.c 2.87.

Since I categorize this as a performance issue and not a 
bug, I've applied the fix to Py2.3 but am not 
recommending for backport.

----------------------------------------------------------------------

Comment By: logistix (logistix)
Date: 2003-02-12 01:43

Message:
Logged In: YES 
user_id=699438

arraymodule's repr used "string += ',' + el" for each element in 
the array.  Lists and dicts did a string.join to build the repr.

Attached patch builds a tuple of array elements and then 
joins them.  (actually for some reason I can't attach now, I'll 
post the patch in patch manager)

This fixes the time issue, but I don't know enough about how 
you guys manage memory in each case to tell what impact 
that'll have on really, really big arrays (although I imagine it 
takes more memory).



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-02-07 01:40

Message:
Logged In: YES 
user_id=31435

I can't make time for this, so unassigned it.  It would make 
a good, brief project for someone -- the list and dict 
tp_reprs are linear-time, and tp_repr for array.array 
objects shouldn't be any harder than they were.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-02-06 21:37

Message:
Logged In: YES 
user_id=45365

Okay, so the real bug is that tp_repr of array objects takes quadratic time.

I'm changing the summary of this report then, and assigning back to you (Tim), on the basis that you did more checkins on arraymodule than I did. Feel free to pass the potato on:-)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-02-05 23:08

Message:
Logged In: YES 
user_id=31435

pdb does import repr.py, but probably doesn't use it in 
whatever way Jurjen is using to display his big array.

WRT that, note that Jurjen is using array.array objects, not 
lists.  The internal array.array tp_repr slot is quadratic-time in 
the size of the array, while list's tp_repr is linear time.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-02-05 22:40

Message:
Logged In: YES 
user_id=45365

The fix is fine (it works for me the same way as for Tim), but I think we're shooting past the problem here.

First, pdb doesn't use repr.repr(), it uses the normal builtin repr().

Second, I don't see any sluggishness in pdb with large arrays. I tried
debugging
def foo():
    a = range(8000000)
and there was no problem. Allocating the object took a bit of time, yes, and if you actually try to print it you'll stare at about 800K lines filled with digits scrolling over your screen, but that is to be expected.

Could it be your sluggishness is coming from something else? For example, MacOSX starts behaving *very* badly if your root disk is full, because then it can't allocate swap space, and due to its optimistic behaviour it comes to a grinding halt.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-02-05 18:36

Message:
Logged In: YES 
user_id=31435

Nice to see you, Jurgen!  I checked this into current CVS, 
and it works fine for me in isolation:

>>> len(a)
11055060
>>> repr.repr(a)
"array('i', [0, 1, 2, 3, 4, ...])"
>>>

That goes in an eyeblink.  So more detail is needed about 
what "it still doesn't work!" means.  Assigned to Jack, and he 
can use current CVS to try it.

Lib/repr.py; new revision: 1.15
Lib/test/test_repr.py; new revision: 1.16
Misc/NEWS; new revision: 1.642

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=680789&group_id=5470


From noreply@sourceforge.net  Fri Apr 25 10:35:39 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 25 Apr 2003 02:35:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-539990 ] Framework.mainloop() - multiple threads
Message-ID: <E198zcJ-0006Fx-00@sc8-sf-web1.sourceforge.net>

Bugs item #539990, was opened at 2002-04-05 21:29
Message generated for change (Comment added) made by jneb
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=539990&group_id=5470

Category: Macintosh
Group: Platform-specific
Status: Open
Resolution: Wont Fix
Priority: 7
Submitted By: Pieter Claerhout (pclaerhout)
Assigned to: Just van Rossum (jvr)
Summary: Framework.mainloop() - multiple threads

Initial Comment:
I tried to use the threading module to start the XML 
RPC server in a different thread (xmlrpcServer itself 
also is a threaded piece of code), but that seems to 
conflict with the mainloop. If you start this 
application, it starts the thread, starts the mainloop 
and stays in there, once you finish the mainloop, the 
thread continues.

You've stumbled on a bug in Framework.mainloop(): it 
doesn't know anything about multiple threads. It gives 
time to other applications (by calling WaitNextEvent) 
but not to other threads within Python.

Also see
http://mail.python.org/pipermail/pythonmac-sig/2002-
April/005416.html

and 

http://mail.python.org/pipermail/pythonmac-sig/2002-
April/005428.html

----------------------------------------------------------------------

Comment By: Jurjen N.E. Bos (jneb)
Date: 2003-04-25 09:35

Message:
Logged In: YES 
user_id=446428

Probably fixing this will also allow to run a long computation and still use 
the IDE for writing other code, or run commands in interactive mode.
Sounds like a cool feature!

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-02-25 10:43

Message:
Logged In: YES 
user_id=45365

If that is true I would be very happy. Could you please investigate this and put it in if it works? Before 2.3b1 please: I don't want to mess with the core of the MacOS support modules after that...

----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2003-02-24 18:51

Message:
Logged In: YES 
user_id=92689

Jack, have you forgotten about autoGIL? It's quite likely that the autoGIL module (as part of the PyObjC project) would fix this issue out of the box on OSX. Do "import autoGIL; autoGIL.installAutoGIL()" before you enter the event loop and the second thread gets time to run.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-02-24 16:45

Message:
Logged In: YES 
user_id=45365

Let's admit this isn't going to be fixed unless someone wants it real bad.

Pieter: if you want it real bad then reopen the bug and I'll find time for it.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-04-22 14:03

Message:
Logged In: YES 
user_id=45365

After some discussion on the SIG it turns out this is a rather complicated problem, because WNE() may cause callbacks to be called (for Carbon Event handlers, for instance), and releasing the GIL would mean those callbacks would be hosed.

A solution will have to have all callback wrappers acquire the GIL, and it will either have to make very sure we never enter WNE() or friends with the GIL held, or the callback code will need to be able to handle both the case of being called with the GIL held and the case of being called without it.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-04-07 21:26

Message:
Logged In: YES 
user_id=45365

Adding an optional time.sleep(0) to the mainloop should do the trick, but unfortunately this won't work with the current MacPython, as time.sleep() is implemented with select(). And while GUSI sleep(0) does the threadswitch sleect(..., 0) doesn't. So this needs to be fixed in timemodule, and then the thread switch can be forced in Framework.Application.mainloop().

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=539990&group_id=5470


From noreply@sourceforge.net  Fri Apr 25 11:53:15 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 25 Apr 2003 03:53:15 -0700
Subject: [Python-bugs-list] [ python-Bugs-727241 ] Core Dumps : Python2.2.2
Message-ID: <E1990pP-0000nH-00@sc8-sf-web4.sourceforge.net>

Bugs item #727241, was opened at 2003-04-24 23:16
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727241&group_id=5470

Category: None
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Eli Rosenberg (elirosenberg)
Assigned to: Nobody/Anonymous (nobody)
Summary: Core Dumps : Python2.2.2 

Initial Comment:

Hello,
I am able to cause python to core dump on IRIX
6.5.18 and above with the code listed below.  I have
compiled with 3 versions of gcc as well as MIPSpro.

Running this code with a valid host and a port
that will cause a connection refused socket error
produces a core dump with the the stack trace below.

>>> import socket
>>> x=socket.socket()
>>> x.connect(('www.google.com', 1234))


>  0 realfree(0x10162e98, 0x0, 0x200000, 0x65637469,
0x17dd4, 0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":527,
0xfb245fc]
   1 cleanfree(0x0, 0x0, 0x200000, 0x65637469, 0x17dd4,
0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":945,
0xfb24e44]
   2 __malloc(0x28, 0x0, 0x200000, 0x65637469, 0x17dd4,
0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":230,
0xfb24078]
   3 _malloc(0x28, 0x0, 0x200000, 0x65637469, 0x17dd4,
0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":186,
0xfb23ee4]
   4 _PyObject_GC_Malloc(tp = 0x1013fbe0, nitems = 0)
["/usr/people/eli/Python-2.2.2/Modules/gcmodule.c":868,
0x10092244]
   5 _PyObject_GC_New(tp = 0x1013fbe0)
["/usr/people/eli/Python-2.2.2/Modules/gcmodule.c":895,
0x10092368]
   6 newtracebackobject(next = (nil), frame =
0x1016b670, lasti = 21, lineno = 1)
["/usr/people/eli/Python-2.2.2/Python/traceback.c":115,
0x100c6684]
   7 PyTraceBack_Here(frame = 0x1016b670)
["/usr/people/eli/Python-2.2.2/Python/traceback.c":133,
0x100c67f4]
   8 eval_frame(f = 0x1016b670)
["/usr/people/eli/Python-2.2.2/Python/ceval.c":2238,
0x1004e894]
   9 PyEval_EvalCodeEx(co = 0x1016e990, globals =
0x1016a5d0, locals = 0x1016a5d0, args = (nil), argcount
= 0, kws = (nil), kwcount = 0, defs = (nil), defcount =
0, closure = (nil))
["/usr/people/eli/Python-2.2.2/Python/ceval.c":2595,
0x1004ffe0
   10 PyEval_EvalCode(co = 0x1016e990, globals =
0x1016a5d0, locals = 0x1016a5d0)
["/usr/people/eli/Python-2.2.2/Python/ceval.c":481,
0x10047ea0]
   11 run_node(n = 0x101a5b28, filename = 0x1014e978 =
"<stdin>", globals = 0x1016a5d0, locals = 0x1016a5d0,
flags = 0x7fff2e2c)
["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":1079,
0x1006f380]
   12 PyRun_InteractiveOneFlags(fp = 0xfb53680,
filename = 0x1014e978 = "<stdin>", flags = 0x7fff2e2c)
["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":590,
0x1006d57c]
   13 PyRun_InteractiveLoopFlags(fp = 0xfb53680,
filename = 0x1014e978 = "<stdin>", flags = 0x7fff2e2c)
["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":526,
0x1006d198]
   14 PyRun_AnyFileExFlags(fp = 0xfb53680, filename =
0x1014e978 = "<stdin>", closeit = 0, flags =
0x7fff2e2c)
["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":489,
0x1006cf48]
   15 Py_Main(argc = 1, argv = 0x7fff2f24)
["/usr/people/eli/Python-2.2.2/Modules/main.c":364,
0x1000fa44]
   16 main(argc = 1, argv = 0x7fff2f24)
["/usr/people/eli/Python-2.2.2/Modules/python.c":10,
0x1000ecdc]
   17 __start()
["/xlv55/kudzu-apr12/work/irix/lib/libc/libc_n32_M4/csu/crt1text.s":177,
0x1000ec78]

I compiled Python 64-bit and the code above appears
not to cause a segfault but the code below will
bus error after a few iterations.

import socket
import time

def doit():
          s = socket.socket()
          start = time.time()
          
          try:
               s.connect(('www.cnn.com', 80))
          except socket.error,e:
               print repr(e),str(e)
          finish = time.time()
          time.sleep(.5)
          print str(finish-start),"\n"
          s.close()

for x in xrange(10):
     doit()

Here is the stack trace:

>  0 realfree(0x10162e98, 0x0, 0x200000, 0x65637469,
0x17dd4, 0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":527,
0xfb245fc]
   1 cleanfree(0x0, 0x0, 0x200000, 0x65637469, 0x17dd4,
0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":945,
0xfb24e44]
   2 __malloc(0x28, 0x0, 0x200000, 0x65637469, 0x17dd4,
0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":230,
0xfb24078]
   3 _malloc(0x28, 0x0, 0x200000, 0x65637469, 0x17dd4,
0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":186,
0xfb23ee4]
   4 _PyObject_GC_Malloc(tp = 0x1013fbe0, nitems = 0)
["/usr/people/eli/Python-2.2.2/Modules/gcmodule.c":868,
0x10092244]
   5 _PyObject_GC_New(tp = 0x1013fbe0)
["/usr/people/eli/Python-2.2.2/Modules/gcmodule.c":895,
0x10092368]
   6 newtracebackobject(next = (nil), frame =
0x1016b670, lasti = 21, lineno = 1)
["/usr/people/eli/Python-2.2.2/Python/traceback.c":115,
0x100c6684]
   7 PyTraceBack_Here(frame = 0x1016b670)
["/usr/people/eli/Python-2.2.2/Python/traceback.c":133,
0x100c67f4]
   8 eval_frame(f = 0x1016b670)
["/usr/people/eli/Python-2.2.2/Python/ceval.c":2238,
0x1004e894]
   9 PyEval_EvalCodeEx(co = 0x1016e990, globals =
0x1016a5d0, locals = 0x1016a5d0, args = (nil), argcount
= 0, kws = (nil), kwcount = 0, defs = (nil), defcount =
0, closure = (nil))
["/usr/people/eli/Python-2.2.2/Python/ceval.c":2595,
0x1004ffe0
   10 PyEval_EvalCode(co = 0x1016e990, globals =
0x1016a5d0, locals = 0x1016a5d0)
["/usr/people/eli/Python-2.2.2/Python/ceval.c":481,
0x10047ea0]
   11 run_node(n = 0x101a5b28, filename = 0x1014e978 =
"<stdin>", globals = 0x1016a5d0, locals = 0x1016a5d0,
flags = 0x7fff2e2c)
["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":1079,
0x1006f380]
   12 PyRun_InteractiveOneFlags(fp = 0xfb53680,
filename = 0x1014e978 = "<stdin>", flags = 0x7fff2e2c)
["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":590,
0x1006d57c]
   13 PyRun_InteractiveLoopFlags(fp = 0xfb53680,
filename = 0x1014e978 = "<stdin>", flags = 0x7fff2e2c)
["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":526,
0x1006d198]
   14 PyRun_AnyFileExFlags(fp = 0xfb53680, filename =
0x1014e978 = "<stdin>", closeit = 0, flags =
0x7fff2e2c)
["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":489,
0x1006cf48]
   15 Py_Main(argc = 1, argv = 0x7fff2f24)
["/usr/people/eli/Python-2.2.2/Modules/main.c":364,
0x1000fa44]
   16 main(argc = 1, argv = 0x7fff2f24)
["/usr/people/eli/Python-2.2.2/Modules/python.c":10,
0x1000ecdc]
   17 __start()
["/xlv55/kudzu-apr12/work/irix/lib/libc/libc_n32_M4/csu/crt1text.s":177,
0x1000ec78]

Any help would be appreciated. thanks.
-Eli

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2003-04-25 11:53

Message:
Logged In: YES 
user_id=6656

This looks nasty...

Could you try making a debug build of Python (pass
--with-pydebug to ./configure) and/or try with current CVS?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727241&group_id=5470


From noreply@sourceforge.net  Fri Apr 25 15:07:22 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 25 Apr 2003 07:07:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-724771 ] test_grp failing
Message-ID: <E1993rG-0001sS-00@sc8-sf-web3.sourceforge.net>

Bugs item #724771, was opened at 2003-04-21 00:13
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724771&group_id=5470

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: test_grp failing

Initial Comment:
Adding this just so it doesn't fall by the roadside (it's been discussed 
on python-dev): test_grp is failing on MacOSX, probably because
there are multiple groups with the same numeric id (didn't 
investigate, though).

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2003-04-25 16:07

Message:
Logged In: YES 
user_id=45365

The problem is fixed. For reasons unknown the fix isn't needed for pwd: 
getpwuid() returns a * password, just like getpwall().

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2003-04-23 21:55

Message:
Logged In: YES 
user_id=89016

I checked in test_grp.py 1.15, which will hopefully fix the
problem: Mac OS X returns "*" as the password in
grp.getgrall() and "" in grp.getgrgid(). Does test_grp work
now? Should the same fix be done for test_pwd?

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-04-23 00:16

Message:
Logged In: YES 
user_id=45365

It stil fails, sigh.

I've added the output, maybe that tells you more?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-22 16:17

Message:
Logged In: YES 
user_id=33168

I believe this problem was fixed on all the snake-farm
machines after Walter's last checkins.  Thanks Walter.

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2003-04-22 16:14

Message:
Logged In: YES 
user_id=89016

Could you try the attached patch and post the output?

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-04-22 15:28

Message:
Logged In: YES 
user_id=45365

Still fails:
  File "/Users/jack/src/python/Lib/test/test_grp.py", line 37, in test_values
    self.assert_(grp.getgrgid(e.gr_gid) in entriesbygid[e.gr_gid])
  File "/Users/jack/src/python/Lib/unittest.py", line 268, in failUnless
    if not expr: raise self.failureException, msg


----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2003-04-22 13:09

Message:
Logged In: YES 
user_id=89016

According to
http://www.lysator.liu.se/xenofarm/python/files/579_3/python-testlog.txt
the problem is not duplicate ids, but duplicate names. I've
changed
test_pwd and test_grp, so that they handle names in the same
way as ids. (test_pwd.py 1.15, test_grp.py 1.14). Does this
fix the problem?


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-21 19:42

Message:
Logged In: YES 
user_id=33168

This is failling on several other architectures in the snake
farm:  http://www.lysator.liu.se/xenofarm/python/latest.html

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724771&group_id=5470


From noreply@sourceforge.net  Fri Apr 25 15:22:41 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 25 Apr 2003 07:22:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-699594 ] refcount problem involving debugger
Message-ID: <E199465-0003nk-00@sc8-sf-web1.sourceforge.net>

Bugs item #699594, was opened at 2003-03-07 14:58
Message generated for change (Settings changed) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699594&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
>Priority: 5
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Guido van Rossum (gvanrossum)
>Summary: refcount problem involving debugger

Initial Comment:
Barry and I have both seen a debug version of Python
fail when we exit an interpreter after using pdb.  The
failure in both cases is reported in line 400 of
frameobject.c on the first iteration of the loop that
frees the stack.  The object being decrefed has already
been freed.

I don't know how to reliably provoke the problem, but I
do have a core file.

(gdb) where
#0  0x42029331 in kill () from /lib/i686/libc.so.6
#1  0x40033bdb in raise () from /lib/i686/libpthread.so.0
#2  0x4202a8c2 in abort () from /lib/i686/libc.so.6
#3  0x080e4aac in Py_AtExit (func=0xbfffba80) at
../Python/pythonrun.c:1369
#4  0x0807d767 in _Py_NegativeRefcount (
    fname=0x8125884 "../Objects/frameobject.c",
lineno=400, op=0x4078e114)
    at ../Objects/object.c:104
#5  0x08105e26 in frame_dealloc (f=0x81c0d24) at
../Objects/frameobject.c:400
#6  0x08081723 in _Py_Dealloc (op=0x81c0d24) at
../Objects/object.c:1976
#7  0x080e7522 in tb_dealloc (tb=0x40788b74) at
../Python/traceback.c:41
#8  0x08081723 in _Py_Dealloc (op=0x40788b74) at
../Objects/object.c:1976
#9  0x080e74ca in tb_dealloc (tb=0x40788cb4) at
../Python/traceback.c:40
#10 0x08081723 in _Py_Dealloc (op=0x40788cb4) at
../Objects/object.c:1976
#11 0x080e74ca in tb_dealloc (tb=0x40788cf4) at
../Python/traceback.c:40
#12 0x08081723 in _Py_Dealloc (op=0x40788cf4) at
../Objects/object.c:1976
#13 0x0807a197 in PyDict_DelItem (op=0x4007f994,
key=0x4081a5e8)
    at ../Objects/dictobject.c:571
#14 0x0807d4de in PyDict_DelItemString (v=0x4007f994, 
    key=0x8119ab0 "exc_traceback") at
../Objects/dictobject.c:1973
#15 0x080e5382 in PySys_SetObject (name=0x8119ab0
"exc_traceback", v=0x0)
    at ../Python/sysmodule.c:65
#16 0x080bfa91 in reset_exc_info (tstate=0x4007c028) at
../Python/ceval.c:2750
#17 0x080be907 in eval_frame (f=0x81c058c) at
../Python/ceval.c:2367
#18 0x080bf4d3 in PyEval_EvalCodeEx (co=0x4015c9c8,
globals=0x401f2d54, 
    locals=0x0, args=0x40773898, argcount=2, kws=0x0,
kwcount=0, 
    defs=0x40162ef0, defcount=1, closure=0x0) at
../Python/ceval.c:2602
#19 0x08108877 in function_call (func=0x4016a444,
arg=0x40773884, kw=0x0)
    at ../Objects/funcobject.c:501
#20 0x0805bf67 in PyObject_Call (func=0x4016a444,
arg=0x40773884, kw=0x0)
    at ../Objects/abstract.c:1755
#21 0x08063fd6 in instancemethod_call (func=0x4016a444,
arg=0x40773884, kw=0x0)
    at ../Objects/classobject.c:2411
#22 0x0805bf67 in PyObject_Call (func=0x40730074,
arg=0x40769f4c, kw=0x0)
    at ../Objects/abstract.c:1755
#23 0x0809b4f9 in slot_tp_call (self=0x406d2d54,
args=0x40769f4c, kwds=0x0)
    at ../Objects/typeobject.c:4357
#24 0x0805bf67 in PyObject_Call (func=0x406d2d54,
arg=0x40769f4c, kw=0x0)
    at ../Objects/abstract.c:1755
#25 0x080c186d in do_call (func=0x406d2d54,
pp_stack=0xbfffc344, na=1, nk=0)
    at ../Python/ceval.c:3565
#26 0x080c1115 in call_function (pp_stack=0xbfffc344,
oparg=1)
    at ../Python/ceval.c:3381
#27 0x080bd63f in eval_frame (f=0x8178f64) at
../Python/ceval.c:2055
#28 0x080bf4d3 in PyEval_EvalCodeEx (co=0x4015f810,
globals=0x401f2d54, 
    locals=0x0, args=0x40773240, argcount=2, kws=0x0,
kwcount=0, defs=0x0, 
    defcount=0, closure=0x0) at ../Python/ceval.c:2602


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-11 13:30

Message:
Logged In: YES 
user_id=6380

I hav seen segfaults like this too, but never bothered to
debug them. :-(

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-03-07 15:57

Message:
Logged In: YES 
user_id=6380

This is going to be tricky unless we find a reliable way to
reproduce it. :-(

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699594&group_id=5470


From noreply@sourceforge.net  Fri Apr 25 15:35:53 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 25 Apr 2003 07:35:53 -0700
Subject: [Python-bugs-list] [ python-Bugs-678217 ] test_logging fails
Message-ID: <E1994Ir-0004hl-00@sc8-sf-web1.sourceforge.net>

Bugs item #678217, was opened at 2003-01-31 11:43
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678217&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_logging fails

Initial Comment:
When I run the test suite, test_logging sometimes
fails.  It misses the following output and gets a bunch
of exceptions llike the one I included at the end.  I
haven't counted, but I'd guess that there's one
traceback for each missing line of output.

test test_logging produced unexpected output:
**********************************************************************
*** lines 489-514 of expected output missing:
- ERR -> CRITICAL: Message 0 (via logrecv.tcp.ERR)
- ERR -> ERROR: Message 1 (via logrecv.tcp.ERR)
- INF -> CRITICAL: Message 2 (via logrecv.tcp.INF)
- INF -> ERROR: Message 3 (via logrecv.tcp.INF)
- INF -> WARN: Message 4 (via logrecv.tcp.INF)
- INF -> INFO: Message 5 (via logrecv.tcp.INF)
- INF.UNDEF -> CRITICAL: Message 6 (via
logrecv.tcp.INF.UNDEF)
- INF.UNDEF -> ERROR: Message 7 (via logrecv.tcp.INF.UNDEF)
- INF.UNDEF -> WARN: Message 8 (via logrecv.tcp.INF.UNDEF)
- INF.UNDEF -> INFO: Message 9 (via logrecv.tcp.INF.UNDEF)
- INF.ERR -> CRITICAL: Message 10 (via logrecv.tcp.INF.ERR)
- INF.ERR -> ERROR: Message 11 (via logrecv.tcp.INF.ERR)
- INF.ERR.UNDEF -> CRITICAL: Message 12 (via
logrecv.tcp.INF.ERR.UNDEF)
- INF.ERR.UNDEF -> ERROR: Message 13 (via
logrecv.tcp.INF.ERR.UNDEF)
- DEB -> CRITICAL: Message 14 (via logrecv.tcp.DEB)
- DEB -> ERROR: Message 15 (via logrecv.tcp.DEB)
- DEB -> WARN: Message 16 (via logrecv.tcp.DEB)
- DEB -> INFO: Message 17 (via logrecv.tcp.DEB)
- DEB -> DEBUG: Message 18 (via logrecv.tcp.DEB)
- UNDEF -> CRITICAL: Message 19 (via logrecv.tcp.UNDEF)
- UNDEF -> ERROR: Message 20 (via logrecv.tcp.UNDEF)
- UNDEF -> WARN: Message 21 (via logrecv.tcp.UNDEF)
- UNDEF -> INFO: Message 22 (via logrecv.tcp.UNDEF)
- INF.BADPARENT.UNDEF -> CRITICAL: Message 23 (via
logrecv.tcp.INF.BADPARENT.UNDEF)
- INF.BADPARENT -> CRITICAL: Message 24 (via
logrecv.tcp.INF.BADPARENT)
- INF -> INFO: Messages should bear numbers 0 through
24. (via logrecv.tcp.INF)
**********************************************************************
Traceback (most recent call last):
  File
"/home/jeremy/src/python/dist/src/Lib/logging/__init__.py",
line 648, in emit
    self.stream.write("%s\n" % msg)
ValueError: I/O operation on closed file
Traceback (most recent call last):
  File
"/home/jeremy/src/python/dist/src/Lib/logging/__init__.py",
line 648, in emit
    self.stream.write("%s\n" % msg)
ValueError: I/O operation on closed file


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-25 10:35

Message:
Logged In: YES 
user_id=33168

This problem should be fixed, please test.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-03-03 05:40

Message:
Logged In: YES 
user_id=45365

I see this problem on MacPython-OS9 too, occasionally. So if it is closed I would like to hear the resolution, please...

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-02-28 21:02

Message:
Logged In: YES 
user_id=80475

Can this be closed?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678217&group_id=5470


From noreply@sourceforge.net  Fri Apr 25 17:08:24 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 25 Apr 2003 09:08:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-727571 ] test_bsddb3 fails
Message-ID: <E1995kO-0001Bi-00@sc8-sf-web3.sourceforge.net>

Bugs item #727571, was opened at 2003-04-25 16:08
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727571&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_bsddb3 fails

Initial Comment:
Running regrtest.py -u all with a checkout from this
morning at around 11am.

Exception in thread reader 3:
Traceback (most recent call last):
  File
"/home/jeremy/src/python/dist/src/Lib/threading.py",
line 411, in __bootstrap
    self.run()
  File
"/home/jeremy/src/python/dist/src/Lib/threading.py",
line 399, in run
    self.__target(*self.__args, **self.__kwargs)
  File
"/home/jeremy/src/python/dist/src/Lib/bsddb/test/test_thread.py",
line 270, in readerThread
    rec = c.first()
DBLockDeadlockError: (-30996, 'DB_LOCK_DEADLOCK: Locker
killed to resolve a deadlock')

Exception in thread reader 2:
Traceback (most recent call last):
  File
"/home/jeremy/src/python/dist/src/Lib/threading.py",
line 411, in __bootstrap
    self.run()
  File
"/home/jeremy/src/python/dist/src/Lib/threading.py",
line 399, in run
    self.__target(*self.__args, **self.__kwargs)
  File
"/home/jeremy/src/python/dist/src/Lib/bsddb/test/test_thread.py",
line 270, in readerThread
    rec = c.first()
DBLockDeadlockError: (-30996, 'DB_LOCK_DEADLOCK: Locker
killed to resolve a deadlock')


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727571&group_id=5470


From noreply@sourceforge.net  Fri Apr 25 18:41:15 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 25 Apr 2003 10:41:15 -0700
Subject: [Python-bugs-list] [ python-Bugs-727241 ] Core Dumps : Python2.2.2
Message-ID: <E1997CF-00071A-00@sc8-sf-web3.sourceforge.net>

Bugs item #727241, was opened at 2003-04-24 22:16
Message generated for change (Comment added) made by elirosenberg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727241&group_id=5470

Category: None
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Eli Rosenberg (elirosenberg)
Assigned to: Nobody/Anonymous (nobody)
Summary: Core Dumps : Python2.2.2 

Initial Comment:

Hello,
I am able to cause python to core dump on IRIX
6.5.18 and above with the code listed below.  I have
compiled with 3 versions of gcc as well as MIPSpro.

Running this code with a valid host and a port
that will cause a connection refused socket error
produces a core dump with the the stack trace below.

>>> import socket
>>> x=socket.socket()
>>> x.connect(('www.google.com', 1234))


>  0 realfree(0x10162e98, 0x0, 0x200000, 0x65637469,
0x17dd4, 0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":527,
0xfb245fc]
   1 cleanfree(0x0, 0x0, 0x200000, 0x65637469, 0x17dd4,
0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":945,
0xfb24e44]
   2 __malloc(0x28, 0x0, 0x200000, 0x65637469, 0x17dd4,
0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":230,
0xfb24078]
   3 _malloc(0x28, 0x0, 0x200000, 0x65637469, 0x17dd4,
0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":186,
0xfb23ee4]
   4 _PyObject_GC_Malloc(tp = 0x1013fbe0, nitems = 0)
["/usr/people/eli/Python-2.2.2/Modules/gcmodule.c":868,
0x10092244]
   5 _PyObject_GC_New(tp = 0x1013fbe0)
["/usr/people/eli/Python-2.2.2/Modules/gcmodule.c":895,
0x10092368]
   6 newtracebackobject(next = (nil), frame =
0x1016b670, lasti = 21, lineno = 1)
["/usr/people/eli/Python-2.2.2/Python/traceback.c":115,
0x100c6684]
   7 PyTraceBack_Here(frame = 0x1016b670)
["/usr/people/eli/Python-2.2.2/Python/traceback.c":133,
0x100c67f4]
   8 eval_frame(f = 0x1016b670)
["/usr/people/eli/Python-2.2.2/Python/ceval.c":2238,
0x1004e894]
   9 PyEval_EvalCodeEx(co = 0x1016e990, globals =
0x1016a5d0, locals = 0x1016a5d0, args = (nil), argcount
= 0, kws = (nil), kwcount = 0, defs = (nil), defcount =
0, closure = (nil))
["/usr/people/eli/Python-2.2.2/Python/ceval.c":2595,
0x1004ffe0
   10 PyEval_EvalCode(co = 0x1016e990, globals =
0x1016a5d0, locals = 0x1016a5d0)
["/usr/people/eli/Python-2.2.2/Python/ceval.c":481,
0x10047ea0]
   11 run_node(n = 0x101a5b28, filename = 0x1014e978 =
"<stdin>", globals = 0x1016a5d0, locals = 0x1016a5d0,
flags = 0x7fff2e2c)
["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":1079,
0x1006f380]
   12 PyRun_InteractiveOneFlags(fp = 0xfb53680,
filename = 0x1014e978 = "<stdin>", flags = 0x7fff2e2c)
["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":590,
0x1006d57c]
   13 PyRun_InteractiveLoopFlags(fp = 0xfb53680,
filename = 0x1014e978 = "<stdin>", flags = 0x7fff2e2c)
["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":526,
0x1006d198]
   14 PyRun_AnyFileExFlags(fp = 0xfb53680, filename =
0x1014e978 = "<stdin>", closeit = 0, flags =
0x7fff2e2c)
["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":489,
0x1006cf48]
   15 Py_Main(argc = 1, argv = 0x7fff2f24)
["/usr/people/eli/Python-2.2.2/Modules/main.c":364,
0x1000fa44]
   16 main(argc = 1, argv = 0x7fff2f24)
["/usr/people/eli/Python-2.2.2/Modules/python.c":10,
0x1000ecdc]
   17 __start()
["/xlv55/kudzu-apr12/work/irix/lib/libc/libc_n32_M4/csu/crt1text.s":177,
0x1000ec78]

I compiled Python 64-bit and the code above appears
not to cause a segfault but the code below will
bus error after a few iterations.

import socket
import time

def doit():
          s = socket.socket()
          start = time.time()
          
          try:
               s.connect(('www.cnn.com', 80))
          except socket.error,e:
               print repr(e),str(e)
          finish = time.time()
          time.sleep(.5)
          print str(finish-start),"\n"
          s.close()

for x in xrange(10):
     doit()

Here is the stack trace:

>  0 realfree(0x10162e98, 0x0, 0x200000, 0x65637469,
0x17dd4, 0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":527,
0xfb245fc]
   1 cleanfree(0x0, 0x0, 0x200000, 0x65637469, 0x17dd4,
0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":945,
0xfb24e44]
   2 __malloc(0x28, 0x0, 0x200000, 0x65637469, 0x17dd4,
0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":230,
0xfb24078]
   3 _malloc(0x28, 0x0, 0x200000, 0x65637469, 0x17dd4,
0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":186,
0xfb23ee4]
   4 _PyObject_GC_Malloc(tp = 0x1013fbe0, nitems = 0)
["/usr/people/eli/Python-2.2.2/Modules/gcmodule.c":868,
0x10092244]
   5 _PyObject_GC_New(tp = 0x1013fbe0)
["/usr/people/eli/Python-2.2.2/Modules/gcmodule.c":895,
0x10092368]
   6 newtracebackobject(next = (nil), frame =
0x1016b670, lasti = 21, lineno = 1)
["/usr/people/eli/Python-2.2.2/Python/traceback.c":115,
0x100c6684]
   7 PyTraceBack_Here(frame = 0x1016b670)
["/usr/people/eli/Python-2.2.2/Python/traceback.c":133,
0x100c67f4]
   8 eval_frame(f = 0x1016b670)
["/usr/people/eli/Python-2.2.2/Python/ceval.c":2238,
0x1004e894]
   9 PyEval_EvalCodeEx(co = 0x1016e990, globals =
0x1016a5d0, locals = 0x1016a5d0, args = (nil), argcount
= 0, kws = (nil), kwcount = 0, defs = (nil), defcount =
0, closure = (nil))
["/usr/people/eli/Python-2.2.2/Python/ceval.c":2595,
0x1004ffe0
   10 PyEval_EvalCode(co = 0x1016e990, globals =
0x1016a5d0, locals = 0x1016a5d0)
["/usr/people/eli/Python-2.2.2/Python/ceval.c":481,
0x10047ea0]
   11 run_node(n = 0x101a5b28, filename = 0x1014e978 =
"<stdin>", globals = 0x1016a5d0, locals = 0x1016a5d0,
flags = 0x7fff2e2c)
["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":1079,
0x1006f380]
   12 PyRun_InteractiveOneFlags(fp = 0xfb53680,
filename = 0x1014e978 = "<stdin>", flags = 0x7fff2e2c)
["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":590,
0x1006d57c]
   13 PyRun_InteractiveLoopFlags(fp = 0xfb53680,
filename = 0x1014e978 = "<stdin>", flags = 0x7fff2e2c)
["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":526,
0x1006d198]
   14 PyRun_AnyFileExFlags(fp = 0xfb53680, filename =
0x1014e978 = "<stdin>", closeit = 0, flags =
0x7fff2e2c)
["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":489,
0x1006cf48]
   15 Py_Main(argc = 1, argv = 0x7fff2f24)
["/usr/people/eli/Python-2.2.2/Modules/main.c":364,
0x1000fa44]
   16 main(argc = 1, argv = 0x7fff2f24)
["/usr/people/eli/Python-2.2.2/Modules/python.c":10,
0x1000ecdc]
   17 __start()
["/xlv55/kudzu-apr12/work/irix/lib/libc/libc_n32_M4/csu/crt1text.s":177,
0x1000ec78]

Any help would be appreciated. thanks.
-Eli

----------------------------------------------------------------------

>Comment By: Eli Rosenberg (elirosenberg)
Date: 2003-04-25 17:41

Message:
Logged In: YES 
user_id=764663

Hi, I think I have fixed things...for now. Here is what I see:

IRIX now includes POSIX 1003.1g draft implementations
of getaddrinfo/getnameinfo in accordance with 
http://www.ietf.org/proceedings/01mar/I-D/ipngwg-rfc2553bis-03.txt

Previously, netdb.h on IRIX did not have these definitions and
Python compiled in its own implementations and things seemed
to work.  

I changed pyconfig.h to have socketmodule use its own
implementations, but I did have to make a few changes
because the IRIX prototypes for these functions are
for the 2001 version of the standards, whereas socketmodule
seemed to have 1999 versions from RFC2553.

Not knowing much about the Python C API, I did not 
look closely enough to see why socketmodule
seems to cause memory faults when compiled with 
the IRIX libc versions of these functions.   

Hopefully this is the source of the problem.
-eli


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-04-25 10:53

Message:
Logged In: YES 
user_id=6656

This looks nasty...

Could you try making a debug build of Python (pass
--with-pydebug to ./configure) and/or try with current CVS?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727241&group_id=5470


From noreply@sourceforge.net  Fri Apr 25 19:06:46 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 25 Apr 2003 11:06:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-727241 ] Core Dumps : Python2.2.2
Message-ID: <E1997aw-00018Q-00@sc8-sf-web1.sourceforge.net>

Bugs item #727241, was opened at 2003-04-24 23:16
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727241&group_id=5470

Category: None
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Eli Rosenberg (elirosenberg)
Assigned to: Nobody/Anonymous (nobody)
Summary: Core Dumps : Python2.2.2 

Initial Comment:

Hello,
I am able to cause python to core dump on IRIX
6.5.18 and above with the code listed below.  I have
compiled with 3 versions of gcc as well as MIPSpro.

Running this code with a valid host and a port
that will cause a connection refused socket error
produces a core dump with the the stack trace below.

>>> import socket
>>> x=socket.socket()
>>> x.connect(('www.google.com', 1234))


>  0 realfree(0x10162e98, 0x0, 0x200000, 0x65637469,
0x17dd4, 0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":527,
0xfb245fc]
   1 cleanfree(0x0, 0x0, 0x200000, 0x65637469, 0x17dd4,
0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":945,
0xfb24e44]
   2 __malloc(0x28, 0x0, 0x200000, 0x65637469, 0x17dd4,
0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":230,
0xfb24078]
   3 _malloc(0x28, 0x0, 0x200000, 0x65637469, 0x17dd4,
0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":186,
0xfb23ee4]
   4 _PyObject_GC_Malloc(tp = 0x1013fbe0, nitems = 0)
["/usr/people/eli/Python-2.2.2/Modules/gcmodule.c":868,
0x10092244]
   5 _PyObject_GC_New(tp = 0x1013fbe0)
["/usr/people/eli/Python-2.2.2/Modules/gcmodule.c":895,
0x10092368]
   6 newtracebackobject(next = (nil), frame =
0x1016b670, lasti = 21, lineno = 1)
["/usr/people/eli/Python-2.2.2/Python/traceback.c":115,
0x100c6684]
   7 PyTraceBack_Here(frame = 0x1016b670)
["/usr/people/eli/Python-2.2.2/Python/traceback.c":133,
0x100c67f4]
   8 eval_frame(f = 0x1016b670)
["/usr/people/eli/Python-2.2.2/Python/ceval.c":2238,
0x1004e894]
   9 PyEval_EvalCodeEx(co = 0x1016e990, globals =
0x1016a5d0, locals = 0x1016a5d0, args = (nil), argcount
= 0, kws = (nil), kwcount = 0, defs = (nil), defcount =
0, closure = (nil))
["/usr/people/eli/Python-2.2.2/Python/ceval.c":2595,
0x1004ffe0
   10 PyEval_EvalCode(co = 0x1016e990, globals =
0x1016a5d0, locals = 0x1016a5d0)
["/usr/people/eli/Python-2.2.2/Python/ceval.c":481,
0x10047ea0]
   11 run_node(n = 0x101a5b28, filename = 0x1014e978 =
"<stdin>", globals = 0x1016a5d0, locals = 0x1016a5d0,
flags = 0x7fff2e2c)
["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":1079,
0x1006f380]
   12 PyRun_InteractiveOneFlags(fp = 0xfb53680,
filename = 0x1014e978 = "<stdin>", flags = 0x7fff2e2c)
["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":590,
0x1006d57c]
   13 PyRun_InteractiveLoopFlags(fp = 0xfb53680,
filename = 0x1014e978 = "<stdin>", flags = 0x7fff2e2c)
["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":526,
0x1006d198]
   14 PyRun_AnyFileExFlags(fp = 0xfb53680, filename =
0x1014e978 = "<stdin>", closeit = 0, flags =
0x7fff2e2c)
["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":489,
0x1006cf48]
   15 Py_Main(argc = 1, argv = 0x7fff2f24)
["/usr/people/eli/Python-2.2.2/Modules/main.c":364,
0x1000fa44]
   16 main(argc = 1, argv = 0x7fff2f24)
["/usr/people/eli/Python-2.2.2/Modules/python.c":10,
0x1000ecdc]
   17 __start()
["/xlv55/kudzu-apr12/work/irix/lib/libc/libc_n32_M4/csu/crt1text.s":177,
0x1000ec78]

I compiled Python 64-bit and the code above appears
not to cause a segfault but the code below will
bus error after a few iterations.

import socket
import time

def doit():
          s = socket.socket()
          start = time.time()
          
          try:
               s.connect(('www.cnn.com', 80))
          except socket.error,e:
               print repr(e),str(e)
          finish = time.time()
          time.sleep(.5)
          print str(finish-start),"\n"
          s.close()

for x in xrange(10):
     doit()

Here is the stack trace:

>  0 realfree(0x10162e98, 0x0, 0x200000, 0x65637469,
0x17dd4, 0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":527,
0xfb245fc]
   1 cleanfree(0x0, 0x0, 0x200000, 0x65637469, 0x17dd4,
0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":945,
0xfb24e44]
   2 __malloc(0x28, 0x0, 0x200000, 0x65637469, 0x17dd4,
0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":230,
0xfb24078]
   3 _malloc(0x28, 0x0, 0x200000, 0x65637469, 0x17dd4,
0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":186,
0xfb23ee4]
   4 _PyObject_GC_Malloc(tp = 0x1013fbe0, nitems = 0)
["/usr/people/eli/Python-2.2.2/Modules/gcmodule.c":868,
0x10092244]
   5 _PyObject_GC_New(tp = 0x1013fbe0)
["/usr/people/eli/Python-2.2.2/Modules/gcmodule.c":895,
0x10092368]
   6 newtracebackobject(next = (nil), frame =
0x1016b670, lasti = 21, lineno = 1)
["/usr/people/eli/Python-2.2.2/Python/traceback.c":115,
0x100c6684]
   7 PyTraceBack_Here(frame = 0x1016b670)
["/usr/people/eli/Python-2.2.2/Python/traceback.c":133,
0x100c67f4]
   8 eval_frame(f = 0x1016b670)
["/usr/people/eli/Python-2.2.2/Python/ceval.c":2238,
0x1004e894]
   9 PyEval_EvalCodeEx(co = 0x1016e990, globals =
0x1016a5d0, locals = 0x1016a5d0, args = (nil), argcount
= 0, kws = (nil), kwcount = 0, defs = (nil), defcount =
0, closure = (nil))
["/usr/people/eli/Python-2.2.2/Python/ceval.c":2595,
0x1004ffe0
   10 PyEval_EvalCode(co = 0x1016e990, globals =
0x1016a5d0, locals = 0x1016a5d0)
["/usr/people/eli/Python-2.2.2/Python/ceval.c":481,
0x10047ea0]
   11 run_node(n = 0x101a5b28, filename = 0x1014e978 =
"<stdin>", globals = 0x1016a5d0, locals = 0x1016a5d0,
flags = 0x7fff2e2c)
["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":1079,
0x1006f380]
   12 PyRun_InteractiveOneFlags(fp = 0xfb53680,
filename = 0x1014e978 = "<stdin>", flags = 0x7fff2e2c)
["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":590,
0x1006d57c]
   13 PyRun_InteractiveLoopFlags(fp = 0xfb53680,
filename = 0x1014e978 = "<stdin>", flags = 0x7fff2e2c)
["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":526,
0x1006d198]
   14 PyRun_AnyFileExFlags(fp = 0xfb53680, filename =
0x1014e978 = "<stdin>", closeit = 0, flags =
0x7fff2e2c)
["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":489,
0x1006cf48]
   15 Py_Main(argc = 1, argv = 0x7fff2f24)
["/usr/people/eli/Python-2.2.2/Modules/main.c":364,
0x1000fa44]
   16 main(argc = 1, argv = 0x7fff2f24)
["/usr/people/eli/Python-2.2.2/Modules/python.c":10,
0x1000ecdc]
   17 __start()
["/xlv55/kudzu-apr12/work/irix/lib/libc/libc_n32_M4/csu/crt1text.s":177,
0x1000ec78]

Any help would be appreciated. thanks.
-Eli

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2003-04-25 19:06

Message:
Logged In: YES 
user_id=6656

so... do you think the fault is with Python or IRIX?

if you're happy enough with the situation as it stands, we may as well close 
this...

----------------------------------------------------------------------

Comment By: Eli Rosenberg (elirosenberg)
Date: 2003-04-25 18:41

Message:
Logged In: YES 
user_id=764663

Hi, I think I have fixed things...for now. Here is what I see:

IRIX now includes POSIX 1003.1g draft implementations
of getaddrinfo/getnameinfo in accordance with 
http://www.ietf.org/proceedings/01mar/I-D/ipngwg-rfc2553bis-03.txt

Previously, netdb.h on IRIX did not have these definitions and
Python compiled in its own implementations and things seemed
to work.  

I changed pyconfig.h to have socketmodule use its own
implementations, but I did have to make a few changes
because the IRIX prototypes for these functions are
for the 2001 version of the standards, whereas socketmodule
seemed to have 1999 versions from RFC2553.

Not knowing much about the Python C API, I did not 
look closely enough to see why socketmodule
seems to cause memory faults when compiled with 
the IRIX libc versions of these functions.   

Hopefully this is the source of the problem.
-eli


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-04-25 11:53

Message:
Logged In: YES 
user_id=6656

This looks nasty...

Could you try making a debug build of Python (pass
--with-pydebug to ./configure) and/or try with current CVS?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727241&group_id=5470


From noreply@sourceforge.net  Fri Apr 25 19:28:05 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 25 Apr 2003 11:28:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-727241 ] Core Dumps : Python2.2.2
Message-ID: <E1997vZ-00037m-00@sc8-sf-web2.sourceforge.net>

Bugs item #727241, was opened at 2003-04-24 22:16
Message generated for change (Comment added) made by elirosenberg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727241&group_id=5470

Category: None
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Eli Rosenberg (elirosenberg)
Assigned to: Nobody/Anonymous (nobody)
Summary: Core Dumps : Python2.2.2 

Initial Comment:

Hello,
I am able to cause python to core dump on IRIX
6.5.18 and above with the code listed below.  I have
compiled with 3 versions of gcc as well as MIPSpro.

Running this code with a valid host and a port
that will cause a connection refused socket error
produces a core dump with the the stack trace below.

>>> import socket
>>> x=socket.socket()
>>> x.connect(('www.google.com', 1234))


>  0 realfree(0x10162e98, 0x0, 0x200000, 0x65637469,
0x17dd4, 0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":527,
0xfb245fc]
   1 cleanfree(0x0, 0x0, 0x200000, 0x65637469, 0x17dd4,
0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":945,
0xfb24e44]
   2 __malloc(0x28, 0x0, 0x200000, 0x65637469, 0x17dd4,
0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":230,
0xfb24078]
   3 _malloc(0x28, 0x0, 0x200000, 0x65637469, 0x17dd4,
0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":186,
0xfb23ee4]
   4 _PyObject_GC_Malloc(tp = 0x1013fbe0, nitems = 0)
["/usr/people/eli/Python-2.2.2/Modules/gcmodule.c":868,
0x10092244]
   5 _PyObject_GC_New(tp = 0x1013fbe0)
["/usr/people/eli/Python-2.2.2/Modules/gcmodule.c":895,
0x10092368]
   6 newtracebackobject(next = (nil), frame =
0x1016b670, lasti = 21, lineno = 1)
["/usr/people/eli/Python-2.2.2/Python/traceback.c":115,
0x100c6684]
   7 PyTraceBack_Here(frame = 0x1016b670)
["/usr/people/eli/Python-2.2.2/Python/traceback.c":133,
0x100c67f4]
   8 eval_frame(f = 0x1016b670)
["/usr/people/eli/Python-2.2.2/Python/ceval.c":2238,
0x1004e894]
   9 PyEval_EvalCodeEx(co = 0x1016e990, globals =
0x1016a5d0, locals = 0x1016a5d0, args = (nil), argcount
= 0, kws = (nil), kwcount = 0, defs = (nil), defcount =
0, closure = (nil))
["/usr/people/eli/Python-2.2.2/Python/ceval.c":2595,
0x1004ffe0
   10 PyEval_EvalCode(co = 0x1016e990, globals =
0x1016a5d0, locals = 0x1016a5d0)
["/usr/people/eli/Python-2.2.2/Python/ceval.c":481,
0x10047ea0]
   11 run_node(n = 0x101a5b28, filename = 0x1014e978 =
"<stdin>", globals = 0x1016a5d0, locals = 0x1016a5d0,
flags = 0x7fff2e2c)
["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":1079,
0x1006f380]
   12 PyRun_InteractiveOneFlags(fp = 0xfb53680,
filename = 0x1014e978 = "<stdin>", flags = 0x7fff2e2c)
["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":590,
0x1006d57c]
   13 PyRun_InteractiveLoopFlags(fp = 0xfb53680,
filename = 0x1014e978 = "<stdin>", flags = 0x7fff2e2c)
["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":526,
0x1006d198]
   14 PyRun_AnyFileExFlags(fp = 0xfb53680, filename =
0x1014e978 = "<stdin>", closeit = 0, flags =
0x7fff2e2c)
["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":489,
0x1006cf48]
   15 Py_Main(argc = 1, argv = 0x7fff2f24)
["/usr/people/eli/Python-2.2.2/Modules/main.c":364,
0x1000fa44]
   16 main(argc = 1, argv = 0x7fff2f24)
["/usr/people/eli/Python-2.2.2/Modules/python.c":10,
0x1000ecdc]
   17 __start()
["/xlv55/kudzu-apr12/work/irix/lib/libc/libc_n32_M4/csu/crt1text.s":177,
0x1000ec78]

I compiled Python 64-bit and the code above appears
not to cause a segfault but the code below will
bus error after a few iterations.

import socket
import time

def doit():
          s = socket.socket()
          start = time.time()
          
          try:
               s.connect(('www.cnn.com', 80))
          except socket.error,e:
               print repr(e),str(e)
          finish = time.time()
          time.sleep(.5)
          print str(finish-start),"\n"
          s.close()

for x in xrange(10):
     doit()

Here is the stack trace:

>  0 realfree(0x10162e98, 0x0, 0x200000, 0x65637469,
0x17dd4, 0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":527,
0xfb245fc]
   1 cleanfree(0x0, 0x0, 0x200000, 0x65637469, 0x17dd4,
0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":945,
0xfb24e44]
   2 __malloc(0x28, 0x0, 0x200000, 0x65637469, 0x17dd4,
0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":230,
0xfb24078]
   3 _malloc(0x28, 0x0, 0x200000, 0x65637469, 0x17dd4,
0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":186,
0xfb23ee4]
   4 _PyObject_GC_Malloc(tp = 0x1013fbe0, nitems = 0)
["/usr/people/eli/Python-2.2.2/Modules/gcmodule.c":868,
0x10092244]
   5 _PyObject_GC_New(tp = 0x1013fbe0)
["/usr/people/eli/Python-2.2.2/Modules/gcmodule.c":895,
0x10092368]
   6 newtracebackobject(next = (nil), frame =
0x1016b670, lasti = 21, lineno = 1)
["/usr/people/eli/Python-2.2.2/Python/traceback.c":115,
0x100c6684]
   7 PyTraceBack_Here(frame = 0x1016b670)
["/usr/people/eli/Python-2.2.2/Python/traceback.c":133,
0x100c67f4]
   8 eval_frame(f = 0x1016b670)
["/usr/people/eli/Python-2.2.2/Python/ceval.c":2238,
0x1004e894]
   9 PyEval_EvalCodeEx(co = 0x1016e990, globals =
0x1016a5d0, locals = 0x1016a5d0, args = (nil), argcount
= 0, kws = (nil), kwcount = 0, defs = (nil), defcount =
0, closure = (nil))
["/usr/people/eli/Python-2.2.2/Python/ceval.c":2595,
0x1004ffe0
   10 PyEval_EvalCode(co = 0x1016e990, globals =
0x1016a5d0, locals = 0x1016a5d0)
["/usr/people/eli/Python-2.2.2/Python/ceval.c":481,
0x10047ea0]
   11 run_node(n = 0x101a5b28, filename = 0x1014e978 =
"<stdin>", globals = 0x1016a5d0, locals = 0x1016a5d0,
flags = 0x7fff2e2c)
["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":1079,
0x1006f380]
   12 PyRun_InteractiveOneFlags(fp = 0xfb53680,
filename = 0x1014e978 = "<stdin>", flags = 0x7fff2e2c)
["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":590,
0x1006d57c]
   13 PyRun_InteractiveLoopFlags(fp = 0xfb53680,
filename = 0x1014e978 = "<stdin>", flags = 0x7fff2e2c)
["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":526,
0x1006d198]
   14 PyRun_AnyFileExFlags(fp = 0xfb53680, filename =
0x1014e978 = "<stdin>", closeit = 0, flags =
0x7fff2e2c)
["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":489,
0x1006cf48]
   15 Py_Main(argc = 1, argv = 0x7fff2f24)
["/usr/people/eli/Python-2.2.2/Modules/main.c":364,
0x1000fa44]
   16 main(argc = 1, argv = 0x7fff2f24)
["/usr/people/eli/Python-2.2.2/Modules/python.c":10,
0x1000ecdc]
   17 __start()
["/xlv55/kudzu-apr12/work/irix/lib/libc/libc_n32_M4/csu/crt1text.s":177,
0x1000ec78]

Any help would be appreciated. thanks.
-Eli

----------------------------------------------------------------------

>Comment By: Eli Rosenberg (elirosenberg)
Date: 2003-04-25 18:28

Message:
Logged In: YES 
user_id=764663

Hmm, I don't know for sure, but closing might not be
the best idea because anyone else building on a 
really recent IRIX will have problems with socketmodule.
Is there an IRIX maintainer or somebody like that?



----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-04-25 18:06

Message:
Logged In: YES 
user_id=6656

so... do you think the fault is with Python or IRIX?

if you're happy enough with the situation as it stands, we may as well close 
this...

----------------------------------------------------------------------

Comment By: Eli Rosenberg (elirosenberg)
Date: 2003-04-25 17:41

Message:
Logged In: YES 
user_id=764663

Hi, I think I have fixed things...for now. Here is what I see:

IRIX now includes POSIX 1003.1g draft implementations
of getaddrinfo/getnameinfo in accordance with 
http://www.ietf.org/proceedings/01mar/I-D/ipngwg-rfc2553bis-03.txt

Previously, netdb.h on IRIX did not have these definitions and
Python compiled in its own implementations and things seemed
to work.  

I changed pyconfig.h to have socketmodule use its own
implementations, but I did have to make a few changes
because the IRIX prototypes for these functions are
for the 2001 version of the standards, whereas socketmodule
seemed to have 1999 versions from RFC2553.

Not knowing much about the Python C API, I did not 
look closely enough to see why socketmodule
seems to cause memory faults when compiled with 
the IRIX libc versions of these functions.   

Hopefully this is the source of the problem.
-eli


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-04-25 10:53

Message:
Logged In: YES 
user_id=6656

This looks nasty...

Could you try making a debug build of Python (pass
--with-pydebug to ./configure) and/or try with current CVS?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727241&group_id=5470


From noreply@sourceforge.net  Fri Apr 25 19:57:59 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 25 Apr 2003 11:57:59 -0700
Subject: [Python-bugs-list] [ python-Bugs-727692 ] Documentation formatting bugs
Message-ID: <E1998OV-0004rP-00@sc8-sf-web2.sourceforge.net>

Bugs item #727692, was opened at 2003-04-25 20:57
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727692&group_id=5470

Category: None
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin v. Löwis (loewis)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Documentation formatting bugs

Initial Comment:
I found that some of my changes get incorrectly 
formatted, but I don't know how to fix them. Assigning to 
Fred in the hope that he knows the proper incantations.

- HTML version of 4.9.2 (standard encodings):
The table is incorrect in the lines that have an empty 
Aliases column (e.g. cp874). The Alias ought to be 
empty, and "Thai" ought to occur in the third column

- HTML version of 4.9.3 (encodings.IDNA)
The first paragraph starts with a bogus "P>"

- HTML of whatsnew, 17, "Support for internationalized 
domain names": The first line of Python prints as a 
guillemet, not as ">>" Notice that I used a non-
preformatted enviroment so that I could output c-cedilla.

- Postscript version of 4.9.2: the table is overfull in its 
width. It would be ok to wrap the aliases lists as much 
as necessary

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727692&group_id=5470


From noreply@sourceforge.net  Fri Apr 25 20:03:48 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 25 Apr 2003 12:03:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-727241 ] Core Dumps : Python2.2.2
Message-ID: <E1998U8-0005FR-00@sc8-sf-web2.sourceforge.net>

Bugs item #727241, was opened at 2003-04-25 00:16
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727241&group_id=5470

Category: None
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Eli Rosenberg (elirosenberg)
Assigned to: Nobody/Anonymous (nobody)
Summary: Core Dumps : Python2.2.2 

Initial Comment:

Hello,
I am able to cause python to core dump on IRIX
6.5.18 and above with the code listed below.  I have
compiled with 3 versions of gcc as well as MIPSpro.

Running this code with a valid host and a port
that will cause a connection refused socket error
produces a core dump with the the stack trace below.

>>> import socket
>>> x=socket.socket()
>>> x.connect(('www.google.com', 1234))


>  0 realfree(0x10162e98, 0x0, 0x200000, 0x65637469,
0x17dd4, 0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":527,
0xfb245fc]
   1 cleanfree(0x0, 0x0, 0x200000, 0x65637469, 0x17dd4,
0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":945,
0xfb24e44]
   2 __malloc(0x28, 0x0, 0x200000, 0x65637469, 0x17dd4,
0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":230,
0xfb24078]
   3 _malloc(0x28, 0x0, 0x200000, 0x65637469, 0x17dd4,
0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":186,
0xfb23ee4]
   4 _PyObject_GC_Malloc(tp = 0x1013fbe0, nitems = 0)
["/usr/people/eli/Python-2.2.2/Modules/gcmodule.c":868,
0x10092244]
   5 _PyObject_GC_New(tp = 0x1013fbe0)
["/usr/people/eli/Python-2.2.2/Modules/gcmodule.c":895,
0x10092368]
   6 newtracebackobject(next = (nil), frame =
0x1016b670, lasti = 21, lineno = 1)
["/usr/people/eli/Python-2.2.2/Python/traceback.c":115,
0x100c6684]
   7 PyTraceBack_Here(frame = 0x1016b670)
["/usr/people/eli/Python-2.2.2/Python/traceback.c":133,
0x100c67f4]
   8 eval_frame(f = 0x1016b670)
["/usr/people/eli/Python-2.2.2/Python/ceval.c":2238,
0x1004e894]
   9 PyEval_EvalCodeEx(co = 0x1016e990, globals =
0x1016a5d0, locals = 0x1016a5d0, args = (nil), argcount
= 0, kws = (nil), kwcount = 0, defs = (nil), defcount =
0, closure = (nil))
["/usr/people/eli/Python-2.2.2/Python/ceval.c":2595,
0x1004ffe0
   10 PyEval_EvalCode(co = 0x1016e990, globals =
0x1016a5d0, locals = 0x1016a5d0)
["/usr/people/eli/Python-2.2.2/Python/ceval.c":481,
0x10047ea0]
   11 run_node(n = 0x101a5b28, filename = 0x1014e978 =
"<stdin>", globals = 0x1016a5d0, locals = 0x1016a5d0,
flags = 0x7fff2e2c)
["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":1079,
0x1006f380]
   12 PyRun_InteractiveOneFlags(fp = 0xfb53680,
filename = 0x1014e978 = "<stdin>", flags = 0x7fff2e2c)
["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":590,
0x1006d57c]
   13 PyRun_InteractiveLoopFlags(fp = 0xfb53680,
filename = 0x1014e978 = "<stdin>", flags = 0x7fff2e2c)
["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":526,
0x1006d198]
   14 PyRun_AnyFileExFlags(fp = 0xfb53680, filename =
0x1014e978 = "<stdin>", closeit = 0, flags =
0x7fff2e2c)
["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":489,
0x1006cf48]
   15 Py_Main(argc = 1, argv = 0x7fff2f24)
["/usr/people/eli/Python-2.2.2/Modules/main.c":364,
0x1000fa44]
   16 main(argc = 1, argv = 0x7fff2f24)
["/usr/people/eli/Python-2.2.2/Modules/python.c":10,
0x1000ecdc]
   17 __start()
["/xlv55/kudzu-apr12/work/irix/lib/libc/libc_n32_M4/csu/crt1text.s":177,
0x1000ec78]

I compiled Python 64-bit and the code above appears
not to cause a segfault but the code below will
bus error after a few iterations.

import socket
import time

def doit():
          s = socket.socket()
          start = time.time()
          
          try:
               s.connect(('www.cnn.com', 80))
          except socket.error,e:
               print repr(e),str(e)
          finish = time.time()
          time.sleep(.5)
          print str(finish-start),"\n"
          s.close()

for x in xrange(10):
     doit()

Here is the stack trace:

>  0 realfree(0x10162e98, 0x0, 0x200000, 0x65637469,
0x17dd4, 0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":527,
0xfb245fc]
   1 cleanfree(0x0, 0x0, 0x200000, 0x65637469, 0x17dd4,
0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":945,
0xfb24e44]
   2 __malloc(0x28, 0x0, 0x200000, 0x65637469, 0x17dd4,
0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":230,
0xfb24078]
   3 _malloc(0x28, 0x0, 0x200000, 0x65637469, 0x17dd4,
0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":186,
0xfb23ee4]
   4 _PyObject_GC_Malloc(tp = 0x1013fbe0, nitems = 0)
["/usr/people/eli/Python-2.2.2/Modules/gcmodule.c":868,
0x10092244]
   5 _PyObject_GC_New(tp = 0x1013fbe0)
["/usr/people/eli/Python-2.2.2/Modules/gcmodule.c":895,
0x10092368]
   6 newtracebackobject(next = (nil), frame =
0x1016b670, lasti = 21, lineno = 1)
["/usr/people/eli/Python-2.2.2/Python/traceback.c":115,
0x100c6684]
   7 PyTraceBack_Here(frame = 0x1016b670)
["/usr/people/eli/Python-2.2.2/Python/traceback.c":133,
0x100c67f4]
   8 eval_frame(f = 0x1016b670)
["/usr/people/eli/Python-2.2.2/Python/ceval.c":2238,
0x1004e894]
   9 PyEval_EvalCodeEx(co = 0x1016e990, globals =
0x1016a5d0, locals = 0x1016a5d0, args = (nil), argcount
= 0, kws = (nil), kwcount = 0, defs = (nil), defcount =
0, closure = (nil))
["/usr/people/eli/Python-2.2.2/Python/ceval.c":2595,
0x1004ffe0
   10 PyEval_EvalCode(co = 0x1016e990, globals =
0x1016a5d0, locals = 0x1016a5d0)
["/usr/people/eli/Python-2.2.2/Python/ceval.c":481,
0x10047ea0]
   11 run_node(n = 0x101a5b28, filename = 0x1014e978 =
"<stdin>", globals = 0x1016a5d0, locals = 0x1016a5d0,
flags = 0x7fff2e2c)
["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":1079,
0x1006f380]
   12 PyRun_InteractiveOneFlags(fp = 0xfb53680,
filename = 0x1014e978 = "<stdin>", flags = 0x7fff2e2c)
["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":590,
0x1006d57c]
   13 PyRun_InteractiveLoopFlags(fp = 0xfb53680,
filename = 0x1014e978 = "<stdin>", flags = 0x7fff2e2c)
["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":526,
0x1006d198]
   14 PyRun_AnyFileExFlags(fp = 0xfb53680, filename =
0x1014e978 = "<stdin>", closeit = 0, flags =
0x7fff2e2c)
["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":489,
0x1006cf48]
   15 Py_Main(argc = 1, argv = 0x7fff2f24)
["/usr/people/eli/Python-2.2.2/Modules/main.c":364,
0x1000fa44]
   16 main(argc = 1, argv = 0x7fff2f24)
["/usr/people/eli/Python-2.2.2/Modules/python.c":10,
0x1000ecdc]
   17 __start()
["/xlv55/kudzu-apr12/work/irix/lib/libc/libc_n32_M4/csu/crt1text.s":177,
0x1000ec78]

Any help would be appreciated. thanks.
-Eli

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-04-25 21:03

Message:
Logged In: YES 
user_id=21627

No. Except for MacOS, there is are no port maintainers. 
There are experts for some of the Unices, but only for Linux 
and Solaris. For things as strange as Irix, we have to have 
actual users of the systems to fully understand the problem 
and provide patches.

In general, we accept work-arounds only if it can be shown 
that a work-around is necessary around a true platform bug 
(see how the getaddrinfo emulation is used on OSX, even 
though the platform provides a native implementation).

I'm pretty certain that Python's usage of the getaddrinfo API 
is correct. If this is still causing crashes, it may be that the 
implementation in the Irix library is buggy. Have you applied 
all vendor patches?

----------------------------------------------------------------------

Comment By: Eli Rosenberg (elirosenberg)
Date: 2003-04-25 20:28

Message:
Logged In: YES 
user_id=764663

Hmm, I don't know for sure, but closing might not be
the best idea because anyone else building on a 
really recent IRIX will have problems with socketmodule.
Is there an IRIX maintainer or somebody like that?



----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-04-25 20:06

Message:
Logged In: YES 
user_id=6656

so... do you think the fault is with Python or IRIX?

if you're happy enough with the situation as it stands, we may as well close 
this...

----------------------------------------------------------------------

Comment By: Eli Rosenberg (elirosenberg)
Date: 2003-04-25 19:41

Message:
Logged In: YES 
user_id=764663

Hi, I think I have fixed things...for now. Here is what I see:

IRIX now includes POSIX 1003.1g draft implementations
of getaddrinfo/getnameinfo in accordance with 
http://www.ietf.org/proceedings/01mar/I-D/ipngwg-rfc2553bis-03.txt

Previously, netdb.h on IRIX did not have these definitions and
Python compiled in its own implementations and things seemed
to work.  

I changed pyconfig.h to have socketmodule use its own
implementations, but I did have to make a few changes
because the IRIX prototypes for these functions are
for the 2001 version of the standards, whereas socketmodule
seemed to have 1999 versions from RFC2553.

Not knowing much about the Python C API, I did not 
look closely enough to see why socketmodule
seems to cause memory faults when compiled with 
the IRIX libc versions of these functions.   

Hopefully this is the source of the problem.
-eli


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-04-25 12:53

Message:
Logged In: YES 
user_id=6656

This looks nasty...

Could you try making a debug build of Python (pass
--with-pydebug to ./configure) and/or try with current CVS?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727241&group_id=5470


From noreply@sourceforge.net  Fri Apr 25 20:04:18 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 25 Apr 2003 12:04:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-727692 ] Documentation formatting bugs
Message-ID: <E1998Uc-0005IY-00@sc8-sf-web2.sourceforge.net>

Bugs item #727692, was opened at 2003-04-25 14:57
Message generated for change (Settings changed) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727692&group_id=5470

>Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin v. Löwis (loewis)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Documentation formatting bugs

Initial Comment:
I found that some of my changes get incorrectly 
formatted, but I don't know how to fix them. Assigning to 
Fred in the hope that he knows the proper incantations.

- HTML version of 4.9.2 (standard encodings):
The table is incorrect in the lines that have an empty 
Aliases column (e.g. cp874). The Alias ought to be 
empty, and "Thai" ought to occur in the third column

- HTML version of 4.9.3 (encodings.IDNA)
The first paragraph starts with a bogus "P>"

- HTML of whatsnew, 17, "Support for internationalized 
domain names": The first line of Python prints as a 
guillemet, not as ">>" Notice that I used a non-
preformatted enviroment so that I could output c-cedilla.

- Postscript version of 4.9.2: the table is overfull in its 
width. It would be ok to wrap the aliases lists as much 
as necessary

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727692&group_id=5470


From noreply@sourceforge.net  Fri Apr 25 20:05:40 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 25 Apr 2003 12:05:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-724588 ] socketmodule doesn't compile on strict POSIX systems
Message-ID: <E1998Vw-0005OT-00@sc8-sf-web2.sourceforge.net>

Bugs item #724588, was opened at 2003-04-20 14:42
Message generated for change (Settings changed) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724588&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Marc Recht (marc)
>Assigned to: Martin v. Löwis (loewis)
Summary: socketmodule doesn't compile on strict POSIX systems

Initial Comment:
socketmodule uses the functions: 
- hstrerror 
- inet_aton 
- inet_pton 
 
and definitions: 
- NI_MAXHOST 
- NI_MAXSERV 
 
which aren't defined by IEEE Std 1003.1, 2003 Edition 
(regarding to 
http://www.unix.org/single_unix_specification/). 
 
The attached patch changes configure.in so that configure 
tries to take the adress of the functions rather than the 
autoconf library function check. Because with the later the 
POSIX/POSIX_C_SOURCE/XOPEN etc definitions are not 
set. It also changes socketmodule.c to define NI_MAXHOST 
and NI_MAXSERV if they haven't been defined already. 
This fixes compilation of socketmodule on: 
NetBSD 1.6R i386 
 

----------------------------------------------------------------------

Comment By: Marc Recht (marc)
Date: 2003-04-20 15:43

Message:
Logged In: YES 
user_id=205

This is for Python 2.3/CVS (20.04.2003). 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724588&group_id=5470


From noreply@sourceforge.net  Fri Apr 25 20:08:17 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 25 Apr 2003 12:08:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-654783 ] doctest and exception messages
Message-ID: <E1998YT-0003wX-00@sc8-sf-web3.sourceforge.net>

Bugs item #654783, was opened at 2002-12-16 14:23
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654783&group_id=5470

Category: Documentation
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Aahz (aahz)
>Assigned to: Aahz (aahz)
Summary: doctest and exception messages

Initial Comment:
doctest should include information something like this:

    doctest docstrings should not rely on the text of internal Python
    exceptions.  Notice the way factorial() uses its own error messages
    with the standard Python exceptions.  The internal messages can
    change even in bugfix releases (as in 2.2.1 to 2.2.2).


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2003-04-25 15:08

Message:
Logged In: YES 
user_id=31435

Back to Aahz.  I don't mind if you change this -- edit the docs 
and check it in.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-12-16 18:39

Message:
Logged In: YES 
user_id=31435

It could, but it shouldn't:  error msgs in docs that don't match 
reality are also an insult to users.  doctest should grow some 
sort of option here, though, as its uses outgrew its original 
purposes.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-12-16 17:01

Message:
Logged In: YES 
user_id=35752

Couldn't doctest be modified so that it only compares the
exception
name only?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654783&group_id=5470


From noreply@sourceforge.net  Fri Apr 25 20:40:36 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 25 Apr 2003 12:40:36 -0700
Subject: [Python-bugs-list] [ python-Bugs-727719 ] email parsedate still wrong (PATCH)
Message-ID: <E19993k-0007mr-00@sc8-sf-web4.sourceforge.net>

Bugs item #727719, was opened at 2003-04-25 19:40
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727719&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Bob Miller (kbob)
Assigned to: Nobody/Anonymous (nobody)
Summary: email parsedate still wrong (PATCH)

Initial Comment:
Under python2.3a2 and current CVS, this script:

       #!/usr/bin/python2.3
        import email.Utils
        d = '25 Feb 2003 13:47:26 -0800'
        print email.Utils.parsedate_tz(d)

prints 'None'.  It should print a tuple.

Here is a patch to the bug, which was apparently
introduced by _parseaddr.py rev 1.5.

tivopc ~ mips> diff -u _parseaddr.py~ _parseaddr.py
--- _parseaddr.py~      Fri Apr 18 19:21:10 2003
+++ _parseaddr.py       Fri Apr 18 19:23:08 2003
@@ -1,4 +1,4 @@
-# Copyright (C) 2002 Python Software Foundation
+# Copyright (C) 2002, 2003 Python Software Foundation
 
 """Email address parsing code.
 
@@ -54,9 +54,9 @@
         del data[0]
     else:
         i = data[0].rfind(',')
-        if i < 0:
-            return None
-        data[0] = data[0][i+1:]
+        if i >= 0:
+            # Trim off the leading dayname.
+            data[0] = data[0][i+1:]
     if len(data) == 3: # RFC 850 date, deprecated
         stuff = data[0].split('-')
         if len(stuff) == 3:


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727719&group_id=5470


From noreply@sourceforge.net  Fri Apr 25 20:57:06 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 25 Apr 2003 12:57:06 -0700
Subject: [Python-bugs-list] [ python-Bugs-727732 ] getpath.c-generated prefix wrong for Tru64 scripts
Message-ID: <E1999Ji-0000W4-00@sc8-sf-web2.sourceforge.net>

Bugs item #727732, was opened at 2003-04-25 14:57
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727732&group_id=5470

Category: Python Interpreter Core
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Coleman (mkc)
Assigned to: Nobody/Anonymous (nobody)
Summary: getpath.c-generated prefix wrong for Tru64 scripts

Initial Comment:
Under Tru64 (version 5.1a, and probably others), when a
Python script is structured like so:

    #!/something/bin/python
    import sys
    print sys.prefix

the calculation of prefix in getpath.c won't work
correctly.  The reason is that argv[0] will be 'python'
rather than '/something/bin/python' (as it would be
under, say, Linux).

The code happens to work correctly in some simple
scenarios, but fails in a pretty mysterious way if one
has a different python in one's PATH than the one in
the #! line.  So, for example, if my PATH=/usr/bin and
there is a /usr/bin/python, then if I run the script
above, sys.prefix will be set to '/usr' instead of
'/something' and the wrong module path will be set up, etc.

It would be much better to simply obey the compiled
PREFIX instead, at least in the case where argv[0] has
no slashes.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727732&group_id=5470


From noreply@sourceforge.net  Fri Apr 25 21:04:05 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 25 Apr 2003 13:04:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-727719 ] email parsedate still wrong (PATCH)
Message-ID: <E1999QT-0007ll-00@sc8-sf-web3.sourceforge.net>

Bugs item #727719, was opened at 2003-04-25 15:40
Message generated for change (Settings changed) made by bwarsaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727719&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Bob Miller (kbob)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: email parsedate still wrong (PATCH)

Initial Comment:
Under python2.3a2 and current CVS, this script:

       #!/usr/bin/python2.3
        import email.Utils
        d = '25 Feb 2003 13:47:26 -0800'
        print email.Utils.parsedate_tz(d)

prints 'None'.  It should print a tuple.

Here is a patch to the bug, which was apparently
introduced by _parseaddr.py rev 1.5.

tivopc ~ mips> diff -u _parseaddr.py~ _parseaddr.py
--- _parseaddr.py~      Fri Apr 18 19:21:10 2003
+++ _parseaddr.py       Fri Apr 18 19:23:08 2003
@@ -1,4 +1,4 @@
-# Copyright (C) 2002 Python Software Foundation
+# Copyright (C) 2002, 2003 Python Software Foundation
 
 """Email address parsing code.
 
@@ -54,9 +54,9 @@
         del data[0]
     else:
         i = data[0].rfind(',')
-        if i < 0:
-            return None
-        data[0] = data[0][i+1:]
+        if i >= 0:
+            # Trim off the leading dayname.
+            data[0] = data[0][i+1:]
     if len(data) == 3: # RFC 850 date, deprecated
         stuff = data[0].split('-')
         if len(stuff) == 3:


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727719&group_id=5470


From noreply@sourceforge.net  Fri Apr 25 21:09:07 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 25 Apr 2003 13:09:07 -0700
Subject: [Python-bugs-list] [ python-Bugs-711019 ] math.log(0) differs from math.log(0L)
Message-ID: <E1999VL-0001Bu-00@sc8-sf-web4.sourceforge.net>

Bugs item #711019, was opened at 2003-03-27 16:30
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711019&group_id=5470

Category: Extension Modules
Group: Python 2.3
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Tim Peters (tim_one)
Summary: math.log(0) differs from math.log(0L)

Initial Comment:
This is maybe a minor nit, but math.log(0) raises an OverflowError
(range error) while math.log(0L) raises a ValueError (domain error).
Seems to me they ought to behave the same.  I noticed this in
2.2.2 but it's present in CVS.  In 2.1, both return -Inf.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2003-04-25 16:09

Message:
Logged In: YES 
user_id=31435

I'm happy enough the way it is.

2.2 specifically added the ability to get a good result for log
(long) even when the long is far too large to fit in a float.  
That's why log(long) takes a different path starting in 2.2, and 
why there's no inconsistency across platforms in log(0L) 
behavior since 2.2.

If you want consistency for log(0.0), then Python cannot allow 
the platfrom log to see 0.0:  "standard" libm error behavior is 
platform-dependent, and error cases for log aren't unique in 
this respect:  Python would have to write its own error-
checking code around all libm functions.  That's a much 
larger project than it may sound, and short of doing that, 
there's really no point special-casing the snot out of one 
specific log case.

It might be better if the math module docs explained that the 
specific exceptions raised in assorted error cases (and even 
whether some arguments are considered to be exceptional at 
all) are, in reality, not defined in any useful cross-platform or 
cross-release way.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-03-28 17:50

Message:
Logged In: YES 
user_id=44345

Ack!  I realized this is probably platform-dependent.  The results I
reported on were for Mac OS X.  Here's a little table of everything I could
quickly get my hands on.

Platform                Python Version  math.log(0)     math.log(0L)
Mac OS X                2.1.3           -Inf            -Inf
Mac OS X                2.2.2           OverflowError   ValueError
Mac OS X                CVS             OverflowError   ValueError
Win2k/MSVC              2.2.2           OverflowError   ValueError
Win2k/MSVC              2.3a2           OverflowError   ValueError
Win2k/cygwin            2.2.2           ValueError      ValueError
Solaris/gcc 2.95.2      2.3a2+          OverflowError   ValueError

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711019&group_id=5470


From noreply@sourceforge.net  Fri Apr 25 22:15:28 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 25 Apr 2003 14:15:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-711019 ] math.log(0) differs from math.log(0L)
Message-ID: <E199AXY-0000f5-00@sc8-sf-web1.sourceforge.net>

Bugs item #711019, was opened at 2003-03-27 15:30
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711019&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Tim Peters (tim_one)
Summary: math.log(0) differs from math.log(0L)

Initial Comment:
This is maybe a minor nit, but math.log(0) raises an OverflowError
(range error) while math.log(0L) raises a ValueError (domain error).
Seems to me they ought to behave the same.  I noticed this in
2.2.2 but it's present in CVS.  In 2.1, both return -Inf.


----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2003-04-25 16:15

Message:
Logged In: YES 
user_id=44345

Thanks, I'll see about getting a blurb added to the math module docs.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-04-25 15:09

Message:
Logged In: YES 
user_id=31435

I'm happy enough the way it is.

2.2 specifically added the ability to get a good result for log
(long) even when the long is far too large to fit in a float.  
That's why log(long) takes a different path starting in 2.2, and 
why there's no inconsistency across platforms in log(0L) 
behavior since 2.2.

If you want consistency for log(0.0), then Python cannot allow 
the platfrom log to see 0.0:  "standard" libm error behavior is 
platform-dependent, and error cases for log aren't unique in 
this respect:  Python would have to write its own error-
checking code around all libm functions.  That's a much 
larger project than it may sound, and short of doing that, 
there's really no point special-casing the snot out of one 
specific log case.

It might be better if the math module docs explained that the 
specific exceptions raised in assorted error cases (and even 
whether some arguments are considered to be exceptional at 
all) are, in reality, not defined in any useful cross-platform or 
cross-release way.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-03-28 16:50

Message:
Logged In: YES 
user_id=44345

Ack!  I realized this is probably platform-dependent.  The results I
reported on were for Mac OS X.  Here's a little table of everything I could
quickly get my hands on.

Platform                Python Version  math.log(0)     math.log(0L)
Mac OS X                2.1.3           -Inf            -Inf
Mac OS X                2.2.2           OverflowError   ValueError
Mac OS X                CVS             OverflowError   ValueError
Win2k/MSVC              2.2.2           OverflowError   ValueError
Win2k/MSVC              2.3a2           OverflowError   ValueError
Win2k/cygwin            2.2.2           ValueError      ValueError
Solaris/gcc 2.95.2      2.3a2+          OverflowError   ValueError

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711019&group_id=5470


From noreply@sourceforge.net  Fri Apr 25 22:21:39 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 25 Apr 2003 14:21:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-711019 ] math.log(0) differs from math.log(0L)
Message-ID: <E199AdX-0003XD-00@sc8-sf-web3.sourceforge.net>

Bugs item #711019, was opened at 2003-03-27 16:30
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711019&group_id=5470

>Category: Documentation
Group: Python 2.3
>Status: Open
Resolution: Wont Fix
Priority: 5
Submitted By: Skip Montanaro (montanaro)
>Assigned to: Skip Montanaro (montanaro)
Summary: math.log(0) differs from math.log(0L)

Initial Comment:
This is maybe a minor nit, but math.log(0) raises an OverflowError
(range error) while math.log(0L) raises a ValueError (domain error).
Seems to me they ought to behave the same.  I noticed this in
2.2.2 but it's present in CVS.  In 2.1, both return -Inf.


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-04-25 17:21

Message:
Logged In: YES 
user_id=3066

Reopened and assigned to Skip for a documentation patch he
has.  It will be applied *after* the 2.3b1 release; we're
too far along at this point.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-04-25 17:15

Message:
Logged In: YES 
user_id=44345

Thanks, I'll see about getting a blurb added to the math module docs.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-04-25 16:09

Message:
Logged In: YES 
user_id=31435

I'm happy enough the way it is.

2.2 specifically added the ability to get a good result for log
(long) even when the long is far too large to fit in a float.  
That's why log(long) takes a different path starting in 2.2, and 
why there's no inconsistency across platforms in log(0L) 
behavior since 2.2.

If you want consistency for log(0.0), then Python cannot allow 
the platfrom log to see 0.0:  "standard" libm error behavior is 
platform-dependent, and error cases for log aren't unique in 
this respect:  Python would have to write its own error-
checking code around all libm functions.  That's a much 
larger project than it may sound, and short of doing that, 
there's really no point special-casing the snot out of one 
specific log case.

It might be better if the math module docs explained that the 
specific exceptions raised in assorted error cases (and even 
whether some arguments are considered to be exceptional at 
all) are, in reality, not defined in any useful cross-platform or 
cross-release way.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-03-28 17:50

Message:
Logged In: YES 
user_id=44345

Ack!  I realized this is probably platform-dependent.  The results I
reported on were for Mac OS X.  Here's a little table of everything I could
quickly get my hands on.

Platform                Python Version  math.log(0)     math.log(0L)
Mac OS X                2.1.3           -Inf            -Inf
Mac OS X                2.2.2           OverflowError   ValueError
Mac OS X                CVS             OverflowError   ValueError
Win2k/MSVC              2.2.2           OverflowError   ValueError
Win2k/MSVC              2.3a2           OverflowError   ValueError
Win2k/cygwin            2.2.2           ValueError      ValueError
Solaris/gcc 2.95.2      2.3a2+          OverflowError   ValueError

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711019&group_id=5470


From noreply@sourceforge.net  Fri Apr 25 22:22:41 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 25 Apr 2003 14:22:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-711019 ] math.log(0) differs from math.log(0L)
Message-ID: <E199AeX-00013C-00@sc8-sf-web1.sourceforge.net>

Bugs item #711019, was opened at 2003-03-27 16:30
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711019&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: Wont Fix
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Skip Montanaro (montanaro)
Summary: math.log(0) differs from math.log(0L)

Initial Comment:
This is maybe a minor nit, but math.log(0) raises an OverflowError
(range error) while math.log(0L) raises a ValueError (domain error).
Seems to me they ought to behave the same.  I noticed this in
2.2.2 but it's present in CVS.  In 2.1, both return -Inf.


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-04-25 17:22

Message:
Logged In: YES 
user_id=3066

I'll also note that the patch should be applied for 2.2.3;
there's no need to delay committing it on that branch.

Thanks, Skip!

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-04-25 17:21

Message:
Logged In: YES 
user_id=3066

Reopened and assigned to Skip for a documentation patch he
has.  It will be applied *after* the 2.3b1 release; we're
too far along at this point.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-04-25 17:15

Message:
Logged In: YES 
user_id=44345

Thanks, I'll see about getting a blurb added to the math module docs.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-04-25 16:09

Message:
Logged In: YES 
user_id=31435

I'm happy enough the way it is.

2.2 specifically added the ability to get a good result for log
(long) even when the long is far too large to fit in a float.  
That's why log(long) takes a different path starting in 2.2, and 
why there's no inconsistency across platforms in log(0L) 
behavior since 2.2.

If you want consistency for log(0.0), then Python cannot allow 
the platfrom log to see 0.0:  "standard" libm error behavior is 
platform-dependent, and error cases for log aren't unique in 
this respect:  Python would have to write its own error-
checking code around all libm functions.  That's a much 
larger project than it may sound, and short of doing that, 
there's really no point special-casing the snot out of one 
specific log case.

It might be better if the math module docs explained that the 
specific exceptions raised in assorted error cases (and even 
whether some arguments are considered to be exceptional at 
all) are, in reality, not defined in any useful cross-platform or 
cross-release way.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-03-28 17:50

Message:
Logged In: YES 
user_id=44345

Ack!  I realized this is probably platform-dependent.  The results I
reported on were for Mac OS X.  Here's a little table of everything I could
quickly get my hands on.

Platform                Python Version  math.log(0)     math.log(0L)
Mac OS X                2.1.3           -Inf            -Inf
Mac OS X                2.2.2           OverflowError   ValueError
Mac OS X                CVS             OverflowError   ValueError
Win2k/MSVC              2.2.2           OverflowError   ValueError
Win2k/MSVC              2.3a2           OverflowError   ValueError
Win2k/cygwin            2.2.2           ValueError      ValueError
Solaris/gcc 2.95.2      2.3a2+          OverflowError   ValueError

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711019&group_id=5470


From noreply@sourceforge.net  Sat Apr 26 04:00:43 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 25 Apr 2003 20:00:43 -0700
Subject: [Python-bugs-list] [ python-Bugs-711019 ] math.log(0) differs from math.log(0L)
Message-ID: <E199Fvf-0001It-00@sc8-sf-web2.sourceforge.net>

Bugs item #711019, was opened at 2003-03-27 15:30
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711019&group_id=5470

Category: Documentation
Group: Python 2.3
>Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Skip Montanaro (montanaro)
Summary: math.log(0) differs from math.log(0L)

Initial Comment:
This is maybe a minor nit, but math.log(0) raises an OverflowError
(range error) while math.log(0L) raises a ValueError (domain error).
Seems to me they ought to behave the same.  I noticed this in
2.2.2 but it's present in CVS.  In 2.1, both return -Inf.


----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2003-04-25 22:00

Message:
Logged In: YES 
user_id=44345

added note to Doc/lib/libmath.tex (v. 1.29 and 1.25.22.1).


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-04-25 16:22

Message:
Logged In: YES 
user_id=3066

I'll also note that the patch should be applied for 2.2.3;
there's no need to delay committing it on that branch.

Thanks, Skip!

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-04-25 16:21

Message:
Logged In: YES 
user_id=3066

Reopened and assigned to Skip for a documentation patch he
has.  It will be applied *after* the 2.3b1 release; we're
too far along at this point.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-04-25 16:15

Message:
Logged In: YES 
user_id=44345

Thanks, I'll see about getting a blurb added to the math module docs.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-04-25 15:09

Message:
Logged In: YES 
user_id=31435

I'm happy enough the way it is.

2.2 specifically added the ability to get a good result for log
(long) even when the long is far too large to fit in a float.  
That's why log(long) takes a different path starting in 2.2, and 
why there's no inconsistency across platforms in log(0L) 
behavior since 2.2.

If you want consistency for log(0.0), then Python cannot allow 
the platfrom log to see 0.0:  "standard" libm error behavior is 
platform-dependent, and error cases for log aren't unique in 
this respect:  Python would have to write its own error-
checking code around all libm functions.  That's a much 
larger project than it may sound, and short of doing that, 
there's really no point special-casing the snot out of one 
specific log case.

It might be better if the math module docs explained that the 
specific exceptions raised in assorted error cases (and even 
whether some arguments are considered to be exceptional at 
all) are, in reality, not defined in any useful cross-platform or 
cross-release way.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-03-28 16:50

Message:
Logged In: YES 
user_id=44345

Ack!  I realized this is probably platform-dependent.  The results I
reported on were for Mac OS X.  Here's a little table of everything I could
quickly get my hands on.

Platform                Python Version  math.log(0)     math.log(0L)
Mac OS X                2.1.3           -Inf            -Inf
Mac OS X                2.2.2           OverflowError   ValueError
Mac OS X                CVS             OverflowError   ValueError
Win2k/MSVC              2.2.2           OverflowError   ValueError
Win2k/MSVC              2.3a2           OverflowError   ValueError
Win2k/cygwin            2.2.2           ValueError      ValueError
Solaris/gcc 2.95.2      2.3a2+          OverflowError   ValueError

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711019&group_id=5470


From noreply@sourceforge.net  Sat Apr 26 07:37:47 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 25 Apr 2003 23:37:47 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-727898 ] Support for sending multipart form data
Message-ID: <E199JJj-0002cQ-00@sc8-sf-web1.sourceforge.net>

Feature Requests item #727898, was opened at 2003-04-26 02:37
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=727898&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Hunter Peress (hfastedge)
Assigned to: Nobody/Anonymous (nobody)
Summary: Support for sending multipart form data

Initial Comment:
This is necessary, and simple. 

See:http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/146306
There should be 0 politics about the lack of this.

In response to this if there is some reason you cannot
include this code directly into urllib (most likely),
please tell me what I can do within the time frame of
my reply to 1 email response to get this code included
into the python libraries immediately.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=727898&group_id=5470


From noreply@sourceforge.net  Sat Apr 26 11:22:37 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 26 Apr 2003 03:22:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-474836 ] Tix not included in windows distribution
Message-ID: <E199MpJ-0006Pc-00@sc8-sf-web2.sourceforge.net>

Bugs item #474836, was opened at 2001-10-25 13:22
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=474836&group_id=5470

Category: Tkinter
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Tim Peters (tim_one)
Summary: Tix not included in windows distribution

Initial Comment:
Although there is a Tix.py available, there is no Tix
support in the precomiled 
Python-distribution for windows. So 

import Tix

works fine, but

root = Tix.Tk()

results in 

TclError: package not found. 

It is possible to circumvent this problem by installing
a regular Tcl/Tk distribution (e.g. in
c:\programme\tcl) and installing Tix in the regular
Tcl-path (i.e. tcl\lib).

Mathias

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-04-26 12:22

Message:
Logged In: YES 
user_id=21627

I still think Python should include Tix. Here are some 
instructions on how to make Tix 8.1.4 work:

1. Unpack as a sibling of tcl8.4.1 and tk8.4.1
2. Edit win\common.mk, to set the following variables
    TCL_VER=8.4
    INSTALLDIR=<directory to pick up installation from later>
    MKDIR=mkdir
3. Edit win\makefile.vc, to set the following variables
    TOOLS32=<directory of cl>
    TOOLS32_rc=<directory of rc.exe>
4. Edit win\tk\pkgindex.tcl, to replace
    lappend dirs ../../Dlls
    with
    lappend dirs [file join [file dirname [info nameofexe]] Dlls]
5. nmake -f makefile.vc
6. nmake -f makefile.vc install
7. Copy INSTALLDIR\bin\tix8184.dll to <python>\DLLs
8. Optionally copy tix8184.lib somewhere
9. copy INSTALLDIR\lib\tix8.1 into <python>\tcl

With these instructions, invoking t.tk.eval("package require 
Tix") succeeds. For some reason, Tix won't still find any of 
the commands; I'll investigate this later.

----------------------------------------------------------------------

Comment By: Internet Discovery (idiscovery)
Date: 2002-12-11 10:14

Message:
Logged In: YES 
user_id=33229

My you're courageous - going with a version of Tcl that doesn't
even pass its own tests :-) Been there, seen it, done it ....

8.1.4 will be out this week, which compiles with 8.4 but I don't
expect it to "support" 8.4 for a while yet (they added more problems
in 8.4.1). 8.3.5 is definitely "supported".

Check back with me before 2.3 goes into beta and I'll do
another minor release if necessary. Maybe Tk will test clean then.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-11-20 02:36

Message:
Logged In: YES 
user_id=31435

Parents shouldn't disagree in front of their children <wink>.

Not all the Tcl or Tk tests (their tests, not ours) passed 
when I built 8.4.1, but I couldn't (and can't) make time to 
dig into that, and all the Python stuff I tried worked fine.  So 
I don't fear 8.4, and am inclined to accept Martin's 
assurance that 8.4 is best for Python.

We intend to put out the first 2.3 Python alpha by the end 
of the year, and my bet is it won't be a minute before that.  
If Tix 8.1.4 is at RC3 now, I'd *guess* you'll have a final 
release out well before then.  Yes?  No?

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-11-19 23:12

Message:
Logged In: YES 
user_id=21627

I think the recommendation cannot apply to Python; I'm very
much in favour of releasing Python 2.3 with Tk 8.4.x. 

So the question then is whether Python 2.3 should include
Tix 8.1.4 or no Tix at all, and at what time Tix 8.1.4 can
be expected.

----------------------------------------------------------------------

Comment By: Internet Discovery (idiscovery)
Date: 2002-11-19 20:10

Message:
Logged In: YES 
user_id=33229

Look on http://tix.sourceforge.net/download.shtml for
Tix 8.1.4 RC3. It works with Tk 8.4.1 and passes the test suite,
but there are still issues with Tk 8.4 and it has not been
widely tested with yet with 8.4.1, so we still recommend 8.3.5.
(Tcl major releases often aren't stable until patch .3 or so.)

If you have any problems let me know directly by email
and I'll try and help.








----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-11-18 17:35

Message:
Logged In: YES 
user_id=31435

Does Tix 8.1.3 play with Tcl/Tk 8.4.1?  The 2.3. Windows 
distro is set up to include the latter now.  The 
win\common.mak file from Tix 8.1.3 doesn't have a section 
for Tcl/Tk 8.4, though.

There appear to be several reasons Tix won't compile on 
my box anyway without fiddling the Tix makefiles (e.g., my 
VC doesn't live in \DevStudio), so before spending more 
time on that I'd like to know whether it's doomed.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-11-07 15:52

Message:
Logged In: YES 
user_id=6380

I support this. Tim, I know you're not a big Tk user (to say
the least). I'll offer to help in person.

----------------------------------------------------------------------

Comment By: Internet Discovery (idiscovery)
Date: 2002-11-03 08:30

Message:
Logged In: YES 
user_id=33229

I would really like to see Tix in 2.3 and will be glad to help.
AFAIK there are no major issues with tix-8.1.3 and Python 2.x
and it should be a simple drop in of a cannonically compiled Tix.

If there are any issues that need dealing with at Tix's end, I'll be 
glad to put out a new minor release of Tix to address them.

On Python's end I've suggested a fix for http://python.org/sf/564729

FYI, please also see my comments for bug 632323.


----------------------------------------------------------------------

Comment By: Internet Discovery (idiscovery)
Date: 2002-11-03 06:34

Message:
Logged In: YES 
user_id=33229

I would really like to see Tix in 2.3 and will be glad to help.
AFAIK there are no major issues with tix-8.1.3 and Python 2.x
and it should be a simple drop in of a cannonically compiled Tix.

If there are any issues that need dealing with at Tix's end, I'll be 
glad to put out a new minor release of Tix to address them.

On Python's end I've suggested a fix for http://python.org/sf/564729

FYI, please also see my comments for bug 632323.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-23 04:34

Message:
Logged In: YES 
user_id=6380

Yes, for 2.3.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-10 02:48

Message:
Logged In: YES 
user_id=31435

Guido, do you want me to spend time on this?

----------------------------------------------------------------------

Comment By: Mathias Palm (monos)
Date: 2002-03-07 14:38

Message:
Logged In: YES 
user_id=361926

Thanks.

Mathias

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-02-25 13:57

Message:
Logged In: YES 
user_id=21627

The zip file is slightly too large for SF, so it is now at

http://www.informatik.hu-
berlin.de/~loewis/python/tix813win.zip

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-02-25 13:56

Message:
Logged In: YES 
user_id=21627

Building Tix from sources is non-trivial, and I could not 
find any recent Windows binary distribution (based on Tix 
8.1). So I'll attach a build of Tix 8.1.3 for Tcl/Tk 8.3, 
as a drop-in into the Python binary distribution.

Compared to the original distribution, only tix8.1
\pkgIndex.tcl required tweaking, to tell it that 
tix8183.dll can be found in the DLLs subdirectory.

Also, unless TIX_LIBRARY is set, the Tix tcl files *must* 
live in tcl\tix8.1, since tix8183.dll will look in 
TCL_LIBRARY\..\tix<TIX_VERSION> (among other locations).

If a major Tcl release happens before Python 2.3 is 
released (and it is then still desirable to distribute 
Python with Tix), these binaries need to be regenerated.

Would these instructions (unpack zip file into 
distribution tree) be precise enough to allow 
incorporation into the windows installer?

----------------------------------------------------------------------

Comment By: Mathias Palm (monos)
Date: 2001-10-29 12:53

Message:
Logged In: YES 
user_id=361926

As mentioned in the mail above (by me, Mathias), Tix is a
package belonging to Tcl/Tk (to be found on sourceforge:
tix.sourceforge.net, or via the Python home page - tkinter
link). 

Everything needed can be found there, just read about it
(and dont forget about the winking,  eyes might be getting
dry)

Mathias



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-10-25 20:26

Message:
Logged In: YES 
user_id=31435

I don't know anything about Tix, so if somebody wants this 
in the Windows installer, they're going to have to explain 
exactly (by which I mean exactly <0.5 wink>) what's needed.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=474836&group_id=5470


From noreply@sourceforge.net  Sat Apr 26 15:23:41 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 26 Apr 2003 07:23:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-728051 ] Test failures on Linux, Python 2.3b1 tarball
Message-ID: <E199Qab-0007Wf-00@sc8-sf-web4.sourceforge.net>

Bugs item #728051, was opened at 2003-04-26 14:23
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728051&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Phillip J. Eby (pje)
Assigned to: Nobody/Anonymous (nobody)
Summary: Test failures on Linux, Python 2.3b1 tarball

Initial Comment:
"make test" resulted in:

test test_tempfile failed -- Traceback (most recent
call last):
  File
"/home/admin/Python-2.3b1/Lib/test/test_tempfile.py",
line 299, in test_noinherit
    self.failIf(retval > 0, "child process reports
failure")
  File "/home/admin/Python-2.3b1/Lib/unittest.py", line
264, in failIf
    if expr: raise self.failureException, msg
AssertionError: child process reports failure

test test_time failed -- Traceback (most recent call last):
  File
"/home/admin/Python-2.3b1/Lib/test/test_time.py", line
107, in test_tzset
    self.failUnless(time.tzname[1] == 'AEDT',
str(time.tzname[1]))
  File "/home/admin/Python-2.3b1/Lib/unittest.py", line
268, in failUnless
    if not expr: raise self.failureException, msg
AssertionError: AEST


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728051&group_id=5470


From noreply@sourceforge.net  Sat Apr 26 17:28:24 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 26 Apr 2003 09:28:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-728097 ] tmpnam problems on windows 2.3b, breaks test.test_os
Message-ID: <E199SXI-0006kj-00@sc8-sf-web2.sourceforge.net>

Bugs item #728097, was opened at 2003-04-26 18:28
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728097&group_id=5470

Category: Windows
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Irmen de Jong (irmen)
Assigned to: Tim Peters (tim_one)
Summary: tmpnam problems on windows 2.3b, breaks test.test_os

Initial Comment:
(python 2.3b on Windows XP, regular user account)

Problem running test.test_os:

==============================================================
ERROR: test_tmpfile (__main__.TemporaryFileTests)
--------------------------------------------------------------
Traceback (most recent call last):
  File "Lib\test\test_os.py", line 49, in test_tmpfile
    fp = os.tmpfile()
OSError: [Errno 13] Permission denied

==============================================================
ERROR: test_tmpnam (__main__.TemporaryFileTests)
--------------------------------------------------------------
Traceback (most recent call last):
  File "Lib\test\test_os.py", line 61, in test_tmpnam
    self.check_tempfile(os.tmpnam())
  File "Lib\test\test_os.py", line 29, in check_tempfile
    open(name, "w")
IOError: [Errno 13] Permission denied: '\sd4.'


It appears Python 2.3b has troubles writing to a file
returned by os.tmpnam(), because when I try this on
Python 2.2:
>>> open(os.tmpnam(),"w")
<open file '\s128.8', mode 'w' at 0x0091BCC8>

Where Python 2.3b gives:
>>> open(os.tmpnam(),"w")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: [Errno 13] Permission denied: '\sg4.1'


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728097&group_id=5470


From noreply@sourceforge.net  Sat Apr 26 17:39:42 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 26 Apr 2003 09:39:42 -0700
Subject: [Python-bugs-list] [ python-Bugs-728097 ] tmpnam problems on windows 2.3b, breaks test.test_os
Message-ID: <E199SiE-0003Dn-00@sc8-sf-web1.sourceforge.net>

Bugs item #728097, was opened at 2003-04-26 18:28
Message generated for change (Comment added) made by irmen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728097&group_id=5470

Category: Windows
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Irmen de Jong (irmen)
Assigned to: Tim Peters (tim_one)
Summary: tmpnam problems on windows 2.3b, breaks test.test_os

Initial Comment:
(python 2.3b on Windows XP, regular user account)

Problem running test.test_os:

==============================================================
ERROR: test_tmpfile (__main__.TemporaryFileTests)
--------------------------------------------------------------
Traceback (most recent call last):
  File "Lib\test\test_os.py", line 49, in test_tmpfile
    fp = os.tmpfile()
OSError: [Errno 13] Permission denied

==============================================================
ERROR: test_tmpnam (__main__.TemporaryFileTests)
--------------------------------------------------------------
Traceback (most recent call last):
  File "Lib\test\test_os.py", line 61, in test_tmpnam
    self.check_tempfile(os.tmpnam())
  File "Lib\test\test_os.py", line 29, in check_tempfile
    open(name, "w")
IOError: [Errno 13] Permission denied: '\sd4.'


It appears Python 2.3b has troubles writing to a file
returned by os.tmpnam(), because when I try this on
Python 2.2:
>>> open(os.tmpnam(),"w")
<open file '\s128.8', mode 'w' at 0x0091BCC8>

Where Python 2.3b gives:
>>> open(os.tmpnam(),"w")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: [Errno 13] Permission denied: '\sg4.1'


----------------------------------------------------------------------

>Comment By: Irmen de Jong (irmen)
Date: 2003-04-26 18:39

Message:
Logged In: YES 
user_id=129426

Extra info:
Forget about Python 2.2, I tried again and it doesn't work
with 2.2 either. I found out why: My user account has no
write access in the root of C:\  !!  I don't know about the
format of the filenames returned from os.tmpnam(), but it
appears that they are created in the root of  the current
drive, which fails if that is C:\ -- where I have no write
access.

Needless to say, it works fine when running with
administrative priviliges because then we are allowed to
write in the root of C:\


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728097&group_id=5470


From noreply@sourceforge.net  Sat Apr 26 17:45:33 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 26 Apr 2003 09:45:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-728101 ] RuntimeError "not holding import lock" with test.autotest
Message-ID: <E199Snt-0007Ft-00@sc8-sf-web3.sourceforge.net>

Bugs item #728101, was opened at 2003-04-26 18:45
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728101&group_id=5470

Category: Windows
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Irmen de Jong (irmen)
Assigned to: Tim Peters (tim_one)
Summary: RuntimeError "not holding import lock" with test.autotest

Initial Comment:
(windows XP, python 2.3b)
I get the following error at the end of an "import
test.autotest":

Traceback (most recent call last):
  File "<string>", line 1, in ?
RuntimeError: not holding the import lock

The "test_imp" test failed with the following error:
testLock (test.test_imp.ImpLock) ... ERROR

======================================================================
ERROR: testLock (test.test_imp.ImpLock)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Python23\lib\test\test_imp.py", line 22, in
testLock
    raise TestFailed, \
TestFailed: release_lock() without lock should raise
RuntimeError

----------------------------------------------------------------------
Ran 1 test in 0.000s

FAILED (errors=1)
test test_imp failed -- Traceback (most recent call last):
  File "C:\Python23\lib\test\test_imp.py", line 22, in
testLock
    raise TestFailed, \
TestFailed: release_lock() without lock should raise
RuntimeError


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728101&group_id=5470


From noreply@sourceforge.net  Sat Apr 26 18:14:42 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 26 Apr 2003 10:14:42 -0700
Subject: [Python-bugs-list] [ python-Bugs-663782 ] test_socket test_unicode_file fail on 2.3a1 on winNT
Message-ID: <E199TG6-0007n3-00@sc8-sf-web4.sourceforge.net>

Bugs item #663782, was opened at 2003-01-07 16:58
Message generated for change (Comment added) made by irmen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663782&group_id=5470

Category: Windows
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Miki Tebeka (tebeka)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_socket test_unicode_file fail on 2.3a1 on winNT

Initial Comment:
This happens after installing 2.3a1 on winNT 4 sp6.

D:\apps\Python23>python
D:\apps\Python23\Lib\test\test_socket.py
testCrucialConstants (__main__.GeneralModuleTests) ... ok
testDefaultTimeout (__main__.GeneralModuleTests) ... ok
testGetServByName (__main__.GeneralModuleTests) ... ok
testGetSockOpt (__main__.GeneralModuleTests) ... ok
testHostnameRes (__main__.GeneralModuleTests) ... ok
testInterpreterCrash (__main__.GeneralModuleTests) ... ok
testNtoH (__main__.GeneralModuleTests) ... ok
testRefCountGetNameInfo (__main__.GeneralModuleTests)
... ok
testSendAfterClose (__main__.GeneralModuleTests) ... ok
testSetSockOpt (__main__.GeneralModuleTests) ... ok
testSockName (__main__.GeneralModuleTests) ... ok
testSocketError (__main__.GeneralModuleTests) ... ok
testFromFd (__main__.BasicTCPTest) ... ok
testOverFlowRecv (__main__.BasicTCPTest) ... ok
testOverFlowRecvFrom (__main__.BasicTCPTest) ... ok
testRecv (__main__.BasicTCPTest) ... ok
testRecvFrom (__main__.BasicTCPTest) ... ok
testSendAll (__main__.BasicTCPTest) ... ok
testShutdown (__main__.BasicTCPTest) ... ok
testRecvFrom (__main__.BasicUDPTest) ... ok
testSendtoAndRecv (__main__.BasicUDPTest) ... ok
testAccept (__main__.NonBlockingTCPTests) ... FAIL
ERROR
testConnect (__main__.NonBlockingTCPTests) ... ok
testRecv (__main__.NonBlockingTCPTests) ... ok
testSetBlocking (__main__.NonBlockingTCPTests) ... ok
testFullRead (__main__.FileObjectClassTestCase) ... ok
testReadline (__main__.FileObjectClassTestCase) ... ok
testSmallRead (__main__.FileObjectClassTestCase) ... ok
testUnbufferedRead (__main__.FileObjectClassTestCase)
... ok
testFullRead
(__main__.UnbufferedFileObjectClassTestCase) ... ok
testReadline
(__main__.UnbufferedFileObjectClassTestCase) ... ok
testSmallRead
(__main__.UnbufferedFileObjectClassTestCase) ... ok
testUnbufferedRead
(__main__.UnbufferedFileObjectClassTestCase) ... ok
testUnbufferedReadline
(__main__.UnbufferedFileObjectClassTestCase) ... ok
testFullRead
(__main__.LineBufferedFileObjectClassTestCase) ... ok
testReadline
(__main__.LineBufferedFileObjectClassTestCase) ... ok
testSmallRead
(__main__.LineBufferedFileObjectClassTestCase) ... ok
testUnbufferedRead
(__main__.LineBufferedFileObjectClassTestCase) ... ok
testFullRead
(__main__.SmallBufferedFileObjectClassTestCase) ... ok
testReadline
(__main__.SmallBufferedFileObjectClassTestCase) ... ok
testSmallRead
(__main__.SmallBufferedFileObjectClassTestCase) ... ok
testUnbufferedRead
(__main__.SmallBufferedFileObjectClassTestCase) ... ok

======================================================================
ERROR: testAccept (__main__.NonBlockingTCPTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\apps\Python23\Lib\test\test_socket.py", line
117, in _tearDown
    self.fail(msg)
  File "D:\apps\Python23\lib\unittest.py", line 260, in
fail
    raise self.failureException, msg
AssertionError: (10061, 'Connection refused')

======================================================================
FAIL: testAccept (__main__.NonBlockingTCPTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\apps\Python23\Lib\test\test_socket.py", line
475, in testAccept
    self.fail("Error trying to do non-blocking accept.")
  File "D:\apps\Python23\lib\unittest.py", line 260, in
fail
    raise self.failureException, msg
AssertionError: Error trying to do non-blocking accept.

----------------------------------------------------------------------
Ran 42 tests in 2.204s

FAILED (failures=1, errors=1)
Traceback (most recent call last):
  File "D:\apps\Python23\Lib\test\test_socket.py", line
632, in ?
    test_main()
  File "D:\apps\Python23\Lib\test\test_socket.py", line
629, in test_main
    test_support.run_suite(suite)
  File "D:\apps\Python23\lib\test\test_support.py",
line 217, in run_suite
    raise TestFailed(msg)
test.test_support.TestFailed: errors occurred; run in
verbose mode for details
D:\apps\Python23>python
D:\apps\Python23\Lib\test\test_unicode_file.py
File doesn't exist (encoded string) after creating it
Traceback (most recent call last):
  File
"D:\apps\Python23\Lib\test\test_unicode_file.py", line
37, in ?
    if os.stat(TESTFN_ENCODED) != os.stat(TESTFN_UNICODE):
OSError: [Errno 2] No such file or directory: '@test-??'


----------------------------------------------------------------------

Comment By: Irmen de Jong (irmen)
Date: 2003-04-26 19:14

Message:
Logged In: YES 
user_id=129426

Both tests run fine on my windows XP box with Python 2.3b...

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-03-25 05:03

Message:
Logged In: YES 
user_id=31435

I personally tested these before the releases, on Win98SE 
and on Win2000 Pro.  No problems there, although 
test_unicode_file turns itself off on Win9x.  I don't have 
access to an NT box, and these won't get fixed until a 
Python developer who does have NT can dig into them 
there.

----------------------------------------------------------------------

Comment By: Miki Tebeka (tebeka)
Date: 2003-03-24 08:51

Message:
Logged In: YES 
user_id=358087

Yes.
Version is:
2.3a2 (#39, Feb 19 2003, 17:58:58) [MSC v.1200 32 bit (Intel)]

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-23 21:40

Message:
Logged In: YES 
user_id=33168

Is this problem still happening with 2.3a2+ ?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663782&group_id=5470


From noreply@sourceforge.net  Sat Apr 26 18:21:35 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 26 Apr 2003 10:21:35 -0700
Subject: [Python-bugs-list] [ python-Bugs-549151 ] urllib2 POSTs on redirect
Message-ID: <E199TMl-0001CU-00@sc8-sf-web2.sourceforge.net>

Bugs item #549151, was opened at 2002-04-26 12:04
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470

Category: Python Library
Group: None
>Status: Open
Resolution: Fixed
Priority: 7
Submitted By: John J Lee (jjlee)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: urllib2 POSTs on redirect

Initial Comment:

urllib2 (I'm using 1.13.22 with Python 2.0, but I assume the 2.2 branch does the same) uses the 
POST method on redirect, contrary to RFC1945 section 9.3:

> 9.3  Redirection 3xx
> 
>    This class of status code indicates that further action needs to be
>    taken by the user agent in order to fulfill the request. The action
>    required may be carried out by the user agent without interaction
>    with the user if and only if the method used in the subsequent
>    request is GET or HEAD. A user agent should never automatically
>    redirect a request more than 5 times, since such redirections usually
>    indicate an infinite loop.

Can be fixed in HTTPRedirectHandler.http_error_302 by replacing
        new = Request(newurl, req.get_data())

with
        new = Request(newurl)

so that GET is done on redirect instead of POST.

I suppose the limit of 10 in the same function should be changed to 5, also.


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-26 13:21

Message:
Logged In: YES 
user_id=6380

Blech! Reopening. I just stumbled upon the relevant part of
RFC 2616, and it suggests to me the following rules when the
original request was a POST. I should have made the time for
this earlier, but I simply didn't have time. :-(

Reference:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3

Summary:

- 307 means repeat the POST to the new URL *after user
confirmation*

- 303 means do a GET to the new URL

- 301 means repeat the POST to the new URL *after user
confirmation*, *but* old agents often do a GET instead

- 302 may be treated the same as 303 (i.e. GET the new URL)
for compatibility with existing practice

This suggests to me that *no* automatic repeat of POST
requests should ever be done, and that in the case of a 302
or 303 response, a POST should be replaced by a GET; this
may also be done for a 301 response -- even though the
standard calls that an error, it admits that it is done by
old clients.

But the new code in urllib.py doesn't seem to do that: it
treats 301, 302 and 303 all the same, doing a POST if the
original request was a POST (POST is determined by 'data is
not None'). And it doesn't redirect on a 307 at all, even
though it should do that if the original request was GET.
The updated documentation describes the desired behavior for
301,302,303.

I think the desired behavior can be obtained by always
omitting the data argument in the call to self.open(newurl)
in redirect_internal(). Then a handler for 307 could be
handled that raises an error if the original request was a
POST, and redirects otherwise. I'm attaching a suggested
patch to urllib.py (guido.txt).

It appears urllib2.py was patched correctly.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-25 04:21

Message:
Logged In: YES 
user_id=80475

Backported to 2.2.3.
Closing bug.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-24 11:49

Message:
Logged In: YES 
user_id=6380

Yes, I think that would be a good idea.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-24 11:34

Message:
Logged In: YES 
user_id=80475

Committed as:

Lib/urllib.py 1.157
Lib/urllib2.py 1.39
Doc/lib/liburllib.tex 1.47
Doc/lib/liburllib2.tex 1.7


Guido, would you like this backported to 2.2.3?

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2003-04-20 16:44

Message:
Logged In: YES 
user_id=261020

Just noticed that I forgot to upload one of the doc patches 
on 2003-03-05.  Here it is. 
 
The patches that need to be applied are the three I 
uploaded on 2003-03-05 (urllib.py.patch, urllib2.py.patch 
and liburllib2.tex.patch), and the liburllib.tex.patch I just 
uploaded. 
 

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-16 16:35

Message:
Logged In: YES 
user_id=6380

I think this is the right thing to do. Can you check it in?
 (There are several files -- urllib, urllib2, and its docs).

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-16 16:27

Message:
Logged In: YES 
user_id=80475

Do you have time to take this one back?  My head starts to 
explode when researching whether this is the right thing 
to do.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-03-07 15:57

Message:
Logged In: YES 
user_id=6380

I'll try to work on this.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2003-03-05 16:03

Message:
Logged In: YES 
user_id=261020

The fix for this was set to go into 2.3, but nothing has  
happened yet. 
 
There were a couple of minor details to be fixed in the 
patches, so I've done that, and uploaded new patches for  
urllib2.py, urllib.py, and their documentation files (against  
current CVS). Well, I'm just about to upload them... 
 
Jeremy, can you apply the patches and finally close this 
one now?  Let me know if anything else needs doing. 
 
This should actually close another bug on SF, too (if it's still 
open), which deals with the urllib.py case.  I can't find it,  
though.  I did attach a comment to it (before I lost it) that 
references this bug. 
 

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-10-15 11:22

Message:
Logged In: YES 
user_id=261020

Well, when I carefully read the RFC I came to the conclusion
that 301 should be redirected to GET, not POST.  I also came
to the conclusion that the RFC was slightly ambiguous on
this point, so I guess that's why A. Flavell came to the
conclusion that 301 should redirect to POST rather than GET.
Anyway, clearly the established practice is to redirect 301
as GET, so this is all academic.

Assuming he's right about Netscape / IE etc., I suppose I'm
happy for 301 to redirect without an exception, since that's
what we've agreed to do for 302.  Obviously, the docs should
say this is contrary to the RFC (as my doc patch says for
302 already).

As for urllib.py, I see the problem.  303 should still be
added, though, since that poses no problem at all.


John


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-10-11 11:40

Message:
Logged In: YES 
user_id=31392

I'm still uncertain about what to do on 301 responses.  As
you say, there are two issues to sort out: 1) what method
should a POST be redicted to and 2) whether the user should
be asked to confirm.

There's discussion of this at:
http://ppewww.ph.gla.ac.uk/~flavell/www/post-redirect.html
The page is a bit old, but I don't know if it is out of date.
It says that IE5, Netscape 4, and Mozilla 1.0 all redirect a
301 POST to a GET without user confirmation.  That seems
like a widespread disregard for the spec that we ought to
emulate.

I agree with your interpretation that urllib2 raise an
HTTPError to signal "request confirm" because an HTTPError
is also a valid response that the user could interpret.  But
of urllib, an HTTP error doesn't contain a valid response. 
The change would make it impossible for the client to do
anything if a 301 response is returned from a POST.  That
seems worse than doing the wrong.



----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-10-09 21:27

Message:
Logged In: YES 
user_id=6380

OK, over to jeremy.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-10-09 17:16

Message:
Logged In: YES 
user_id=261020

Ah.  Here it is.

John


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-10-08 14:23

Message:
Logged In: YES 
user_id=6380

Um, I don't see the patch for urllib.py.  Perhaps you didn't
check the box?

Jeremy, let's do this in 2.3, OK?

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-10-08 12:53

Message:
Logged In: YES 
user_id=261020

Guido mentioned that urllib.py should be fixed
too.  I've attached another patch.


John


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-10-05 13:44

Message:
Logged In: YES 
user_id=261020

Here is a patch for the minor documentation changes required
for the patch I uploaded earlier to fix this bug.  I've also
uploaded a slightly revised patch:

I renamed the `method' method to `get_method' for
consistency with the other methods of the Request class.
The reason this new method is there at all is because the
logic that decides whether or not a redirection should take
place is defined in terms of the method type
(GET/HEAD/POST).  urllib2 doesn't support HEAD ATM, but it
might in future.  OTOH, the Request class is supposed to be
generic -- not specific to HTTP -- so perhaps get_method
isn't really appropriate.  OTOOH, add_data is already
documented to only be meaningful for HTTP Requests.  I
suppose there could be a subclass HTTPRequest, but that's
less simple.  What do you think is best?

I also changed redirect_request to raise an exception
instead of returning None (because no other Handler should
handle the redirect), and changed its documented return
value / exception interface to be consistent with the rest
of urllib2.


John


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-06-23 15:23

Message:
Logged In: YES 
user_id=261020

First, can I underline the fact that there are two issues
here:

  1. What method should POST be redirected as for a
     particular 30x response?

  2. Should the user be asked to confirm the redirection
     (which presumably maps onto raising an HTTPError in
     urllib2)?

I think current client implementations go against the RFCs
on both these points for 302.  Contrastingly, RFC 2616's
note on 301 responses (section 10.3.2) implies that only a
subset of HTTP/1.0 (not 1.1, note) clients violate the RFCs
(1945, 2068, 2616) on point 1 for 301 responses, and I know
of no clients that violate the RFCs on point 2 for 301
responses (but I haven't tested).  Also, I guess the
original intent (for both 301 and 302) was that POSTs
represent an action, so it's dangerous in general to
redirect them without asking the user: I presume this is why
307 was brought in: 307 POSTs on redirected POST, so the
user must be asked:

10.3 Redirection 3xx
[...]
   The action required MAY be carried out by the user agent
   without interaction with the user if and only if the
   method used in the second request is GET or HEAD.

(and 303 is just meant to have the 'erroneous' 302
behaviour: GET on redirected POST, don't ask the user)

So, I agree with Guido that 302 should probably now be
treated the way most clients treat it: GET on redirected
POST, don't ask the user.  As for 301, if it *is* true that
only a few HTTP/1.0 clients have misinterpreted the RFCs on
301, we should stick to the safe behaviour indicated by the
RFC.

As for Guido's first question: A 307 should indeed be
redirected as a POST, but it should ask the user first (see
10.3 quote, above).  That's what my patch does (the 'return
None' in the else clause in redirect_request causes an
exception to be raised eventually -- maybe it should just
raise it itself).

I've attached a revised patch that deals with 302 (and 303)
in the 'erroneous' way (again: GET on redirected POST, don't
ask the user).

I suppose the comment about HTTPRedirectHandler also needs
to state that 301 and 307 POST requests are not
automatically redirected -- HTTPError is raised in that
case.


John


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-19 20:57

Message:
Logged In: YES 
user_id=6380

Hm, I thought that 307 should be treated differently than
303. In particular, a 307 response to POST should cause the
POST to be redirected. And I'm not sure about what a 301
response to POST should do.

(In the mean time I have been convinced that changing POST
to GET on 302 is the best thing to do given that most
browsers do that. The old urllib.py should be fixed too.)

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-06-19 17:57

Message:
Logged In: YES 
user_id=261020

I've attached a patch -- was simpler than I thought.

I think this is in compliance with RFC 2616.  It's also
simple for clients to inherit from HTTPRedirectHandler and
override redirect_request if, for example, they know they
want all 302 POSTs to be redirected as a GET, which removes
the need for mixing redirection code with normal client code
even when the server doesn't follow the RFC (if the server
expects a 302 POST to be redirected as a GET, for example).
Note that I had to add a method, named 'method', to the
Request class, for maintainability (it's possible that
urllib2 may be able to do methods other than GET and POST in
future).

Possibly redirect_request should take fewer parameters.

John


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-06-19 17:56

Message:
Logged In: YES 
user_id=261020

I've attached a patch -- was simpler than I thought.

I think this is in compliance with RFC 2616.  It's also
simple for clients to inherit from HTTPRedirectHandler and
override redirect_request if, for example, they know they
want all 302 POSTs to be redirected as a GET, which removes
the need for mixing redirection code with normal client code
even when the server doesn't follow the RFC (if the server
expects a 302 POST to be redirected as a GET, for example).
Note that I had to add a method, named 'method', to the
Request class, for maintainability (it's possible that
urllib2 may be able to do methods other than GET and POST in
future).

Possibly redirect_request should take fewer parameters.

John


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-06-06 17:25

Message:
Logged In: YES 
user_id=261020

Oh, I hadn't realised httplib uses HTTP/1.1 now -- and now I
check, I see that even RFC 1945 (HTTP/1.0) has a whole set of
restrictions on 30x for particular values of x which I missed
completely.

I guess it should do what Guido suggested -- report an error if a
POST is redirected -- until somebody gets time to do it properly.
I won't have time for a couple of months, but if nobody has done
it by then I'll upload a patch.


John


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-06-06 11:09

Message:
Logged In: YES 
user_id=31392

I think you need to review the current HTTP spec -- RFC 2616
-- and look at the section on redirection (10.3).  I think
urllib2 could improve its handling of redirection, but the
behavior you describe from lynx sounds incorrect.  I'd be
happy to review a patch the implemented the current spec.

Also, RFC 2616 removes the recommendation of a 5 redirect limit.




----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-29 14:10

Message:
Logged In: YES 
user_id=6380

Fair enough. I'll leve it to Jeremy to review the proposed
fix. (Note that he's busy though.)

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-04-29 12:29

Message:
Logged In: YES 
user_id=261020

I don't see why it shouldn't substitue a GET.  That certainly seems to be
the standard practice (well, at least that's what lynx does), and in the case
of the only site where I've encountered redirects on POST, the redirect URL
contains urlencoded stuff, so it clearly expects the user-agent to do a GET.
The site would break if this didn't happen, so I guess Netscape and IE must
do the same thing.

Clearly the RFC *does* allow this, though it doesn't require it (or specify
what should happen here in any way other than to say that a POST is not
allowed, in fact).  Since it's standard practice and allowed by the RFC, I
don't think it should be an error.

John


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-28 20:53

Message:
Logged In: YES 
user_id=6380

Hm, the way I interpret the text you quote, if the original
request is  a POST, it should probably not substitute a GET
but report the error.

Assigning to Jeremy since it's his module.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-04-28 12:21

Message:
Logged In: YES 
user_id=261020

1. Bug is also in 2.2 branch

2. The fix (in 2.1 and 2.2) should reflect the earlier bug fix in the 2.2 branch to add the old headers:

new = Request(newurl, headers=req.headers)

3. I guess 10 should be replaced with 4, not 5.


John


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470


From noreply@sourceforge.net  Sat Apr 26 20:17:05 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 26 Apr 2003 12:17:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-667931 ] BoundaryError: multipart message with no defined boundary
Message-ID: <E199VAX-0002Ok-00@sc8-sf-web1.sourceforge.net>

Bugs item #667931, was opened at 2003-01-14 11:36
Message generated for change (Comment added) made by jasonrm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=667931&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 3
Submitted By: Jason R. Mastaler (jasonrm)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: BoundaryError: multipart message with no defined boundary

Initial Comment:
More problems with the email package raising
exceptions when trying to parse non-compliant
messages.

Even when lax parsing is enabled, a BoundaryError
is raised when trying to parse the attached spam
message.

I'd like to see some sort of workaround to handle these
cases more gracefully when when lax parsing is
enabled.

This behavior seems like 'strict' parsing behavior to me.



----------------------------------------------------------------------

>Comment By: Jason R. Mastaler (jasonrm)
Date: 2003-04-26 13:17

Message:
Logged In: YES 
user_id=85984

I'm unclear what you mean by: 
 
``You can always fall back to email.Header.HeaderParser  
when all else fails'' 
 

----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-03-05 23:31

Message:
Logged In: YES 
user_id=12800

I see what you're saying, Jason, but I don't know how Parser
could do much better.  You can always fall back to
email.Header.HeaderParser when all else fails (well all else
modulo severely broken headers).


----------------------------------------------------------------------

Comment By: Jason R. Mastaler (jasonrm)
Date: 2003-02-20 12:33

Message:
Logged In: YES 
user_id=85984

As Python 2.3a2 was just released, I'm worried that
this one is going to fall through the cracks before
2.3-final is released which would be unfortunate because
it would mean I'd have to continue bundling my own
copy of email with my applications.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=667931&group_id=5470


From noreply@sourceforge.net  Sun Apr 27 00:59:06 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 26 Apr 2003 16:59:06 -0700
Subject: [Python-bugs-list] [ python-Bugs-728101 ] RuntimeError "not holding import lock" with test.autotest
Message-ID: <E199ZZS-00060V-00@sc8-sf-web1.sourceforge.net>

Bugs item #728101, was opened at 2003-04-26 12:45
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728101&group_id=5470

Category: Windows
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Irmen de Jong (irmen)
Assigned to: Tim Peters (tim_one)
Summary: RuntimeError "not holding import lock" with test.autotest

Initial Comment:
(windows XP, python 2.3b)
I get the following error at the end of an "import
test.autotest":

Traceback (most recent call last):
  File "<string>", line 1, in ?
RuntimeError: not holding the import lock

The "test_imp" test failed with the following error:
testLock (test.test_imp.ImpLock) ... ERROR

======================================================================
ERROR: testLock (test.test_imp.ImpLock)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Python23\lib\test\test_imp.py", line 22, in
testLock
    raise TestFailed, \
TestFailed: release_lock() without lock should raise
RuntimeError

----------------------------------------------------------------------
Ran 1 test in 0.000s

FAILED (errors=1)
test test_imp failed -- Traceback (most recent call last):
  File "C:\Python23\lib\test\test_imp.py", line 22, in
testLock
    raise TestFailed, \
TestFailed: release_lock() without lock should raise
RuntimeError


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2003-04-26 19:59

Message:
Logged In: YES 
user_id=31435

Thanks for the report!  I don't believe any developer 
does "import test.autotest", else this would have failed on 
every platform.  I rewrote the test so that it doesn't care 
whether the import lock is already held at the time the test 
starts (it *assumed* the import lock was not held then), 
and that made the problem go away.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728101&group_id=5470


From noreply@sourceforge.net  Sun Apr 27 02:31:00 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 26 Apr 2003 18:31:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-549151 ] urllib2 POSTs on redirect
Message-ID: <E199b0O-0003lI-00@sc8-sf-web3.sourceforge.net>

Bugs item #549151, was opened at 2002-04-26 17:04
Message generated for change (Comment added) made by jjlee
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: Fixed
Priority: 7
Submitted By: John J Lee (jjlee)
Assigned to: Guido van Rossum (gvanrossum)
Summary: urllib2 POSTs on redirect

Initial Comment:

urllib2 (I'm using 1.13.22 with Python 2.0, but I assume the 2.2 branch does the same) uses the 
POST method on redirect, contrary to RFC1945 section 9.3:

> 9.3  Redirection 3xx
> 
>    This class of status code indicates that further action needs to be
>    taken by the user agent in order to fulfill the request. The action
>    required may be carried out by the user agent without interaction
>    with the user if and only if the method used in the subsequent
>    request is GET or HEAD. A user agent should never automatically
>    redirect a request more than 5 times, since such redirections usually
>    indicate an infinite loop.

Can be fixed in HTTPRedirectHandler.http_error_302 by replacing
        new = Request(newurl, req.get_data())

with
        new = Request(newurl)

so that GET is done on redirect instead of POST.

I suppose the limit of 10 in the same function should be changed to 5, also.


----------------------------------------------------------------------

>Comment By: John J Lee (jjlee)
Date: 2003-04-27 02:31

Message:
Logged In: YES 
user_id=261020

The patch for urllib.py is indeed broken, and I think Guido's 
patch is correct.  I agree with the summary Guido gives, which is 
also in agreement with our previous discussion. 
 
A side issue that occurred to me on re-reading the RFC is whether 
301 redirection should be automatic.  A 301 is supposed to 
indicate permanent redirection, so one is supposed to update 
one's URL when a 301 happens. Redirecting automatically doesn't 
allow the user of urllib / urllib2 to do that.  However, I 
suppose that since 2.2 *does* redirect automatically (for both 
urllib and urllib2) it's a bit late to worry about this. 
 
The patched urllib2.py is also broken in two ways: 
 
1. It tries to call req.method() -- which doesn't exist -- rather 
than req.get_method() as it should. 
 
print "Must use pychecker.\n"*100 
 
especially when there are no unit tests... 
 
Anyway, I decided the new get_method method is unnecessary and 
the new patch I'll upload in a minute removes it again. 
 
2. 301 response to POST isn't redirected to GET.  It should be, 
as we agreed earlier. 
 
Just about to upload revised patches, against 2.3beta CVS. 
(urllib2.py.patch2, liburllib2.tex.patch2, liburllib.tex.patch2). 
They need backporting to 2.2 again, too. 
 
Bother. 
 

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-26 18:21

Message:
Logged In: YES 
user_id=6380

Blech! Reopening. I just stumbled upon the relevant part of
RFC 2616, and it suggests to me the following rules when the
original request was a POST. I should have made the time for
this earlier, but I simply didn't have time. :-(

Reference:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3

Summary:

- 307 means repeat the POST to the new URL *after user
confirmation*

- 303 means do a GET to the new URL

- 301 means repeat the POST to the new URL *after user
confirmation*, *but* old agents often do a GET instead

- 302 may be treated the same as 303 (i.e. GET the new URL)
for compatibility with existing practice

This suggests to me that *no* automatic repeat of POST
requests should ever be done, and that in the case of a 302
or 303 response, a POST should be replaced by a GET; this
may also be done for a 301 response -- even though the
standard calls that an error, it admits that it is done by
old clients.

But the new code in urllib.py doesn't seem to do that: it
treats 301, 302 and 303 all the same, doing a POST if the
original request was a POST (POST is determined by 'data is
not None'). And it doesn't redirect on a 307 at all, even
though it should do that if the original request was GET.
The updated documentation describes the desired behavior for
301,302,303.

I think the desired behavior can be obtained by always
omitting the data argument in the call to self.open(newurl)
in redirect_internal(). Then a handler for 307 could be
handled that raises an error if the original request was a
POST, and redirects otherwise. I'm attaching a suggested
patch to urllib.py (guido.txt).

It appears urllib2.py was patched correctly.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-25 09:21

Message:
Logged In: YES 
user_id=80475

Backported to 2.2.3.
Closing bug.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-24 16:49

Message:
Logged In: YES 
user_id=6380

Yes, I think that would be a good idea.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-24 16:34

Message:
Logged In: YES 
user_id=80475

Committed as:

Lib/urllib.py 1.157
Lib/urllib2.py 1.39
Doc/lib/liburllib.tex 1.47
Doc/lib/liburllib2.tex 1.7


Guido, would you like this backported to 2.2.3?

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2003-04-20 21:44

Message:
Logged In: YES 
user_id=261020

Just noticed that I forgot to upload one of the doc patches 
on 2003-03-05.  Here it is. 
 
The patches that need to be applied are the three I 
uploaded on 2003-03-05 (urllib.py.patch, urllib2.py.patch 
and liburllib2.tex.patch), and the liburllib.tex.patch I just 
uploaded. 
 

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-16 21:35

Message:
Logged In: YES 
user_id=6380

I think this is the right thing to do. Can you check it in?
 (There are several files -- urllib, urllib2, and its docs).

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-16 21:27

Message:
Logged In: YES 
user_id=80475

Do you have time to take this one back?  My head starts to 
explode when researching whether this is the right thing 
to do.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-03-07 20:57

Message:
Logged In: YES 
user_id=6380

I'll try to work on this.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2003-03-05 21:03

Message:
Logged In: YES 
user_id=261020

The fix for this was set to go into 2.3, but nothing has  
happened yet. 
 
There were a couple of minor details to be fixed in the 
patches, so I've done that, and uploaded new patches for  
urllib2.py, urllib.py, and their documentation files (against  
current CVS). Well, I'm just about to upload them... 
 
Jeremy, can you apply the patches and finally close this 
one now?  Let me know if anything else needs doing. 
 
This should actually close another bug on SF, too (if it's still 
open), which deals with the urllib.py case.  I can't find it,  
though.  I did attach a comment to it (before I lost it) that 
references this bug. 
 

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-10-15 16:22

Message:
Logged In: YES 
user_id=261020

Well, when I carefully read the RFC I came to the conclusion
that 301 should be redirected to GET, not POST.  I also came
to the conclusion that the RFC was slightly ambiguous on
this point, so I guess that's why A. Flavell came to the
conclusion that 301 should redirect to POST rather than GET.
Anyway, clearly the established practice is to redirect 301
as GET, so this is all academic.

Assuming he's right about Netscape / IE etc., I suppose I'm
happy for 301 to redirect without an exception, since that's
what we've agreed to do for 302.  Obviously, the docs should
say this is contrary to the RFC (as my doc patch says for
302 already).

As for urllib.py, I see the problem.  303 should still be
added, though, since that poses no problem at all.


John


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-10-11 16:40

Message:
Logged In: YES 
user_id=31392

I'm still uncertain about what to do on 301 responses.  As
you say, there are two issues to sort out: 1) what method
should a POST be redicted to and 2) whether the user should
be asked to confirm.

There's discussion of this at:
http://ppewww.ph.gla.ac.uk/~flavell/www/post-redirect.html
The page is a bit old, but I don't know if it is out of date.
It says that IE5, Netscape 4, and Mozilla 1.0 all redirect a
301 POST to a GET without user confirmation.  That seems
like a widespread disregard for the spec that we ought to
emulate.

I agree with your interpretation that urllib2 raise an
HTTPError to signal "request confirm" because an HTTPError
is also a valid response that the user could interpret.  But
of urllib, an HTTP error doesn't contain a valid response. 
The change would make it impossible for the client to do
anything if a 301 response is returned from a POST.  That
seems worse than doing the wrong.



----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-10-10 02:27

Message:
Logged In: YES 
user_id=6380

OK, over to jeremy.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-10-09 22:16

Message:
Logged In: YES 
user_id=261020

Ah.  Here it is.

John


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-10-08 19:23

Message:
Logged In: YES 
user_id=6380

Um, I don't see the patch for urllib.py.  Perhaps you didn't
check the box?

Jeremy, let's do this in 2.3, OK?

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-10-08 17:53

Message:
Logged In: YES 
user_id=261020

Guido mentioned that urllib.py should be fixed
too.  I've attached another patch.


John


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-10-05 18:44

Message:
Logged In: YES 
user_id=261020

Here is a patch for the minor documentation changes required
for the patch I uploaded earlier to fix this bug.  I've also
uploaded a slightly revised patch:

I renamed the `method' method to `get_method' for
consistency with the other methods of the Request class.
The reason this new method is there at all is because the
logic that decides whether or not a redirection should take
place is defined in terms of the method type
(GET/HEAD/POST).  urllib2 doesn't support HEAD ATM, but it
might in future.  OTOH, the Request class is supposed to be
generic -- not specific to HTTP -- so perhaps get_method
isn't really appropriate.  OTOOH, add_data is already
documented to only be meaningful for HTTP Requests.  I
suppose there could be a subclass HTTPRequest, but that's
less simple.  What do you think is best?

I also changed redirect_request to raise an exception
instead of returning None (because no other Handler should
handle the redirect), and changed its documented return
value / exception interface to be consistent with the rest
of urllib2.


John


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-06-23 20:23

Message:
Logged In: YES 
user_id=261020

First, can I underline the fact that there are two issues
here:

  1. What method should POST be redirected as for a
     particular 30x response?

  2. Should the user be asked to confirm the redirection
     (which presumably maps onto raising an HTTPError in
     urllib2)?

I think current client implementations go against the RFCs
on both these points for 302.  Contrastingly, RFC 2616's
note on 301 responses (section 10.3.2) implies that only a
subset of HTTP/1.0 (not 1.1, note) clients violate the RFCs
(1945, 2068, 2616) on point 1 for 301 responses, and I know
of no clients that violate the RFCs on point 2 for 301
responses (but I haven't tested).  Also, I guess the
original intent (for both 301 and 302) was that POSTs
represent an action, so it's dangerous in general to
redirect them without asking the user: I presume this is why
307 was brought in: 307 POSTs on redirected POST, so the
user must be asked:

10.3 Redirection 3xx
[...]
   The action required MAY be carried out by the user agent
   without interaction with the user if and only if the
   method used in the second request is GET or HEAD.

(and 303 is just meant to have the 'erroneous' 302
behaviour: GET on redirected POST, don't ask the user)

So, I agree with Guido that 302 should probably now be
treated the way most clients treat it: GET on redirected
POST, don't ask the user.  As for 301, if it *is* true that
only a few HTTP/1.0 clients have misinterpreted the RFCs on
301, we should stick to the safe behaviour indicated by the
RFC.

As for Guido's first question: A 307 should indeed be
redirected as a POST, but it should ask the user first (see
10.3 quote, above).  That's what my patch does (the 'return
None' in the else clause in redirect_request causes an
exception to be raised eventually -- maybe it should just
raise it itself).

I've attached a revised patch that deals with 302 (and 303)
in the 'erroneous' way (again: GET on redirected POST, don't
ask the user).

I suppose the comment about HTTPRedirectHandler also needs
to state that 301 and 307 POST requests are not
automatically redirected -- HTTPError is raised in that
case.


John


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-20 01:57

Message:
Logged In: YES 
user_id=6380

Hm, I thought that 307 should be treated differently than
303. In particular, a 307 response to POST should cause the
POST to be redirected. And I'm not sure about what a 301
response to POST should do.

(In the mean time I have been convinced that changing POST
to GET on 302 is the best thing to do given that most
browsers do that. The old urllib.py should be fixed too.)

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-06-19 22:57

Message:
Logged In: YES 
user_id=261020

I've attached a patch -- was simpler than I thought.

I think this is in compliance with RFC 2616.  It's also
simple for clients to inherit from HTTPRedirectHandler and
override redirect_request if, for example, they know they
want all 302 POSTs to be redirected as a GET, which removes
the need for mixing redirection code with normal client code
even when the server doesn't follow the RFC (if the server
expects a 302 POST to be redirected as a GET, for example).
Note that I had to add a method, named 'method', to the
Request class, for maintainability (it's possible that
urllib2 may be able to do methods other than GET and POST in
future).

Possibly redirect_request should take fewer parameters.

John


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-06-19 22:56

Message:
Logged In: YES 
user_id=261020

I've attached a patch -- was simpler than I thought.

I think this is in compliance with RFC 2616.  It's also
simple for clients to inherit from HTTPRedirectHandler and
override redirect_request if, for example, they know they
want all 302 POSTs to be redirected as a GET, which removes
the need for mixing redirection code with normal client code
even when the server doesn't follow the RFC (if the server
expects a 302 POST to be redirected as a GET, for example).
Note that I had to add a method, named 'method', to the
Request class, for maintainability (it's possible that
urllib2 may be able to do methods other than GET and POST in
future).

Possibly redirect_request should take fewer parameters.

John


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-06-06 22:25

Message:
Logged In: YES 
user_id=261020

Oh, I hadn't realised httplib uses HTTP/1.1 now -- and now I
check, I see that even RFC 1945 (HTTP/1.0) has a whole set of
restrictions on 30x for particular values of x which I missed
completely.

I guess it should do what Guido suggested -- report an error if a
POST is redirected -- until somebody gets time to do it properly.
I won't have time for a couple of months, but if nobody has done
it by then I'll upload a patch.


John


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-06-06 16:09

Message:
Logged In: YES 
user_id=31392

I think you need to review the current HTTP spec -- RFC 2616
-- and look at the section on redirection (10.3).  I think
urllib2 could improve its handling of redirection, but the
behavior you describe from lynx sounds incorrect.  I'd be
happy to review a patch the implemented the current spec.

Also, RFC 2616 removes the recommendation of a 5 redirect limit.




----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-29 19:10

Message:
Logged In: YES 
user_id=6380

Fair enough. I'll leve it to Jeremy to review the proposed
fix. (Note that he's busy though.)

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-04-29 17:29

Message:
Logged In: YES 
user_id=261020

I don't see why it shouldn't substitue a GET.  That certainly seems to be
the standard practice (well, at least that's what lynx does), and in the case
of the only site where I've encountered redirects on POST, the redirect URL
contains urlencoded stuff, so it clearly expects the user-agent to do a GET.
The site would break if this didn't happen, so I guess Netscape and IE must
do the same thing.

Clearly the RFC *does* allow this, though it doesn't require it (or specify
what should happen here in any way other than to say that a POST is not
allowed, in fact).  Since it's standard practice and allowed by the RFC, I
don't think it should be an error.

John


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-29 01:53

Message:
Logged In: YES 
user_id=6380

Hm, the way I interpret the text you quote, if the original
request is  a POST, it should probably not substitute a GET
but report the error.

Assigning to Jeremy since it's his module.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-04-28 17:21

Message:
Logged In: YES 
user_id=261020

1. Bug is also in 2.2 branch

2. The fix (in 2.1 and 2.2) should reflect the earlier bug fix in the 2.2 branch to add the old headers:

new = Request(newurl, headers=req.headers)

3. I guess 10 should be replaced with 4, not 5.


John


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470


From noreply@sourceforge.net  Sun Apr 27 02:31:19 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 26 Apr 2003 18:31:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-549151 ] urllib2 POSTs on redirect
Message-ID: <E199b0h-0003lh-00@sc8-sf-web3.sourceforge.net>

Bugs item #549151, was opened at 2002-04-26 17:04
Message generated for change (Comment added) made by jjlee
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: Fixed
Priority: 7
Submitted By: John J Lee (jjlee)
Assigned to: Guido van Rossum (gvanrossum)
Summary: urllib2 POSTs on redirect

Initial Comment:

urllib2 (I'm using 1.13.22 with Python 2.0, but I assume the 2.2 branch does the same) uses the 
POST method on redirect, contrary to RFC1945 section 9.3:

> 9.3  Redirection 3xx
> 
>    This class of status code indicates that further action needs to be
>    taken by the user agent in order to fulfill the request. The action
>    required may be carried out by the user agent without interaction
>    with the user if and only if the method used in the subsequent
>    request is GET or HEAD. A user agent should never automatically
>    redirect a request more than 5 times, since such redirections usually
>    indicate an infinite loop.

Can be fixed in HTTPRedirectHandler.http_error_302 by replacing
        new = Request(newurl, req.get_data())

with
        new = Request(newurl)

so that GET is done on redirect instead of POST.

I suppose the limit of 10 in the same function should be changed to 5, also.


----------------------------------------------------------------------

>Comment By: John J Lee (jjlee)
Date: 2003-04-27 02:31

Message:
Logged In: YES 
user_id=261020

The patch for urllib.py is indeed broken, and I think Guido's 
patch is correct.  I agree with the summary Guido gives, which is 
also in agreement with our previous discussion. 
 
A side issue that occurred to me on re-reading the RFC is whether 
301 redirection should be automatic.  A 301 is supposed to 
indicate permanent redirection, so one is supposed to update 
one's URL when a 301 happens. Redirecting automatically doesn't 
allow the user of urllib / urllib2 to do that.  However, I 
suppose that since 2.2 *does* redirect automatically (for both 
urllib and urllib2) it's a bit late to worry about this. 
 
The patched urllib2.py is also broken in two ways: 
 
1. It tries to call req.method() -- which doesn't exist -- rather 
than req.get_method() as it should. 
 
print "Must use pychecker.\n"*100 
 
especially when there are no unit tests... 
 
Anyway, I decided the new get_method method is unnecessary and 
the new patch I'll upload in a minute removes it again. 
 
2. 301 response to POST isn't redirected to GET.  It should be, 
as we agreed earlier. 
 
Just about to upload revised patches, against 2.3beta CVS. 
(urllib2.py.patch2, liburllib2.tex.patch2, liburllib.tex.patch2). 
They need backporting to 2.2 again, too. 
 
Bother. 
 

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2003-04-27 02:31

Message:
Logged In: YES 
user_id=261020

The patch for urllib.py is indeed broken, and I think Guido's 
patch is correct.  I agree with the summary Guido gives, which is 
also in agreement with our previous discussion. 
 
A side issue that occurred to me on re-reading the RFC is whether 
301 redirection should be automatic.  A 301 is supposed to 
indicate permanent redirection, so one is supposed to update 
one's URL when a 301 happens. Redirecting automatically doesn't 
allow the user of urllib / urllib2 to do that.  However, I 
suppose that since 2.2 *does* redirect automatically (for both 
urllib and urllib2) it's a bit late to worry about this. 
 
The patched urllib2.py is also broken in two ways: 
 
1. It tries to call req.method() -- which doesn't exist -- rather 
than req.get_method() as it should. 
 
print "Must use pychecker.\n"*100 
 
especially when there are no unit tests... 
 
Anyway, I decided the new get_method method is unnecessary and 
the new patch I'll upload in a minute removes it again. 
 
2. 301 response to POST isn't redirected to GET.  It should be, 
as we agreed earlier. 
 
Just about to upload revised patches, against 2.3beta CVS. 
(urllib2.py.patch2, liburllib2.tex.patch2, liburllib.tex.patch2). 
They need backporting to 2.2 again, too. 
 
Bother. 
 

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-26 18:21

Message:
Logged In: YES 
user_id=6380

Blech! Reopening. I just stumbled upon the relevant part of
RFC 2616, and it suggests to me the following rules when the
original request was a POST. I should have made the time for
this earlier, but I simply didn't have time. :-(

Reference:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3

Summary:

- 307 means repeat the POST to the new URL *after user
confirmation*

- 303 means do a GET to the new URL

- 301 means repeat the POST to the new URL *after user
confirmation*, *but* old agents often do a GET instead

- 302 may be treated the same as 303 (i.e. GET the new URL)
for compatibility with existing practice

This suggests to me that *no* automatic repeat of POST
requests should ever be done, and that in the case of a 302
or 303 response, a POST should be replaced by a GET; this
may also be done for a 301 response -- even though the
standard calls that an error, it admits that it is done by
old clients.

But the new code in urllib.py doesn't seem to do that: it
treats 301, 302 and 303 all the same, doing a POST if the
original request was a POST (POST is determined by 'data is
not None'). And it doesn't redirect on a 307 at all, even
though it should do that if the original request was GET.
The updated documentation describes the desired behavior for
301,302,303.

I think the desired behavior can be obtained by always
omitting the data argument in the call to self.open(newurl)
in redirect_internal(). Then a handler for 307 could be
handled that raises an error if the original request was a
POST, and redirects otherwise. I'm attaching a suggested
patch to urllib.py (guido.txt).

It appears urllib2.py was patched correctly.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-25 09:21

Message:
Logged In: YES 
user_id=80475

Backported to 2.2.3.
Closing bug.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-24 16:49

Message:
Logged In: YES 
user_id=6380

Yes, I think that would be a good idea.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-24 16:34

Message:
Logged In: YES 
user_id=80475

Committed as:

Lib/urllib.py 1.157
Lib/urllib2.py 1.39
Doc/lib/liburllib.tex 1.47
Doc/lib/liburllib2.tex 1.7


Guido, would you like this backported to 2.2.3?

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2003-04-20 21:44

Message:
Logged In: YES 
user_id=261020

Just noticed that I forgot to upload one of the doc patches 
on 2003-03-05.  Here it is. 
 
The patches that need to be applied are the three I 
uploaded on 2003-03-05 (urllib.py.patch, urllib2.py.patch 
and liburllib2.tex.patch), and the liburllib.tex.patch I just 
uploaded. 
 

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-16 21:35

Message:
Logged In: YES 
user_id=6380

I think this is the right thing to do. Can you check it in?
 (There are several files -- urllib, urllib2, and its docs).

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-16 21:27

Message:
Logged In: YES 
user_id=80475

Do you have time to take this one back?  My head starts to 
explode when researching whether this is the right thing 
to do.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-03-07 20:57

Message:
Logged In: YES 
user_id=6380

I'll try to work on this.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2003-03-05 21:03

Message:
Logged In: YES 
user_id=261020

The fix for this was set to go into 2.3, but nothing has  
happened yet. 
 
There were a couple of minor details to be fixed in the 
patches, so I've done that, and uploaded new patches for  
urllib2.py, urllib.py, and their documentation files (against  
current CVS). Well, I'm just about to upload them... 
 
Jeremy, can you apply the patches and finally close this 
one now?  Let me know if anything else needs doing. 
 
This should actually close another bug on SF, too (if it's still 
open), which deals with the urllib.py case.  I can't find it,  
though.  I did attach a comment to it (before I lost it) that 
references this bug. 
 

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-10-15 16:22

Message:
Logged In: YES 
user_id=261020

Well, when I carefully read the RFC I came to the conclusion
that 301 should be redirected to GET, not POST.  I also came
to the conclusion that the RFC was slightly ambiguous on
this point, so I guess that's why A. Flavell came to the
conclusion that 301 should redirect to POST rather than GET.
Anyway, clearly the established practice is to redirect 301
as GET, so this is all academic.

Assuming he's right about Netscape / IE etc., I suppose I'm
happy for 301 to redirect without an exception, since that's
what we've agreed to do for 302.  Obviously, the docs should
say this is contrary to the RFC (as my doc patch says for
302 already).

As for urllib.py, I see the problem.  303 should still be
added, though, since that poses no problem at all.


John


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-10-11 16:40

Message:
Logged In: YES 
user_id=31392

I'm still uncertain about what to do on 301 responses.  As
you say, there are two issues to sort out: 1) what method
should a POST be redicted to and 2) whether the user should
be asked to confirm.

There's discussion of this at:
http://ppewww.ph.gla.ac.uk/~flavell/www/post-redirect.html
The page is a bit old, but I don't know if it is out of date.
It says that IE5, Netscape 4, and Mozilla 1.0 all redirect a
301 POST to a GET without user confirmation.  That seems
like a widespread disregard for the spec that we ought to
emulate.

I agree with your interpretation that urllib2 raise an
HTTPError to signal "request confirm" because an HTTPError
is also a valid response that the user could interpret.  But
of urllib, an HTTP error doesn't contain a valid response. 
The change would make it impossible for the client to do
anything if a 301 response is returned from a POST.  That
seems worse than doing the wrong.



----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-10-10 02:27

Message:
Logged In: YES 
user_id=6380

OK, over to jeremy.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-10-09 22:16

Message:
Logged In: YES 
user_id=261020

Ah.  Here it is.

John


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-10-08 19:23

Message:
Logged In: YES 
user_id=6380

Um, I don't see the patch for urllib.py.  Perhaps you didn't
check the box?

Jeremy, let's do this in 2.3, OK?

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-10-08 17:53

Message:
Logged In: YES 
user_id=261020

Guido mentioned that urllib.py should be fixed
too.  I've attached another patch.


John


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-10-05 18:44

Message:
Logged In: YES 
user_id=261020

Here is a patch for the minor documentation changes required
for the patch I uploaded earlier to fix this bug.  I've also
uploaded a slightly revised patch:

I renamed the `method' method to `get_method' for
consistency with the other methods of the Request class.
The reason this new method is there at all is because the
logic that decides whether or not a redirection should take
place is defined in terms of the method type
(GET/HEAD/POST).  urllib2 doesn't support HEAD ATM, but it
might in future.  OTOH, the Request class is supposed to be
generic -- not specific to HTTP -- so perhaps get_method
isn't really appropriate.  OTOOH, add_data is already
documented to only be meaningful for HTTP Requests.  I
suppose there could be a subclass HTTPRequest, but that's
less simple.  What do you think is best?

I also changed redirect_request to raise an exception
instead of returning None (because no other Handler should
handle the redirect), and changed its documented return
value / exception interface to be consistent with the rest
of urllib2.


John


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-06-23 20:23

Message:
Logged In: YES 
user_id=261020

First, can I underline the fact that there are two issues
here:

  1. What method should POST be redirected as for a
     particular 30x response?

  2. Should the user be asked to confirm the redirection
     (which presumably maps onto raising an HTTPError in
     urllib2)?

I think current client implementations go against the RFCs
on both these points for 302.  Contrastingly, RFC 2616's
note on 301 responses (section 10.3.2) implies that only a
subset of HTTP/1.0 (not 1.1, note) clients violate the RFCs
(1945, 2068, 2616) on point 1 for 301 responses, and I know
of no clients that violate the RFCs on point 2 for 301
responses (but I haven't tested).  Also, I guess the
original intent (for both 301 and 302) was that POSTs
represent an action, so it's dangerous in general to
redirect them without asking the user: I presume this is why
307 was brought in: 307 POSTs on redirected POST, so the
user must be asked:

10.3 Redirection 3xx
[...]
   The action required MAY be carried out by the user agent
   without interaction with the user if and only if the
   method used in the second request is GET or HEAD.

(and 303 is just meant to have the 'erroneous' 302
behaviour: GET on redirected POST, don't ask the user)

So, I agree with Guido that 302 should probably now be
treated the way most clients treat it: GET on redirected
POST, don't ask the user.  As for 301, if it *is* true that
only a few HTTP/1.0 clients have misinterpreted the RFCs on
301, we should stick to the safe behaviour indicated by the
RFC.

As for Guido's first question: A 307 should indeed be
redirected as a POST, but it should ask the user first (see
10.3 quote, above).  That's what my patch does (the 'return
None' in the else clause in redirect_request causes an
exception to be raised eventually -- maybe it should just
raise it itself).

I've attached a revised patch that deals with 302 (and 303)
in the 'erroneous' way (again: GET on redirected POST, don't
ask the user).

I suppose the comment about HTTPRedirectHandler also needs
to state that 301 and 307 POST requests are not
automatically redirected -- HTTPError is raised in that
case.


John


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-20 01:57

Message:
Logged In: YES 
user_id=6380

Hm, I thought that 307 should be treated differently than
303. In particular, a 307 response to POST should cause the
POST to be redirected. And I'm not sure about what a 301
response to POST should do.

(In the mean time I have been convinced that changing POST
to GET on 302 is the best thing to do given that most
browsers do that. The old urllib.py should be fixed too.)

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-06-19 22:57

Message:
Logged In: YES 
user_id=261020

I've attached a patch -- was simpler than I thought.

I think this is in compliance with RFC 2616.  It's also
simple for clients to inherit from HTTPRedirectHandler and
override redirect_request if, for example, they know they
want all 302 POSTs to be redirected as a GET, which removes
the need for mixing redirection code with normal client code
even when the server doesn't follow the RFC (if the server
expects a 302 POST to be redirected as a GET, for example).
Note that I had to add a method, named 'method', to the
Request class, for maintainability (it's possible that
urllib2 may be able to do methods other than GET and POST in
future).

Possibly redirect_request should take fewer parameters.

John


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-06-19 22:56

Message:
Logged In: YES 
user_id=261020

I've attached a patch -- was simpler than I thought.

I think this is in compliance with RFC 2616.  It's also
simple for clients to inherit from HTTPRedirectHandler and
override redirect_request if, for example, they know they
want all 302 POSTs to be redirected as a GET, which removes
the need for mixing redirection code with normal client code
even when the server doesn't follow the RFC (if the server
expects a 302 POST to be redirected as a GET, for example).
Note that I had to add a method, named 'method', to the
Request class, for maintainability (it's possible that
urllib2 may be able to do methods other than GET and POST in
future).

Possibly redirect_request should take fewer parameters.

John


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-06-06 22:25

Message:
Logged In: YES 
user_id=261020

Oh, I hadn't realised httplib uses HTTP/1.1 now -- and now I
check, I see that even RFC 1945 (HTTP/1.0) has a whole set of
restrictions on 30x for particular values of x which I missed
completely.

I guess it should do what Guido suggested -- report an error if a
POST is redirected -- until somebody gets time to do it properly.
I won't have time for a couple of months, but if nobody has done
it by then I'll upload a patch.


John


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-06-06 16:09

Message:
Logged In: YES 
user_id=31392

I think you need to review the current HTTP spec -- RFC 2616
-- and look at the section on redirection (10.3).  I think
urllib2 could improve its handling of redirection, but the
behavior you describe from lynx sounds incorrect.  I'd be
happy to review a patch the implemented the current spec.

Also, RFC 2616 removes the recommendation of a 5 redirect limit.




----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-29 19:10

Message:
Logged In: YES 
user_id=6380

Fair enough. I'll leve it to Jeremy to review the proposed
fix. (Note that he's busy though.)

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-04-29 17:29

Message:
Logged In: YES 
user_id=261020

I don't see why it shouldn't substitue a GET.  That certainly seems to be
the standard practice (well, at least that's what lynx does), and in the case
of the only site where I've encountered redirects on POST, the redirect URL
contains urlencoded stuff, so it clearly expects the user-agent to do a GET.
The site would break if this didn't happen, so I guess Netscape and IE must
do the same thing.

Clearly the RFC *does* allow this, though it doesn't require it (or specify
what should happen here in any way other than to say that a POST is not
allowed, in fact).  Since it's standard practice and allowed by the RFC, I
don't think it should be an error.

John


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-29 01:53

Message:
Logged In: YES 
user_id=6380

Hm, the way I interpret the text you quote, if the original
request is  a POST, it should probably not substitute a GET
but report the error.

Assigning to Jeremy since it's his module.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-04-28 17:21

Message:
Logged In: YES 
user_id=261020

1. Bug is also in 2.2 branch

2. The fix (in 2.1 and 2.2) should reflect the earlier bug fix in the 2.2 branch to add the old headers:

new = Request(newurl, headers=req.headers)

3. I guess 10 should be replaced with 4, not 5.


John


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470


From noreply@sourceforge.net  Sun Apr 27 02:33:41 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 26 Apr 2003 18:33:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-549151 ] urllib2 POSTs on redirect
Message-ID: <E199b2z-0003qj-00@sc8-sf-web3.sourceforge.net>

Bugs item #549151, was opened at 2002-04-26 17:04
Message generated for change (Comment added) made by jjlee
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: Fixed
Priority: 7
Submitted By: John J Lee (jjlee)
Assigned to: Guido van Rossum (gvanrossum)
Summary: urllib2 POSTs on redirect

Initial Comment:

urllib2 (I'm using 1.13.22 with Python 2.0, but I assume the 2.2 branch does the same) uses the 
POST method on redirect, contrary to RFC1945 section 9.3:

> 9.3  Redirection 3xx
> 
>    This class of status code indicates that further action needs to be
>    taken by the user agent in order to fulfill the request. The action
>    required may be carried out by the user agent without interaction
>    with the user if and only if the method used in the subsequent
>    request is GET or HEAD. A user agent should never automatically
>    redirect a request more than 5 times, since such redirections usually
>    indicate an infinite loop.

Can be fixed in HTTPRedirectHandler.http_error_302 by replacing
        new = Request(newurl, req.get_data())

with
        new = Request(newurl)

so that GET is done on redirect instead of POST.

I suppose the limit of 10 in the same function should be changed to 5, also.


----------------------------------------------------------------------

>Comment By: John J Lee (jjlee)
Date: 2003-04-27 02:33

Message:
Logged In: YES 
user_id=261020

Damn this SF bug system. 
 

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2003-04-27 02:31

Message:
Logged In: YES 
user_id=261020

The patch for urllib.py is indeed broken, and I think Guido's 
patch is correct.  I agree with the summary Guido gives, which is 
also in agreement with our previous discussion. 
 
A side issue that occurred to me on re-reading the RFC is whether 
301 redirection should be automatic.  A 301 is supposed to 
indicate permanent redirection, so one is supposed to update 
one's URL when a 301 happens. Redirecting automatically doesn't 
allow the user of urllib / urllib2 to do that.  However, I 
suppose that since 2.2 *does* redirect automatically (for both 
urllib and urllib2) it's a bit late to worry about this. 
 
The patched urllib2.py is also broken in two ways: 
 
1. It tries to call req.method() -- which doesn't exist -- rather 
than req.get_method() as it should. 
 
print "Must use pychecker.\n"*100 
 
especially when there are no unit tests... 
 
Anyway, I decided the new get_method method is unnecessary and 
the new patch I'll upload in a minute removes it again. 
 
2. 301 response to POST isn't redirected to GET.  It should be, 
as we agreed earlier. 
 
Just about to upload revised patches, against 2.3beta CVS. 
(urllib2.py.patch2, liburllib2.tex.patch2, liburllib.tex.patch2). 
They need backporting to 2.2 again, too. 
 
Bother. 
 

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2003-04-27 02:31

Message:
Logged In: YES 
user_id=261020

The patch for urllib.py is indeed broken, and I think Guido's 
patch is correct.  I agree with the summary Guido gives, which is 
also in agreement with our previous discussion. 
 
A side issue that occurred to me on re-reading the RFC is whether 
301 redirection should be automatic.  A 301 is supposed to 
indicate permanent redirection, so one is supposed to update 
one's URL when a 301 happens. Redirecting automatically doesn't 
allow the user of urllib / urllib2 to do that.  However, I 
suppose that since 2.2 *does* redirect automatically (for both 
urllib and urllib2) it's a bit late to worry about this. 
 
The patched urllib2.py is also broken in two ways: 
 
1. It tries to call req.method() -- which doesn't exist -- rather 
than req.get_method() as it should. 
 
print "Must use pychecker.\n"*100 
 
especially when there are no unit tests... 
 
Anyway, I decided the new get_method method is unnecessary and 
the new patch I'll upload in a minute removes it again. 
 
2. 301 response to POST isn't redirected to GET.  It should be, 
as we agreed earlier. 
 
Just about to upload revised patches, against 2.3beta CVS. 
(urllib2.py.patch2, liburllib2.tex.patch2, liburllib.tex.patch2). 
They need backporting to 2.2 again, too. 
 
Bother. 
 

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-26 18:21

Message:
Logged In: YES 
user_id=6380

Blech! Reopening. I just stumbled upon the relevant part of
RFC 2616, and it suggests to me the following rules when the
original request was a POST. I should have made the time for
this earlier, but I simply didn't have time. :-(

Reference:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3

Summary:

- 307 means repeat the POST to the new URL *after user
confirmation*

- 303 means do a GET to the new URL

- 301 means repeat the POST to the new URL *after user
confirmation*, *but* old agents often do a GET instead

- 302 may be treated the same as 303 (i.e. GET the new URL)
for compatibility with existing practice

This suggests to me that *no* automatic repeat of POST
requests should ever be done, and that in the case of a 302
or 303 response, a POST should be replaced by a GET; this
may also be done for a 301 response -- even though the
standard calls that an error, it admits that it is done by
old clients.

But the new code in urllib.py doesn't seem to do that: it
treats 301, 302 and 303 all the same, doing a POST if the
original request was a POST (POST is determined by 'data is
not None'). And it doesn't redirect on a 307 at all, even
though it should do that if the original request was GET.
The updated documentation describes the desired behavior for
301,302,303.

I think the desired behavior can be obtained by always
omitting the data argument in the call to self.open(newurl)
in redirect_internal(). Then a handler for 307 could be
handled that raises an error if the original request was a
POST, and redirects otherwise. I'm attaching a suggested
patch to urllib.py (guido.txt).

It appears urllib2.py was patched correctly.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-25 09:21

Message:
Logged In: YES 
user_id=80475

Backported to 2.2.3.
Closing bug.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-24 16:49

Message:
Logged In: YES 
user_id=6380

Yes, I think that would be a good idea.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-24 16:34

Message:
Logged In: YES 
user_id=80475

Committed as:

Lib/urllib.py 1.157
Lib/urllib2.py 1.39
Doc/lib/liburllib.tex 1.47
Doc/lib/liburllib2.tex 1.7


Guido, would you like this backported to 2.2.3?

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2003-04-20 21:44

Message:
Logged In: YES 
user_id=261020

Just noticed that I forgot to upload one of the doc patches 
on 2003-03-05.  Here it is. 
 
The patches that need to be applied are the three I 
uploaded on 2003-03-05 (urllib.py.patch, urllib2.py.patch 
and liburllib2.tex.patch), and the liburllib.tex.patch I just 
uploaded. 
 

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-16 21:35

Message:
Logged In: YES 
user_id=6380

I think this is the right thing to do. Can you check it in?
 (There are several files -- urllib, urllib2, and its docs).

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-16 21:27

Message:
Logged In: YES 
user_id=80475

Do you have time to take this one back?  My head starts to 
explode when researching whether this is the right thing 
to do.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-03-07 20:57

Message:
Logged In: YES 
user_id=6380

I'll try to work on this.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2003-03-05 21:03

Message:
Logged In: YES 
user_id=261020

The fix for this was set to go into 2.3, but nothing has  
happened yet. 
 
There were a couple of minor details to be fixed in the 
patches, so I've done that, and uploaded new patches for  
urllib2.py, urllib.py, and their documentation files (against  
current CVS). Well, I'm just about to upload them... 
 
Jeremy, can you apply the patches and finally close this 
one now?  Let me know if anything else needs doing. 
 
This should actually close another bug on SF, too (if it's still 
open), which deals with the urllib.py case.  I can't find it,  
though.  I did attach a comment to it (before I lost it) that 
references this bug. 
 

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-10-15 16:22

Message:
Logged In: YES 
user_id=261020

Well, when I carefully read the RFC I came to the conclusion
that 301 should be redirected to GET, not POST.  I also came
to the conclusion that the RFC was slightly ambiguous on
this point, so I guess that's why A. Flavell came to the
conclusion that 301 should redirect to POST rather than GET.
Anyway, clearly the established practice is to redirect 301
as GET, so this is all academic.

Assuming he's right about Netscape / IE etc., I suppose I'm
happy for 301 to redirect without an exception, since that's
what we've agreed to do for 302.  Obviously, the docs should
say this is contrary to the RFC (as my doc patch says for
302 already).

As for urllib.py, I see the problem.  303 should still be
added, though, since that poses no problem at all.


John


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-10-11 16:40

Message:
Logged In: YES 
user_id=31392

I'm still uncertain about what to do on 301 responses.  As
you say, there are two issues to sort out: 1) what method
should a POST be redicted to and 2) whether the user should
be asked to confirm.

There's discussion of this at:
http://ppewww.ph.gla.ac.uk/~flavell/www/post-redirect.html
The page is a bit old, but I don't know if it is out of date.
It says that IE5, Netscape 4, and Mozilla 1.0 all redirect a
301 POST to a GET without user confirmation.  That seems
like a widespread disregard for the spec that we ought to
emulate.

I agree with your interpretation that urllib2 raise an
HTTPError to signal "request confirm" because an HTTPError
is also a valid response that the user could interpret.  But
of urllib, an HTTP error doesn't contain a valid response. 
The change would make it impossible for the client to do
anything if a 301 response is returned from a POST.  That
seems worse than doing the wrong.



----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-10-10 02:27

Message:
Logged In: YES 
user_id=6380

OK, over to jeremy.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-10-09 22:16

Message:
Logged In: YES 
user_id=261020

Ah.  Here it is.

John


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-10-08 19:23

Message:
Logged In: YES 
user_id=6380

Um, I don't see the patch for urllib.py.  Perhaps you didn't
check the box?

Jeremy, let's do this in 2.3, OK?

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-10-08 17:53

Message:
Logged In: YES 
user_id=261020

Guido mentioned that urllib.py should be fixed
too.  I've attached another patch.


John


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-10-05 18:44

Message:
Logged In: YES 
user_id=261020

Here is a patch for the minor documentation changes required
for the patch I uploaded earlier to fix this bug.  I've also
uploaded a slightly revised patch:

I renamed the `method' method to `get_method' for
consistency with the other methods of the Request class.
The reason this new method is there at all is because the
logic that decides whether or not a redirection should take
place is defined in terms of the method type
(GET/HEAD/POST).  urllib2 doesn't support HEAD ATM, but it
might in future.  OTOH, the Request class is supposed to be
generic -- not specific to HTTP -- so perhaps get_method
isn't really appropriate.  OTOOH, add_data is already
documented to only be meaningful for HTTP Requests.  I
suppose there could be a subclass HTTPRequest, but that's
less simple.  What do you think is best?

I also changed redirect_request to raise an exception
instead of returning None (because no other Handler should
handle the redirect), and changed its documented return
value / exception interface to be consistent with the rest
of urllib2.


John


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-06-23 20:23

Message:
Logged In: YES 
user_id=261020

First, can I underline the fact that there are two issues
here:

  1. What method should POST be redirected as for a
     particular 30x response?

  2. Should the user be asked to confirm the redirection
     (which presumably maps onto raising an HTTPError in
     urllib2)?

I think current client implementations go against the RFCs
on both these points for 302.  Contrastingly, RFC 2616's
note on 301 responses (section 10.3.2) implies that only a
subset of HTTP/1.0 (not 1.1, note) clients violate the RFCs
(1945, 2068, 2616) on point 1 for 301 responses, and I know
of no clients that violate the RFCs on point 2 for 301
responses (but I haven't tested).  Also, I guess the
original intent (for both 301 and 302) was that POSTs
represent an action, so it's dangerous in general to
redirect them without asking the user: I presume this is why
307 was brought in: 307 POSTs on redirected POST, so the
user must be asked:

10.3 Redirection 3xx
[...]
   The action required MAY be carried out by the user agent
   without interaction with the user if and only if the
   method used in the second request is GET or HEAD.

(and 303 is just meant to have the 'erroneous' 302
behaviour: GET on redirected POST, don't ask the user)

So, I agree with Guido that 302 should probably now be
treated the way most clients treat it: GET on redirected
POST, don't ask the user.  As for 301, if it *is* true that
only a few HTTP/1.0 clients have misinterpreted the RFCs on
301, we should stick to the safe behaviour indicated by the
RFC.

As for Guido's first question: A 307 should indeed be
redirected as a POST, but it should ask the user first (see
10.3 quote, above).  That's what my patch does (the 'return
None' in the else clause in redirect_request causes an
exception to be raised eventually -- maybe it should just
raise it itself).

I've attached a revised patch that deals with 302 (and 303)
in the 'erroneous' way (again: GET on redirected POST, don't
ask the user).

I suppose the comment about HTTPRedirectHandler also needs
to state that 301 and 307 POST requests are not
automatically redirected -- HTTPError is raised in that
case.


John


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-20 01:57

Message:
Logged In: YES 
user_id=6380

Hm, I thought that 307 should be treated differently than
303. In particular, a 307 response to POST should cause the
POST to be redirected. And I'm not sure about what a 301
response to POST should do.

(In the mean time I have been convinced that changing POST
to GET on 302 is the best thing to do given that most
browsers do that. The old urllib.py should be fixed too.)

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-06-19 22:57

Message:
Logged In: YES 
user_id=261020

I've attached a patch -- was simpler than I thought.

I think this is in compliance with RFC 2616.  It's also
simple for clients to inherit from HTTPRedirectHandler and
override redirect_request if, for example, they know they
want all 302 POSTs to be redirected as a GET, which removes
the need for mixing redirection code with normal client code
even when the server doesn't follow the RFC (if the server
expects a 302 POST to be redirected as a GET, for example).
Note that I had to add a method, named 'method', to the
Request class, for maintainability (it's possible that
urllib2 may be able to do methods other than GET and POST in
future).

Possibly redirect_request should take fewer parameters.

John


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-06-19 22:56

Message:
Logged In: YES 
user_id=261020

I've attached a patch -- was simpler than I thought.

I think this is in compliance with RFC 2616.  It's also
simple for clients to inherit from HTTPRedirectHandler and
override redirect_request if, for example, they know they
want all 302 POSTs to be redirected as a GET, which removes
the need for mixing redirection code with normal client code
even when the server doesn't follow the RFC (if the server
expects a 302 POST to be redirected as a GET, for example).
Note that I had to add a method, named 'method', to the
Request class, for maintainability (it's possible that
urllib2 may be able to do methods other than GET and POST in
future).

Possibly redirect_request should take fewer parameters.

John


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-06-06 22:25

Message:
Logged In: YES 
user_id=261020

Oh, I hadn't realised httplib uses HTTP/1.1 now -- and now I
check, I see that even RFC 1945 (HTTP/1.0) has a whole set of
restrictions on 30x for particular values of x which I missed
completely.

I guess it should do what Guido suggested -- report an error if a
POST is redirected -- until somebody gets time to do it properly.
I won't have time for a couple of months, but if nobody has done
it by then I'll upload a patch.


John


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-06-06 16:09

Message:
Logged In: YES 
user_id=31392

I think you need to review the current HTTP spec -- RFC 2616
-- and look at the section on redirection (10.3).  I think
urllib2 could improve its handling of redirection, but the
behavior you describe from lynx sounds incorrect.  I'd be
happy to review a patch the implemented the current spec.

Also, RFC 2616 removes the recommendation of a 5 redirect limit.




----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-29 19:10

Message:
Logged In: YES 
user_id=6380

Fair enough. I'll leve it to Jeremy to review the proposed
fix. (Note that he's busy though.)

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-04-29 17:29

Message:
Logged In: YES 
user_id=261020

I don't see why it shouldn't substitue a GET.  That certainly seems to be
the standard practice (well, at least that's what lynx does), and in the case
of the only site where I've encountered redirects on POST, the redirect URL
contains urlencoded stuff, so it clearly expects the user-agent to do a GET.
The site would break if this didn't happen, so I guess Netscape and IE must
do the same thing.

Clearly the RFC *does* allow this, though it doesn't require it (or specify
what should happen here in any way other than to say that a POST is not
allowed, in fact).  Since it's standard practice and allowed by the RFC, I
don't think it should be an error.

John


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-29 01:53

Message:
Logged In: YES 
user_id=6380

Hm, the way I interpret the text you quote, if the original
request is  a POST, it should probably not substitute a GET
but report the error.

Assigning to Jeremy since it's his module.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-04-28 17:21

Message:
Logged In: YES 
user_id=261020

1. Bug is also in 2.2 branch

2. The fix (in 2.1 and 2.2) should reflect the earlier bug fix in the 2.2 branch to add the old headers:

new = Request(newurl, headers=req.headers)

3. I guess 10 should be replaced with 4, not 5.


John


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470


From noreply@sourceforge.net  Sun Apr 27 02:49:41 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 26 Apr 2003 18:49:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-667931 ] BoundaryError: multipart message with no defined boundary
Message-ID: <E199bIT-0004FV-00@sc8-sf-web3.sourceforge.net>

Bugs item #667931, was opened at 2003-01-14 13:36
Message generated for change (Comment added) made by bwarsaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=667931&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 3
Submitted By: Jason R. Mastaler (jasonrm)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: BoundaryError: multipart message with no defined boundary

Initial Comment:
More problems with the email package raising
exceptions when trying to parse non-compliant
messages.

Even when lax parsing is enabled, a BoundaryError
is raised when trying to parse the attached spam
message.

I'd like to see some sort of workaround to handle these
cases more gracefully when when lax parsing is
enabled.

This behavior seems like 'strict' parsing behavior to me.



----------------------------------------------------------------------

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-04-26 21:49

Message:
Logged In: YES 
user_id=12800

HeaderParser is a parser that stops after reading just the
rfc 2822 headers, leaving the entirety of the body of the
message as one big text payload.

Sometimes that's the best you can do.

----------------------------------------------------------------------

Comment By: Jason R. Mastaler (jasonrm)
Date: 2003-04-26 15:17

Message:
Logged In: YES 
user_id=85984

I'm unclear what you mean by: 
 
``You can always fall back to email.Header.HeaderParser  
when all else fails'' 
 

----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-03-06 01:31

Message:
Logged In: YES 
user_id=12800

I see what you're saying, Jason, but I don't know how Parser
could do much better.  You can always fall back to
email.Header.HeaderParser when all else fails (well all else
modulo severely broken headers).


----------------------------------------------------------------------

Comment By: Jason R. Mastaler (jasonrm)
Date: 2003-02-20 14:33

Message:
Logged In: YES 
user_id=85984

As Python 2.3a2 was just released, I'm worried that
this one is going to fall through the cracks before
2.3-final is released which would be unfortunate because
it would mean I'd have to continue bundling my own
copy of email with my applications.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=667931&group_id=5470


From noreply@sourceforge.net  Sun Apr 27 04:35:49 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 26 Apr 2003 20:35:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-728277 ] Tools/msgfmt.py results in two warnings under Python 2.3b1
Message-ID: <E199cxB-0006oo-00@sc8-sf-web4.sourceforge.net>

Bugs item #728277, was opened at 2003-04-27 03:35
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728277&group_id=5470

Category: Demos and Tools
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Stephan R.A. Deibel (sdeibel)
Assigned to: Nobody/Anonymous (nobody)
Summary: Tools/msgfmt.py results in two warnings under Python 2.3b1

Initial Comment:
Running Tools/msgfmt.py under Python 2.3b1 (also the
alphas) results in the following warnings:

[sdeibel@hedgehog build-files]$ python2.3
~/src/Python-2.3b1/Tools/i18n/msgfmt.py --help
sys:1: DeprecationWarning: Non-ASCII character '\xf6'
in file
/home/sdeibel/src/Python-2.3b1/Tools/i18n/msgfmt.py on
line 3, but no encoding declared; see
http://www.python.org/peps/pep-0263.html for details
/home/sdeibel/src/Python-2.3b1/Tools/i18n/msgfmt.py:86:
FutureWarning: hex/oct constants > sys.maxint will
return positive values in Python 2.4 and up
  0x950412de,        # Magic

Doesn't cause any problems but would be cleaner to add
encoding info and the 'L' for the constant.

This is on Mandrake 8.2 but I'm sure it happens everywhere.

- Stephan


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728277&group_id=5470


From noreply@sourceforge.net  Sun Apr 27 05:53:44 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 26 Apr 2003 21:53:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-667931 ] BoundaryError: multipart message with no defined boundary
Message-ID: <E199eAa-00029K-00@sc8-sf-web2.sourceforge.net>

Bugs item #667931, was opened at 2003-01-14 11:36
Message generated for change (Comment added) made by jasonrm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=667931&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 3
Submitted By: Jason R. Mastaler (jasonrm)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: BoundaryError: multipart message with no defined boundary

Initial Comment:
More problems with the email package raising
exceptions when trying to parse non-compliant
messages.

Even when lax parsing is enabled, a BoundaryError
is raised when trying to parse the attached spam
message.

I'd like to see some sort of workaround to handle these
cases more gracefully when when lax parsing is
enabled.

This behavior seems like 'strict' parsing behavior to me.



----------------------------------------------------------------------

>Comment By: Jason R. Mastaler (jasonrm)
Date: 2003-04-26 22:53

Message:
Logged In: YES 
user_id=85984

Ok, I see now.  I ended up replacing use 
of email.message_from_file() with my own  
implementation based upon email.Parser.HeaderParser. 
 
HeaderParser completely slipped past me.  I might 
suggest noting it a bit more prominently in the docs, 
perhaps in 2.2.1 under the description of the Parser 
class.  Even if there's some redundancy, it will help 
bring HeaderParser to the attention of more programmers. 
 
You can close this one out, thanks. 

----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-04-26 19:49

Message:
Logged In: YES 
user_id=12800

HeaderParser is a parser that stops after reading just the
rfc 2822 headers, leaving the entirety of the body of the
message as one big text payload.

Sometimes that's the best you can do.

----------------------------------------------------------------------

Comment By: Jason R. Mastaler (jasonrm)
Date: 2003-04-26 13:17

Message:
Logged In: YES 
user_id=85984

I'm unclear what you mean by: 
 
``You can always fall back to email.Header.HeaderParser  
when all else fails'' 
 

----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-03-05 23:31

Message:
Logged In: YES 
user_id=12800

I see what you're saying, Jason, but I don't know how Parser
could do much better.  You can always fall back to
email.Header.HeaderParser when all else fails (well all else
modulo severely broken headers).


----------------------------------------------------------------------

Comment By: Jason R. Mastaler (jasonrm)
Date: 2003-02-20 12:33

Message:
Logged In: YES 
user_id=85984

As Python 2.3a2 was just released, I'm worried that
this one is going to fall through the cracks before
2.3-final is released which would be unfortunate because
it would mean I'd have to continue bundling my own
copy of email with my applications.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=667931&group_id=5470


From noreply@sourceforge.net  Sun Apr 27 07:30:12 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 26 Apr 2003 23:30:12 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-728304 ] reverse form of enumeration
Message-ID: <E199ffw-0002xW-00@sc8-sf-web3.sourceforge.net>

Feature Requests item #728304, was opened at 2003-04-27 01:30
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=728304&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Douglas Napoleone (derivin)
Assigned to: Nobody/Anonymous (nobody)
Summary: reverse form of enumeration

Initial Comment:
I love the new enumeration builtin. Before it was put in I 
had my own version of the functionality as many did 
using xrange and zip.

I also used an extension that would give a reverse of 
what enumeration returns (in behavior at least)

enumeration(list)
returns an xrange like itterator that behaves like:
( (0, list[0]), (1, list(1)), ...)

my old code looked like:

def old_enumeration( argList):
_ return zip(range(len(argList)), argList)

def revenum( argList ):
_ temp = old_enumeration( argList)
_ temp.reverse()
_ return temp


obviously this is really slow for really long lists and 
tuples

these structures would be used for looping 90% of the 
time. One of my fav's:
matches = []
for ind, val in revenum(aList):
_ if test(val): matches.append(aList.pop(ind))

am I the only person wanting an effecient reverse 
enumeration??

(NOTE: currently if the list is really long I use:
for ind in xrange(len(aList) - 1, -1, -1):
create two new lists, then delete the old one.
the additional time for pop() is non trivial on a list of 
50Mil entries and memory isnt much of a concern as 
time for me. A reverse enumeration would be much 
clearer to read IMO).



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=728304&group_id=5470


From noreply@sourceforge.net  Sun Apr 27 09:44:29 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 27 Apr 2003 01:44:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-728322 ] setup.py breaks during build of Python-2.3b1
Message-ID: <E199hlt-0000GR-00@sc8-sf-web2.sourceforge.net>

Bugs item #728322, was opened at 2003-04-27 08:44
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728322&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: John Ochiltree (joch1)
Assigned to: Nobody/Anonymous (nobody)
Summary: setup.py breaks during build of Python-2.3b1

Initial Comment:
I'm having trouble building Python-2.3b1 on SuSE 8.2.
The ./configure didn't seem to object to anything but
running the
make bombs out with:

running build
running build_ext
Traceback (most recent call last):
  File "./setup.py", line 1110, in ?
    main()
  File "./setup.py", line 1105, in main
    scripts = ['Tools/scripts/pydoc']
  File
"/home/johnoch/build/Python-2.3b1/Lib/distutils/core.py",
line 149,
in setup
    dist.run_commands()
  File
"/home/johnoch/build/Python-2.3b1/Lib/distutils/dist.py",
line 907,
in run_commands
    self.run_command(cmd)
  File
"/home/johnoch/build/Python-2.3b1/Lib/distutils/dist.py",
line 927,
in run_command
    cmd_obj.run()
  File
"/home/johnoch/build/Python-2.3b1/Lib/distutils/command/build.py",
line 107, in run
    self.run_command(cmd_name)
  File
"/home/johnoch/build/Python-2.3b1/Lib/distutils/cmd.py",
line 333, in
run_command
    self.distribution.run_command(command)
  File
"/home/johnoch/build/Python-2.3b1/Lib/distutils/dist.py",
line 927,
in run_command
    cmd_obj.run()
  File
"/home/johnoch/build/Python-2.3b1/Lib/distutils/command/build_ext.py",
line
269, in run
    self.build_extensions()
  File "./setup.py", line 99, in build_extensions
    self.detect_modules()
  File "./setup.py", line 844, in detect_modules
    self.detect_tkinter(inc_dirs, lib_dirs)
  File "./setup.py", line 941, in detect_tkinter
    for dir in tcl_includes + tk_includes:
TypeError: unsupported operand type(s) for +:
'NoneType' and 'list'
make: *** [sharedmods] Error 1


I mentioned this on comp.lang.python and received the
following from Martin v Lowis:

It's a typo in setup.py. Replace

        if (tcllib is None or tklib is None and
            tcl_includes is None or tk_includes is None):
            # Something's missing, so give up
            return

with

        if (tcllib is None or tklib is None or
            tcl_includes is None or tk_includes is None):
            # Something's missing, so give up
            return

Alternatively, install the Tcl/Tk header files if you
also want to
build Tkinter.

Please do report bugs at sf.net/projects/python in the
future; a bug
report in comp.lang.python will get lost.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728322&group_id=5470


From noreply@sourceforge.net  Sun Apr 27 10:21:03 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 27 Apr 2003 02:21:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-728330 ] IRIX, 2.3b1, socketmodule.c compilation errors
Message-ID: <E199iLH-00083R-00@sc8-sf-web4.sourceforge.net>

Bugs item #728330, was opened at 2003-04-27 02:21
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470

Category: Installation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ralf W. Grosse-Kunstleve (rwgk)
Assigned to: Nobody/Anonymous (nobody)
Summary: IRIX, 2.3b1, socketmodule.c compilation errors

Initial Comment:
Python release:
  2.3b1
Platform:
  IRIX 6.5
  MIPSpro Compilers: Version 7.3.1.2m
Commands used:
  ./configure --prefix=/usr/local_cci/Python-2.3b1t
  make

The socket module fails to compile. The output from 
the compiler is attached.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470


From noreply@sourceforge.net  Sun Apr 27 13:35:29 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 27 Apr 2003 05:35:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-725106 ] SRE bug with capturing groups in alternatives in repeats
Message-ID: <E199lNR-0002I5-00@sc8-sf-web3.sourceforge.net>

Bugs item #725106, was opened at 2003-04-21 17:16
Message generated for change (Comment added) made by niemeyer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=725106&group_id=5470

Category: Regular Expressions
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Fredrik Lundh (effbot)
Summary: SRE bug with capturing groups in alternatives in repeats

Initial Comment:
SRE does not always correctly handle groups in 
alternatives in repeats.  For example:

>>> re.match('((a)|b)*', 'abc').groups()
('b', '')

Group 2 should obviously never be an empty string.  As I 
understand it, the rule for groups inside a repeat is that 
they should have the last value they matched during the 
iterations of the repeat (or None if they never match), so 
in the above case Group 2 should be 'a'.  To fix this, it 
appears that (when inside a repeat) the BRANCH 
opcode must call mark_save before trying an alternative 
and then call mark_restore if the alternative fails.  The 
attached patch does this.



----------------------------------------------------------------------

>Comment By: Gustavo Niemeyer (niemeyer)
Date: 2003-04-27 12:35

Message:
Logged In: YES 
user_id=7887

Good catch Greg!

Just for reference, here are two tests to confirm that
you're right:

perl -e '"abc" =~ /^((a)|b)*/; print "$1 $2\n";'
echo "abc" | sed -r -e "s/^((a)|b)*/\1 \2|/"

The only change I made was to port your tests to test_re.py.

Applied as:

Modules/_sre.c: 2.94
Lib/test/test_re.py: 1.40

Thanks!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=725106&group_id=5470


From noreply@sourceforge.net  Sun Apr 27 14:28:05 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 27 Apr 2003 06:28:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-725149 ] SRE bugs with capturing groups in negative assertions
Message-ID: <E199mCL-0004hl-00@sc8-sf-web3.sourceforge.net>

Bugs item #725149, was opened at 2003-04-21 18:22
Message generated for change (Comment added) made by niemeyer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=725149&group_id=5470

Category: Regular Expressions
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
>Assigned to: Gustavo Niemeyer (niemeyer)
Summary: SRE bugs with capturing groups in negative assertions

Initial Comment:
SRE is broken in some subtle ways when you combine 
capturing groups with assertions.  For example:

>>> re.match('((?!(a)c)[ab])*', 'abc').groups()
('b', '')

In the above '(a)' has matched an empty string.  Or 
worse:

>>> re.match('(a)((?!(b)*))*', 'abb').groups()
('b', None, None)

Here '(a)' matches 'b'.

Although Perl reports matches for groups in negative 
assertions, I think it is better to adopt the PCRE rule 
that these groups are always reported as unmatched 
outside the assertion (inside the assertion, if used with 
backreferences, they should behave as normal).  This 
would make the handling of subpatterns in negative 
assertions consistent with that of subpatterns in 
branches:

>>> re.match('(a)c|ab', 'ab').groups()
(None,)

In the above, although '(a)' matches before the branch 
fails, the failure of the branch means '(a)' is considered 
not to have matched.

Anyway, the attached patch is an effort to fix this 
problem by saving the values of marks before calling the 
assertion, and then restoring them afterwards (thus 
undoing whatever might have been done in the assertion).


----------------------------------------------------------------------

>Comment By: Gustavo Niemeyer (niemeyer)
Date: 2003-04-27 13:28

Message:
Logged In: YES 
user_id=7887

Greg, I think there are two different issues here.

One of them is related to a wrong behavior from
mark_save/restore(), which don't restore the stackbase
before restoring the marks. Asserts were afected because
they're the only recursive ops that can continue the loop,
but the problem would happen to any operation with the same
behavior. So, rather than hardcoding this into asserts, I
have changed mark_save/restore() to always restore the
stackbase before restoring the marks. This should fix these
two cases you presented:

>>> re.match('(a)(?:(?=(b)*)c)*', 'abb').groups()
>>> re.match('(a)((?!(b)*))*', 'abb').groups()

And was applied as:

Modules/_sre.c: 2.95
Lib/test/test_re.py: 1.41

The other issue is related to the asserts which are leaving
half-marked groups. While your solution does work, it
changes the current behavior, which is also compatible to
how perl works. I understand that individual groups matching
when the whole string doesn't match is atypical. OTOH, a
negative assertion *is* atypical, and IMO denying external
group access won't help the user to understand how it works.
In other words, I think it's better to have incomplete
support for the moment, than having none.
This way, we can think further about this, and look for an
elegant solution to fix that support, certainly including
some algorithm to check for half-marked groups.

Thank you very much for spotting these bugs, and submitting
a solution for them.


----------------------------------------------------------------------

Comment By: Greg Chapman (glchapman)
Date: 2003-04-22 18:46

Message:
Logged In: YES 
user_id=86307

In thinking further, I realized that positive assertions are also 
affected by the second problem.  E.g.:

>>> re.match('(a)(?:(?=(b)*)c)*', 'abb').groups()
('b', None)

The problem here is that a successful match in an assertion 
can leave marks at the top of the mark stack which then get 
popped in the wrong place.  Attaching a new patch which 
should catch this problem for both kinds of assertions (and 
which also should "unmark" groups in negative assertions).


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=725149&group_id=5470


From noreply@sourceforge.net  Sun Apr 27 14:29:05 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 27 Apr 2003 06:29:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-725106 ] SRE bug with capturing groups in alternatives in repeats
Message-ID: <E199mDJ-0004k1-00@sc8-sf-web3.sourceforge.net>

Bugs item #725106, was opened at 2003-04-21 17:16
Message generated for change (Settings changed) made by niemeyer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=725106&group_id=5470

Category: Regular Expressions
Group: Python 2.3
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Greg Chapman (glchapman)
>Assigned to: Gustavo Niemeyer (niemeyer)
Summary: SRE bug with capturing groups in alternatives in repeats

Initial Comment:
SRE does not always correctly handle groups in 
alternatives in repeats.  For example:

>>> re.match('((a)|b)*', 'abc').groups()
('b', '')

Group 2 should obviously never be an empty string.  As I 
understand it, the rule for groups inside a repeat is that 
they should have the last value they matched during the 
iterations of the repeat (or None if they never match), so 
in the above case Group 2 should be 'a'.  To fix this, it 
appears that (when inside a repeat) the BRANCH 
opcode must call mark_save before trying an alternative 
and then call mark_restore if the alternative fails.  The 
attached patch does this.



----------------------------------------------------------------------

Comment By: Gustavo Niemeyer (niemeyer)
Date: 2003-04-27 12:35

Message:
Logged In: YES 
user_id=7887

Good catch Greg!

Just for reference, here are two tests to confirm that
you're right:

perl -e '"abc" =~ /^((a)|b)*/; print "$1 $2\n";'
echo "abc" | sed -r -e "s/^((a)|b)*/\1 \2|/"

The only change I made was to port your tests to test_re.py.

Applied as:

Modules/_sre.c: 2.94
Lib/test/test_re.py: 1.40

Thanks!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=725106&group_id=5470


From noreply@sourceforge.net  Sun Apr 27 14:55:14 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 27 Apr 2003 06:55:14 -0700
Subject: [Python-bugs-list] [ python-Bugs-725106 ] SRE bug with capturing groups in alternatives in repeats
Message-ID: <E199mcc-0005nA-00@sc8-sf-web3.sourceforge.net>

Bugs item #725106, was opened at 2003-04-21 17:16
Message generated for change (Settings changed) made by niemeyer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=725106&group_id=5470

Category: Regular Expressions
Group: Python 2.3
Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: SRE bug with capturing groups in alternatives in repeats

Initial Comment:
SRE does not always correctly handle groups in 
alternatives in repeats.  For example:

>>> re.match('((a)|b)*', 'abc').groups()
('b', '')

Group 2 should obviously never be an empty string.  As I 
understand it, the rule for groups inside a repeat is that 
they should have the last value they matched during the 
iterations of the repeat (or None if they never match), so 
in the above case Group 2 should be 'a'.  To fix this, it 
appears that (when inside a repeat) the BRANCH 
opcode must call mark_save before trying an alternative 
and then call mark_restore if the alternative fails.  The 
attached patch does this.



----------------------------------------------------------------------

Comment By: Gustavo Niemeyer (niemeyer)
Date: 2003-04-27 12:35

Message:
Logged In: YES 
user_id=7887

Good catch Greg!

Just for reference, here are two tests to confirm that
you're right:

perl -e '"abc" =~ /^((a)|b)*/; print "$1 $2\n";'
echo "abc" | sed -r -e "s/^((a)|b)*/\1 \2|/"

The only change I made was to port your tests to test_re.py.

Applied as:

Modules/_sre.c: 2.94
Lib/test/test_re.py: 1.40

Thanks!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=725106&group_id=5470


From noreply@sourceforge.net  Sun Apr 27 15:26:21 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 27 Apr 2003 07:26:21 -0700
Subject: [Python-bugs-list] [ python-Bugs-725106 ] SRE bug with capturing groups in alternatives in repeats
Message-ID: <E199n6j-0006RL-00@sc8-sf-web4.sourceforge.net>

Bugs item #725106, was opened at 2003-04-21 17:16
Message generated for change (Comment added) made by niemeyer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=725106&group_id=5470

Category: Regular Expressions
Group: Python 2.3
Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: SRE bug with capturing groups in alternatives in repeats

Initial Comment:
SRE does not always correctly handle groups in 
alternatives in repeats.  For example:

>>> re.match('((a)|b)*', 'abc').groups()
('b', '')

Group 2 should obviously never be an empty string.  As I 
understand it, the rule for groups inside a repeat is that 
they should have the last value they matched during the 
iterations of the repeat (or None if they never match), so 
in the above case Group 2 should be 'a'.  To fix this, it 
appears that (when inside a repeat) the BRANCH 
opcode must call mark_save before trying an alternative 
and then call mark_restore if the alternative fails.  The 
attached patch does this.



----------------------------------------------------------------------

>Comment By: Gustavo Niemeyer (niemeyer)
Date: 2003-04-27 14:26

Message:
Logged In: YES 
user_id=7887

Greg, I'm going to change the fix slightly, moving the
mark_save() to outside of the for loop.


----------------------------------------------------------------------

Comment By: Gustavo Niemeyer (niemeyer)
Date: 2003-04-27 12:35

Message:
Logged In: YES 
user_id=7887

Good catch Greg!

Just for reference, here are two tests to confirm that
you're right:

perl -e '"abc" =~ /^((a)|b)*/; print "$1 $2\n";'
echo "abc" | sed -r -e "s/^((a)|b)*/\1 \2|/"

The only change I made was to port your tests to test_re.py.

Applied as:

Modules/_sre.c: 2.94
Lib/test/test_re.py: 1.40

Thanks!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=725106&group_id=5470


From noreply@sourceforge.net  Sun Apr 27 18:17:48 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 27 Apr 2003 10:17:48 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-728304 ] reverse form of enumeration
Message-ID: <E199pme-0006ZV-00@sc8-sf-web4.sourceforge.net>

Feature Requests item #728304, was opened at 2003-04-27 01:30
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=728304&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Douglas Napoleone (derivin)
Assigned to: Nobody/Anonymous (nobody)
Summary: reverse form of enumeration

Initial Comment:
I love the new enumeration builtin. Before it was put in I 
had my own version of the functionality as many did 
using xrange and zip.

I also used an extension that would give a reverse of 
what enumeration returns (in behavior at least)

enumeration(list)
returns an xrange like itterator that behaves like:
( (0, list[0]), (1, list(1)), ...)

my old code looked like:

def old_enumeration( argList):
_ return zip(range(len(argList)), argList)

def revenum( argList ):
_ temp = old_enumeration( argList)
_ temp.reverse()
_ return temp


obviously this is really slow for really long lists and 
tuples

these structures would be used for looping 90% of the 
time. One of my fav's:
matches = []
for ind, val in revenum(aList):
_ if test(val): matches.append(aList.pop(ind))

am I the only person wanting an effecient reverse 
enumeration??

(NOTE: currently if the list is really long I use:
for ind in xrange(len(aList) - 1, -1, -1):
create two new lists, then delete the old one.
the additional time for pop() is non trivial on a list of 
50Mil entries and memory isnt much of a concern as 
time for me. A reverse enumeration would be much 
clearer to read IMO).



----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-27 12:17

Message:
Logged In: YES 
user_id=80475

This runs pretty fast:

     list(enumerate(data))[::-1]

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=728304&group_id=5470


From noreply@sourceforge.net  Sun Apr 27 18:37:33 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 27 Apr 2003 10:37:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-728511 ] Opening a nonexistent tar file in mode r:bz2 seg faults
Message-ID: <E199q5l-0001So-00@sc8-sf-web2.sourceforge.net>

Bugs item #728511, was opened at 2003-04-27 17:37
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728511&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gary Herron (herron)
Assigned to: Nobody/Anonymous (nobody)
Summary: Opening a nonexistent tar file in mode r:bz2 seg faults

Initial Comment:
 
Running Python 2.3 beta 1 on a Linux (RH9) system, I get a 
segmentation fault when I mistakenly open a nonexistent 
file in mode 
"r:bz2". 
 
>>> import tarfile 
>>> tar = tarfile.open("non-existent-file", "r:bz2") 
Segmentation fault 
 
If the mode is "r:gz" then the result is (properly) 
  No such file ... 
 
And, of course, all is fine if the file *does* exist. 
 
 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728511&group_id=5470


From noreply@sourceforge.net  Sun Apr 27 18:44:54 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 27 Apr 2003 10:44:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-728515 ] mmap's resize method resizes the file in win32 but not unix
Message-ID: <E199qCs-0007lk-00@sc8-sf-web4.sourceforge.net>

Bugs item #728515, was opened at 2003-04-27 13:44
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728515&group_id=5470

Category: Extension Modules
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Myers Carpenter (myers_carpenter)
Assigned to: Nobody/Anonymous (nobody)
Summary: mmap's resize method resizes the file in win32 but not unix

Initial Comment:
In the resize method under win32 you have something
like this:

	/* Move to the desired EOF position */
        SetFilePointer (self->file_handle,
                new_size, NULL, FILE_BEGIN);
        /* Change the size of the file */
        SetEndOfFile (self->file_handle);

Which resizes the file

Under Unix you need to call 

   ftruncate(self->fileno, new_size)

before calling remap() to make it do the same thing.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728515&group_id=5470


From noreply@sourceforge.net  Sun Apr 27 19:21:21 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 27 Apr 2003 11:21:21 -0700
Subject: [Python-bugs-list] [ python-Bugs-728511 ] Opening a nonexistent tar file in mode r:bz2 seg faults
Message-ID: <E199qm9-0002Lz-00@sc8-sf-web3.sourceforge.net>

Bugs item #728511, was opened at 2003-04-27 17:37
Message generated for change (Comment added) made by herron
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728511&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gary Herron (herron)
Assigned to: Nobody/Anonymous (nobody)
Summary: Opening a nonexistent tar file in mode r:bz2 seg faults

Initial Comment:
 
Running Python 2.3 beta 1 on a Linux (RH9) system, I get a 
segmentation fault when I mistakenly open a nonexistent 
file in mode 
"r:bz2". 
 
>>> import tarfile 
>>> tar = tarfile.open("non-existent-file", "r:bz2") 
Segmentation fault 
 
If the mode is "r:gz" then the result is (properly) 
  No such file ... 
 
And, of course, all is fine if the file *does* exist. 
 
 

----------------------------------------------------------------------

>Comment By: Gary Herron (herron)
Date: 2003-04-27 18:21

Message:
Logged In: YES 
user_id=395736

Similarily on windows,  with the same code, on gets an 
Application Error popup with the message 
 
  The instruction at "..." referenced memory at "0x00000000". ... 
 
 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728511&group_id=5470


From noreply@sourceforge.net  Sun Apr 27 21:26:13 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 27 Apr 2003 13:26:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-728574 ] Long file names in osa suites
Message-ID: <E199siz-0001OP-00@sc8-sf-web2.sourceforge.net>

Bugs item #728574, was opened at 2003-04-27 22:26
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728574&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: Long file names in osa suites

Initial Comment:
Some of the standard osa suite modules have filenames that are too
long for MacOS9. This needs to be fixed.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728574&group_id=5470


From noreply@sourceforge.net  Sun Apr 27 22:21:33 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 27 Apr 2003 14:21:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-728608 ] ConfigurePython gives depreaction warning
Message-ID: <E199taX-0003vZ-00@sc8-sf-web2.sourceforge.net>

Bugs item #728608, was opened at 2003-04-27 23:21
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728608&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: ConfigurePython gives depreaction warning

Initial Comment:
ConfigurePython gives a deprecation warning for macfs, this should 
be suppressed.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728608&group_id=5470


From noreply@sourceforge.net  Mon Apr 28 00:27:05 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 27 Apr 2003 16:27:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-728511 ] Opening a nonexistent tar file in mode r:bz2 seg faults
Message-ID: <E199vY1-0006GT-00@sc8-sf-web4.sourceforge.net>

Bugs item #728511, was opened at 2003-04-27 12:37
Message generated for change (Comment added) made by logistix
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728511&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gary Herron (herron)
Assigned to: Nobody/Anonymous (nobody)
Summary: Opening a nonexistent tar file in mode r:bz2 seg faults

Initial Comment:
 
Running Python 2.3 beta 1 on a Linux (RH9) system, I get a 
segmentation fault when I mistakenly open a nonexistent 
file in mode 
"r:bz2". 
 
>>> import tarfile 
>>> tar = tarfile.open("non-existent-file", "r:bz2") 
Segmentation fault 
 
If the mode is "r:gz" then the result is (properly) 
  No such file ... 
 
And, of course, all is fine if the file *does* exist. 
 
 

----------------------------------------------------------------------

Comment By: logistix (logistix)
Date: 2003-04-27 18:27

Message:
Logged In: YES 
user_id=699438

bz2module's cleanup code used a Py_DECREF when it 
should've used an Py_XDECREF.

Patch 728656 posted.

Error now replies "Read Error: not a bzip2 file"



----------------------------------------------------------------------

Comment By: Gary Herron (herron)
Date: 2003-04-27 13:21

Message:
Logged In: YES 
user_id=395736

Similarily on windows,  with the same code, on gets an 
Application Error popup with the message 
 
  The instruction at "..." referenced memory at "0x00000000". ... 
 
 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728511&group_id=5470


From noreply@sourceforge.net  Mon Apr 28 03:52:12 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 27 Apr 2003 19:52:12 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-728304 ] reverse form of enumeration
Message-ID: <E199ykW-0002yI-00@sc8-sf-web1.sourceforge.net>

Feature Requests item #728304, was opened at 2003-04-27 01:30
Message generated for change (Comment added) made by derivin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=728304&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Douglas Napoleone (derivin)
Assigned to: Nobody/Anonymous (nobody)
Summary: reverse form of enumeration

Initial Comment:
I love the new enumeration builtin. Before it was put in I 
had my own version of the functionality as many did 
using xrange and zip.

I also used an extension that would give a reverse of 
what enumeration returns (in behavior at least)

enumeration(list)
returns an xrange like itterator that behaves like:
( (0, list[0]), (1, list(1)), ...)

my old code looked like:

def old_enumeration( argList):
_ return zip(range(len(argList)), argList)

def revenum( argList ):
_ temp = old_enumeration( argList)
_ temp.reverse()
_ return temp


obviously this is really slow for really long lists and 
tuples

these structures would be used for looping 90% of the 
time. One of my fav's:
matches = []
for ind, val in revenum(aList):
_ if test(val): matches.append(aList.pop(ind))

am I the only person wanting an effecient reverse 
enumeration??

(NOTE: currently if the list is really long I use:
for ind in xrange(len(aList) - 1, -1, -1):
create two new lists, then delete the old one.
the additional time for pop() is non trivial on a list of 
50Mil entries and memory isnt much of a concern as 
time for me. A reverse enumeration would be much 
clearer to read IMO).



----------------------------------------------------------------------

>Comment By: Douglas Napoleone (derivin)
Date: 2003-04-27 21:52

Message:
Logged In: YES 
user_id=541557

At issue is the speed of list operations on excessivly large 
lists. 

a = list(xrange(5000000))    - 1 second
a = list(xrange(50000000))  - 4 min

list(enumerate(a))[::-1]

is 3 list operations... or 12min (actually took 25min for me in 
a test but other processes were running. NOTE: the list
(xrange(#)) time is NOT included in this.)

enumerate(a, reverse=True)  - 15seconds  (took the code for 
enumerate and made my own pyd)

this does not include the time that it would take to make all 
the calls to the enumerate's next() method; obviously.

in the end, quarter of a min, or quarter of an hour. What 
would you use?



----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-27 12:17

Message:
Logged In: YES 
user_id=80475

This runs pretty fast:

     list(enumerate(data))[::-1]

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=728304&group_id=5470


From noreply@sourceforge.net  Mon Apr 28 16:46:04 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 28 Apr 2003 08:46:04 -0700
Subject: [Python-bugs-list] [ python-Bugs-725149 ] SRE bugs with capturing groups in negative assertions
Message-ID: <E19AApQ-0005hf-00@sc8-sf-web1.sourceforge.net>

Bugs item #725149, was opened at 2003-04-21 10:22
Message generated for change (Comment added) made by glchapman
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=725149&group_id=5470

Category: Regular Expressions
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: SRE bugs with capturing groups in negative assertions

Initial Comment:
SRE is broken in some subtle ways when you combine 
capturing groups with assertions.  For example:

>>> re.match('((?!(a)c)[ab])*', 'abc').groups()
('b', '')

In the above '(a)' has matched an empty string.  Or 
worse:

>>> re.match('(a)((?!(b)*))*', 'abb').groups()
('b', None, None)

Here '(a)' matches 'b'.

Although Perl reports matches for groups in negative 
assertions, I think it is better to adopt the PCRE rule 
that these groups are always reported as unmatched 
outside the assertion (inside the assertion, if used with 
backreferences, they should behave as normal).  This 
would make the handling of subpatterns in negative 
assertions consistent with that of subpatterns in 
branches:

>>> re.match('(a)c|ab', 'ab').groups()
(None,)

In the above, although '(a)' matches before the branch 
fails, the failure of the branch means '(a)' is considered 
not to have matched.

Anyway, the attached patch is an effort to fix this 
problem by saving the values of marks before calling the 
assertion, and then restoring them afterwards (thus 
undoing whatever might have been done in the assertion).


----------------------------------------------------------------------

>Comment By: Greg Chapman (glchapman)
Date: 2003-04-28 07:46

Message:
Logged In: YES 
user_id=86307

Gustavo,

Just a quick note on compatibility.  As I mentioned, the PCRE 
rule is that groups in negative asserts do not match.  So, with 
Python 2.2, you get this result using pre:

>>> pre.match('((?!(a)c)[ab])*', 'abc').groups()
('b', None)

Although I understand your argument, I'll just say that I 
personally think it would be better to move toward compatibility 
with pre (which after all was the official Python regex engine 
before sre), rather than to remain partly compatible with Perl.

Thanks for reviewing my patches and fixing the bugs!


----------------------------------------------------------------------

Comment By: Gustavo Niemeyer (niemeyer)
Date: 2003-04-27 05:28

Message:
Logged In: YES 
user_id=7887

Greg, I think there are two different issues here.

One of them is related to a wrong behavior from
mark_save/restore(), which don't restore the stackbase
before restoring the marks. Asserts were afected because
they're the only recursive ops that can continue the loop,
but the problem would happen to any operation with the same
behavior. So, rather than hardcoding this into asserts, I
have changed mark_save/restore() to always restore the
stackbase before restoring the marks. This should fix these
two cases you presented:

>>> re.match('(a)(?:(?=(b)*)c)*', 'abb').groups()
>>> re.match('(a)((?!(b)*))*', 'abb').groups()

And was applied as:

Modules/_sre.c: 2.95
Lib/test/test_re.py: 1.41

The other issue is related to the asserts which are leaving
half-marked groups. While your solution does work, it
changes the current behavior, which is also compatible to
how perl works. I understand that individual groups matching
when the whole string doesn't match is atypical. OTOH, a
negative assertion *is* atypical, and IMO denying external
group access won't help the user to understand how it works.
In other words, I think it's better to have incomplete
support for the moment, than having none.
This way, we can think further about this, and look for an
elegant solution to fix that support, certainly including
some algorithm to check for half-marked groups.

Thank you very much for spotting these bugs, and submitting
a solution for them.


----------------------------------------------------------------------

Comment By: Greg Chapman (glchapman)
Date: 2003-04-22 10:46

Message:
Logged In: YES 
user_id=86307

In thinking further, I realized that positive assertions are also 
affected by the second problem.  E.g.:

>>> re.match('(a)(?:(?=(b)*)c)*', 'abb').groups()
('b', None)

The problem here is that a successful match in an assertion 
can leave marks at the top of the mark stack which then get 
popped in the wrong place.  Attaching a new patch which 
should catch this problem for both kinds of assertions (and 
which also should "unmark" groups in negative assertions).


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=725149&group_id=5470


From noreply@sourceforge.net  Mon Apr 28 19:37:29 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 28 Apr 2003 11:37:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-729096 ] getopt online documentation example improvement
Message-ID: <E19ADVJ-0001ae-00@sc8-sf-web3.sourceforge.net>

Bugs item #729096, was opened at 2003-04-28 11:37
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729096&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ben Hartshorne (b655321)
Assigned to: Nobody/Anonymous (nobody)
Summary: getopt online documentation example improvement

Initial Comment:
The online documentation for the getopt module
(http://www.python.org/doc/current/lib/module-getopt.html)
has the following example:
    for o, a in opts:
        if o in ("-h", "--help"):
            usage()
            sys.exit()
        if o in ("-o", "--output"):
            output = a
    # ...
As a python newbie, I was trying to use this example,
but I had only short options in my program.  It took me
quite a bit of confusion to realize that the third form
below is correct.  While this may be obvious to people
experienced in python (that this actually must be a
tuple of a single element, which only the third if()
statement below creates), it caused me quite a bit of
frustration. 
for o, a in opts:
    if o in "-i":
        input_file = a
    if(o in ("-o"):
        output_file = a
    if(o in ("-s",):
        source_file = a
    if(o in ("-h", "--help")):
        print_usage()
        sys.exit()

I would like to suggest that the example in the
documentation include three if o in ... statements: one
with only a short option, one with both, and one with
only a long option.

-ben
sourceforge@green.hartshorne.net

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729096&group_id=5470


From noreply@sourceforge.net  Mon Apr 28 19:47:53 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 28 Apr 2003 11:47:53 -0700
Subject: [Python-bugs-list] [ python-Bugs-729103 ] super bug
Message-ID: <E19ADfN-0003U3-00@sc8-sf-web2.sourceforge.net>

Bugs item #729103, was opened at 2003-04-28 14:47
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729103&group_id=5470

Category: Type/class unification
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Michele Simionato (michele_s)
Assigned to: Nobody/Anonymous (nobody)
Summary: super bug

Initial Comment:
I see that in Python 2.3b1 many problems of super
have been fixed, but this one is still there:
I cannot retrieve the __name__ of a super object.
This generates problems with pydoc, for instance:

>>> class C(B):
...     sup=super(B)
>>> help(C)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.3/site.py", line 293, in
__call__
    return pydoc.help(*args, **kwds)
  File "/usr/local/lib/python2.3/pydoc.py", line 1539,
in __call__
    self.help(request)
  File "/usr/local/lib/python2.3/pydoc.py", line 1575,
in help
    else: doc(request, 'Help on %s:')
  File "/usr/local/lib/python2.3/pydoc.py", line 1368,
in doc
    pager(title % desc + '\n\n' + text.document(object,
name))
  File "/usr/local/lib/python2.3/pydoc.py", line 279,
in document
    if inspect.isclass(object): return
self.docclass(*args)
  File "/usr/local/lib/python2.3/pydoc.py", line 1122,
in docclass
    lambda t: t[1] == 'method')
  File "/usr/local/lib/python2.3/pydoc.py", line 1057,
in spill
    name, mod, object))
  File "/usr/local/lib/python2.3/pydoc.py", line 280,
in document
    if inspect.isroutine(object): return
self.docroutine(*args)
  File "/usr/local/lib/python2.3/pydoc.py", line 1145,
in docroutine
    realname = object.__name__
AttributeError: 'super' object has no attribute
'__name__'

P.S. I seem to remember I already submitted this
bug (or feature request, as you wish ;) but I don't
find it in bugtracker and I had no feedback; maybe
it wasn't sent at all due to some connection problem.
If not, please accept my apologies.

    Michele Simionato

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729103&group_id=5470


From noreply@sourceforge.net  Mon Apr 28 20:33:53 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 28 Apr 2003 12:33:53 -0700
Subject: [Python-bugs-list] [ python-Bugs-722413 ] _winreg doesn't handle NULL bytes in value names
Message-ID: <E19AENt-0004mR-00@sc8-sf-web4.sourceforge.net>

Bugs item #722413, was opened at 2003-04-16 06:54
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=722413&group_id=5470

Category: Windows
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Hammond (mhammond)
>Assigned to: Mark Hammond (mhammond)
Summary: _winreg doesn't handle NULL bytes in value names

Initial Comment:
Reported via pywin32 mailing list

>>We are trying to read all of the data under specific
registry keys.
>>Unfortunately, we cannot seem to enumerate keys or values
>>correctly if
>>the name contains Unicode or binary characters.
>>    
>>
>
>Eeek - you mean the *value* names can contain embedded
NULL characters?!
>  
>
The value names can contain NULL bytes. The NT/2K/XP
registry is all 
MBCS. The value names cannot contain MBCS character 0.
The key names



----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2003-04-28 15:33

Message:
Logged In: YES 
user_id=31435

Reassigned to MarkH.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=722413&group_id=5470


From noreply@sourceforge.net  Mon Apr 28 20:55:05 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 28 Apr 2003 12:55:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-678250 ] test_mmap failling on AIX
Message-ID: <E19AEiP-0006Bd-00@sc8-sf-web4.sourceforge.net>

Bugs item #678250, was opened at 2003-01-31 12:44
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678250&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
>Assigned to: Martin v. Löwis (loewis)
Summary: test_mmap failling on AIX

Initial Comment:
test_mmap is failing on a flush while trying to do:
  Copy-on-write memory map data not written correctly

The problem is that the mmap is opened with 
ACCESS_COPY.  This translates to MAP_PRIVATE.  
On AIX, the msync man page says:  "When the 
MS_SYNC and MAP_PRIVATE flags both are used, the 
msync subroutine returns an errno value of EINVAL."

I'm not sure what the correct fix should be.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2003-04-28 15:55

Message:
Logged In: YES 
user_id=31435

Sorry, I've had nothing to do with mmap beyond fixing bugs.  
The "access" feature was due to Jay Miller, although I believe 
I checked in his patch.

Martin, I don't understand why you think it's reasonable for 
flush to complain here:  the mmap is open for writing, so 
what's surprising about expecting to be able to flush after a 
write?  Simply that there's no associated file, due to copy-on-
write?  Then user code would have to be acutely aware of how 
an mmap'ed object was opened, just to avoid nuisance 
complaints when they flush after writing.

So that's a third alternative:  alter the implementation to make 
mmap.flush() do nothing when an mmap object was opened 
as copy-on-write.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-04 02:00

Message:
Logged In: YES 
user_id=21627

I think the test is somewhat bogus: It tries to check that
modification to an ACCESS_COPY doesn't modify the underlying
file, but assumes that .flush becomes a no-op, even though
an exception is more reasonable (IMO; errors should never
pass silently).

So I see two options: Declare that .flush() always raises an
exception (and modify implementations that don't produce an
exception accordingly), or declare that aspect to be
system-dependent, and modify the test (and the
documentation) to expect and ignore an exception.

Assigning to Tim, as he incorporated that feature into mmap.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678250&group_id=5470


From noreply@sourceforge.net  Mon Apr 28 21:57:37 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 28 Apr 2003 13:57:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-708901 ] Lineno calculation sometimes broken
Message-ID: <E19AFgv-0001rc-00@sc8-sf-web1.sourceforge.net>

Bugs item #708901, was opened at 2003-03-24 12:09
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=708901&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
>Assigned to: Michael Hudson (mwh)
Summary: Lineno calculation sometimes broken

Initial Comment:
I'm running the win32 version of Python 2.3a2.  I ran into 
this when I got a traceback pointing to a wrong 
linenumber.  It also messes up debugging in 
Pythonwin.  Anyway, you can see from the disassembly 
below that something goes seriously amiss when the 
code reaches the FOR_ITER:


>>> import httplib
>>> import dis
>>> dis.dis(httplib.HTTPConnection.connect)
524           0 LOAD_CONST

              3 STORE_FAST

525           6 SETUP_LOOP
              9 LOAD_GLOBAL
             12 LOAD_ATTR
             15 LOAD_FAST
             18 LOAD_ATTR
             21 LOAD_FAST
             24 LOAD_ATTR
             27 LOAD_CONST

526          30 LOAD_GLOBAL
             33 LOAD_ATTR
             36 CALL_FUNCTION
             39 GET_ITER

781     >>   40 FOR_ITER


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2003-04-28 16:57

Message:
Logged In: YES 
user_id=31435

Well, this one's a mess.  The patch changes debugger 
behavior in that it no longer stops on the 'for' each time 
around the loop.  I had better luck leaving the com_set_lineno
() call where it is now, but changing its second argument 
instead, like so:

	com_set_lineno(c, c->c_last_line);

Then it stops on the "for" each time around the loop, but 
pointing at the last line of the "for" (in your whittled example, 
on the line ending with "10):").  Better than nothing.

Unfortunately, the encoding of lnotab assumes that line 
numbers and byte offsets are presented in monotonically non-
decreasing order.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-29 18:38

Message:
Logged In: YES 
user_id=33168

The patch worked for me on Linux, after I removed
httplib.pyc. :-)
Does it jump to the right line in the debugger whe iterating
through a loop?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-03-24 12:43

Message:
Logged In: YES 
user_id=6656

Stupid minimal testcase:

def f():
    for res in range(1,
                     10):
        pass

Tim, you've looked at compile.c today <wink>, can you check
the attached patch?


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-03-24 12:36

Message:
Logged In: YES 
user_id=6656

Waddya know, it's not my fault.

For some reason, something is trying to store a negative
line_incr into the c_lnotab which gets masked into a line
increment of 255.  Fun.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-03-24 12:16

Message:
Logged In: YES 
user_id=6656

yow!  probably my fault.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=708901&group_id=5470


From noreply@sourceforge.net  Mon Apr 28 22:34:09 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 28 Apr 2003 14:34:09 -0700
Subject: [Python-bugs-list] [ python-Bugs-708205 ] math.fabs documentation is misleading
Message-ID: <E19AGGH-0004Wp-00@sc8-sf-web3.sourceforge.net>

Bugs item #708205, was opened at 2003-03-22 19:26
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=708205&group_id=5470

Category: Documentation
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: George Yoshida (quiver)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: math.fabs documentation is misleading

Initial Comment:
math.fabs documentation is misleading.
It says,
"Return the absolute value of the floating point number 
x. ".
but I think it should look like this:
"Return the absolute value of x as a float."

See the code below.

>>> from math import *
>>> abs(3)
3
>>> fabs(3)
3.0

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2003-04-28 17:34

Message:
Logged In: YES 
user_id=31435

Assigned to Fred.  I removed words from the fabs docs, for 
consistency with the other descriptions, and added a note 
that *all* functions in this module return floats.  There's 
nothing special about math.fabs() in this respect, and I don't 
want to end every description with "as a float".  If you're 
happy with this, please close the bug.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=708205&group_id=5470


From noreply@sourceforge.net  Mon Apr 28 22:41:02 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 28 Apr 2003 14:41:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-708205 ] math.fabs documentation is misleading
Message-ID: <E19AGMw-0006Qd-00@sc8-sf-web2.sourceforge.net>

Bugs item #708205, was opened at 2003-03-22 19:26
Message generated for change (Settings changed) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=708205&group_id=5470

Category: Documentation
Group: Python 2.2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: George Yoshida (quiver)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: math.fabs documentation is misleading

Initial Comment:
math.fabs documentation is misleading.
It says,
"Return the absolute value of the floating point number 
x. ".
but I think it should look like this:
"Return the absolute value of x as a float."

See the code below.

>>> from math import *
>>> abs(3)
3
>>> fabs(3)
3.0

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-04-28 17:34

Message:
Logged In: YES 
user_id=31435

Assigned to Fred.  I removed words from the fabs docs, for 
consistency with the other descriptions, and added a note 
that *all* functions in this module return floats.  There's 
nothing special about math.fabs() in this respect, and I don't 
want to end every description with "as a float".  If you're 
happy with this, please close the bug.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=708205&group_id=5470


From noreply@sourceforge.net  Tue Apr 29 00:03:13 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 28 Apr 2003 16:03:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-729236 ] building readline module on Irix 6.5
Message-ID: <E19AHeT-0008Q4-00@sc8-sf-web4.sourceforge.net>

Bugs item #729236, was opened at 2003-04-28 23:03
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729236&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: alexandre gillet (gillet)
Assigned to: Nobody/Anonymous (nobody)
Summary: building readline module on Irix 6.5

Initial Comment:
I am trying to build  Python2.3b1 on a sgi Irix 6.5 using
MIPSpro Compilers: Version 7.30

I can't get the readline module to build. I get the
following error:
cc  -OPT:Olimit=0 -DNDEBUG -O -I. -I../Include 
-I/mgl/prog/share/include/ -c ../Modules/readline.c -o
Modules/readline.o
cc-1119 cc: ERROR File = ../Modules/readline.c, Line = 587
  The "return" expression type differs from the
function return type.

        return completion_matches(text, *on_completion);
               ^

cc-1552 cc: WARNING File = ../Modules/readline.c, Line
= 732
  The variable "m" is set but never used.

        PyObject *m;
                  ^

1 error detected in the compilation of
"../Modules/readline.c".
gmake: *** [Modules/readline.o] Error 2


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729236&group_id=5470


From noreply@sourceforge.net  Tue Apr 29 00:04:12 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 28 Apr 2003 16:04:12 -0700
Subject: [Python-bugs-list] [ python-Bugs-729236 ] building readline module fails on Irix 6.5
Message-ID: <E19AHfQ-0002Ee-00@sc8-sf-web2.sourceforge.net>

Bugs item #729236, was opened at 2003-04-28 23:03
Message generated for change (Settings changed) made by gillet
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729236&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: alexandre gillet (gillet)
Assigned to: Nobody/Anonymous (nobody)
>Summary: building readline module fails on Irix 6.5

Initial Comment:
I am trying to build  Python2.3b1 on a sgi Irix 6.5 using
MIPSpro Compilers: Version 7.30

I can't get the readline module to build. I get the
following error:
cc  -OPT:Olimit=0 -DNDEBUG -O -I. -I../Include 
-I/mgl/prog/share/include/ -c ../Modules/readline.c -o
Modules/readline.o
cc-1119 cc: ERROR File = ../Modules/readline.c, Line = 587
  The "return" expression type differs from the
function return type.

        return completion_matches(text, *on_completion);
               ^

cc-1552 cc: WARNING File = ../Modules/readline.c, Line
= 732
  The variable "m" is set but never used.

        PyObject *m;
                  ^

1 error detected in the compilation of
"../Modules/readline.c".
gmake: *** [Modules/readline.o] Error 2


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729236&group_id=5470


From noreply@sourceforge.net  Tue Apr 29 03:07:42 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 28 Apr 2003 19:07:42 -0700
Subject: [Python-bugs-list] [ python-Bugs-729297 ] What's new in Python2.3b1 HTML generation.
Message-ID: <E19AKX0-0000Ds-00@sc8-sf-web1.sourceforge.net>

Bugs item #729297, was opened at 2003-04-28 22:07
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729297&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexis Layton (alayton)
Assigned to: Nobody/Anonymous (nobody)
Summary: What's new in Python2.3b1 HTML generation.

Initial Comment:
Whenever a section name includes a style change, the
llinks generated for it are truncated.

To reproduce:
  Go to section "5. PEP 278: Universal New Line Support"

Notice the next link: "6. PEP 279: The".  The link
should read
"6. PEP 279: The enumerate() Built-In Function."  Similar
problems happen with links for sections 7 and 8.

This problem does not happen in the table of contents
however.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729297&group_id=5470


From noreply@sourceforge.net  Tue Apr 29 03:12:26 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 28 Apr 2003 19:12:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-729300 ] Compiling --with-pydebug=yes --with-threads=no fails
Message-ID: <E19AKba-0001LT-00@sc8-sf-web2.sourceforge.net>

Bugs item #729300, was opened at 2003-04-28 21:12
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729300&group_id=5470

Category: Threads
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: logistix (logistix)
Assigned to: Nobody/Anonymous (nobody)
Summary: Compiling --with-pydebug=yes --with-threads=no fails

Initial Comment:
A PyGILstate_ function is called outside of a 
WITH_THREADS #ifdef.  Of course all the PyGIL 
functions only exist when threads are enabled. 
 
The attached patch fixes it, although I don't know enough  
about the new GIL Implementation to verify that it's  
'correct'.  

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729300&group_id=5470


From noreply@sourceforge.net  Tue Apr 29 04:41:18 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 28 Apr 2003 20:41:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-729317 ] comparing versions - one a float
Message-ID: <E19ALza-0003Hz-00@sc8-sf-web3.sourceforge.net>

Bugs item #729317, was opened at 2003-04-29 03:41
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729317&group_id=5470

Category: Tkinter
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Larry Bugbee (thunderbug)
Assigned to: Nobody/Anonymous (nobody)
Summary: comparing versions - one a float

Initial Comment:
Tkinter.py, line 1572, 2.3b1 from python.org....

Attempts to compare tcl_version with
_tkinter.TCL_VERSION.  Both have the same value, 8.4,
but...

    tcl_version is a <type 'float'> and
    _tkinter.TCL_VERSION is a <type 'str'>

Temporary kludge: wrap it...    str(tcl_version)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729317&group_id=5470


From noreply@sourceforge.net  Tue Apr 29 05:38:15 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 28 Apr 2003 21:38:15 -0700
Subject: [Python-bugs-list] [ python-Bugs-729096 ] getopt online documentation example improvement
Message-ID: <E19AMsh-00054u-00@sc8-sf-web3.sourceforge.net>

Bugs item #729096, was opened at 2003-04-28 13:37
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729096&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Ben Hartshorne (b655321)
Assigned to: Nobody/Anonymous (nobody)
Summary: getopt online documentation example improvement

Initial Comment:
The online documentation for the getopt module
(http://www.python.org/doc/current/lib/module-getopt.html)
has the following example:
    for o, a in opts:
        if o in ("-h", "--help"):
            usage()
            sys.exit()
        if o in ("-o", "--output"):
            output = a
    # ...
As a python newbie, I was trying to use this example,
but I had only short options in my program.  It took me
quite a bit of confusion to realize that the third form
below is correct.  While this may be obvious to people
experienced in python (that this actually must be a
tuple of a single element, which only the third if()
statement below creates), it caused me quite a bit of
frustration. 
for o, a in opts:
    if o in "-i":
        input_file = a
    if(o in ("-o"):
        output_file = a
    if(o in ("-s",):
        source_file = a
    if(o in ("-h", "--help")):
        print_usage()
        sys.exit()

I would like to suggest that the example in the
documentation include three if o in ... statements: one
with only a short option, one with both, and one with
only a long option.

-ben
sourceforge@green.hartshorne.net

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-28 23:38

Message:
Logged In: YES 
user_id=80475

Fixed example.
See libgetopt.tex 1.21 and 1.19.8.1

Thanks for the bug report!


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729096&group_id=5470


From noreply@sourceforge.net  Tue Apr 29 06:00:08 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 28 Apr 2003 22:00:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-729317 ] comparing versions - one a float
Message-ID: <E19ANDs-0006ES-00@sc8-sf-web1.sourceforge.net>

Bugs item #729317, was opened at 2003-04-28 22:41
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729317&group_id=5470

Category: Tkinter
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Larry Bugbee (thunderbug)
>Assigned to: Eric S. Raymond (esr)
Summary: comparing versions - one a float

Initial Comment:
Tkinter.py, line 1572, 2.3b1 from python.org....

Attempts to compare tcl_version with
_tkinter.TCL_VERSION.  Both have the same value, 8.4,
but...

    tcl_version is a <type 'float'> and
    _tkinter.TCL_VERSION is a <type 'str'>

Temporary kludge: wrap it...    str(tcl_version)


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-29 00:00

Message:
Logged In: YES 
user_id=80475

Eric,  I think this was your change.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729317&group_id=5470


From noreply@sourceforge.net  Tue Apr 29 06:05:55 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 28 Apr 2003 22:05:55 -0700
Subject: [Python-bugs-list] [ python-Bugs-729297 ] What's new in Python2.3b1 HTML generation.
Message-ID: <E19ANJT-0005yz-00@sc8-sf-web3.sourceforge.net>

Bugs item #729297, was opened at 2003-04-28 21:07
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729297&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexis Layton (alayton)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: What's new in Python2.3b1 HTML generation.

Initial Comment:
Whenever a section name includes a style change, the
llinks generated for it are truncated.

To reproduce:
  Go to section "5. PEP 278: Universal New Line Support"

Notice the next link: "6. PEP 279: The".  The link
should read
"6. PEP 279: The enumerate() Built-In Function."  Similar
problems happen with links for sections 7 and 8.

This problem does not happen in the table of contents
however.


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-29 00:05

Message:
Logged In: YES 
user_id=80475

It looks like it is always grabbing the first word even when 
there is no style change.  Looking back at Py2.2.2, it also 
occurred there.  I'm this it is a TeX macro issue for Fred.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729297&group_id=5470


From noreply@sourceforge.net  Tue Apr 29 12:40:12 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 29 Apr 2003 04:40:12 -0700
Subject: [Python-bugs-list] [ python-Bugs-708901 ] Lineno calculation sometimes broken
Message-ID: <E19ATT2-0008Tp-00@sc8-sf-web3.sourceforge.net>

Bugs item #708901, was opened at 2003-03-24 17:09
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=708901&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Michael Hudson (mwh)
Summary: Lineno calculation sometimes broken

Initial Comment:
I'm running the win32 version of Python 2.3a2.  I ran into 
this when I got a traceback pointing to a wrong 
linenumber.  It also messes up debugging in 
Pythonwin.  Anyway, you can see from the disassembly 
below that something goes seriously amiss when the 
code reaches the FOR_ITER:


>>> import httplib
>>> import dis
>>> dis.dis(httplib.HTTPConnection.connect)
524           0 LOAD_CONST

              3 STORE_FAST

525           6 SETUP_LOOP
              9 LOAD_GLOBAL
             12 LOAD_ATTR
             15 LOAD_FAST
             18 LOAD_ATTR
             21 LOAD_FAST
             24 LOAD_ATTR
             27 LOAD_CONST

526          30 LOAD_GLOBAL
             33 LOAD_ATTR
             36 CALL_FUNCTION
             39 GET_ITER

781     >>   40 FOR_ITER


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2003-04-29 12:40

Message:
Logged In: YES 
user_id=6656

> Well, this one's a mess.

Hadn't noticed that <wink>.

I had become aware that my patch wasn't the right answer. 
I'll try your idea when cvs up finishes...

> Unfortunately, the encoding of lnotab assumes that line 
> numbers and byte offsets are presented in monotonically 
> non-decreasing order.

Presumably this *could* change, if we were sufficiently
motivated.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-04-28 21:57

Message:
Logged In: YES 
user_id=31435

Well, this one's a mess.  The patch changes debugger 
behavior in that it no longer stops on the 'for' each time 
around the loop.  I had better luck leaving the com_set_lineno
() call where it is now, but changing its second argument 
instead, like so:

	com_set_lineno(c, c->c_last_line);

Then it stops on the "for" each time around the loop, but 
pointing at the last line of the "for" (in your whittled example, 
on the line ending with "10):").  Better than nothing.

Unfortunately, the encoding of lnotab assumes that line 
numbers and byte offsets are presented in monotonically non-
decreasing order.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-29 23:38

Message:
Logged In: YES 
user_id=33168

The patch worked for me on Linux, after I removed
httplib.pyc. :-)
Does it jump to the right line in the debugger whe iterating
through a loop?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-03-24 17:43

Message:
Logged In: YES 
user_id=6656

Stupid minimal testcase:

def f():
    for res in range(1,
                     10):
        pass

Tim, you've looked at compile.c today <wink>, can you check
the attached patch?


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-03-24 17:36

Message:
Logged In: YES 
user_id=6656

Waddya know, it's not my fault.

For some reason, something is trying to store a negative
line_incr into the c_lnotab which gets masked into a line
increment of 255.  Fun.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-03-24 17:16

Message:
Logged In: YES 
user_id=6656

yow!  probably my fault.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=708901&group_id=5470


From noreply@sourceforge.net  Tue Apr 29 12:42:48 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 29 Apr 2003 04:42:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-729300 ] Compiling --with-pydebug=yes --with-threads=no fails
Message-ID: <E19ATVY-0000BJ-00@sc8-sf-web3.sourceforge.net>

Bugs item #729300, was opened at 2003-04-29 04:12
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729300&group_id=5470

Category: Threads
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: logistix (logistix)
>Assigned to: Mark Hammond (mhammond)
Summary: Compiling --with-pydebug=yes --with-threads=no fails

Initial Comment:
A PyGILstate_ function is called outside of a 
WITH_THREADS #ifdef.  Of course all the PyGIL 
functions only exist when threads are enabled. 
 
The attached patch fixes it, although I don't know enough  
about the new GIL Implementation to verify that it's  
'correct'.  

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-04-29 13:42

Message:
Logged In: YES 
user_id=21627

Mark, can you take a look?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729300&group_id=5470


From noreply@sourceforge.net  Tue Apr 29 12:44:05 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 29 Apr 2003 04:44:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-729236 ] building readline module fails on Irix 6.5
Message-ID: <E19ATWn-0000Gw-00@sc8-sf-web3.sourceforge.net>

Bugs item #729236, was opened at 2003-04-29 01:03
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729236&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: alexandre gillet (gillet)
Assigned to: Nobody/Anonymous (nobody)
Summary: building readline module fails on Irix 6.5

Initial Comment:
I am trying to build  Python2.3b1 on a sgi Irix 6.5 using
MIPSpro Compilers: Version 7.30

I can't get the readline module to build. I get the
following error:
cc  -OPT:Olimit=0 -DNDEBUG -O -I. -I../Include 
-I/mgl/prog/share/include/ -c ../Modules/readline.c -o
Modules/readline.o
cc-1119 cc: ERROR File = ../Modules/readline.c, Line = 587
  The "return" expression type differs from the
function return type.

        return completion_matches(text, *on_completion);
               ^

cc-1552 cc: WARNING File = ../Modules/readline.c, Line
= 732
  The variable "m" is set but never used.

        PyObject *m;
                  ^

1 error detected in the compilation of
"../Modules/readline.c".
gmake: *** [Modules/readline.o] Error 2


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-04-29 13:44

Message:
Logged In: YES 
user_id=21627

What is your readline version?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729236&group_id=5470


From noreply@sourceforge.net  Tue Apr 29 12:49:23 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 29 Apr 2003 04:49:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-729300 ] Compiling --with-pydebug=yes --with-threads=no fails
Message-ID: <E19ATbv-0002c7-00@sc8-sf-web2.sourceforge.net>

Bugs item #729300, was opened at 2003-04-29 12:12
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729300&group_id=5470

Category: Threads
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: logistix (logistix)
>Assigned to: Martin v. Löwis (loewis)
Summary: Compiling --with-pydebug=yes --with-threads=no fails

Initial Comment:
A PyGILstate_ function is called outside of a 
WITH_THREADS #ifdef.  Of course all the PyGIL 
functions only exist when threads are enabled. 
 
The attached patch fixes it, although I don't know enough  
about the new GIL Implementation to verify that it's  
'correct'.  

----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2003-04-29 21:49

Message:
Logged In: YES 
user_id=14198

Thanks Martin - please check this in.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-04-29 21:42

Message:
Logged In: YES 
user_id=21627

Mark, can you take a look?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729300&group_id=5470


From noreply@sourceforge.net  Tue Apr 29 15:57:14 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 29 Apr 2003 07:57:14 -0700
Subject: [Python-bugs-list] [ python-Bugs-728511 ] Opening a nonexistent tar file in mode r:bz2 seg faults
Message-ID: <E19AWXi-0005zT-00@sc8-sf-web1.sourceforge.net>

Bugs item #728511, was opened at 2003-04-27 17:37
Message generated for change (Comment added) made by niemeyer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728511&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Gary Herron (herron)
Assigned to: Nobody/Anonymous (nobody)
Summary: Opening a nonexistent tar file in mode r:bz2 seg faults

Initial Comment:
 
Running Python 2.3 beta 1 on a Linux (RH9) system, I get a 
segmentation fault when I mistakenly open a nonexistent 
file in mode 
"r:bz2". 
 
>>> import tarfile 
>>> tar = tarfile.open("non-existent-file", "r:bz2") 
Segmentation fault 
 
If the mode is "r:gz" then the result is (properly) 
  No such file ... 
 
And, of course, all is fine if the file *does* exist. 
 
 

----------------------------------------------------------------------

>Comment By: Gustavo Niemeyer (niemeyer)
Date: 2003-04-29 14:57

Message:
Logged In: YES 
user_id=7887

Fixed with acceptance of patch #728656.

Thanks for reporting.

----------------------------------------------------------------------

Comment By: logistix (logistix)
Date: 2003-04-27 23:27

Message:
Logged In: YES 
user_id=699438

bz2module's cleanup code used a Py_DECREF when it 
should've used an Py_XDECREF.

Patch 728656 posted.

Error now replies "Read Error: not a bzip2 file"



----------------------------------------------------------------------

Comment By: Gary Herron (herron)
Date: 2003-04-27 18:21

Message:
Logged In: YES 
user_id=395736

Similarily on windows,  with the same code, on gets an 
Application Error popup with the message 
 
  The instruction at "..." referenced memory at "0x00000000". ... 
 
 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728511&group_id=5470


From noreply@sourceforge.net  Tue Apr 29 16:19:08 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 29 Apr 2003 08:19:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-729622 ] line tracing hook errors
Message-ID: <E19AWsu-0007Pt-00@sc8-sf-web1.sourceforge.net>

Bugs item #729622, was opened at 2003-04-29 15:19
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729622&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: line tracing hook errors

Initial Comment:
The new line tracing hook in ceval.c:822 doesn't
correctly handle errors raised by the hook functions.
Mea culpa, the error was in a patch I submitted.

The problem is that when maybe_call_line_trace()
returns an error, f->f_stacktop is not correctly reset
to NULL. Then the stack is emptied by the usual
exception mecanisms below, but f->f_stacktop still
points somewhere in the stack. This makes the frame
destructor and GC visitors crash.

The equivalent code in 2.2.2 resets f->f_stacktop to
NULL in all cases. The attached patch for 2.3b1 does
the same.

The code is very slightly different than what we have
in 2.2.2 to allow programs like Psyco to work around
the bug in a manner that works with all 2.3 versions --
both with and without the patch. Still, the patch is
necessary : any line hook function in Python that
raises an exception can crash the interpreter.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729622&group_id=5470


From noreply@sourceforge.net  Tue Apr 29 16:24:52 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 29 Apr 2003 08:24:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-729622 ] line tracing hook errors
Message-ID: <E19AWyS-0007ZH-00@sc8-sf-web3.sourceforge.net>

Bugs item #729622, was opened at 2003-04-29 16:19
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729622&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
>Assigned to: Michael Hudson (mwh)
Summary: line tracing hook errors

Initial Comment:
The new line tracing hook in ceval.c:822 doesn't
correctly handle errors raised by the hook functions.
Mea culpa, the error was in a patch I submitted.

The problem is that when maybe_call_line_trace()
returns an error, f->f_stacktop is not correctly reset
to NULL. Then the stack is emptied by the usual
exception mecanisms below, but f->f_stacktop still
points somewhere in the stack. This makes the frame
destructor and GC visitors crash.

The equivalent code in 2.2.2 resets f->f_stacktop to
NULL in all cases. The attached patch for 2.3b1 does
the same.

The code is very slightly different than what we have
in 2.2.2 to allow programs like Psyco to work around
the bug in a manner that works with all 2.3 versions --
both with and without the patch. Still, the patch is
necessary : any line hook function in Python that
raises an exception can crash the interpreter.


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2003-04-29 16:24

Message:
Logged In: YES 
user_id=6656

is this possible to write a test case for?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729622&group_id=5470


From noreply@sourceforge.net  Tue Apr 29 16:42:51 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 29 Apr 2003 08:42:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-729622 ] line tracing hook errors
Message-ID: <E19AXFr-0000XP-00@sc8-sf-web1.sourceforge.net>

Bugs item #729622, was opened at 2003-04-29 15:19
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729622&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Michael Hudson (mwh)
Summary: line tracing hook errors

Initial Comment:
The new line tracing hook in ceval.c:822 doesn't
correctly handle errors raised by the hook functions.
Mea culpa, the error was in a patch I submitted.

The problem is that when maybe_call_line_trace()
returns an error, f->f_stacktop is not correctly reset
to NULL. Then the stack is emptied by the usual
exception mecanisms below, but f->f_stacktop still
points somewhere in the stack. This makes the frame
destructor and GC visitors crash.

The equivalent code in 2.2.2 resets f->f_stacktop to
NULL in all cases. The attached patch for 2.3b1 does
the same.

The code is very slightly different than what we have
in 2.2.2 to allow programs like Psyco to work around
the bug in a manner that works with all 2.3 versions --
both with and without the patch. Still, the patch is
necessary : any line hook function in Python that
raises an exception can crash the interpreter.


----------------------------------------------------------------------

>Comment By: Armin Rigo (arigo)
Date: 2003-04-29 15:42

Message:
Logged In: YES 
user_id=4771

yes, here is one (it segfaults the interpreter).

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-04-29 15:24

Message:
Logged In: YES 
user_id=6656

is this possible to write a test case for?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729622&group_id=5470


From noreply@sourceforge.net  Tue Apr 29 17:19:34 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 29 Apr 2003 09:19:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-729622 ] line tracing hook errors
Message-ID: <E19AXpO-00032N-00@sc8-sf-web1.sourceforge.net>

Bugs item #729622, was opened at 2003-04-29 16:19
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729622&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Michael Hudson (mwh)
Summary: line tracing hook errors

Initial Comment:
The new line tracing hook in ceval.c:822 doesn't
correctly handle errors raised by the hook functions.
Mea culpa, the error was in a patch I submitted.

The problem is that when maybe_call_line_trace()
returns an error, f->f_stacktop is not correctly reset
to NULL. Then the stack is emptied by the usual
exception mecanisms below, but f->f_stacktop still
points somewhere in the stack. This makes the frame
destructor and GC visitors crash.

The equivalent code in 2.2.2 resets f->f_stacktop to
NULL in all cases. The attached patch for 2.3b1 does
the same.

The code is very slightly different than what we have
in 2.2.2 to allow programs like Psyco to work around
the bug in a manner that works with all 2.3 versions --
both with and without the patch. Still, the patch is
necessary : any line hook function in Python that
raises an exception can crash the interpreter.


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2003-04-29 17:19

Message:
Logged In: YES 
user_id=6656

Ok, this is checked in as 

Lib/test/test_trace.py revision 1.8
Python/ceval.c revision 2.362

(amusing: i was running cvs up while the test suite, and the
second trip round the tests got the new bz2 tests -- which
dumped core.  had me worried for a minute...)

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2003-04-29 16:42

Message:
Logged In: YES 
user_id=4771

yes, here is one (it segfaults the interpreter).

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-04-29 16:24

Message:
Logged In: YES 
user_id=6656

is this possible to write a test case for?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729622&group_id=5470


From noreply@sourceforge.net  Tue Apr 29 18:03:52 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 29 Apr 2003 10:03:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-729622 ] line tracing hook errors
Message-ID: <E19AYWG-0006qV-00@sc8-sf-web1.sourceforge.net>

Bugs item #729622, was opened at 2003-04-29 16:19
Message generated for change (Settings changed) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729622&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Michael Hudson (mwh)
Summary: line tracing hook errors

Initial Comment:
The new line tracing hook in ceval.c:822 doesn't
correctly handle errors raised by the hook functions.
Mea culpa, the error was in a patch I submitted.

The problem is that when maybe_call_line_trace()
returns an error, f->f_stacktop is not correctly reset
to NULL. Then the stack is emptied by the usual
exception mecanisms below, but f->f_stacktop still
points somewhere in the stack. This makes the frame
destructor and GC visitors crash.

The equivalent code in 2.2.2 resets f->f_stacktop to
NULL in all cases. The attached patch for 2.3b1 does
the same.

The code is very slightly different than what we have
in 2.2.2 to allow programs like Psyco to work around
the bug in a manner that works with all 2.3 versions --
both with and without the patch. Still, the patch is
necessary : any line hook function in Python that
raises an exception can crash the interpreter.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-04-29 17:19

Message:
Logged In: YES 
user_id=6656

Ok, this is checked in as 

Lib/test/test_trace.py revision 1.8
Python/ceval.c revision 2.362

(amusing: i was running cvs up while the test suite, and the
second trip round the tests got the new bz2 tests -- which
dumped core.  had me worried for a minute...)

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2003-04-29 16:42

Message:
Logged In: YES 
user_id=4771

yes, here is one (it segfaults the interpreter).

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-04-29 16:24

Message:
Logged In: YES 
user_id=6656

is this possible to write a test case for?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729622&group_id=5470


From noreply@sourceforge.net  Tue Apr 29 18:08:17 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 29 Apr 2003 10:08:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-708901 ] Lineno calculation sometimes broken
Message-ID: <E19AYaX-0007FN-00@sc8-sf-web1.sourceforge.net>

Bugs item #708901, was opened at 2003-03-24 17:09
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=708901&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Michael Hudson (mwh)
Summary: Lineno calculation sometimes broken

Initial Comment:
I'm running the win32 version of Python 2.3a2.  I ran into 
this when I got a traceback pointing to a wrong 
linenumber.  It also messes up debugging in 
Pythonwin.  Anyway, you can see from the disassembly 
below that something goes seriously amiss when the 
code reaches the FOR_ITER:


>>> import httplib
>>> import dis
>>> dis.dis(httplib.HTTPConnection.connect)
524           0 LOAD_CONST

              3 STORE_FAST

525           6 SETUP_LOOP
              9 LOAD_GLOBAL
             12 LOAD_ATTR
             15 LOAD_FAST
             18 LOAD_ATTR
             21 LOAD_FAST
             24 LOAD_ATTR
             27 LOAD_CONST

526          30 LOAD_GLOBAL
             33 LOAD_ATTR
             36 CALL_FUNCTION
             39 GET_ITER

781     >>   40 FOR_ITER


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2003-04-29 18:08

Message:
Logged In: YES 
user_id=6656

Used Tim's idea on compile.c.

Knocked test_dis about a bit to include this case, and make
it *slightly* less rampantly fragile.

Python/compile.c revision 2.282
Lib/test/test_trace.py revision 1.3

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-04-29 12:40

Message:
Logged In: YES 
user_id=6656

> Well, this one's a mess.

Hadn't noticed that <wink>.

I had become aware that my patch wasn't the right answer. 
I'll try your idea when cvs up finishes...

> Unfortunately, the encoding of lnotab assumes that line 
> numbers and byte offsets are presented in monotonically 
> non-decreasing order.

Presumably this *could* change, if we were sufficiently
motivated.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-04-28 21:57

Message:
Logged In: YES 
user_id=31435

Well, this one's a mess.  The patch changes debugger 
behavior in that it no longer stops on the 'for' each time 
around the loop.  I had better luck leaving the com_set_lineno
() call where it is now, but changing its second argument 
instead, like so:

	com_set_lineno(c, c->c_last_line);

Then it stops on the "for" each time around the loop, but 
pointing at the last line of the "for" (in your whittled example, 
on the line ending with "10):").  Better than nothing.

Unfortunately, the encoding of lnotab assumes that line 
numbers and byte offsets are presented in monotonically non-
decreasing order.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-29 23:38

Message:
Logged In: YES 
user_id=33168

The patch worked for me on Linux, after I removed
httplib.pyc. :-)
Does it jump to the right line in the debugger whe iterating
through a loop?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-03-24 17:43

Message:
Logged In: YES 
user_id=6656

Stupid minimal testcase:

def f():
    for res in range(1,
                     10):
        pass

Tim, you've looked at compile.c today <wink>, can you check
the attached patch?


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-03-24 17:36

Message:
Logged In: YES 
user_id=6656

Waddya know, it's not my fault.

For some reason, something is trying to store a negative
line_incr into the c_lnotab which gets masked into a line
increment of 255.  Fun.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-03-24 17:16

Message:
Logged In: YES 
user_id=6656

yow!  probably my fault.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=708901&group_id=5470


From noreply@sourceforge.net  Tue Apr 29 19:41:10 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 29 Apr 2003 11:41:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-708901 ] Lineno calculation sometimes broken
Message-ID: <E19Aa2Q-00077L-00@sc8-sf-web4.sourceforge.net>

Bugs item #708901, was opened at 2003-03-24 17:09
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=708901&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Michael Hudson (mwh)
Summary: Lineno calculation sometimes broken

Initial Comment:
I'm running the win32 version of Python 2.3a2.  I ran into 
this when I got a traceback pointing to a wrong 
linenumber.  It also messes up debugging in 
Pythonwin.  Anyway, you can see from the disassembly 
below that something goes seriously amiss when the 
code reaches the FOR_ITER:


>>> import httplib
>>> import dis
>>> dis.dis(httplib.HTTPConnection.connect)
524           0 LOAD_CONST

              3 STORE_FAST

525           6 SETUP_LOOP
              9 LOAD_GLOBAL
             12 LOAD_ATTR
             15 LOAD_FAST
             18 LOAD_ATTR
             21 LOAD_FAST
             24 LOAD_ATTR
             27 LOAD_CONST

526          30 LOAD_GLOBAL
             33 LOAD_ATTR
             36 CALL_FUNCTION
             39 GET_ITER

781     >>   40 FOR_ITER


----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2003-04-29 18:41

Message:
Logged In: YES 
user_id=4771

Someone motivated could go ahead and allow for ranges of
bytecodes to be mapped to *ranges* of line numbers instead
of to just a single line. The debugger would then display
all the lines in the range. The result would be more natural
when single-stepping through multiline statements.

It would also give a clean fix to several problems beside
the one discussed here, e.g. the final POP_TOP of an
if/then/else being mapped to the last line of the 'else'
part, but being reached when the 'then' branch is taken.
This currently works as expected because the line trace hook
is only fired when we reach the first opcode of a range, not
when we jump in the middle of a range -- which is a hack
because it is the cause of Michael's patch not stopping on
the 'for' after each iteration.

I may be the aforementioned motivated person if the solution
seems worthwhile to try :-)

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-04-29 17:08

Message:
Logged In: YES 
user_id=6656

Used Tim's idea on compile.c.

Knocked test_dis about a bit to include this case, and make
it *slightly* less rampantly fragile.

Python/compile.c revision 2.282
Lib/test/test_trace.py revision 1.3

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-04-29 11:40

Message:
Logged In: YES 
user_id=6656

> Well, this one's a mess.

Hadn't noticed that <wink>.

I had become aware that my patch wasn't the right answer. 
I'll try your idea when cvs up finishes...

> Unfortunately, the encoding of lnotab assumes that line 
> numbers and byte offsets are presented in monotonically 
> non-decreasing order.

Presumably this *could* change, if we were sufficiently
motivated.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-04-28 20:57

Message:
Logged In: YES 
user_id=31435

Well, this one's a mess.  The patch changes debugger 
behavior in that it no longer stops on the 'for' each time 
around the loop.  I had better luck leaving the com_set_lineno
() call where it is now, but changing its second argument 
instead, like so:

	com_set_lineno(c, c->c_last_line);

Then it stops on the "for" each time around the loop, but 
pointing at the last line of the "for" (in your whittled example, 
on the line ending with "10):").  Better than nothing.

Unfortunately, the encoding of lnotab assumes that line 
numbers and byte offsets are presented in monotonically non-
decreasing order.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-29 23:38

Message:
Logged In: YES 
user_id=33168

The patch worked for me on Linux, after I removed
httplib.pyc. :-)
Does it jump to the right line in the debugger whe iterating
through a loop?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-03-24 17:43

Message:
Logged In: YES 
user_id=6656

Stupid minimal testcase:

def f():
    for res in range(1,
                     10):
        pass

Tim, you've looked at compile.c today <wink>, can you check
the attached patch?


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-03-24 17:36

Message:
Logged In: YES 
user_id=6656

Waddya know, it's not my fault.

For some reason, something is trying to store a negative
line_incr into the c_lnotab which gets masked into a line
increment of 255.  Fun.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-03-24 17:16

Message:
Logged In: YES 
user_id=6656

yow!  probably my fault.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=708901&group_id=5470


From noreply@sourceforge.net  Tue Apr 29 20:06:59 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 29 Apr 2003 12:06:59 -0700
Subject: [Python-bugs-list] [ python-Bugs-727051 ] valgrind python fails
Message-ID: <E19AaRP-0007xT-00@sc8-sf-web2.sourceforge.net>

Bugs item #727051, was opened at 2003-04-24 17:49
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727051&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ralf W. Grosse-Kunstleve (rwgk)
Assigned to: Nobody/Anonymous (nobody)
Summary: valgrind python fails

Initial Comment:
Platform:
  Redhat 7.3 on Intel Xeon

Packages involved:
  valgrind-1.9.5 (http://developer.kde.org/~sewardj/)
  Python CVS snapshot Thu Apr 24 10:00:00 PDT 2003

valgrind python fails with the following message:

% valgrind python
python: relocation error: /lib/librt.so.1: symbol 
__pthread_clock_settime, version GLIBC_PRIVATE not 
defined in file libpthread.so.0 with link time reference

This is with:

% python
Python 2.3b1 (#1, Apr 24 2003, 10:20:26) 
[GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-113)] on 
linux2
Type "help", "copyright", "credits" or "license" for more 
information.
>>> 

I observed the same problem with Python 2.3a2.

There are no problems when using Python 2.2.1 on the 
exact same platform with the same valgrind installation.


----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2003-04-29 19:06

Message:
Logged In: YES 
user_id=4771

This is documented as a known problem with the librt.so
library on http://developer.kde.org/~sewardj/docs-1.9.5/FAQ.txt.

What I cannot understand is the purpose of binding against
that library on Linux. It ends up in the Makefile for some
indirect reason. I tried without it and the 'make test'
works just fine.

Is it worth any further investigation ? If not, close this
bug track.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-24 19:14

Message:
Logged In: YES 
user_id=33168

I think I got around this problem by adding:

  void __pthread_clock_settime() { }

I think this may be mentioned in the valgrind FAQ/doc.  Or
perhaps, it's something similar which I am confusing.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727051&group_id=5470


From noreply@sourceforge.net  Tue Apr 29 21:01:32 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 29 Apr 2003 13:01:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-729817 ] rexec not listed as dead
Message-ID: <E19AbIC-00015N-00@sc8-sf-web1.sourceforge.net>

Bugs item #729817, was opened at 2003-04-29 13:01
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729817&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Russell Owen (reowen)
Assigned to: Nobody/Anonymous (nobody)
Summary: rexec not listed as dead

Initial Comment:
The docs for 2.3b1 still list rexec as a valid module (although with some warnings of known vulnerabilities). However, the rexec module has apparently been killed (according to the what's new and to my tests of 2.3b1).

-- Russell

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729817&group_id=5470


From noreply@sourceforge.net  Tue Apr 29 21:49:11 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 29 Apr 2003 13:49:11 -0700
Subject: [Python-bugs-list] [ python-Bugs-727051 ] valgrind python fails
Message-ID: <E19Ac2J-0005zy-00@sc8-sf-web2.sourceforge.net>

Bugs item #727051, was opened at 2003-04-24 10:49
Message generated for change (Comment added) made by rwgk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727051&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ralf W. Grosse-Kunstleve (rwgk)
Assigned to: Nobody/Anonymous (nobody)
Summary: valgrind python fails

Initial Comment:
Platform:
  Redhat 7.3 on Intel Xeon

Packages involved:
  valgrind-1.9.5 (http://developer.kde.org/~sewardj/)
  Python CVS snapshot Thu Apr 24 10:00:00 PDT 2003

valgrind python fails with the following message:

% valgrind python
python: relocation error: /lib/librt.so.1: symbol 
__pthread_clock_settime, version GLIBC_PRIVATE not 
defined in file libpthread.so.0 with link time reference

This is with:

% python
Python 2.3b1 (#1, Apr 24 2003, 10:20:26) 
[GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-113)] on 
linux2
Type "help", "copyright", "credits" or "license" for more 
information.
>>> 

I observed the same problem with Python 2.3a2.

There are no problems when using Python 2.2.1 on the 
exact same platform with the same valgrind installation.


----------------------------------------------------------------------

>Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2003-04-29 13:49

Message:
Logged In: YES 
user_id=71407

> Is it worth any further investigation ? If not, close this
> bug track.

valgrind is extremely useful. It seems very important to me that 
Python 2.3 works with valgrind out-of-the-box, just like Python 2.2 
does. I'm afraid otherwise "Why doesn't Python work with 
valgrind?" is going to wind up in the Python FAQ.


> What I cannot understand is the purpose of binding against
> that library on Linux. It ends up in the Makefile for some
> indirect reason. I tried without it and the 'make test'
> works just fine.

I'd be very glad if you could find ways of not binding against 
librt.so if it is not needed.


----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2003-04-29 12:06

Message:
Logged In: YES 
user_id=4771

This is documented as a known problem with the librt.so
library on http://developer.kde.org/~sewardj/docs-1.9.5/FAQ.txt.

What I cannot understand is the purpose of binding against
that library on Linux. It ends up in the Makefile for some
indirect reason. I tried without it and the 'make test'
works just fine.

Is it worth any further investigation ? If not, close this
bug track.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-24 12:14

Message:
Logged In: YES 
user_id=33168

I think I got around this problem by adding:

  void __pthread_clock_settime() { }

I think this may be mentioned in the valgrind FAQ/doc.  Or
perhaps, it's something similar which I am confusing.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727051&group_id=5470


From noreply@sourceforge.net  Tue Apr 29 22:42:38 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 29 Apr 2003 14:42:38 -0700
Subject: [Python-bugs-list] [ python-Bugs-729871 ] MacPython-OS9 eats CPU while waiting for I/O
Message-ID: <E19Acs2-0007Vt-00@sc8-sf-web3.sourceforge.net>

Bugs item #729871, was opened at 2003-04-29 23:42
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729871&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: MacPython-OS9 eats CPU while waiting for I/O

Initial Comment:
MacPython-OS9 gobbles up CPU cycles while it is idle waiting for I/O 
(at least for user input to the terminal). On OS9 this has not much 
effect, because of the other scheduling tricks involved, but on OSX it 
is a real nuisance.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729871&group_id=5470


From noreply@sourceforge.net  Tue Apr 29 22:45:25 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 29 Apr 2003 14:45:25 -0700
Subject: [Python-bugs-list] [ python-Bugs-678217 ] test_logging fails
Message-ID: <E19Acuj-0007hn-00@sc8-sf-web3.sourceforge.net>

Bugs item #678217, was opened at 2003-01-31 17:43
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678217&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_logging fails

Initial Comment:
When I run the test suite, test_logging sometimes
fails.  It misses the following output and gets a bunch
of exceptions llike the one I included at the end.  I
haven't counted, but I'd guess that there's one
traceback for each missing line of output.

test test_logging produced unexpected output:
**********************************************************************
*** lines 489-514 of expected output missing:
- ERR -> CRITICAL: Message 0 (via logrecv.tcp.ERR)
- ERR -> ERROR: Message 1 (via logrecv.tcp.ERR)
- INF -> CRITICAL: Message 2 (via logrecv.tcp.INF)
- INF -> ERROR: Message 3 (via logrecv.tcp.INF)
- INF -> WARN: Message 4 (via logrecv.tcp.INF)
- INF -> INFO: Message 5 (via logrecv.tcp.INF)
- INF.UNDEF -> CRITICAL: Message 6 (via
logrecv.tcp.INF.UNDEF)
- INF.UNDEF -> ERROR: Message 7 (via logrecv.tcp.INF.UNDEF)
- INF.UNDEF -> WARN: Message 8 (via logrecv.tcp.INF.UNDEF)
- INF.UNDEF -> INFO: Message 9 (via logrecv.tcp.INF.UNDEF)
- INF.ERR -> CRITICAL: Message 10 (via logrecv.tcp.INF.ERR)
- INF.ERR -> ERROR: Message 11 (via logrecv.tcp.INF.ERR)
- INF.ERR.UNDEF -> CRITICAL: Message 12 (via
logrecv.tcp.INF.ERR.UNDEF)
- INF.ERR.UNDEF -> ERROR: Message 13 (via
logrecv.tcp.INF.ERR.UNDEF)
- DEB -> CRITICAL: Message 14 (via logrecv.tcp.DEB)
- DEB -> ERROR: Message 15 (via logrecv.tcp.DEB)
- DEB -> WARN: Message 16 (via logrecv.tcp.DEB)
- DEB -> INFO: Message 17 (via logrecv.tcp.DEB)
- DEB -> DEBUG: Message 18 (via logrecv.tcp.DEB)
- UNDEF -> CRITICAL: Message 19 (via logrecv.tcp.UNDEF)
- UNDEF -> ERROR: Message 20 (via logrecv.tcp.UNDEF)
- UNDEF -> WARN: Message 21 (via logrecv.tcp.UNDEF)
- UNDEF -> INFO: Message 22 (via logrecv.tcp.UNDEF)
- INF.BADPARENT.UNDEF -> CRITICAL: Message 23 (via
logrecv.tcp.INF.BADPARENT.UNDEF)
- INF.BADPARENT -> CRITICAL: Message 24 (via
logrecv.tcp.INF.BADPARENT)
- INF -> INFO: Messages should bear numbers 0 through
24. (via logrecv.tcp.INF)
**********************************************************************
Traceback (most recent call last):
  File
"/home/jeremy/src/python/dist/src/Lib/logging/__init__.py",
line 648, in emit
    self.stream.write("%s\n" % msg)
ValueError: I/O operation on closed file
Traceback (most recent call last):
  File
"/home/jeremy/src/python/dist/src/Lib/logging/__init__.py",
line 648, in emit
    self.stream.write("%s\n" % msg)
ValueError: I/O operation on closed file


----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2003-04-29 23:45

Message:
Logged In: YES 
user_id=45365

On MacOS9 the problem is indeed fixed.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-25 16:35

Message:
Logged In: YES 
user_id=33168

This problem should be fixed, please test.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-03-03 11:40

Message:
Logged In: YES 
user_id=45365

I see this problem on MacPython-OS9 too, occasionally. So if it is closed I would like to hear the resolution, please...

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-03-01 03:02

Message:
Logged In: YES 
user_id=80475

Can this be closed?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678217&group_id=5470


From noreply@sourceforge.net  Tue Apr 29 22:51:36 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 29 Apr 2003 14:51:36 -0700
Subject: [Python-bugs-list] [ python-Bugs-680789 ] repr() of large array objects takes quadratic time
Message-ID: <E19Ad0i-0001we-00@sc8-sf-web2.sourceforge.net>

Bugs item #680789, was opened at 2003-02-05 12:00
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=680789&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Jurjen N.E. Bos (jneb)
Assigned to: Raymond Hettinger (rhettinger)
Summary: repr() of large array objects takes quadratic time

Initial Comment:
This is a bug and a partial patch.

If I debug a program that contains a ridiculously large array (8M entries in my case), the debugger takes forever.
It happens in Mac OS X, Python 2.2, but I found the bug in is the repr module, so it is probably universal.
The thing is, that after the fix below, it still doesn't work!
Did I miss something trivial (like repr is builtin, or something like that?). Would someone with Mac OS X experience help out here, please (Jack?).

Here's the diff to make repr.repr work with large arrays:
13a14
>       self.maxarray = 5
50a52,62
>     def repr_array(self, x, level):
>         n = len(x)
>       header = "array('"+x.typecode+"', ["
>         if n == 0: return header+"])"
>         if level <= 0: return header+"...])"
>         s = ''
>         for i in range(min(n, self.maxarray)):
>             if s: s = s + ', '
>             s = s + self.repr1(x[i], level-1)
>         if n > self.maxarray: s = s + ', ...'
>         return header + s + "])"

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2003-04-29 23:51

Message:
Logged In: YES 
user_id=45365

Jurjen,
could you submit a separate bug report for the MacPython IDE? It needs a 
different solution (and I'm not going to come around to it soon, so otherwise 
I may forget).

----------------------------------------------------------------------

Comment By: Jurjen N.E. Bos (jneb)
Date: 2003-04-25 11:32

Message:
Logged In: YES 
user_id=446428

The debugger I use, is not pdb, but the Mac only IDE debugger. I thought 
this was only a front end on pdb, but it apparently is not.
It seems that it is still slow in 2.3. (I can't check it at the moment, I am 
running a multiple hour computation...)
May it will automatically be fixed if Jack manages to get IDLE working on the 
Mac...


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-23 19:33

Message:
Logged In: YES 
user_id=80475

Fixed this up by converting the array to a list and then 
using the list object's efficient repr().

See Modules/arraymodule.c 2.87.

Since I categorize this as a performance issue and not a 
bug, I've applied the fix to Py2.3 but am not 
recommending for backport.

----------------------------------------------------------------------

Comment By: logistix (logistix)
Date: 2003-02-12 02:43

Message:
Logged In: YES 
user_id=699438

arraymodule's repr used "string += ',' + el" for each element in 
the array.  Lists and dicts did a string.join to build the repr.

Attached patch builds a tuple of array elements and then 
joins them.  (actually for some reason I can't attach now, I'll 
post the patch in patch manager)

This fixes the time issue, but I don't know enough about how 
you guys manage memory in each case to tell what impact 
that'll have on really, really big arrays (although I imagine it 
takes more memory).



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-02-07 02:40

Message:
Logged In: YES 
user_id=31435

I can't make time for this, so unassigned it.  It would make 
a good, brief project for someone -- the list and dict 
tp_reprs are linear-time, and tp_repr for array.array 
objects shouldn't be any harder than they were.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-02-06 22:37

Message:
Logged In: YES 
user_id=45365

Okay, so the real bug is that tp_repr of array objects takes quadratic time.

I'm changing the summary of this report then, and assigning back to you (Tim), on the basis that you did more checkins on arraymodule than I did. Feel free to pass the potato on:-)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-02-06 00:08

Message:
Logged In: YES 
user_id=31435

pdb does import repr.py, but probably doesn't use it in 
whatever way Jurjen is using to display his big array.

WRT that, note that Jurjen is using array.array objects, not 
lists.  The internal array.array tp_repr slot is quadratic-time in 
the size of the array, while list's tp_repr is linear time.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-02-05 23:40

Message:
Logged In: YES 
user_id=45365

The fix is fine (it works for me the same way as for Tim), but I think we're shooting past the problem here.

First, pdb doesn't use repr.repr(), it uses the normal builtin repr().

Second, I don't see any sluggishness in pdb with large arrays. I tried
debugging
def foo():
    a = range(8000000)
and there was no problem. Allocating the object took a bit of time, yes, and if you actually try to print it you'll stare at about 800K lines filled with digits scrolling over your screen, but that is to be expected.

Could it be your sluggishness is coming from something else? For example, MacOSX starts behaving *very* badly if your root disk is full, because then it can't allocate swap space, and due to its optimistic behaviour it comes to a grinding halt.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-02-05 19:36

Message:
Logged In: YES 
user_id=31435

Nice to see you, Jurgen!  I checked this into current CVS, 
and it works fine for me in isolation:

>>> len(a)
11055060
>>> repr.repr(a)
"array('i', [0, 1, 2, 3, 4, ...])"
>>>

That goes in an eyeblink.  So more detail is needed about 
what "it still doesn't work!" means.  Assigned to Jack, and he 
can use current CVS to try it.

Lib/repr.py; new revision: 1.15
Lib/test/test_repr.py; new revision: 1.16
Misc/NEWS; new revision: 1.642

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=680789&group_id=5470


From noreply@sourceforge.net  Wed Apr 30 00:41:39 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 29 Apr 2003 16:41:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-723962 ] imaplib should convert line endings to be rfc2822 complient
Message-ID: <E19AejD-0007q8-00@sc8-sf-web4.sourceforge.net>

Bugs item #723962, was opened at 2003-04-19 10:16
Message generated for change (Comment added) made by pierslauder
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723962&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tony Meyer (anadelonbrin)
Assigned to: Piers Lauder (pierslauder)
Summary: imaplib should convert line endings to be rfc2822 complient

Initial Comment:
When imaplib.append is called, it should convert line 
endings from whatever they are (\r, \n or \r\n) to the 
format required by rfc2822 (in turn, required by rfc1730), 
i.e. CRLF - \r\n.

The email package generates mail with Python "internal" 
line endings (i.e. \n), and so if a message is flattened 
and then appended via imap improper line endings are 
sent.

While some imap servers are ok with this, at least one 
(Communigate Pro) mangles the message (all the 
headers become part of the body).

smtplib has an example of how to do this.

----------------------------------------------------------------------

>Comment By: Piers Lauder (pierslauder)
Date: 2003-04-30 09:41

Message:
Logged In: YES 
user_id=196212

This is a bug. Can't think how it's managed to survive for
so long (there must be a lot of forgiving imap servers out
there). Anyway,
I've just checked in a fix (based on the smtplib code -
thanks for
the ref.)

And thanks for the bug report.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-04-19 23:44

Message:
Logged In: YES 
user_id=6656

Or just assign it to him :-)


----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-04-19 22:55

Message:
Logged In: YES 
user_id=29957

You may want to contact imaplib's author, (Piers Lauder
<piers@cs.su.oz.au>)
directly about this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723962&group_id=5470


From noreply@sourceforge.net  Wed Apr 30 00:48:55 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 29 Apr 2003 16:48:55 -0700
Subject: [Python-bugs-list] [ python-Bugs-723962 ] imaplib should convert line endings to be rfc2822 complient
Message-ID: <E19AeqF-0005Fr-00@sc8-sf-web3.sourceforge.net>

Bugs item #723962, was opened at 2003-04-19 12:16
Message generated for change (Comment added) made by anadelonbrin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723962&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tony Meyer (anadelonbrin)
Assigned to: Piers Lauder (pierslauder)
Summary: imaplib should convert line endings to be rfc2822 complient

Initial Comment:
When imaplib.append is called, it should convert line 
endings from whatever they are (\r, \n or \r\n) to the 
format required by rfc2822 (in turn, required by rfc1730), 
i.e. CRLF - \r\n.

The email package generates mail with Python "internal" 
line endings (i.e. \n), and so if a message is flattened 
and then appended via imap improper line endings are 
sent.

While some imap servers are ok with this, at least one 
(Communigate Pro) mangles the message (all the 
headers become part of the body).

smtplib has an example of how to do this.

----------------------------------------------------------------------

>Comment By: Tony Meyer (anadelonbrin)
Date: 2003-04-30 11:48

Message:
Logged In: YES 
user_id=552329

By the way, since posting this there was some discussion 
about the re used in smtplib.  Tim Peters, Tim Stone and 
Skip Montareo eventually agreed (more or less) that
CRLF_RE = re.compile(r'\r\n|\r|\n')
was better than the one in smtplib.  (I really ought to suggest 
that to whoever maintains smtplib as well...)

But anyway, thanks for fixing it.  I must say that the imap 
servers I have access to are forgiving enough - but it only 
takes one...

----------------------------------------------------------------------

Comment By: Piers Lauder (pierslauder)
Date: 2003-04-30 11:41

Message:
Logged In: YES 
user_id=196212

This is a bug. Can't think how it's managed to survive for
so long (there must be a lot of forgiving imap servers out
there). Anyway,
I've just checked in a fix (based on the smtplib code -
thanks for
the ref.)

And thanks for the bug report.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-04-20 01:44

Message:
Logged In: YES 
user_id=6656

Or just assign it to him :-)


----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-04-20 00:55

Message:
Logged In: YES 
user_id=29957

You may want to contact imaplib's author, (Piers Lauder
<piers@cs.su.oz.au>)
directly about this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723962&group_id=5470


From noreply@sourceforge.net  Wed Apr 30 00:57:21 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 29 Apr 2003 16:57:21 -0700
Subject: [Python-bugs-list] [ python-Bugs-729913 ] metaclasses, __getattr__, and special methods
Message-ID: <E19AeyP-0002Hc-00@sc8-sf-web1.sourceforge.net>

Bugs item #729913, was opened at 2003-04-29 16:57
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729913&group_id=5470

Category: Type/class unification
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bjorn Pettersen (bpettersen)
Assigned to: Nobody/Anonymous (nobody)
Summary: metaclasses, __getattr__, and special methods

Initial Comment:
__getattr__ on metaclasses aren't called when it would 
seem "logical" <wink> for it to be. E.g.:

>>> class meta(type):
...   def __getattr__(cls, name):
...     if name == '__len__':
...        print "meta.__getattr__('__len__')"
...        return lambda: 42
...     else:
...        print 'meta.__getattr__', name
...        return name
...
>>> class S(object):
...   __metaclass__ = meta
...
>>> S.__len__()
meta.__getattr__('__len__')
42
>>> len(S)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: len() of unsized object
>>>

I was told that special method "foo(x, arg)" was 
implemented as
"type(x).__foo__(x, arg)", which doesn't seem to be the 
case always...
Compare:

>>> class meta(type):
...   def __len__(cls):
...     return 42
...
>>> class S(object):
...   __metaclass__ = meta
...
>>> S.__len__()
42
>>> len(S)
42
>>>

So, it looks like it's looking up __len__ in the 
metaclass, but not
falling back on __getattr__ when it isn't there? I've 
looked at the C
code and it seems like special methods each have their 
own way of
finding the function they're needing.

>From Alex Martelli:
Ah yes, I see now!  Yes, functions such as len() rely on 
slots in
the type object, e.g. as you've noticed:

> finding the function they're needing, e.g. for len, it 
looks like it
> uses:
> 
>   m = o->ob_type->tp_as_sequence;
>   if (m && m->sq_length)
>     return m->sq_length(o);
> 
>   return PyMapping_Size(o);

and the "incredibly complex thinking" (quoting from 
typeobject.c)
in update_one_slot doesn't seem to work except for 
operations the
which "the class overrides in its dict" (again from a 
comment in
typeobject.c, this one for fixup_slot_dispatchers).

The issue may be with _PyType_Lookup (again in the 
same ,c file),
which just gives up if it can't find a name somewhere 
along the mro
(it doesn't "look upwards" to the metaclass) while 
type_getattro
DOES work upwards on the metaclass too.  Hmmmm.  
I'm not sure I
really understand all that's going on here - it IS a rather 
hairy
zone of the code.  Maybe you can post this as a bug in 
2.3 beta 1
on sourgeforge (ideally showing where in the docs it 
defines the
semantics that it then doesn't respect) so we can get 
this looked
at by the few people who really DO grasp these parts...;-
).  There
is probably some sound implementation reason for the 
current
behavior, but if so it should be better documented, I 
think.

Back to me:
The point being that I haven't found any place in the 
documentation that defines what the attribute lookup is 
on new-style classes (and the C code is too hairy for 
me to understand :-)

As a special case of this problem, super() can't create 
an object which intercepts the special methods like it 
does for other methods, e.g.:

  super(MyCls, self).__getitem__(5)

works, but not

  super(MyCls, self)[5]

I don't know if that is intended or not, but it's not 
documented, though neither is exactly _what_ super is? 
(i.e. it looks like it's an object, that when you call a 
method, 'm', on it, uses the superclass method 'm', but 
the subclass versions of all other methods, although as 
above, not in all contexts, and I'm not sure whether 
you're supposed to be able to treat it as a first class 
object [pass as arg, return, etc])....

-- bjorn



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729913&group_id=5470


From noreply@sourceforge.net  Wed Apr 30 01:02:30 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 29 Apr 2003 17:02:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-723962 ] imaplib should convert line endings to be rfc2822 complient
Message-ID: <E19Af3O-0000HK-00@sc8-sf-web4.sourceforge.net>

Bugs item #723962, was opened at 2003-04-19 10:16
Message generated for change (Comment added) made by pierslauder
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723962&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Tony Meyer (anadelonbrin)
Assigned to: Piers Lauder (pierslauder)
Summary: imaplib should convert line endings to be rfc2822 complient

Initial Comment:
When imaplib.append is called, it should convert line 
endings from whatever they are (\r, \n or \r\n) to the 
format required by rfc2822 (in turn, required by rfc1730), 
i.e. CRLF - \r\n.

The email package generates mail with Python "internal" 
line endings (i.e. \n), and so if a message is flattened 
and then appended via imap improper line endings are 
sent.

While some imap servers are ok with this, at least one 
(Communigate Pro) mangles the message (all the 
headers become part of the body).

smtplib has an example of how to do this.

----------------------------------------------------------------------

>Comment By: Piers Lauder (pierslauder)
Date: 2003-04-30 10:02

Message:
Logged In: YES 
user_id=196212

Couldn't agree more :-)  Now uses the much simpler regex.
I'm also going to mark this bug as 'fixed"


----------------------------------------------------------------------

Comment By: Tony Meyer (anadelonbrin)
Date: 2003-04-30 09:48

Message:
Logged In: YES 
user_id=552329

By the way, since posting this there was some discussion 
about the re used in smtplib.  Tim Peters, Tim Stone and 
Skip Montareo eventually agreed (more or less) that
CRLF_RE = re.compile(r'\r\n|\r|\n')
was better than the one in smtplib.  (I really ought to suggest 
that to whoever maintains smtplib as well...)

But anyway, thanks for fixing it.  I must say that the imap 
servers I have access to are forgiving enough - but it only 
takes one...

----------------------------------------------------------------------

Comment By: Piers Lauder (pierslauder)
Date: 2003-04-30 09:41

Message:
Logged In: YES 
user_id=196212

This is a bug. Can't think how it's managed to survive for
so long (there must be a lot of forgiving imap servers out
there). Anyway,
I've just checked in a fix (based on the smtplib code -
thanks for
the ref.)

And thanks for the bug report.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-04-19 23:44

Message:
Logged In: YES 
user_id=6656

Or just assign it to him :-)


----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-04-19 22:55

Message:
Logged In: YES 
user_id=29957

You may want to contact imaplib's author, (Piers Lauder
<piers@cs.su.oz.au>)
directly about this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723962&group_id=5470


From noreply@sourceforge.net  Wed Apr 30 09:29:50 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 30 Apr 2003 01:29:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-708901 ] Lineno calculation sometimes broken
Message-ID: <E19AmyM-0008R9-00@sc8-sf-web3.sourceforge.net>

Bugs item #708901, was opened at 2003-03-24 17:09
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=708901&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Michael Hudson (mwh)
Summary: Lineno calculation sometimes broken

Initial Comment:
I'm running the win32 version of Python 2.3a2.  I ran into 
this when I got a traceback pointing to a wrong 
linenumber.  It also messes up debugging in 
Pythonwin.  Anyway, you can see from the disassembly 
below that something goes seriously amiss when the 
code reaches the FOR_ITER:


>>> import httplib
>>> import dis
>>> dis.dis(httplib.HTTPConnection.connect)
524           0 LOAD_CONST

              3 STORE_FAST

525           6 SETUP_LOOP
              9 LOAD_GLOBAL
             12 LOAD_ATTR
             15 LOAD_FAST
             18 LOAD_ATTR
             21 LOAD_FAST
             24 LOAD_ATTR
             27 LOAD_CONST

526          30 LOAD_GLOBAL
             33 LOAD_ATTR
             36 CALL_FUNCTION
             39 GET_ITER

781     >>   40 FOR_ITER


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2003-04-30 09:29

Message:
Logged In: YES 
user_id=6656

It has struck me before that some CS type must have thought
about efficient ways of mapping intervals into some domain.

There are quite a few warts here -- for example given

1: f(parm1,
2:   parm2,
3:   parm3)

if the body of f raises an exception, the traceback points
at line 3.
That's always annoyed me.

At any rate, if you're prepared to think about this, don't
let me be the one to stop you!

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2003-04-29 19:41

Message:
Logged In: YES 
user_id=4771

Someone motivated could go ahead and allow for ranges of
bytecodes to be mapped to *ranges* of line numbers instead
of to just a single line. The debugger would then display
all the lines in the range. The result would be more natural
when single-stepping through multiline statements.

It would also give a clean fix to several problems beside
the one discussed here, e.g. the final POP_TOP of an
if/then/else being mapped to the last line of the 'else'
part, but being reached when the 'then' branch is taken.
This currently works as expected because the line trace hook
is only fired when we reach the first opcode of a range, not
when we jump in the middle of a range -- which is a hack
because it is the cause of Michael's patch not stopping on
the 'for' after each iteration.

I may be the aforementioned motivated person if the solution
seems worthwhile to try :-)

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-04-29 18:08

Message:
Logged In: YES 
user_id=6656

Used Tim's idea on compile.c.

Knocked test_dis about a bit to include this case, and make
it *slightly* less rampantly fragile.

Python/compile.c revision 2.282
Lib/test/test_trace.py revision 1.3

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-04-29 12:40

Message:
Logged In: YES 
user_id=6656

> Well, this one's a mess.

Hadn't noticed that <wink>.

I had become aware that my patch wasn't the right answer. 
I'll try your idea when cvs up finishes...

> Unfortunately, the encoding of lnotab assumes that line 
> numbers and byte offsets are presented in monotonically 
> non-decreasing order.

Presumably this *could* change, if we were sufficiently
motivated.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-04-28 21:57

Message:
Logged In: YES 
user_id=31435

Well, this one's a mess.  The patch changes debugger 
behavior in that it no longer stops on the 'for' each time 
around the loop.  I had better luck leaving the com_set_lineno
() call where it is now, but changing its second argument 
instead, like so:

	com_set_lineno(c, c->c_last_line);

Then it stops on the "for" each time around the loop, but 
pointing at the last line of the "for" (in your whittled example, 
on the line ending with "10):").  Better than nothing.

Unfortunately, the encoding of lnotab assumes that line 
numbers and byte offsets are presented in monotonically non-
decreasing order.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-29 23:38

Message:
Logged In: YES 
user_id=33168

The patch worked for me on Linux, after I removed
httplib.pyc. :-)
Does it jump to the right line in the debugger whe iterating
through a loop?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-03-24 17:43

Message:
Logged In: YES 
user_id=6656

Stupid minimal testcase:

def f():
    for res in range(1,
                     10):
        pass

Tim, you've looked at compile.c today <wink>, can you check
the attached patch?


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-03-24 17:36

Message:
Logged In: YES 
user_id=6656

Waddya know, it's not my fault.

For some reason, something is trying to store a negative
line_incr into the c_lnotab which gets masked into a line
increment of 255.  Fun.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-03-24 17:16

Message:
Logged In: YES 
user_id=6656

yow!  probably my fault.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=708901&group_id=5470


From noreply@sourceforge.net  Wed Apr 30 09:59:27 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 30 Apr 2003 01:59:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-730087 ] new-style classes with just __eq__ hashable
Message-ID: <E19AnR1-0004MG-00@sc8-sf-web4.sourceforge.net>

Bugs item #730087, was opened at 2003-04-30 09:59
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730087&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Guido van Rossum (gvanrossum)
Summary: new-style classes with just __eq__ hashable

Initial Comment:
Forgive me if the rules changed somewhere without me
knowing, but:

/>> class C(object): # new style
|..  def __eq__(self, other):
|..   return 1
\__ 
->> hash(C())
137007476
/>> class C: # old-style
|..  def __eq__(self, other):
|..   return 1
\__ 
->> hash(C())
Traceback (most recent call last):
  File "<input>", line 1, in ?
TypeError: unhashable instance

This would seem to be quite bad.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730087&group_id=5470


From noreply@sourceforge.net  Wed Apr 30 10:26:35 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 30 Apr 2003 02:26:35 -0700
Subject: [Python-bugs-list] [ python-Bugs-730087 ] new-style classes with just __eq__ hashable
Message-ID: <E19AnrH-0005BE-00@sc8-sf-web2.sourceforge.net>

Bugs item #730087, was opened at 2003-04-30 09:59
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730087&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Guido van Rossum (gvanrossum)
Summary: new-style classes with just __eq__ hashable

Initial Comment:
Forgive me if the rules changed somewhere without me
knowing, but:

/>> class C(object): # new style
|..  def __eq__(self, other):
|..   return 1
\__ 
->> hash(C())
137007476
/>> class C: # old-style
|..  def __eq__(self, other):
|..   return 1
\__ 
->> hash(C())
Traceback (most recent call last):
  File "<input>", line 1, in ?
TypeError: unhashable instance

This would seem to be quite bad.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2003-04-30 10:26

Message:
Logged In: YES 
user_id=6656

This is actually the same issue as bug #660098.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730087&group_id=5470


From noreply@sourceforge.net  Wed Apr 30 10:31:04 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 30 Apr 2003 02:31:04 -0700
Subject: [Python-bugs-list] [ python-Bugs-727051 ] valgrind python fails
Message-ID: <E19Anvc-0005OX-00@sc8-sf-web2.sourceforge.net>

Bugs item #727051, was opened at 2003-04-24 17:49
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727051&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ralf W. Grosse-Kunstleve (rwgk)
Assigned to: Nobody/Anonymous (nobody)
Summary: valgrind python fails

Initial Comment:
Platform:
  Redhat 7.3 on Intel Xeon

Packages involved:
  valgrind-1.9.5 (http://developer.kde.org/~sewardj/)
  Python CVS snapshot Thu Apr 24 10:00:00 PDT 2003

valgrind python fails with the following message:

% valgrind python
python: relocation error: /lib/librt.so.1: symbol 
__pthread_clock_settime, version GLIBC_PRIVATE not 
defined in file libpthread.so.0 with link time reference

This is with:

% python
Python 2.3b1 (#1, Apr 24 2003, 10:20:26) 
[GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-113)] on 
linux2
Type "help", "copyright", "credits" or "license" for more 
information.
>>> 

I observed the same problem with Python 2.3a2.

There are no problems when using Python 2.2.1 on the 
exact same platform with the same valgrind installation.


----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2003-04-30 09:31

Message:
Logged In: YES 
user_id=4771

I figured it out. 'configure.in' now looks in various
libraries for the sem_init() function (it is in different
libs on different platforms); more precisely, it searches in
librt and libposix4. However, on Linux, for some reason it
is also defined in libpthread which is always linked with
Python (unless one disables threads, of course).

As a suggested fix, I'd say that configure.in should first
look for sem_init in libpthread. That way, the Linux
compilation won't be linked against the unneeded and
valgrind-conflicting librt at all.

I can provide a patch that does this.

----------------------------------------------------------------------

Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2003-04-29 20:49

Message:
Logged In: YES 
user_id=71407

> Is it worth any further investigation ? If not, close this
> bug track.

valgrind is extremely useful. It seems very important to me that 
Python 2.3 works with valgrind out-of-the-box, just like Python 2.2 
does. I'm afraid otherwise "Why doesn't Python work with 
valgrind?" is going to wind up in the Python FAQ.


> What I cannot understand is the purpose of binding against
> that library on Linux. It ends up in the Makefile for some
> indirect reason. I tried without it and the 'make test'
> works just fine.

I'd be very glad if you could find ways of not binding against 
librt.so if it is not needed.


----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2003-04-29 19:06

Message:
Logged In: YES 
user_id=4771

This is documented as a known problem with the librt.so
library on http://developer.kde.org/~sewardj/docs-1.9.5/FAQ.txt.

What I cannot understand is the purpose of binding against
that library on Linux. It ends up in the Makefile for some
indirect reason. I tried without it and the 'make test'
works just fine.

Is it worth any further investigation ? If not, close this
bug track.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-24 19:14

Message:
Logged In: YES 
user_id=33168

I think I got around this problem by adding:

  void __pthread_clock_settime() { }

I think this may be mentioned in the valgrind FAQ/doc.  Or
perhaps, it's something similar which I am confusing.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727051&group_id=5470


From noreply@sourceforge.net  Wed Apr 30 16:01:37 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 30 Apr 2003 08:01:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-730222 ] socketmodule.c: inet_pton() expects 4-byte packed_addr
Message-ID: <E19At5V-0007q5-00@sc8-sf-web2.sourceforge.net>

Bugs item #730222, was opened at 2003-04-30 11:00
Message generated for change (Settings changed) made by john_marshall
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730222&group_id=5470

Category: Python Library
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: John Marshall (john_marshall)
Assigned to: Nobody/Anonymous (nobody)
>Summary: socketmodule.c: inet_pton() expects 4-byte packed_addr

Initial Comment:
In the Modules/socketmodule.c file, the inet_pton function 
implicitly treats "long packed_addr" as a 4-byte object or 
expects that the required 4-bytes is at 
&packed_addr[0]-[3]. This is not true under 
SUPER-UX/SX. In order to get this working right, I 
changed the data type from "long" to "int". This now 
works properly. 
 
-----Modules/socketmodule.c: #3825  
 /* 042303; JM; this routine really expects a 4-byte  
packed_addr  
 * not a long; long on SX is 8-bytes! */  
#if SX  
        int packed_addr;  
#else  
        long packed_addr;  
#endif 
... 
         if (packed_addr == INADDR_NONE) 
            return 0; 
        memcpy(dst, &packed_addr, 4); 
----- 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730222&group_id=5470


From noreply@sourceforge.net  Wed Apr 30 16:06:40 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 30 Apr 2003 08:06:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-727692 ] Documentation formatting bugs
Message-ID: <E19AtAO-0004oz-00@sc8-sf-web3.sourceforge.net>

Bugs item #727692, was opened at 2003-04-25 14:57
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727692&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin v. Löwis (loewis)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Documentation formatting bugs

Initial Comment:
I found that some of my changes get incorrectly 
formatted, but I don't know how to fix them. Assigning to 
Fred in the hope that he knows the proper incantations.

- HTML version of 4.9.2 (standard encodings):
The table is incorrect in the lines that have an empty 
Aliases column (e.g. cp874). The Alias ought to be 
empty, and "Thai" ought to occur in the third column

- HTML version of 4.9.3 (encodings.IDNA)
The first paragraph starts with a bogus "P>"

- HTML of whatsnew, 17, "Support for internationalized 
domain names": The first line of Python prints as a 
guillemet, not as ">>" Notice that I used a non-
preformatted enviroment so that I could output c-cedilla.

- Postscript version of 4.9.2: the table is overfull in its 
width. It would be ok to wrap the aliases lists as much 
as necessary

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-04-30 11:06

Message:
Logged In: YES 
user_id=3066

- Standard encodings table: ouch!  I'll see what I can do
about this, but it'll take more time than I can spend right now.

- encodings.idna documentation:  That's a bug in the
formatting software; hopefully I'll be able to fix it. 
Worked around it for now (Doc/lib/libcodecs.tex 1.20).

- What's New document: I've worked around the problem so the
interactive prompt shows up properly, but an extraneous
space is generated at the beginning of the line; not sure
why (Doc/whatsnew/whatsnew23.tex 1.144).

- Postscript:  I expect the PDF to exhibit the same problem.
 This is a general problem for tables with a lot of
horizontal-mode material in LaTeX; I don't know how to work
around this (yet).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727692&group_id=5470


From noreply@sourceforge.net  Wed Apr 30 16:10:11 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 30 Apr 2003 08:10:11 -0700
Subject: [Python-bugs-list] [ python-Bugs-730229 ] stringprep not documented
Message-ID: <E19AtDn-0005CK-00@sc8-sf-web3.sourceforge.net>

Bugs item #730229, was opened at 2003-04-30 11:10
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730229&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Martin v. Löwis (loewis)
Summary: stringprep not documented

Initial Comment:
The stringprep module is not documented in the Library
Reference.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730229&group_id=5470


From noreply@sourceforge.net  Wed Apr 30 16:00:08 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 30 Apr 2003 08:00:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-730221 ] sgmllib: Add "@" to valid attribute characters
Message-ID: <E19At44-0007lL-00@sc8-sf-web2.sourceforge.net>

Bugs item #730221, was opened at 2003-04-30 11:00
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730221&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Nobody/Anonymous (nobody)
Summary: sgmllib: Add "@" to valid attribute characters

Initial Comment:
According to http://www.w3.org/Addressing/rfc1808.txt, 
the query portion of an URL (and, therefore, and 
attribute) can contain any of the "safe", "extra", or 
"reserved" characters.

436621 added in some, but not all.  Current CVS adds in 
",", but is still missing "@".  Google groups provides 
examples URLS that use the @, as the end of the query 
is the article-ID, including the @.

Suggested patch just adds that "@" to the attrfind.

36c36
<     r'(\'[^\']*\'|"[^"]*"|[-a-zA-Z0-9./,:;+*%?!&$\(\)
_#=~\'"]*))?')
---
>     r'(\'[^\']*\'|"[^"]*"|[-a-zA-Z0-9./,@:;+*%?!&$\(\)
_#=~\'"]*))?')


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730221&group_id=5470


From noreply@sourceforge.net  Wed Apr 30 16:59:25 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 30 Apr 2003 08:59:25 -0700
Subject: [Python-bugs-list] [ python-Bugs-730221 ] sgmllib: Add "@" to valid attribute characters
Message-ID: <E19AtzR-0000U9-00@sc8-sf-web3.sourceforge.net>

Bugs item #730221, was opened at 2003-04-30 11:00
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730221&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jim Jewett (jimjjewett)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: sgmllib: Add "@" to valid attribute characters

Initial Comment:
According to http://www.w3.org/Addressing/rfc1808.txt, 
the query portion of an URL (and, therefore, and 
attribute) can contain any of the "safe", "extra", or 
"reserved" characters.

436621 added in some, but not all.  Current CVS adds in 
",", but is still missing "@".  Google groups provides 
examples URLS that use the @, as the end of the query 
is the article-ID, including the @.

Suggested patch just adds that "@" to the attrfind.

36c36
<     r'(\'[^\']*\'|"[^"]*"|[-a-zA-Z0-9./,:;+*%?!&$\(\)
_#=~\'"]*))?')
---
>     r'(\'[^\']*\'|"[^"]*"|[-a-zA-Z0-9./,@:;+*%?!&$\(\)
_#=~\'"]*))?')


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-04-30 11:59

Message:
Logged In: YES 
user_id=3066

Already fixed in CVS:

Lib/sgmllib.py 1.45
Lib/test/test_sgmllib.py 1.6

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730221&group_id=5470


From noreply@sourceforge.net  Wed Apr 30 16:00:18 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 30 Apr 2003 08:00:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-730222 ] socketmodule.c: inet_pton excepts 4-byte packed_addr
Message-ID: <E19At4E-0007lz-00@sc8-sf-web2.sourceforge.net>

Bugs item #730222, was opened at 2003-04-30 11:00
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730222&group_id=5470

Category: Python Library
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: John Marshall (john_marshall)
Assigned to: Nobody/Anonymous (nobody)
Summary: socketmodule.c: inet_pton excepts 4-byte packed_addr

Initial Comment:
In the Modules/socketmodule.c file, the inet_pton function 
implicitly treats "long packed_addr" as a 4-byte object or 
expects that the required 4-bytes is at 
&packed_addr[0]-[3]. This is not true under 
SUPER-UX/SX. In order to get this working right, I 
changed the data type from "long" to "int". This now 
works properly. 
 
-----Modules/socketmodule.c: #3825  
 /* 042303; JM; this routine really expects a 4-byte  
packed_addr  
 * not a long; long on SX is 8-bytes! */  
#if SX  
        int packed_addr;  
#else  
        long packed_addr;  
#endif 
... 
         if (packed_addr == INADDR_NONE) 
            return 0; 
        memcpy(dst, &packed_addr, 4); 
----- 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730222&group_id=5470


From noreply@sourceforge.net  Wed Apr 30 17:45:13 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 30 Apr 2003 09:45:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-730296 ] Unexpected Changes in list Iterator
Message-ID: <E19Auhl-00007g-00@sc8-sf-web1.sourceforge.net>

Bugs item #730296, was opened at 2003-04-30 09:45
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730296&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gary H. Loechelt (loechelt)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unexpected Changes in list Iterator

Initial Comment:
I encountered an unexpected change in the behavior of
the iterator for the built-in list class.  I created a
subclass of the list class in which a start attribute
was added.  The intended behavior was to make the
list look shorter by "hiding" an arbitrary number of
starting elements.  The start attribute was used to
control the number of hidden elements.  In order to
make my shifted list class work in my application,
I had to override a number of special methods,
including the __iter__ method.  In Python 2.2.1 and
Python 2.3a2, the default __iter__ method indexed over
the entire, unshifted list even with other special
methods changed to reflect the shifting.  Therefore, I
had to override the __iter__ method as well.  When
I tested my application on Python 2.3b1, I encountered
an error which I tracked down to my __iter__
method.  I found that it had doubled the shift of the
starting value.  Eventually, I traced this to a change
in the behavior of the default __iter__ method of the
built-in list class.  I was able to recreate the
problem
with a simple test case.

I created a simple shifted list class with a public
start attribute, a __len__ method that subtracts start
from
the length of the list, and a __getitem__ method that
adds start to the index during element access.
Iteration over the list (using the default __iter__
inherited from list) returns all the elements in Python
2.2.1,
but only the elements after the start value in Python
2.3b1.  This change in behavior was an unexpected
surprise for me!


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730296&group_id=5470


From noreply@sourceforge.net  Wed Apr 30 17:45:51 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 30 Apr 2003 09:45:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-723136 ] Put a reference to print in the Library Reference, please.
Message-ID: <E19AuiN-0002nq-00@sc8-sf-web2.sourceforge.net>

Bugs item #723136, was opened at 2003-04-17 09:41
Message generated for change (Settings changed) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723136&group_id=5470

Category: Documentation
Group: Feature Request
>Status: Closed
>Resolution: Fixed
Priority: 6
Submitted By: Laura Creighton (lcreighton)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Put a reference to print in the Library Reference, please.

Initial Comment:
Often the first question a Newbie has is 'how do I
print stuff?'.
They come to the Library Reference, looking for a print
function.   They are unaware that print is an
expression, and
that they need to be looking in the Language Reference
Manual.
One line, early on telling them where to look will save
aggrevation
for them.  Thanks very much,
Laura Creighton

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-04-30 12:45

Message:
Logged In: YES 
user_id=3066

The Library Reference contains an index entry for "print
statement", which points to a minor reference at the
beginning of the "Built-in Types" chapter.  I've expanded
the reference to include:

- a specific link to the "print" reference documentation in
the language reference;

- a link to the contents page for the language reference,
advising the reader that all language statements are
documented there; and

- a link to the contents page for the tutorial, 'cause it's
useful for newbies.

I don't know that this exactly matches you're looking for.

I'll note that the % operator for string formatting is
indexed in the library already.

If these changes are not sufficient, please explain in more
detail where you were looking for the information and failed
to find it.

Changes committed as Doc/lib/libstdtypes.tex 1.123 and
1.80.6.22.

----------------------------------------------------------------------

Comment By: Laura Creighton (lcreighton)
Date: 2003-04-19 04:55

Message:
Logged In: YES 
user_id=376262

This is probably the best time to add a reference to the %
operator and 
what it is good for.  

----------------------------------------------------------------------

Comment By: logistix (logistix)
Date: 2003-04-18 18:04

Message:
Logged In: YES 
user_id=699438

Perhaps this could be a "builtin statements" subsection of 
section 2 that lists all statements and crossreferences the 
Language Reference.  It took me a year before it finally stuck 
that I needed to go to the Language Reference to look at try... 
syntax, etc.

It's probably my biggest usability gripe with the manuals.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-04-17 10:49

Message:
Logged In: YES 
user_id=3066

Guido wants this fixed, so bumped priority and assigned it
to me.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723136&group_id=5470


From noreply@sourceforge.net  Wed Apr 30 23:22:01 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 30 Apr 2003 15:22:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-730467 ] Not detecting AIX_GENUINE_CPLUSPLUS
Message-ID: <E19Azxh-0003Ws-00@sc8-sf-web3.sourceforge.net>

Bugs item #730467, was opened at 2003-04-30 15:22
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730467&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Patrick Miller (patmiller)
Assigned to: Nobody/Anonymous (nobody)
Summary: Not detecting AIX_GENUINE_CPLUSPLUS

Initial Comment:
PYthon2.2.2 and Python2.3
AIX
xlC 

Need to update the code in configure.in to
remove the hardcoded path for load where
we detect AIX_GENUINE_CPLUSPLUS

The current version looks for
/usr/lpp/xlC/include/load.h
but it should just use <load.h>

Without it, Python uses load() for dynamic load
instead of loadAndInit() in dynload_aix.c

Patch attached

# checks for system dependent C++ extensions support
case "$ac_sys_system" in
	AIX*)	AC_MSG_CHECKING(for genuine AIX C++ extensions
support)
		AC_TRY_LINK([#include "<load.h>],
			    [loadAndInit("", 0, "")],
			    [AC_DEFINE(AIX_GENUINE_CPLUSPLUS)
			     AC_MSG_RESULT(yes)],
			    [AC_MSG_RESULT(no)]);;
	*) ;;
esac

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730467&group_id=5470