From noreply at sourceforge.net  Wed Dec  1 06:44:58 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Dec  1 06:45:07 2004
Subject: [Patches] [ python-Patches-1075928 ] AUTH PLAIN in smtplib
Message-ID: <E1CZNIQ-0002YK-RS@sc8-sf-web4.sourceforge.net>

Patches item #1075928, was opened at 2004-11-30 11:27
Message generated for change (Comment added) made by flyingboy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1075928&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: James Lan (flyingboy)
Assigned to: Johannes Gijsbers (jlgijsbers)
Summary: AUTH PLAIN in smtplib

Initial Comment:
smtplib can not log in to some server using command
AUTH PLAIN, it sends ``user\0user\0pass'' to the
server, but ``\0user\0pass'' has better compatibility.

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

>Comment By: James Lan (flyingboy)
Date: 2004-12-01 05:44

Message:
Logged In: YES 
user_id=222344

Some freemail servers in China :-(
If you could read chinese, you can try registering an
account at www.126.com :-)


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

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-11-30 12:13

Message:
Logged In: YES 
user_id=469548

Assigning to me for commit after the trunk opens again, as
it shouldn't be harmful. James, I'm just wondering what
servers are so broken that they can't handle the first form?

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

Comment By: James Lan (flyingboy)
Date: 2004-11-30 11:33

Message:
Logged In: YES 
user_id=222344

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file. In addition, even if you
*did* check this checkbox, a bug in SourceForge
prevents attaching a file when *creating* an issue.

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=305470&aid=1075928&group_id=5470
From noreply at sourceforge.net  Wed Dec  1 15:03:19 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Dec  1 15:03:25 2004
Subject: [Patches] [ python-Patches-1071755 ] raise error for common mistake
	with subprocess
Message-ID: <E1CZV4h-00021S-Sc@sc8-sf-web3.sourceforge.net>

Patches item #1071755, was opened at 2004-11-23 15:35
Message generated for change (Comment added) made by astrand
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1071755&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Nick Craig-Wood (ncw)
Assigned to: Nobody/Anonymous (nobody)
Summary: raise error for common mistake with subprocess

Initial Comment:
subprocess has a very easy to mistake error in it -
forgetting to pass the command as a list.  Eg

>>> import subprocess
>>> subprocess.call("ls")
BaseHTTPServer.py      dummy_threading.py 
pickletools.py   socket.py
Bastion.py             email               pipes.py   
     sre.py
[...]
dummy_thread.py        pickle.pyc          sndhdr.py  
     zipfile.py
0
>>> subprocess.call("ls", "-l")
BaseHTTPServer.py      dummy_threading.py 
pickletools.py   socket.py
Bastion.py             email               pipes.py   
     sre.py
[...]
dummy_thread.py        pickle.pyc          sndhdr.py  
     zipfile.py
0
>>> 

# Note no error, warning or anything, but no "ls -l" either

And with the patch...

>>> subprocess.call("ls", "-l")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "subprocess.py", line 428, in call
    return Popen(*args, **kwargs).wait()
  File "subprocess.py", line 508, in __init__
    raise TypeError("bufsize must be an integer - "
TypeError: bufsize must be an integer - did you forget
to pass your arguments in a list?
>>> 


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

>Comment By: Peter ?strand (astrand)
Date: 2004-12-01 15:03

Message:
Logged In: YES 
user_id=344921

Should be applied to the 2.4 branch as well. 

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

Comment By: Peter ?strand (astrand)
Date: 2004-11-30 22:55

Message:
Logged In: YES 
user_id=344921

I've applied the patch (slightly modified) on the CVS trunk:
subprocess.py 1.10
test_subprocess.py 1.16

I've not committed the patch to the 2.4 branch, however. 

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1071755&group_id=5470
From noreply at sourceforge.net  Wed Dec  1 15:04:39 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Dec  1 15:04:43 2004
Subject: [Patches] [ python-Patches-1071764 ] a new subprocess.call which
	raises an error on non-zero rc
Message-ID: <E1CZV5z-00063r-Bf@sc8-sf-web2.sourceforge.net>

Patches item #1071764, was opened at 2004-11-23 15:45
Message generated for change (Comment added) made by astrand
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1071764&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Nick Craig-Wood (ncw)
Assigned to: Nobody/Anonymous (nobody)
Summary: a new subprocess.call which raises an error on non-zero rc

Initial Comment:
The attached patch introduces a 3rd utility function -
xcall() to the
subprocess module.  This function acts just like call
but raises
errors if the command had a non-zero return code.

This saves writing

if call(...):
    raise OSError(...)

It is most useful for shell script replacement
programming.  Checking
the return codes of commands called is often forgotten
in shell
programming.

When you've moved up to python because shell is too
limiting (usually
about 10 lines of shell in my case ;-) you want to make
sure that all
your commands work so you write robust code.

I consider raising an exception to be much more
pythonic than checking
a return code (ie "Errors should never pass silently"
from Zen of
Python)

Eg

# An easy to miss error

>>> subprocess.call(["mkdir", "a/b"])
mkdir: cannot create directory `a/b': No such file or
directory
1
>>> # user forgot to check non-zero return code

# becomes an impossible to miss exception

>>> subprocess.xcall(["mkdir", "a/b"])
mkdir: cannot create directory `a/b': No such file or
directory
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "subprocess.py", line 462, in xcall
    raise CalledProcessError(rc, "Command %s returned
non zero exit status" % args[0])
subprocess.CalledProcessError: [Errno 1] Command
['mkdir', 'a/b'] returned non zero exit status
>>> 

See attached patch for more!  Its been tested under
python 2.3 on
windows and linux.


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

>Comment By: Peter ?strand (astrand)
Date: 2004-12-01 15:04

Message:
Logged In: YES 
user_id=344921

Since this is a new feature, the patch will go into trunk,
but not the 2.4 maint branch. 

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1071764&group_id=5470
From noreply at sourceforge.net  Wed Dec  1 16:32:13 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Dec  1 16:32:14 2004
Subject: [Patches] [ python-Patches-1076826 ] readline does not need termcap
Message-ID: <E1CZWSj-00018j-3a@sc8-sf-web1.sourceforge.net>

Patches item #1076826, was opened at 2004-12-01 16:32
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1076826&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Michal &#268;iha&#345; (nijel)
Assigned to: Nobody/Anonymous (nobody)
Summary: readline does not need termcap

Initial Comment:
Readline doesn't need -ltermcap (at least on some
systems), so configure check should deal with this.
Attached patch completely removes -ltermcap, however
better might be to check both possibilities.

Patch is against 2.3.3, however it applies to 2.4 also.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1076826&group_id=5470
From canadianpublications at bigstring.com  Wed Dec  1 23:50:05 2004
From: canadianpublications at bigstring.com (info)
Date: Thu Dec  2 00:36:27 2004
Subject: [Patches] Press release patches@python.org
Message-ID: <200412012250.iB1MoK932462@smtpauthproxy.prontonetworks.com>

patches@python.org


Canadian Subsidy Directory
4865 Hwy. 138
St-Andrews west
Ontario
K0C 2A0

CANADIAN SUBSIDY DIRECTORY YEAR 2004 EDITION

PRESS RELEASE


Legal Deposit-National Library of Canada
ISBN 2-922870-05-7

The revised edition of the Canadian Subsidy Directory is available. 
The most complete and affordable reference for anyone looking for
financial support.
It is deemed to be the perfect tool for new or existing businesses,
individual ventures, foundations and associations.

This Publication contains  more than 2600 direct and indirect financial
subsidies, grants and loans offered by government departments and
agencies, foundations, associations and organizations.  In this 2004
edition all programs are well described.

The Canadian Subsidy Directory is sold $ 69.95, to obtain a copy please
call:
Canadian Publications toll free at: 1 - 8 6 6 - 3 2 2 - 3 3 7 6
From noreply at sourceforge.net  Thu Dec  2 07:57:06 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Dec  2 07:57:09 2004
Subject: [Patches] [ python-Patches-1077353 ] add key= argument to min and
	max
Message-ID: <E1CZktm-000631-PD@sc8-sf-web2.sourceforge.net>

Patches item #1077353, was opened at 2004-12-01 23:57
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1077353&group_id=5470

Category: Core (C code)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Steven Bethard (bediviere)
Assigned to: Nobody/Anonymous (nobody)
Summary: add key= argument to min and max

Initial Comment:
Adds a key= keyword argument to the builtin functions
min and max.  This argument works just like key for
list.sort and sorted, so that the values compared by
the min/max routine are produced by applying the key=
function to the item under consideration.  Note that
key= is *only* a keyword argument and cannot be
accessed as a positional argument so as not to
interfere with the max(a, b, c, ...) form of the functions.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1077353&group_id=5470
From noreply at sourceforge.net  Thu Dec  2 07:59:28 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Dec  2 07:59:34 2004
Subject: [Patches] [ python-Patches-1077353 ] add key= argument to min and
	max
Message-ID: <E1CZkw4-0001UI-DU@sc8-sf-web3.sourceforge.net>

Patches item #1077353, was opened at 2004-12-01 23:57
Message generated for change (Settings changed) made by bediviere
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1077353&group_id=5470

Category: Core (C code)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Steven Bethard (bediviere)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: add key= argument to min and max

Initial Comment:
Adds a key= keyword argument to the builtin functions
min and max.  This argument works just like key for
list.sort and sorted, so that the values compared by
the min/max routine are produced by applying the key=
function to the item under consideration.  Note that
key= is *only* a keyword argument and cannot be
accessed as a positional argument so as not to
interfere with the max(a, b, c, ...) form of the functions.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1077353&group_id=5470
From noreply at sourceforge.net  Thu Dec  2 23:41:33 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Dec  2 23:41:36 2004
Subject: [Patches] [ python-Patches-1077979 ] Simple webbrowser fix for
	netscape -remote
Message-ID: <E1CZzdl-0006ua-NC@sc8-sf-web4.sourceforge.net>

Patches item #1077979, was opened at 2004-12-02 17:41
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1077979&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Josh Cherry (jlcherry)
Assigned to: Nobody/Anonymous (nobody)
Summary: Simple webbrowser fix for netscape -remote

Initial Comment:
This patch simply removes a space in a netscape -remote
command that is executed by webbrowser.  This space
caused problems with certain urls, at least with
netscape 7.2.  For example,

webbrowser.open_new('http://www.python.org')

would file, though

webbrowser.open_new('http://www.python.org/')

would work.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1077979&group_id=5470
From noreply at sourceforge.net  Fri Dec  3 09:31:36 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Dec  3 09:31:39 2004
Subject: [Patches] [ python-Patches-1077353 ] add key= argument to min and
	max
Message-ID: <E1Ca8qm-0005mE-0n@sc8-sf-web3.sourceforge.net>

Patches item #1077353, was opened at 2004-12-02 01:57
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1077353&group_id=5470

Category: Core (C code)
Group: Python 2.5
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Steven Bethard (bediviere)
Assigned to: Raymond Hettinger (rhettinger)
Summary: add key= argument to min and max

Initial Comment:
Adds a key= keyword argument to the builtin functions
min and max.  This argument works just like key for
list.sort and sorted, so that the values compared by
the min/max routine are produced by applying the key=
function to the item under consideration.  Note that
key= is *only* a keyword argument and cannot be
accessed as a positional argument so as not to
interfere with the max(a, b, c, ...) form of the functions.

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-03 03:31

Message:
Logged In: YES 
user_id=80475

Added various fixups (arg handliing, error handling, ref
counts, more tests, docs, news item, and acknowledgement).

Accepted and applied.

See:
    Python/bltinmodule.c 2.319

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1077353&group_id=5470
From MICHAEL at MCPS-NY.COM  Fri Dec  3 21:48:08 2004
From: MICHAEL at MCPS-NY.COM (MICHAEL)
Date: Fri Dec  3 23:04:17 2004
Subject: [Patches] FW:  Please forward this email to your Purchasing Office,
	Thanks!
Message-ID: <20041203213429.TIYF1365.out004.verizon.net@michael>

Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: SPY_CAM_Price_List_3_110804.doc
Type: application/msword
Size: 2480128 bytes
Desc: not available
Url : http://mail.python.org/pipermail/patches/attachments/20041203/d56dcb30/SPY_CAM_Price_List_3_110804-0001.doc
From noreply at sourceforge.net  Sat Dec  4 11:14:31 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Dec  4 11:14:35 2004
Subject: [Patches] [ python-Patches-1071911 ] Add support for db 4.3
Message-ID: <E1CaWvv-0002Wh-Iw@sc8-sf-web3.sourceforge.net>

Patches item #1071911, was opened at 2004-11-24 02:11
Message generated for change (Comment added) made by suzuki_hisao
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1071911&group_id=5470

Category: Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Michal &#268;iha&#345; (nijel)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add support for db 4.3

Initial Comment:
Hi, attached patch adds support for db 4.3. It doens't
cover almost no new constants (only one that was at
least in 4.2), but just allows compiling.

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

Comment By: SUZUKI Hisao (suzuki_hisao)
Date: 2004-12-04 19:14

Message:
Logged In: YES 
user_id=495142

Your patch works well, except for "has_key()".
It results False always.
This is because an API of DB has changed slightly:
DB->get() returns DB_BUFFER_SMALL instead of ENOMEM now.
For Modules/_bsddb.c, we need:

@@ -2536,7 +2552,11 @@
     err = self->db->get(self->db, txn, &key, &data, 0);
     MYDB_END_ALLOW_THREADS;
     FREE_DBT(key);
+#if (DBVER >= 43)
+    return PyInt_FromLong((err == DB_BUFFER_SMALL) || (err
== 0));
+#else
     return PyInt_FromLong((err == ENOMEM) || (err == 0));
+#endif
 }


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1071911&group_id=5470
From noreply at sourceforge.net  Sun Dec  5 07:56:17 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Dec  5 07:56:20 2004
Subject: [Patches] [ python-Patches-1068277 ] os.path.exists returns False
	if no permission
Message-ID: <E1CaqJd-0005iO-3p@sc8-sf-web1.sourceforge.net>

Patches item #1068277, was opened at 2004-11-17 16:20
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1068277&group_id=5470

Category: Documentation
Group: Python 2.5
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Robert Brewer (aminusfu)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.path.exists returns False if no permission

Initial Comment:
A single new sentence for os.path.exists description,
which makes it clear that it may return False even if
the path actually exists.

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2004-12-05 01:56

Message:
Logged In: YES 
user_id=3066

This should be committed on the trunk and release24-maint
branch.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1068277&group_id=5470
From noreply at sourceforge.net  Sun Dec  5 19:59:09 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Dec  5 19:59:14 2004
Subject: [Patches] [ python-Patches-1076826 ] readline does not need termcap
Message-ID: <E1Cb1bB-000121-2b@sc8-sf-web2.sourceforge.net>

Patches item #1076826, was opened at 2004-12-01 16:32
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1076826&group_id=5470

Category: Library (Lib)
Group: Python 2.4
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Michal &#268;iha&#345; (nijel)
Assigned to: Nobody/Anonymous (nobody)
Summary: readline does not need termcap

Initial Comment:
Readline doesn't need -ltermcap (at least on some
systems), so configure check should deal with this.
Attached patch completely removes -ltermcap, however
better might be to check both possibilities.

Patch is against 2.3.3, however it applies to 2.4 also.

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

>Comment By: Martin v. L?wis (loewis)
Date: 2004-12-05 19:59

Message:
Logged In: YES 
user_id=21627

The patch is incorrect. As you suggest yourself, readline
*does* need -ltermcap on some systems; this patch breaks
these systems. Rejecting the patch. If you can come up with
a patch that performs an autoconf test first, please submit
a new patch.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1076826&group_id=5470
From noreply at sourceforge.net  Sun Dec  5 21:05:58 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Dec  5 21:06:04 2004
Subject: [Patches] [ python-Patches-1071755 ] raise error for common mistake
	with subprocess
Message-ID: <E1Cb2dq-0000iZ-Kv@sc8-sf-web1.sourceforge.net>

Patches item #1071755, was opened at 2004-11-23 15:35
Message generated for change (Comment added) made by astrand
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1071755&group_id=5470

Category: Library (Lib)
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nick Craig-Wood (ncw)
Assigned to: Nobody/Anonymous (nobody)
Summary: raise error for common mistake with subprocess

Initial Comment:
subprocess has a very easy to mistake error in it -
forgetting to pass the command as a list.  Eg

>>> import subprocess
>>> subprocess.call("ls")
BaseHTTPServer.py      dummy_threading.py 
pickletools.py   socket.py
Bastion.py             email               pipes.py   
     sre.py
[...]
dummy_thread.py        pickle.pyc          sndhdr.py  
     zipfile.py
0
>>> subprocess.call("ls", "-l")
BaseHTTPServer.py      dummy_threading.py 
pickletools.py   socket.py
Bastion.py             email               pipes.py   
     sre.py
[...]
dummy_thread.py        pickle.pyc          sndhdr.py  
     zipfile.py
0
>>> 

# Note no error, warning or anything, but no "ls -l" either

And with the patch...

>>> subprocess.call("ls", "-l")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "subprocess.py", line 428, in call
    return Popen(*args, **kwargs).wait()
  File "subprocess.py", line 508, in __init__
    raise TypeError("bufsize must be an integer - "
TypeError: bufsize must be an integer - did you forget
to pass your arguments in a list?
>>> 


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

>Comment By: Peter ?strand (astrand)
Date: 2004-12-05 21:05

Message:
Logged In: YES 
user_id=344921

Now applied to 2.4-branch:

subprocess.py: 1.8.2.2
test_subprocess.py: 1.15.2.1


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

Comment By: Peter ?strand (astrand)
Date: 2004-12-01 15:03

Message:
Logged In: YES 
user_id=344921

Should be applied to the 2.4 branch as well. 

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

Comment By: Peter ?strand (astrand)
Date: 2004-11-30 22:55

Message:
Logged In: YES 
user_id=344921

I've applied the patch (slightly modified) on the CVS trunk:
subprocess.py 1.10
test_subprocess.py 1.16

I've not committed the patch to the 2.4 branch, however. 

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1071755&group_id=5470
From noreply at sourceforge.net  Sun Dec  5 22:20:42 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Dec  5 22:20:45 2004
Subject: [Patches] [ python-Patches-1071764 ] a new subprocess.call which
	raises an error on non-zero rc
Message-ID: <E1Cb3oA-0002Ob-JO@sc8-sf-web4.sourceforge.net>

Patches item #1071764, was opened at 2004-11-23 15:45
Message generated for change (Comment added) made by astrand
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1071764&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Nick Craig-Wood (ncw)
Assigned to: Nobody/Anonymous (nobody)
Summary: a new subprocess.call which raises an error on non-zero rc

Initial Comment:
The attached patch introduces a 3rd utility function -
xcall() to the
subprocess module.  This function acts just like call
but raises
errors if the command had a non-zero return code.

This saves writing

if call(...):
    raise OSError(...)

It is most useful for shell script replacement
programming.  Checking
the return codes of commands called is often forgotten
in shell
programming.

When you've moved up to python because shell is too
limiting (usually
about 10 lines of shell in my case ;-) you want to make
sure that all
your commands work so you write robust code.

I consider raising an exception to be much more
pythonic than checking
a return code (ie "Errors should never pass silently"
from Zen of
Python)

Eg

# An easy to miss error

>>> subprocess.call(["mkdir", "a/b"])
mkdir: cannot create directory `a/b': No such file or
directory
1
>>> # user forgot to check non-zero return code

# becomes an impossible to miss exception

>>> subprocess.xcall(["mkdir", "a/b"])
mkdir: cannot create directory `a/b': No such file or
directory
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "subprocess.py", line 462, in xcall
    raise CalledProcessError(rc, "Command %s returned
non zero exit status" % args[0])
subprocess.CalledProcessError: [Errno 1] Command
['mkdir', 'a/b'] returned non zero exit status
>>> 

See attached patch for more!  Its been tested under
python 2.3 on
windows and linux.


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

>Comment By: Peter ?strand (astrand)
Date: 2004-12-05 22:20

Message:
Logged In: YES 
user_id=344921

My suggested name is "check_call". 

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

Comment By: Peter ?strand (astrand)
Date: 2004-12-01 15:04

Message:
Logged In: YES 
user_id=344921

Since this is a new feature, the patch will go into trunk,
but not the 2.4 maint branch. 

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1071764&group_id=5470
From noreply at sourceforge.net  Mon Dec  6 05:05:58 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Dec  6 05:06:01 2004
Subject: [Patches] [ python-Patches-1079729 ] Make cgi.py use logging module
Message-ID: <E1CbA8M-00076A-Vr@sc8-sf-web4.sourceforge.net>

Patches item #1079729, was opened at 2004-12-05 20:05
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1079729&group_id=5470

Category: Library (Lib)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Josh Hoyt (joshhoyt)
Assigned to: Nobody/Anonymous (nobody)
Summary: Make cgi.py use logging module

Initial Comment:
The attached patch makes the CGI module use the logging
module for logging.

There is no change in behaviour for the old idioms of
using the cgi module's built-in logging facility, but
this allows users to use the logging framework to
direct and format log messages.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1079729&group_id=5470
From noreply at sourceforge.net  Mon Dec  6 05:22:10 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Dec  6 05:22:13 2004
Subject: [Patches] [ python-Patches-1079734 ] Make cgi.py use email instead
	of rfc822 or mimetools
Message-ID: <E1CbAO2-0007Ye-5m@sc8-sf-web4.sourceforge.net>

Patches item #1079734, was opened at 2004-12-05 20:22
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1079734&group_id=5470

Category: Library (Lib)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Josh Hoyt (joshhoyt)
Assigned to: Nobody/Anonymous (nobody)
Summary: Make cgi.py use email instead of rfc822 or mimetools

Initial Comment:
Remove dependencies on (deprecated) rfc822 and
mimetools modules, replacing with email.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1079734&group_id=5470
From noreply at sourceforge.net  Mon Dec  6 11:33:47 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Dec  6 11:33:49 2004
Subject: [Patches] [ python-Patches-1079734 ] Make cgi.py use email instead
	of rfc822 or mimetools
Message-ID: <E1CbGBf-00033v-AY@sc8-sf-web3.sourceforge.net>

Patches item #1079734, was opened at 2004-12-05 23:22
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1079734&group_id=5470

Category: Library (Lib)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Josh Hoyt (joshhoyt)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Make cgi.py use email instead of rfc822 or mimetools

Initial Comment:
Remove dependencies on (deprecated) rfc822 and
mimetools modules, replacing with email.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1079734&group_id=5470
From noreply at sourceforge.net  Mon Dec  6 11:38:47 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Dec  6 11:38:53 2004
Subject: [Patches] [ python-Patches-1070218 ] Add BLANK_LINE to token.py
Message-ID: <E1CbGGV-00056X-Sw@sc8-sf-web4.sourceforge.net>

Patches item #1070218, was opened at 2004-11-20 16:58
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1070218&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: logistix (logistix)
>Assigned to: Jeremy Hylton (jhylton)
Summary: Add BLANK_LINE to token.py

Initial Comment:
The parser module generates an ast node number 54 for 
an entirely blank line.  These lines are apparently ignored 
by the real parser, and don't have a real definition in 
include\token.h.  Presumably because of that they don't 
have an entry in token.py.

However, this broke an app where I hardcoded the 
number and recent language features have changed the 
mapping of numbers to token names.

I think there should be a BLANK_LINE defined in token.py 
so that it can be referred to by name, even if it's not 
used in the real parser.  While dealing with parsermodule 
generated ast-trees, "symbol.sym_name[node] or 
token.tok_name[node]" should always be true.

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

Comment By: logistix (logistix)
Date: 2004-11-21 19:41

Message:
Logged In: YES 
user_id=699438

A few clarifications:

On further review, the node number 54 comes from 
tokenize.py, not the parsermodule.

I also meant to say that "symbol.sym_name.has_key(node) or 
token.tok_name.has_key(node)" should always be true.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1070218&group_id=5470
From noreply at sourceforge.net  Mon Dec  6 12:09:28 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Dec  6 12:09:32 2004
Subject: [Patches] [ python-Patches-1071911 ] Add support for db 4.3
Message-ID: <E1CbGkC-0004TT-9m@sc8-sf-web3.sourceforge.net>

Patches item #1071911, was opened at 2004-11-23 18:11
Message generated for change (Comment added) made by nijel
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1071911&group_id=5470

Category: Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Michal &#268;iha&#345; (nijel)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add support for db 4.3

Initial Comment:
Hi, attached patch adds support for db 4.3. It doens't
cover almost no new constants (only one that was at
least in 4.2), but just allows compiling.

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

>Comment By: Michal &#268;iha&#345; (nijel)
Date: 2004-12-06 12:09

Message:
Logged In: YES 
user_id=192186

Yes, you're right I missed that (or better to say: I looked
just at compile time errors). Updated patch with included
your hunk.

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

Comment By: SUZUKI Hisao (suzuki_hisao)
Date: 2004-12-04 11:14

Message:
Logged In: YES 
user_id=495142

Your patch works well, except for "has_key()".
It results False always.
This is because an API of DB has changed slightly:
DB->get() returns DB_BUFFER_SMALL instead of ENOMEM now.
For Modules/_bsddb.c, we need:

@@ -2536,7 +2552,11 @@
     err = self->db->get(self->db, txn, &key, &data, 0);
     MYDB_END_ALLOW_THREADS;
     FREE_DBT(key);
+#if (DBVER >= 43)
+    return PyInt_FromLong((err == DB_BUFFER_SMALL) || (err
== 0));
+#else
     return PyInt_FromLong((err == ENOMEM) || (err == 0));
+#endif
 }


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1071911&group_id=5470
From noreply at sourceforge.net  Mon Dec  6 12:18:31 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Dec  6 12:18:35 2004
Subject: [Patches] [ python-Patches-1076826 ] readline does not need termcap
Message-ID: <E1CbGsx-0006n0-J0@sc8-sf-web4.sourceforge.net>

Patches item #1076826, was opened at 2004-12-01 16:32
Message generated for change (Comment added) made by nijel
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1076826&group_id=5470

Category: Library (Lib)
Group: Python 2.4
>Status: Open
>Resolution: None
Priority: 5
Submitted By: Michal &#268;iha&#345; (nijel)
Assigned to: Nobody/Anonymous (nobody)
Summary: readline does not need termcap

Initial Comment:
Readline doesn't need -ltermcap (at least on some
systems), so configure check should deal with this.
Attached patch completely removes -ltermcap, however
better might be to check both possibilities.

Patch is against 2.3.3, however it applies to 2.4 also.

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

>Comment By: Michal &#268;iha&#345; (nijel)
Date: 2004-12-06 12:18

Message:
Logged In: YES 
user_id=192186

Okay, here is IMHO correct patch, which does more or less
same as setup.py does for finding needed libraries.

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

Comment By: Martin v. L?wis (loewis)
Date: 2004-12-05 19:59

Message:
Logged In: YES 
user_id=21627

The patch is incorrect. As you suggest yourself, readline
*does* need -ltermcap on some systems; this patch breaks
these systems. Rejecting the patch. If you can come up with
a patch that performs an autoconf test first, please submit
a new patch.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1076826&group_id=5470
From noreply at sourceforge.net  Mon Dec  6 18:15:26 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Dec  6 18:15:29 2004
Subject: [Patches] [ python-Patches-1080078 ] list sort is not "in place"
Message-ID: <E1CbMSM-0003mL-GE@sc8-sf-web3.sourceforge.net>

Patches item #1080078, was opened at 2004-12-06 19:15
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1080078&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Heikki Orsila (shd)
Assigned to: Nobody/Anonymous (nobody)
Summary: list sort is not "in place"

Initial Comment:
list sort method says the sort algorithm is "in place",
but it is not. It requires O(N) extra memory at worst
case. A patch is attached that corrects the
documentation in Objects/listobjects.c.




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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1080078&group_id=5470
From noreply at sourceforge.net  Mon Dec  6 18:48:54 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Dec  6 18:48:59 2004
Subject: [Patches] [ python-Patches-1080078 ] list sort is not "in place"
Message-ID: <E1CbMyk-0004HD-6X@sc8-sf-web2.sourceforge.net>

Patches item #1080078, was opened at 2004-12-06 12:15
Message generated for change (Settings changed) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1080078&group_id=5470

Category: Documentation
Group: Python 2.4
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Heikki Orsila (shd)
>Assigned to: Tim Peters (tim_one)
Summary: list sort is not "in place"

Initial Comment:
list sort method says the sort algorithm is "in place",
but it is not. It requires O(N) extra memory at worst
case. A patch is attached that corrects the
documentation in Objects/listobjects.c.




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

>Comment By: Tim Peters (tim_one)
Date: 2004-12-06 12:48

Message:
Logged In: YES 
user_id=31435

Sorry, I'm rejecting this.  Of course it's "in place":  x.sort() 
does not return a new list.  Its only visible effect is to 
permute the elements of x.  That's what "in place" means.

That the current implementation may require temp memory is 
irrelevant to that, and *because* it's an internal 
implementation detail, doesn't belong in the docstring.  
The "in place" was added to the docstring because many 
newcomers believed x.sort() left x alone, and returned a new 
list in sorted order (which is what the new-in-2.4 sorted() 
builtin does).

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1080078&group_id=5470
From noreply at sourceforge.net  Mon Dec  6 18:49:31 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Dec  6 18:49:35 2004
Subject: [Patches] [ python-Patches-1080078 ] list sort is not "in place"
Message-ID: <E1CbMzL-0005Nk-5s@sc8-sf-web3.sourceforge.net>

Patches item #1080078, was opened at 2004-12-06 12:15
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1080078&group_id=5470

Category: Documentation
Group: Python 2.4
>Status: Open
Resolution: Rejected
Priority: 5
Submitted By: Heikki Orsila (shd)
>Assigned to: Nobody/Anonymous (nobody)
Summary: list sort is not "in place"

Initial Comment:
list sort method says the sort algorithm is "in place",
but it is not. It requires O(N) extra memory at worst
case. A patch is attached that corrects the
documentation in Objects/listobjects.c.




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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-06 12:49

Message:
Logged In: YES 
user_id=80475

Sorry, the patch is not right.  In-place is meant to
communicate thet the original list is mutated.  Contrast
that with the behavior of sorted() which leaves the original
intact.

Perhaps you are thinking in terms of heapsort which is
in-place and requires no additional auxiliary storage. 
While that is not true for the current algorithm, we do not
document or make promises about the memory requirements --
that is considered to be an implementation detail that is
subject to change.

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

Comment By: Tim Peters (tim_one)
Date: 2004-12-06 12:48

Message:
Logged In: YES 
user_id=31435

Sorry, I'm rejecting this.  Of course it's "in place":  x.sort() 
does not return a new list.  Its only visible effect is to 
permute the elements of x.  That's what "in place" means.

That the current implementation may require temp memory is 
irrelevant to that, and *because* it's an internal 
implementation detail, doesn't belong in the docstring.  
The "in place" was added to the docstring because many 
newcomers believed x.sort() left x alone, and returned a new 
list in sorted order (which is what the new-in-2.4 sorted() 
builtin does).

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1080078&group_id=5470
From noreply at sourceforge.net  Mon Dec  6 18:49:46 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Dec  6 18:49:52 2004
Subject: [Patches] [ python-Patches-1080078 ] list sort is not "in place"
Message-ID: <E1CbMza-0005OY-It@sc8-sf-web3.sourceforge.net>

Patches item #1080078, was opened at 2004-12-06 12:15
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1080078&group_id=5470

Category: Documentation
Group: Python 2.4
>Status: Closed
Resolution: Rejected
Priority: 5
Submitted By: Heikki Orsila (shd)
Assigned to: Nobody/Anonymous (nobody)
Summary: list sort is not "in place"

Initial Comment:
list sort method says the sort algorithm is "in place",
but it is not. It requires O(N) extra memory at worst
case. A patch is attached that corrects the
documentation in Objects/listobjects.c.




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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-06 12:49

Message:
Logged In: YES 
user_id=80475

Sorry, the patch is not right.  In-place is meant to
communicate thet the original list is mutated.  Contrast
that with the behavior of sorted() which leaves the original
intact.

Perhaps you are thinking in terms of heapsort which is
in-place and requires no additional auxiliary storage. 
While that is not true for the current algorithm, we do not
document or make promises about the memory requirements --
that is considered to be an implementation detail that is
subject to change.

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

Comment By: Tim Peters (tim_one)
Date: 2004-12-06 12:48

Message:
Logged In: YES 
user_id=31435

Sorry, I'm rejecting this.  Of course it's "in place":  x.sort() 
does not return a new list.  Its only visible effect is to 
permute the elements of x.  That's what "in place" means.

That the current implementation may require temp memory is 
irrelevant to that, and *because* it's an internal 
implementation detail, doesn't belong in the docstring.  
The "in place" was added to the docstring because many 
newcomers believed x.sort() left x alone, and returned a new 
list in sorted order (which is what the new-in-2.4 sorted() 
builtin does).

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1080078&group_id=5470
From noreply at sourceforge.net  Mon Dec  6 22:26:01 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Dec  6 22:26:06 2004
Subject: [Patches] [ python-Patches-1075928 ] AUTH PLAIN in smtplib
Message-ID: <E1CbQMr-0003lB-0f@sc8-sf-web1.sourceforge.net>

Patches item #1075928, was opened at 2004-11-30 12:27
Message generated for change (Comment added) made by jlgijsbers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1075928&group_id=5470

Category: Library (Lib)
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: James Lan (flyingboy)
Assigned to: Johannes Gijsbers (jlgijsbers)
Summary: AUTH PLAIN in smtplib

Initial Comment:
smtplib can not log in to some server using command
AUTH PLAIN, it sends ``user\0user\0pass'' to the
server, but ``\0user\0pass'' has better compatibility.

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

>Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-12-06 22:26

Message:
Logged In: YES 
user_id=469548

Checked in on HEAD as rev 1.66 of smtplib.py.

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

Comment By: James Lan (flyingboy)
Date: 2004-12-01 06:44

Message:
Logged In: YES 
user_id=222344

Some freemail servers in China :-(
If you could read chinese, you can try registering an
account at www.126.com :-)


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

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-11-30 13:13

Message:
Logged In: YES 
user_id=469548

Assigning to me for commit after the trunk opens again, as
it shouldn't be harmful. James, I'm just wondering what
servers are so broken that they can't handle the first form?

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

Comment By: James Lan (flyingboy)
Date: 2004-11-30 12:33

Message:
Logged In: YES 
user_id=222344

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file. In addition, even if you
*did* check this checkbox, a bug in SourceForge
prevents attaching a file when *creating* an issue.

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=305470&aid=1075928&group_id=5470
From noreply at sourceforge.net  Mon Dec  6 22:35:23 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Dec  6 22:35:32 2004
Subject: [Patches] [ python-Patches-736962 ] Port tests to unittest (Part 2)
Message-ID: <E1CbQVv-0001CK-Gj@sc8-sf-web4.sourceforge.net>

Patches item #736962, was opened at 2003-05-13 12:45
Message generated for change (Comment added) made by jlgijsbers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470

Category: Tests
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Walter D?rwald (doerwalter)
Assigned to: Nobody/Anonymous (nobody)
Summary: Port tests to unittest (Part 2)

Initial Comment:
Here are the next test scripts ported to PyUnit:
test_winsound and test_array. For test_array many
additional tests have been added (code coverage is at 91%)

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

>Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-12-06 22:35

Message:
Logged In: YES 
user_id=469548

Just reviewed my test_inspect conversion again and didn't
find any faults. Does anyone have the time to review it or
should I just check it in? http://python.org/sf/1011890 is
waiting on this conversion, so I'm aching to go. :)

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

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-09-24 23:42

Message:
Logged In: YES 
user_id=469548

Checked in as rev 1.8 of test_unpack.py. Thanks for the review!

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

Comment By: Walter D?rwald (doerwalter)
Date: 2004-09-22 20:36

Message:
Logged In: YES 
user_id=89016

test_unpack_doctest.py looks good. Please check it in (as 
test_unpack.py)

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

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-09-08 17:37

Message:
Logged In: YES 
user_id=469548

Yeah, bug #1023798 reported that and Brett fixed it.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2004-09-07 22:34

Message:
Logged In: YES 
user_id=89016

I'm getting the following error from the new test__locale:
test test__locale failed -- Traceback (most recent call last):
  File "/home/walter/Achtung/Python-codec-
small/dist/src/Lib/test/test__locale.py", line 37, in 
test_lc_numeric
    "%r != %r (%s); "
  File "/home/walter/Achtung/Python-codec-
small/dist/src/Lib/locale.py", line 363, in getlocale
    return _parse_localename(localename)
  File "/home/walter/Achtung/Python-codec-
small/dist/src/Lib/locale.py", line 278, in _parse_localename
    raise ValueError, 'unknown locale: %s' % localename
ValueError: unknown locale: lv_LV

BTW, could someone have a look at Johannes' test_doctest 
and test_inspect patches?

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

Comment By: Brett Cannon (bcannon)
Date: 2004-09-07 04:32

Message:
Logged In: YES 
user_id=357491

OK, test__locale has been checked in.

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

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-30 13:00

Message:
Logged In: YES 
user_id=469548

Brett: that's just one of the drawbacks of doing data-driven
testing with unittest. I don't think it's terribly
important, so the test is OK to me.

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

Comment By: Brett Cannon (bcannon)
Date: 2004-08-27 05:44

Message:
Logged In: YES 
user_id=357491

Just attached a new version of test__locale.  Since it is so small of a file 
and the change so drastic I just uploaded the whole file.

Only drawback is before the test kept testing all locales when there was 
a failure while my implementation stops at the first failure discovered.  
Don't know if it is important to test all locales.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-08-24 18:59

Message:
Logged In: YES 
user_id=80475

Walter, I'm afraid I don't have time for these right now.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2004-08-20 18:39

Message:
Logged In: YES 
user_id=89016

Raymond, can you take a look at the patches?

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

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-20 17:06

Message:
Logged In: YES 
user_id=469548

Another one: ported test_inspect to unittest and moved out
the inspect fodder out into two modules instead of using the
ugly imp.load_source and TESTFN. I also did a bit of
rearrangement so that the TestCase classes mostly match the
sections in the library docs.

I used a separate module (inspect_fodder2)  and class for
the decorators tests. Those are kind of small now, but I'll
check in http://python.org/sf/1011890 after this port and
let it grow without having to update test_getfunctions().

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

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-19 17:14

Message:
Logged In: YES 
user_id=469548

Hum yes, that was me trying out how doctest fails. The
expected outcome should have been True. Can you try the
corrected version?

Test_zipfile has been checked in as rev 1.11.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2004-08-18 21:29

Message:
Logged In: YES 
user_id=89016

doctest tests should be OK. The error tests in test_unpack 
can be done with PyUnit too, you either use

self.assertRaises(ValueError, eval, "a,b = Seq()")

or

try:
   a,b = Seq()
except ValueError:
   pass
else:
   self.fail("failed")

test_zipfile_unittest.py looks OK, but should of course be 
named test_zipfile.py when you check it in.

test_unpack_doctest.py gives me:
**********************************************
************************
Failure in example: a == 4 and b == 5 and c == 6
from line #14 of test.test_unpack_doctest.doctests 
in /home/walter/Achtung/Python-
test/dist/src/Lib/test/test_unpack_doctest.pyc
Expected: False
Got: True
**********************************************
************************
1 items had failures:
   1 of  28 in test.test_unpack_doctest.doctests
***Test Failed*** 1 failures.
Traceback (most recent call last):
  File "Lib/test/test_unpack_doctest.py", line 133, in ?
    test_main(verbose=True)
  File "Lib/test/test_unpack_doctest.py", line 130, in test_main
    test_support.run_doctest(test_unpack_doctest, verbose)
  File "/home/walter/Achtung/Python-
test/dist/src/Lib/test/test_support.py", line 318, in 
run_doctest
    raise TestFailed("%d of %d doctests failed" % (f, t))
test.test_support.TestFailed: 1 of 28 doctests failed

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

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-18 15:23

Message:
Logged In: YES 
user_id=469548

Is there any problem with porting test scripts to doctest
instead of unittest? doctest is just perfect for test_unpack
(doctest version attached).

I've also ported test_zipfile to unittest (attached as well).

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

Comment By: Walter D?rwald (doerwalter)
Date: 2004-05-31 18:31

Message:
Logged In: YES 
user_id=89016

OK, checked in as:
Lib/test/mapping_tests.py 1.1
Lib/test/test_os.py 1.22
Lib/test/test_shelve.py 1.7
Lib/test/test_types.py 1.60
Lib/test/test_userdict.py 1.19
Lib/test/test_weakref.py 1.39

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-05-29 01:02

Message:
Logged In: YES 
user_id=80475

Looks good.


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

Comment By: Walter D?rwald (doerwalter)
Date: 2004-05-28 22:59

Message:
Logged In: YES 
user_id=89016

OK, I've updated the docstring for dict.update() 
(Object/dictobject.c 2.160)

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

Comment By: Walter D?rwald (doerwalter)
Date: 2004-05-27 21:04

Message:
Logged In: YES 
user_id=89016

dict_diff.txt is a patch that tries to share tests between 
test_dict, test_userdict, test_os, test_shelve and 
test_weakref.

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

Comment By: Tim Peters (tim_one)
Date: 2004-05-25 22:29

Message:
Logged In: YES 
user_id=31435

Don't really care myself.  Would be nice if the docstring for 
dict.update() matched the new realities, though <wink>.

BTW, there is a reliable and conventional way to detect 
whether the 'dict' argument was passed to UserDict.update:  
use a unique marker object instead of the universally visible 
None.  Like

_marker = object()

at module level, and

    ...(self, dict=_marker, ...)

in the method defn.  That can't be fooled without deliberate 
intent to deceive.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-05-25 22:21

Message:
Logged In: YES 
user_id=80475

IMO, it is fine as is.  I would be suprised if some code
were relying on UserDict.update(None) raising an exception.
 This sort of thing also comes up also in places like the
string and random modules whereever a function or method
with an optional argument gets wrapped by another function.
 The only way around this is to use *args and then you break
code that used the unfortunately named "dict" argument as a
keyword.



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

Comment By: Walter D?rwald (doerwalter)
Date: 2004-05-25 21:32

Message:
Logged In: YES 
user_id=89016

Merging test_dict and test_userdict revealed a difference
between dict and UserDict.UserDict:

>>> import UserDict
>>> d = UserDict.UserDict()
>>> d.update(None)
>>> d
{}
>>> d = {}
>>> d.update(None)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: iteration over non-sequence

Should we do anything about this?

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-05-20 18:03

Message:
Logged In: YES 
user_id=80475

test_dict is fine.

Consider beefing up the tests for update().  As of Py2.4, it
now takes all the same argument possibilites as dict():
   
     d.update(a=1, b=2)
     d.update([('a', 1), ('b', 2)])

Also, try to link in:
       from test_userdict import TestMappingProtocol

This was supposed to provide tests common to all mappings.
   

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

Comment By: Walter D?rwald (doerwalter)
Date: 2004-04-03 13:06

Message:
Logged In: YES 
user_id=89016

The attached test_dict.py moves the dict tests from 
test_types.py to a new PyUnit test script. Code coverage for 
dictobject.c is at 90.76% (up from 89.51%)

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

Comment By: Walter D?rwald (doerwalter)
Date: 2004-03-15 13:17

Message:
Logged In: YES 
user_id=89016

Checked in as:
Lib/test/output/test_binascii delete
Lib/test/test_binascii.py 1.17

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-13 21:26

Message:
Logged In: YES 
user_id=80475

Okay, this one is fine.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-12-19 00:49

Message:
Logged In: YES 
user_id=89016

Here's the next one: test_binascii.py. Code coverage in
binascii.c is at 92% (could be improved by enhancing
test_binhex.py).

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-12-13 23:46

Message:
Logged In: YES 
user_id=33168

Looked good to me, test_future_pyunit.diff checked in as:
 * Lib/test/badsyntax_future3.py 1.2
 * Lib/test/badsyntax_future4.py 1.2
 * Lib/test/badsyntax_future5.py 1.2
 * Lib/test/badsyntax_future6.py 1.2
 * Lib/test/badsyntax_future7.py 1.2
 * Lib/test/badsyntax_future8.py 1.1
 * Lib/test/badsyntax_future9.py 1.1
 * Lib/test/test_future.py 1.7
 * Lib/test/test_future1.py 1.3
 * Lib/test/test_future2.py 1.2
 * Lib/test/output/test_future 1.4

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-12-13 22:47

Message:
Logged In: YES 
user_id=33168

Walter, I didn't get a mail from SF either.  After you do a
cvs add, you need to use -N to cvs diff.  For example, cvs
diff -N new_file_added_to_cvs_but_not_committed.  If you
look carefully, you can see this in the patch on the diff
line for each file.  I'll take a look at the patch.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-12-13 21:18

Message:
Logged In: YES 
user_id=89016

Here is a version of test_future ported to PyUnit
(test_future_pyunit.diff). If this makes sense to you Neal,
please check it in.

(BTW, how did you convince CVS to include
badsyntax_future8.py and badsyntax_future9.py in the diff?
Doing a &quot;cvs add&quot; only results in &quot;
Lib/test/badsyntax_future8.py is a new entry, no comparison
available&quot;)

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-12-11 13:36

Message:
Logged In: YES 
user_id=89016

md5/weakref patch checked in as:
Lib/test/test_weakref.py 1.33
Lib/test/test_md5.py 1.5
Lib/test/output/test_md5 remove


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-12-11 07:05

Message:
Logged In: YES 
user_id=33168

Improve coverage for test_future too.  I'm not sure if test
future can be ported to PyUnit.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-12-11 06:52

Message:
Logged In: YES 
user_id=33168

Attached are two tests (in one file, I'm being lazy, sorry)
to improve test coverage for md5c.c and _weakref.c. 
test_md5 was ported to unittest, weakref, just adds two
little tests to get coverage up to 100%.  If you like, just
go ahead and check in.  You will need to remove
Lib/test/output/test_md5

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-12-08 12:42

Message:
Logged In: YES 
user_id=89016

Checked in as:
Lib/test/list_tests.py 1.1
Lib/test/seq_tests.py 1.1
Lib/test/test_list.py 1.1
Lib/test/test_tuple.py 1.1
Lib/test/test_types.py 1.56
Lib/test/test_userlist.py 1.11
Lib/test/output/test_types 1.3

Next will be test_binascii.py before I continue with
test_types.py.


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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-12-08 00:49

Message:
Logged In: YES 
user_id=80475

Looks good.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-11-27 20:48

Message:
Logged In: YES 
user_id=89016

Here the first part of the test_types port: list and tuple
tests have been moved to their own scripts: test_tuple.py
and test_list.py. Common tests for tuple, list and UserList
are shared (in seq_test.py and list_test.py)

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-02 03:53

Message:
Logged In: YES 
user_id=80475

Applied as:
   Lib/test/test_slice.py 1.5.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-01 01:52

Message:
Logged In: YES 
user_id=80475

Looks good.
I added a couple of minor tests.
Revised patch attached.
Okay to apply.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-08-31 21:49

Message:
Logged In: YES 
user_id=89016

Thanks! Here's another one: test_slice.py

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-08-31 01:04

Message:
Logged In: YES 
user_id=80475

Done.

See:
Lib/test/test_longexp.py 1.9; previous revision: 1.8
Lib/test/test_pep263.py 1.3; previous revision: 1.2
Lib/test/test_sets.py 1.27; previous revision: 1.26
Lib/test/test_structseq.py 1.5; previous revision: 1.4
Lib/test/output/test_longexp delete; previous revision: 1.3

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-08-30 19:10

Message:
Logged In: YES 
user_id=80475

Will do!

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-08-30 19:06

Message:
Logged In: YES 
user_id=89016

Here's test_structse.py converted with a few additional
tests. If all three scripts are OK, could you check them in
Raymond, as I'll be on vacation for three weeks?

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-08-09 17:47

Message:
Logged In: YES 
user_id=89016

Here are two simple ones: test_pep263 and test_longexp. I
can't think of any additional tests to add.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-23 15:38

Message:
Logged In: YES 
user_id=80475

Fixed Walter's review comments and
committed as Lib/test/test_compile.py 1.19

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-06-23 13:49

Message:
Logged In: YES 
user_id=89016

Are you sure, that the code path is the same in the new
test_argument_handling() as in the old test? I.e. is
&quot;eval('lambda a,a: 0')&quot; the same as &quot;exec 'def f(a, a): pass'&quot;?

The print statement in test_float_literals should be changed
to a comment.

Should the imports in test_unary_minus() be moved to the
start of the script?

Otherwise the test looks (and runs) OK.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-20 21:26

Message:
Logged In: YES 
user_id=80475

Here's one for you:

test_compile.py is ready.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-06-19 11:46

Message:
Logged In: YES 
user_id=89016

Maybe test_types.py should be split into several scripts:
test_dict, test_tuple, test_list, test_int, test_long etc.
Some of them already exist (like test_long), some don't. The
constructor tests from test_builtin should probably be moved
to the new test scripts as well. Furthermore we should try
to share as much testing functionality as possible (e.g.
between test_int and test_long, or between test_list and
test_userlist)

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-18 21:48

Message:
Logged In: YES 
user_id=80475

Great!
Can I suggest that test_types.py be next.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-06-18 16:27

Message:
Logged In: YES 
user_id=89016

Checked in as:
Lib/test/test_builtin.py 1.21
Lib/test/test_complex.py 1.10

(I've moved the constructor tests from test_builtin to
test_complex)

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-18 01:49

Message:
Logged In: YES 
user_id=80475

I added a few tests.  If they are fine with you, go ahead and 
commit.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-06-17 23:36

Message:
Logged In: YES 
user_id=89016

Here's the next one: text_complex.py.

There one test that's currently commented out, because it
crashes Python on Alpha (see http://www.python.org/sf/756093.

The old test scripts states that tests for the constructor
are in test_builtin, but I've added many tests to this
script, so this is no longer true. We could move the tests
to test_builtin, but IMHO that doesn't make sense, we'd
better move the rest of the constructor tests from
test_builtin to test_complex.

I'd like to have a version of assertAlmostEqual() in
unittest.py that can cope with complex numbers, but this
would have to be coordinated with the standalone version of
PyUnit (and it would probably have to wait until the 2.4
cycle starts) (I noticed that there is no assertAlmostEqual
in the code on pyunit.sf.net anyway.)

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-06-17 14:06

Message:
Logged In: YES 
user_id=89016

I'd like to keep this patch open, as it is an ongoing task
(the next test scripts to be converted will be test_complex
and then maybe test_marshal)

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

Comment By: Brett Cannon (bcannon)
Date: 2003-06-16 23:55

Message:
Logged In: YES 
user_id=357491

OK, all tests pass cleanly.  Applied as revision 1.6.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-06-16 21:51

Message:
Logged In: YES 
user_id=89016

The joys of unittesting: Breaking code to make it better! ;)

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-16 21:41

Message:
Logged In: YES 
user_id=80475

Okay, it runs fine here.  Once Brett confirms that it runs on 
the Mac, go ahead and load it.

P.S. Your improved test_mimetools.py helped detect a latent 
error in mimetools.py when it was run under Windows.  Tim 
made the fix this weekend.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-06-16 21:33

Message:
Logged In: YES 
user_id=89016

Strange, I didn't get this failure here, but I got it on my
laptop at home. I've removed the comparison with the
getatime() value from test_time(). I hope this fixes it.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-16 21:09

Message:
Logged In: YES 
user_id=80475


Walter, there is one failure left:
======================================
================================
FAIL: test_time (__main__.PosixPathTest)
-------------------------------------------------------------------
---
Traceback (most recent call last):
  File &quot;test_posixpath.py&quot;, line 125, in test_time
    self.assert_(
  File &quot;C:\PY23\lib\unittest.py&quot;, line 268, in failUnless
    if not expr: raise self.failureException, msg
AssertionError




Brett, after Walter revises the patch, just load the patch and 
make sure the test runs on the Mac.  Between the three of 
us, we can validate the suite on three different platforms.  
Cheers.



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

Comment By: Brett Cannon (bcannon)
Date: 2003-06-16 20:20

Message:
Logged In: YES 
user_id=357491

Just wanting to work me like a dog, huh, Raymond?  =)

And to clarify for my and Walter's benefit, when you say guards, 
you mean that the tests don't crap out and say they failed on 
Windows, right?  I thought posixpath was not meant to work 
under Windows.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-06-16 20:09

Message:
Logged In: YES 
user_id=89016

I didn't realize that test_posixpath must work on Windows
too. Here's a new version.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-16 18:04

Message:
Logged In: YES 
user_id=80475

The previous comment applied to another patch.
It should have said:

Assigning to Brett to make sure the patch runs on the Mac.  
Don't accept this one until it has guards that allow the tests 
to run on Windows.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-16 17:59

Message:
Logged In: YES 
user_id=80475

Assigning to Brett to give experience doing a detail review on 
this type of change.

* examine every line of the diff and consider whether there is 
any semantic change (exceptions raised, etc).

* apply the diff and run the test suite

* in the interactive mode, call-up each function and make 
sure it behaves as expected (this is necessary because the 
test coverage is very low).

* verify that the whitespace has been cleaned up.

* look for missing changes (such as use of +=)

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-16 17:44

Message:
Logged In: YES 
user_id=80475

The test file now has dependencies that do not apply to 
windows.  The failure messages are attached.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-06-16 14:48

Message:
Logged In: YES 
user_id=89016

Here's the next one: test_posixpath.py with many additional
tests.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-05-22 19:33

Message:
Logged In: YES 
user_id=89016

Checked in as:
Lib/test/output/test_mimetools delete
Lib/test/test_mimetools.py 1.4

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-05-22 18:18

Message:
Logged In: YES 
user_id=80475

test_mimetools.py is ready.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-05-22 17:05

Message:
Logged In: YES 
user_id=89016

I've attached a third version of test_mimetools.py that does
some checks for the mimetools.Message class.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-05-21 15:04

Message:
Logged In: YES 
user_id=80475

Attaching a slightly modified test_mimetools which covers 
more encodings and has a stronger set test.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-05-19 01:46

Message:
Logged In: YES 
user_id=89016

Agreed, this is too much magic for too little gain.

Back to business: Here is test_mimetools ported to PyUnit.
Tests for mimetools.Message are still missing. If you can
think of any tests please add them.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-05-18 05:18

Message:
Logged In: YES 
user_id=80475

Get the module with sys.modules:
  tests = test_support.findtestclasses(sys.modules
[__name__])
  test_support.unittest(*tests)

Yeah, the inheritance thing is a problem.  I was trying to 
avoid having to modify unittest.TestCase to have a 
metaclass.  The control of the module is kept in a 
separate SF project and one of its goals is to be backward 
compatible through 1.5.2 (meaning no metaclasses).

A possible workaround is to define a modified testcase in 
test_support so that people don't import unittest directly 
anymore:

test_support.py
-------------------------
import unittest
class SmartTestCase(unittest.TestCase):
    __metaclass__ = autotracktests
    pass

test_sets.py
------------------
class TestBasicOps(test_support.SmartTestCase):
    run = False
. . .
class TestBasicOpsEmpty(TestBasicOps):
    def setUp(self):
    . . .

Still, this is starting to seem a bit magical and tricky.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-05-18 04:52

Message:
Logged In: YES 
user_id=89016

But how do I pass the module object from inside the module?
And skipping abstract classes seems to be more work in this
version: If skipping is done via a class attribute, derived
classes have to explicitely reset this flag because of
interitance.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-05-18 03:59

Message:
Logged In: YES 
user_id=80475

Good call.

Instead of using metaclasses, perhaps add a module 
introspector function to test_support:

def findtestclasses(mod):
    tests = []
    for elem in dir(mod):
        member = getattr(mod, elem)
        if type(member) != type: continue
        if issubclass(member, unittest.TestCase):
            tests.append(member)
    return tests

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-05-18 03:45

Message:
Logged In: YES 
user_id=89016

But this can be solved with a special non-inheritable class
attribute:

class BaseTest(unittest.TestCase):
    run = False

Then the metaclass can do the following:
def __new__(cls, name, bases, dict):
    if &quot;run&quot; not in dict:
       dict[&quot;run&quot;]  = True
    cls = type.__new__(cls, name, bases, dict)
    if cls.run:
        tests.append(cls)
    return cls


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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-05-18 03:04

Message:
Logged In: YES 
user_id=80475

I don't think metaclasses or module introspection would 
help whenever there are classes that derive from TestCase 
but are not meant to be run directly (their subclasses have 
the setup/teardown/or class data).  test_sets.py has 
examples of that kind of thing.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-05-18 02:50

Message:
Logged In: YES 
user_id=89016

Checked in as:
Lib/test/test_array.py 1.20
Lib/test/test_winsound.py 1.5
Lib/test/output/test_winsound delete

&gt; The approach of using tests.append() is elegant and
&gt; makes it easier to verify that no tests are being omitted.

The most elegant approach would probably be a metaclass that
collects all TestCase subclasses that get defined. Classes
that only serve as a base class could be skipped by
specifying a certain class attribute.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-05-18 01:35

Message:
Logged In: YES 
user_id=80475

The approach of using tests.append() is elegant and 
makes it easier to verify that no tests are being omitted.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470
From noreply at sourceforge.net  Mon Dec  6 22:48:11 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Dec  6 22:48:15 2004
Subject: [Patches] [ python-Patches-1062060 ] fix for 1016880
	urllib.urlretrieve silently truncates dwnld
Message-ID: <E1CbQiJ-0001kp-V4@sc8-sf-web4.sourceforge.net>

Patches item #1062060, was opened at 2004-11-07 21:15
Message generated for change (Comment added) made by jlgijsbers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062060&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Irmen de Jong (irmen)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix for 1016880 urllib.urlretrieve silently truncates dwnld

Initial Comment:
The patch makes urllib.urlretrieve raise an IOError if
the actual download size is different from the expected
size (taken from the content-length header). 

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

>Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-12-06 22:48

Message:
Logged In: YES 
user_id=469548

Sorry Irmen, I'm a bit late with this, but now is the time
to get new "features" checked into the trunk. Could you add
a doc patch that explains the behavior as you did in your
previous message and a tests patch? I can check it in then.

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

Comment By: Irmen de Jong (irmen)
Date: 2004-11-07 21:54

Message:
Logged In: YES 
user_id=129426

NOTE:
urllib.patch2 may be a bit better. It fixes a misspelling,
and also is more relaxed about a 'wrong' download size.
To be more precise: it treats content-length as a lower
bound (just like wget and firefox appear to do). So if
there's more data to read, it  reads more data, but if less
data is available, it gives an IOError

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062060&group_id=5470
From noreply at sourceforge.net  Mon Dec  6 23:29:44 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Dec  6 23:29:48 2004
Subject: [Patches] [ python-Patches-1076826 ] readline does not need termcap
Message-ID: <E1CbRMW-0002tg-DB@sc8-sf-web3.sourceforge.net>

Patches item #1076826, was opened at 2004-12-01 16:32
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1076826&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Michal &#268;iha&#345; (nijel)
Assigned to: Nobody/Anonymous (nobody)
Summary: readline does not need termcap

Initial Comment:
Readline doesn't need -ltermcap (at least on some
systems), so configure check should deal with this.
Attached patch completely removes -ltermcap, however
better might be to check both possibilities.

Patch is against 2.3.3, however it applies to 2.4 also.

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

>Comment By: Martin v. L?wis (loewis)
Date: 2004-12-06 23:29

Message:
Logged In: YES 
user_id=21627

This patch is still incorrect. It breaks on systems where
readline requires termcap, e.g. Solaris.

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

Comment By: Michal &#268;iha&#345; (nijel)
Date: 2004-12-06 12:18

Message:
Logged In: YES 
user_id=192186

Okay, here is IMHO correct patch, which does more or less
same as setup.py does for finding needed libraries.

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

Comment By: Martin v. L?wis (loewis)
Date: 2004-12-05 19:59

Message:
Logged In: YES 
user_id=21627

The patch is incorrect. As you suggest yourself, readline
*does* need -ltermcap on some systems; this patch breaks
these systems. Rejecting the patch. If you can come up with
a patch that performs an autoconf test first, please submit
a new patch.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1076826&group_id=5470
From noreply at sourceforge.net  Mon Dec  6 23:48:44 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Dec  6 23:48:48 2004
Subject: [Patches] [ python-Patches-1076826 ] readline does not need termcap
Message-ID: <E1CbReu-0003dm-MT@sc8-sf-web3.sourceforge.net>

Patches item #1076826, was opened at 2004-12-01 16:32
Message generated for change (Comment added) made by nijel
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1076826&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Michal &#268;iha&#345; (nijel)
Assigned to: Nobody/Anonymous (nobody)
Summary: readline does not need termcap

Initial Comment:
Readline doesn't need -ltermcap (at least on some
systems), so configure check should deal with this.
Attached patch completely removes -ltermcap, however
better might be to check both possibilities.

Patch is against 2.3.3, however it applies to 2.4 also.

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

>Comment By: Michal &#268;iha&#345; (nijel)
Date: 2004-12-06 23:48

Message:
Logged In: YES 
user_id=192186

Ooops, I should better read what I write, there shouldn't be
twice ncurses, once it should be termcap.... Sorry.

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

Comment By: Martin v. L?wis (loewis)
Date: 2004-12-06 23:29

Message:
Logged In: YES 
user_id=21627

This patch is still incorrect. It breaks on systems where
readline requires termcap, e.g. Solaris.

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

Comment By: Michal &#268;iha&#345; (nijel)
Date: 2004-12-06 12:18

Message:
Logged In: YES 
user_id=192186

Okay, here is IMHO correct patch, which does more or less
same as setup.py does for finding needed libraries.

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

Comment By: Martin v. L?wis (loewis)
Date: 2004-12-05 19:59

Message:
Logged In: YES 
user_id=21627

The patch is incorrect. As you suggest yourself, readline
*does* need -ltermcap on some systems; this patch breaks
these systems. Rejecting the patch. If you can come up with
a patch that performs an autoconf test first, please submit
a new patch.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1076826&group_id=5470
From noreply at sourceforge.net  Tue Dec  7 00:36:21 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Dec  7 00:36:28 2004
Subject: [Patches] [ python-Patches-736962 ] Port tests to unittest (Part 2)
Message-ID: <E1CbSOz-0004j7-RT@sc8-sf-web2.sourceforge.net>

Patches item #736962, was opened at 2003-05-13 12:45
Message generated for change (Comment added) made by doerwalter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470

Category: Tests
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Walter D?rwald (doerwalter)
>Assigned to: Johannes Gijsbers (jlgijsbers)
Summary: Port tests to unittest (Part 2)

Initial Comment:
Here are the next test scripts ported to PyUnit:
test_winsound and test_array. For test_array many
additional tests have been added (code coverage is at 91%)

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

>Comment By: Walter D?rwald (doerwalter)
Date: 2004-12-07 00:36

Message:
Logged In: YES 
user_id=89016

What I can say is that the test script passes on my box, so
if you're feeling confident just check it in. Now that
Python 2.4 is out the door a problem in the test shouldn't
be critical.

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

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-12-06 22:35

Message:
Logged In: YES 
user_id=469548

Just reviewed my test_inspect conversion again and didn't
find any faults. Does anyone have the time to review it or
should I just check it in? http://python.org/sf/1011890 is
waiting on this conversion, so I'm aching to go. :)

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

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-09-24 23:42

Message:
Logged In: YES 
user_id=469548

Checked in as rev 1.8 of test_unpack.py. Thanks for the review!

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

Comment By: Walter D?rwald (doerwalter)
Date: 2004-09-22 20:36

Message:
Logged In: YES 
user_id=89016

test_unpack_doctest.py looks good. Please check it in (as 
test_unpack.py)

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

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-09-08 17:37

Message:
Logged In: YES 
user_id=469548

Yeah, bug #1023798 reported that and Brett fixed it.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2004-09-07 22:34

Message:
Logged In: YES 
user_id=89016

I'm getting the following error from the new test__locale:
test test__locale failed -- Traceback (most recent call last):
  File "/home/walter/Achtung/Python-codec-
small/dist/src/Lib/test/test__locale.py", line 37, in 
test_lc_numeric
    "%r != %r (%s); "
  File "/home/walter/Achtung/Python-codec-
small/dist/src/Lib/locale.py", line 363, in getlocale
    return _parse_localename(localename)
  File "/home/walter/Achtung/Python-codec-
small/dist/src/Lib/locale.py", line 278, in _parse_localename
    raise ValueError, 'unknown locale: %s' % localename
ValueError: unknown locale: lv_LV

BTW, could someone have a look at Johannes' test_doctest 
and test_inspect patches?

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

Comment By: Brett Cannon (bcannon)
Date: 2004-09-07 04:32

Message:
Logged In: YES 
user_id=357491

OK, test__locale has been checked in.

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

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-30 13:00

Message:
Logged In: YES 
user_id=469548

Brett: that's just one of the drawbacks of doing data-driven
testing with unittest. I don't think it's terribly
important, so the test is OK to me.

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

Comment By: Brett Cannon (bcannon)
Date: 2004-08-27 05:44

Message:
Logged In: YES 
user_id=357491

Just attached a new version of test__locale.  Since it is so small of a file 
and the change so drastic I just uploaded the whole file.

Only drawback is before the test kept testing all locales when there was 
a failure while my implementation stops at the first failure discovered.  
Don't know if it is important to test all locales.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-08-24 18:59

Message:
Logged In: YES 
user_id=80475

Walter, I'm afraid I don't have time for these right now.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2004-08-20 18:39

Message:
Logged In: YES 
user_id=89016

Raymond, can you take a look at the patches?

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

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-20 17:06

Message:
Logged In: YES 
user_id=469548

Another one: ported test_inspect to unittest and moved out
the inspect fodder out into two modules instead of using the
ugly imp.load_source and TESTFN. I also did a bit of
rearrangement so that the TestCase classes mostly match the
sections in the library docs.

I used a separate module (inspect_fodder2)  and class for
the decorators tests. Those are kind of small now, but I'll
check in http://python.org/sf/1011890 after this port and
let it grow without having to update test_getfunctions().

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

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-19 17:14

Message:
Logged In: YES 
user_id=469548

Hum yes, that was me trying out how doctest fails. The
expected outcome should have been True. Can you try the
corrected version?

Test_zipfile has been checked in as rev 1.11.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2004-08-18 21:29

Message:
Logged In: YES 
user_id=89016

doctest tests should be OK. The error tests in test_unpack 
can be done with PyUnit too, you either use

self.assertRaises(ValueError, eval, "a,b = Seq()")

or

try:
   a,b = Seq()
except ValueError:
   pass
else:
   self.fail("failed")

test_zipfile_unittest.py looks OK, but should of course be 
named test_zipfile.py when you check it in.

test_unpack_doctest.py gives me:
**********************************************
************************
Failure in example: a == 4 and b == 5 and c == 6
from line #14 of test.test_unpack_doctest.doctests 
in /home/walter/Achtung/Python-
test/dist/src/Lib/test/test_unpack_doctest.pyc
Expected: False
Got: True
**********************************************
************************
1 items had failures:
   1 of  28 in test.test_unpack_doctest.doctests
***Test Failed*** 1 failures.
Traceback (most recent call last):
  File "Lib/test/test_unpack_doctest.py", line 133, in ?
    test_main(verbose=True)
  File "Lib/test/test_unpack_doctest.py", line 130, in test_main
    test_support.run_doctest(test_unpack_doctest, verbose)
  File "/home/walter/Achtung/Python-
test/dist/src/Lib/test/test_support.py", line 318, in 
run_doctest
    raise TestFailed("%d of %d doctests failed" % (f, t))
test.test_support.TestFailed: 1 of 28 doctests failed

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

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-18 15:23

Message:
Logged In: YES 
user_id=469548

Is there any problem with porting test scripts to doctest
instead of unittest? doctest is just perfect for test_unpack
(doctest version attached).

I've also ported test_zipfile to unittest (attached as well).

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

Comment By: Walter D?rwald (doerwalter)
Date: 2004-05-31 18:31

Message:
Logged In: YES 
user_id=89016

OK, checked in as:
Lib/test/mapping_tests.py 1.1
Lib/test/test_os.py 1.22
Lib/test/test_shelve.py 1.7
Lib/test/test_types.py 1.60
Lib/test/test_userdict.py 1.19
Lib/test/test_weakref.py 1.39

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-05-29 01:02

Message:
Logged In: YES 
user_id=80475

Looks good.


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

Comment By: Walter D?rwald (doerwalter)
Date: 2004-05-28 22:59

Message:
Logged In: YES 
user_id=89016

OK, I've updated the docstring for dict.update() 
(Object/dictobject.c 2.160)

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

Comment By: Walter D?rwald (doerwalter)
Date: 2004-05-27 21:04

Message:
Logged In: YES 
user_id=89016

dict_diff.txt is a patch that tries to share tests between 
test_dict, test_userdict, test_os, test_shelve and 
test_weakref.

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

Comment By: Tim Peters (tim_one)
Date: 2004-05-25 22:29

Message:
Logged In: YES 
user_id=31435

Don't really care myself.  Would be nice if the docstring for 
dict.update() matched the new realities, though <wink>.

BTW, there is a reliable and conventional way to detect 
whether the 'dict' argument was passed to UserDict.update:  
use a unique marker object instead of the universally visible 
None.  Like

_marker = object()

at module level, and

    ...(self, dict=_marker, ...)

in the method defn.  That can't be fooled without deliberate 
intent to deceive.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-05-25 22:21

Message:
Logged In: YES 
user_id=80475

IMO, it is fine as is.  I would be suprised if some code
were relying on UserDict.update(None) raising an exception.
 This sort of thing also comes up also in places like the
string and random modules whereever a function or method
with an optional argument gets wrapped by another function.
 The only way around this is to use *args and then you break
code that used the unfortunately named "dict" argument as a
keyword.



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

Comment By: Walter D?rwald (doerwalter)
Date: 2004-05-25 21:32

Message:
Logged In: YES 
user_id=89016

Merging test_dict and test_userdict revealed a difference
between dict and UserDict.UserDict:

>>> import UserDict
>>> d = UserDict.UserDict()
>>> d.update(None)
>>> d
{}
>>> d = {}
>>> d.update(None)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: iteration over non-sequence

Should we do anything about this?

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-05-20 18:03

Message:
Logged In: YES 
user_id=80475

test_dict is fine.

Consider beefing up the tests for update().  As of Py2.4, it
now takes all the same argument possibilites as dict():
   
     d.update(a=1, b=2)
     d.update([('a', 1), ('b', 2)])

Also, try to link in:
       from test_userdict import TestMappingProtocol

This was supposed to provide tests common to all mappings.
   

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

Comment By: Walter D?rwald (doerwalter)
Date: 2004-04-03 13:06

Message:
Logged In: YES 
user_id=89016

The attached test_dict.py moves the dict tests from 
test_types.py to a new PyUnit test script. Code coverage for 
dictobject.c is at 90.76% (up from 89.51%)

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

Comment By: Walter D?rwald (doerwalter)
Date: 2004-03-15 13:17

Message:
Logged In: YES 
user_id=89016

Checked in as:
Lib/test/output/test_binascii delete
Lib/test/test_binascii.py 1.17

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-13 21:26

Message:
Logged In: YES 
user_id=80475

Okay, this one is fine.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-12-19 00:49

Message:
Logged In: YES 
user_id=89016

Here's the next one: test_binascii.py. Code coverage in
binascii.c is at 92% (could be improved by enhancing
test_binhex.py).

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-12-13 23:46

Message:
Logged In: YES 
user_id=33168

Looked good to me, test_future_pyunit.diff checked in as:
 * Lib/test/badsyntax_future3.py 1.2
 * Lib/test/badsyntax_future4.py 1.2
 * Lib/test/badsyntax_future5.py 1.2
 * Lib/test/badsyntax_future6.py 1.2
 * Lib/test/badsyntax_future7.py 1.2
 * Lib/test/badsyntax_future8.py 1.1
 * Lib/test/badsyntax_future9.py 1.1
 * Lib/test/test_future.py 1.7
 * Lib/test/test_future1.py 1.3
 * Lib/test/test_future2.py 1.2
 * Lib/test/output/test_future 1.4

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-12-13 22:47

Message:
Logged In: YES 
user_id=33168

Walter, I didn't get a mail from SF either.  After you do a
cvs add, you need to use -N to cvs diff.  For example, cvs
diff -N new_file_added_to_cvs_but_not_committed.  If you
look carefully, you can see this in the patch on the diff
line for each file.  I'll take a look at the patch.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-12-13 21:18

Message:
Logged In: YES 
user_id=89016

Here is a version of test_future ported to PyUnit
(test_future_pyunit.diff). If this makes sense to you Neal,
please check it in.

(BTW, how did you convince CVS to include
badsyntax_future8.py and badsyntax_future9.py in the diff?
Doing a &quot;cvs add&quot; only results in &quot;
Lib/test/badsyntax_future8.py is a new entry, no comparison
available&quot;)

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-12-11 13:36

Message:
Logged In: YES 
user_id=89016

md5/weakref patch checked in as:
Lib/test/test_weakref.py 1.33
Lib/test/test_md5.py 1.5
Lib/test/output/test_md5 remove


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-12-11 07:05

Message:
Logged In: YES 
user_id=33168

Improve coverage for test_future too.  I'm not sure if test
future can be ported to PyUnit.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-12-11 06:52

Message:
Logged In: YES 
user_id=33168

Attached are two tests (in one file, I'm being lazy, sorry)
to improve test coverage for md5c.c and _weakref.c. 
test_md5 was ported to unittest, weakref, just adds two
little tests to get coverage up to 100%.  If you like, just
go ahead and check in.  You will need to remove
Lib/test/output/test_md5

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-12-08 12:42

Message:
Logged In: YES 
user_id=89016

Checked in as:
Lib/test/list_tests.py 1.1
Lib/test/seq_tests.py 1.1
Lib/test/test_list.py 1.1
Lib/test/test_tuple.py 1.1
Lib/test/test_types.py 1.56
Lib/test/test_userlist.py 1.11
Lib/test/output/test_types 1.3

Next will be test_binascii.py before I continue with
test_types.py.


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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-12-08 00:49

Message:
Logged In: YES 
user_id=80475

Looks good.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-11-27 20:48

Message:
Logged In: YES 
user_id=89016

Here the first part of the test_types port: list and tuple
tests have been moved to their own scripts: test_tuple.py
and test_list.py. Common tests for tuple, list and UserList
are shared (in seq_test.py and list_test.py)

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-02 03:53

Message:
Logged In: YES 
user_id=80475

Applied as:
   Lib/test/test_slice.py 1.5.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-01 01:52

Message:
Logged In: YES 
user_id=80475

Looks good.
I added a couple of minor tests.
Revised patch attached.
Okay to apply.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-08-31 21:49

Message:
Logged In: YES 
user_id=89016

Thanks! Here's another one: test_slice.py

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-08-31 01:04

Message:
Logged In: YES 
user_id=80475

Done.

See:
Lib/test/test_longexp.py 1.9; previous revision: 1.8
Lib/test/test_pep263.py 1.3; previous revision: 1.2
Lib/test/test_sets.py 1.27; previous revision: 1.26
Lib/test/test_structseq.py 1.5; previous revision: 1.4
Lib/test/output/test_longexp delete; previous revision: 1.3

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-08-30 19:10

Message:
Logged In: YES 
user_id=80475

Will do!

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-08-30 19:06

Message:
Logged In: YES 
user_id=89016

Here's test_structse.py converted with a few additional
tests. If all three scripts are OK, could you check them in
Raymond, as I'll be on vacation for three weeks?

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-08-09 17:47

Message:
Logged In: YES 
user_id=89016

Here are two simple ones: test_pep263 and test_longexp. I
can't think of any additional tests to add.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-23 15:38

Message:
Logged In: YES 
user_id=80475

Fixed Walter's review comments and
committed as Lib/test/test_compile.py 1.19

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-06-23 13:49

Message:
Logged In: YES 
user_id=89016

Are you sure, that the code path is the same in the new
test_argument_handling() as in the old test? I.e. is
&quot;eval('lambda a,a: 0')&quot; the same as &quot;exec 'def f(a, a): pass'&quot;?

The print statement in test_float_literals should be changed
to a comment.

Should the imports in test_unary_minus() be moved to the
start of the script?

Otherwise the test looks (and runs) OK.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-20 21:26

Message:
Logged In: YES 
user_id=80475

Here's one for you:

test_compile.py is ready.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-06-19 11:46

Message:
Logged In: YES 
user_id=89016

Maybe test_types.py should be split into several scripts:
test_dict, test_tuple, test_list, test_int, test_long etc.
Some of them already exist (like test_long), some don't. The
constructor tests from test_builtin should probably be moved
to the new test scripts as well. Furthermore we should try
to share as much testing functionality as possible (e.g.
between test_int and test_long, or between test_list and
test_userlist)

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-18 21:48

Message:
Logged In: YES 
user_id=80475

Great!
Can I suggest that test_types.py be next.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-06-18 16:27

Message:
Logged In: YES 
user_id=89016

Checked in as:
Lib/test/test_builtin.py 1.21
Lib/test/test_complex.py 1.10

(I've moved the constructor tests from test_builtin to
test_complex)

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-18 01:49

Message:
Logged In: YES 
user_id=80475

I added a few tests.  If they are fine with you, go ahead and 
commit.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-06-17 23:36

Message:
Logged In: YES 
user_id=89016

Here's the next one: text_complex.py.

There one test that's currently commented out, because it
crashes Python on Alpha (see http://www.python.org/sf/756093.

The old test scripts states that tests for the constructor
are in test_builtin, but I've added many tests to this
script, so this is no longer true. We could move the tests
to test_builtin, but IMHO that doesn't make sense, we'd
better move the rest of the constructor tests from
test_builtin to test_complex.

I'd like to have a version of assertAlmostEqual() in
unittest.py that can cope with complex numbers, but this
would have to be coordinated with the standalone version of
PyUnit (and it would probably have to wait until the 2.4
cycle starts) (I noticed that there is no assertAlmostEqual
in the code on pyunit.sf.net anyway.)

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-06-17 14:06

Message:
Logged In: YES 
user_id=89016

I'd like to keep this patch open, as it is an ongoing task
(the next test scripts to be converted will be test_complex
and then maybe test_marshal)

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

Comment By: Brett Cannon (bcannon)
Date: 2003-06-16 23:55

Message:
Logged In: YES 
user_id=357491

OK, all tests pass cleanly.  Applied as revision 1.6.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-06-16 21:51

Message:
Logged In: YES 
user_id=89016

The joys of unittesting: Breaking code to make it better! ;)

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-16 21:41

Message:
Logged In: YES 
user_id=80475

Okay, it runs fine here.  Once Brett confirms that it runs on 
the Mac, go ahead and load it.

P.S. Your improved test_mimetools.py helped detect a latent 
error in mimetools.py when it was run under Windows.  Tim 
made the fix this weekend.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-06-16 21:33

Message:
Logged In: YES 
user_id=89016

Strange, I didn't get this failure here, but I got it on my
laptop at home. I've removed the comparison with the
getatime() value from test_time(). I hope this fixes it.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-16 21:09

Message:
Logged In: YES 
user_id=80475


Walter, there is one failure left:
======================================
================================
FAIL: test_time (__main__.PosixPathTest)
-------------------------------------------------------------------
---
Traceback (most recent call last):
  File &quot;test_posixpath.py&quot;, line 125, in test_time
    self.assert_(
  File &quot;C:\PY23\lib\unittest.py&quot;, line 268, in failUnless
    if not expr: raise self.failureException, msg
AssertionError




Brett, after Walter revises the patch, just load the patch and 
make sure the test runs on the Mac.  Between the three of 
us, we can validate the suite on three different platforms.  
Cheers.



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

Comment By: Brett Cannon (bcannon)
Date: 2003-06-16 20:20

Message:
Logged In: YES 
user_id=357491

Just wanting to work me like a dog, huh, Raymond?  =)

And to clarify for my and Walter's benefit, when you say guards, 
you mean that the tests don't crap out and say they failed on 
Windows, right?  I thought posixpath was not meant to work 
under Windows.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-06-16 20:09

Message:
Logged In: YES 
user_id=89016

I didn't realize that test_posixpath must work on Windows
too. Here's a new version.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-16 18:04

Message:
Logged In: YES 
user_id=80475

The previous comment applied to another patch.
It should have said:

Assigning to Brett to make sure the patch runs on the Mac.  
Don't accept this one until it has guards that allow the tests 
to run on Windows.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-16 17:59

Message:
Logged In: YES 
user_id=80475

Assigning to Brett to give experience doing a detail review on 
this type of change.

* examine every line of the diff and consider whether there is 
any semantic change (exceptions raised, etc).

* apply the diff and run the test suite

* in the interactive mode, call-up each function and make 
sure it behaves as expected (this is necessary because the 
test coverage is very low).

* verify that the whitespace has been cleaned up.

* look for missing changes (such as use of +=)

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-16 17:44

Message:
Logged In: YES 
user_id=80475

The test file now has dependencies that do not apply to 
windows.  The failure messages are attached.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-06-16 14:48

Message:
Logged In: YES 
user_id=89016

Here's the next one: test_posixpath.py with many additional
tests.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-05-22 19:33

Message:
Logged In: YES 
user_id=89016

Checked in as:
Lib/test/output/test_mimetools delete
Lib/test/test_mimetools.py 1.4

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-05-22 18:18

Message:
Logged In: YES 
user_id=80475

test_mimetools.py is ready.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-05-22 17:05

Message:
Logged In: YES 
user_id=89016

I've attached a third version of test_mimetools.py that does
some checks for the mimetools.Message class.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-05-21 15:04

Message:
Logged In: YES 
user_id=80475

Attaching a slightly modified test_mimetools which covers 
more encodings and has a stronger set test.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-05-19 01:46

Message:
Logged In: YES 
user_id=89016

Agreed, this is too much magic for too little gain.

Back to business: Here is test_mimetools ported to PyUnit.
Tests for mimetools.Message are still missing. If you can
think of any tests please add them.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-05-18 05:18

Message:
Logged In: YES 
user_id=80475

Get the module with sys.modules:
  tests = test_support.findtestclasses(sys.modules
[__name__])
  test_support.unittest(*tests)

Yeah, the inheritance thing is a problem.  I was trying to 
avoid having to modify unittest.TestCase to have a 
metaclass.  The control of the module is kept in a 
separate SF project and one of its goals is to be backward 
compatible through 1.5.2 (meaning no metaclasses).

A possible workaround is to define a modified testcase in 
test_support so that people don't import unittest directly 
anymore:

test_support.py
-------------------------
import unittest
class SmartTestCase(unittest.TestCase):
    __metaclass__ = autotracktests
    pass

test_sets.py
------------------
class TestBasicOps(test_support.SmartTestCase):
    run = False
. . .
class TestBasicOpsEmpty(TestBasicOps):
    def setUp(self):
    . . .

Still, this is starting to seem a bit magical and tricky.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-05-18 04:52

Message:
Logged In: YES 
user_id=89016

But how do I pass the module object from inside the module?
And skipping abstract classes seems to be more work in this
version: If skipping is done via a class attribute, derived
classes have to explicitely reset this flag because of
interitance.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-05-18 03:59

Message:
Logged In: YES 
user_id=80475

Good call.

Instead of using metaclasses, perhaps add a module 
introspector function to test_support:

def findtestclasses(mod):
    tests = []
    for elem in dir(mod):
        member = getattr(mod, elem)
        if type(member) != type: continue
        if issubclass(member, unittest.TestCase):
            tests.append(member)
    return tests

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-05-18 03:45

Message:
Logged In: YES 
user_id=89016

But this can be solved with a special non-inheritable class
attribute:

class BaseTest(unittest.TestCase):
    run = False

Then the metaclass can do the following:
def __new__(cls, name, bases, dict):
    if &quot;run&quot; not in dict:
       dict[&quot;run&quot;]  = True
    cls = type.__new__(cls, name, bases, dict)
    if cls.run:
        tests.append(cls)
    return cls


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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-05-18 03:04

Message:
Logged In: YES 
user_id=80475

I don't think metaclasses or module introspection would 
help whenever there are classes that derive from TestCase 
but are not meant to be run directly (their subclasses have 
the setup/teardown/or class data).  test_sets.py has 
examples of that kind of thing.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-05-18 02:50

Message:
Logged In: YES 
user_id=89016

Checked in as:
Lib/test/test_array.py 1.20
Lib/test/test_winsound.py 1.5
Lib/test/output/test_winsound delete

&gt; The approach of using tests.append() is elegant and
&gt; makes it easier to verify that no tests are being omitted.

The most elegant approach would probably be a metaclass that
collects all TestCase subclasses that get defined. Classes
that only serve as a base class could be skipped by
specifying a certain class attribute.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-05-18 01:35

Message:
Logged In: YES 
user_id=80475

The approach of using tests.append() is elegant and 
makes it easier to verify that no tests are being omitted.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470
From noreply at sourceforge.net  Tue Dec  7 12:23:35 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Dec  7 12:23:41 2004
Subject: [Patches] [ python-Patches-754022 ] Enhanced webbrowser.py
Message-ID: <E1CbdRP-0003OK-Bp@sc8-sf-web4.sourceforge.net>

Patches item #754022, was opened at 2003-06-13 19:24
Message generated for change (Comment added) made by phd
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=754022&group_id=5470

Category: Library (Lib)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Oleg Broytmann (phd)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Enhanced webbrowser.py

Initial Comment:
The patch enhances webbrowser.py.

First, all calls to os.system return result code, and
the inverse of the code (it is ok/fail status) passed
through all higher-level routines up to top-level call
to open(url). This allows to check if a browser was
really started.

Second, the very open() modified so it is now trying to
run all registered browsers in order until a browser
returns 1.

Third, the file can be used as a program: webbrowser.py
url. Optional parameters -n allows to open the url in a
new window.


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

>Comment By: Oleg Broytmann (phd)
Date: 2004-12-07 14:23

Message:
Logged In: YES 
user_id=4799

Applied the patch from http://python.org/sf/1077979.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-10-20 10:11

Message:
Logged In: YES 
user_id=80475

Too late for Py2.4.

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

Comment By: Oleg Broytmann (phd)
Date: 2004-10-07 11:48

Message:
Logged In: YES 
user_id=4799

And don't forget to make it executable.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=754022&group_id=5470
From noreply at sourceforge.net  Tue Dec  7 12:26:49 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Dec  7 12:26:53 2004
Subject: [Patches] [ python-Patches-1077979 ] Simple webbrowser fix for
	netscape -remote
Message-ID: <E1CbdUX-0002gZ-OC@sc8-sf-web3.sourceforge.net>

Patches item #1077979, was opened at 2004-12-03 01:41
Message generated for change (Comment added) made by phd
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1077979&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Josh Cherry (jlcherry)
Assigned to: Nobody/Anonymous (nobody)
Summary: Simple webbrowser fix for netscape -remote

Initial Comment:
This patch simply removes a space in a netscape -remote
command that is executed by webbrowser.  This space
caused problems with certain urls, at least with
netscape 7.2.  For example,

webbrowser.open_new('http://www.python.org')

would file, though

webbrowser.open_new('http://www.python.org/')

would work.


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

Comment By: Oleg Broytmann (phd)
Date: 2004-12-07 14:26

Message:
Logged In: YES 
user_id=4799

Yes, I can confirm the problem with Mozilla. I updated my
big patch for webbrowser.py at http://python.org/sf/754022.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1077979&group_id=5470
From noreply at sourceforge.net  Tue Dec  7 14:39:51 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Dec  7 14:39:55 2004
Subject: [Patches] [ python-Patches-1080078 ] list sort is not "in place"
Message-ID: <E1CbfZH-00014c-Rt@sc8-sf-web4.sourceforge.net>

Patches item #1080078, was opened at 2004-12-06 19:15
Message generated for change (Comment added) made by shd
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1080078&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Closed
Resolution: Rejected
Priority: 5
Submitted By: Heikki Orsila (shd)
Assigned to: Nobody/Anonymous (nobody)
Summary: list sort is not "in place"

Initial Comment:
list sort method says the sort algorithm is "in place",
but it is not. It requires O(N) extra memory at worst
case. A patch is attached that corrects the
documentation in Objects/listobjects.c.




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

>Comment By: Heikki Orsila (shd)
Date: 2004-12-07 15:39

Message:
Logged In: YES 
user_id=6941

My bad. Sorry for misunderstanding the meaning of in-place.


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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-06 19:49

Message:
Logged In: YES 
user_id=80475

Sorry, the patch is not right.  In-place is meant to
communicate thet the original list is mutated.  Contrast
that with the behavior of sorted() which leaves the original
intact.

Perhaps you are thinking in terms of heapsort which is
in-place and requires no additional auxiliary storage. 
While that is not true for the current algorithm, we do not
document or make promises about the memory requirements --
that is considered to be an implementation detail that is
subject to change.

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

Comment By: Tim Peters (tim_one)
Date: 2004-12-06 19:48

Message:
Logged In: YES 
user_id=31435

Sorry, I'm rejecting this.  Of course it's "in place":  x.sort() 
does not return a new list.  Its only visible effect is to 
permute the elements of x.  That's what "in place" means.

That the current implementation may require temp memory is 
irrelevant to that, and *because* it's an internal 
implementation detail, doesn't belong in the docstring.  
The "in place" was added to the docstring because many 
newcomers believed x.sort() left x alone, and returned a new 
list in sorted order (which is what the new-in-2.4 sorted() 
builtin does).

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1080078&group_id=5470
From noreply at sourceforge.net  Tue Dec  7 16:26:45 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Dec  7 16:26:48 2004
Subject: [Patches] [ python-Patches-1080684 ] repair typo
Message-ID: <E1CbhEj-0004ta-OP@sc8-sf-web3.sourceforge.net>

Patches item #1080684, was opened at 2004-12-08 00:26
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1080684&group_id=5470

Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: George Yoshida (quiver)
Assigned to: Nobody/Anonymous (nobody)
Summary: repair typo

Initial Comment:
The attached patch fixes these typos:

- Doc/lib/libbase64.tex
  s/algorith/algorithm

- Doc/lib/libpickle.tex
  s/interchangable/interchangeable

- Doc/lib/libxmlrpclib.tex
  s/{_cmp__}/{__cmp__}

  leading underscore needs to be double, not single.

- Doc/ref/ref6.tex
  0/1 => False/True

  __debug__ variable is a boolean value since 
Python 2.3.
  I formatted the text width to 72, so the diff part 
might look a bit
  large. But basically, the change is only values of 
__debug__.

Thanks in advance.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1080684&group_id=5470
From office at omtel.de  Wed Dec  8 19:17:15 2004
From: office at omtel.de (office@omtel.de)
Date: Wed Dec  8 23:04:42 2004
Subject: [Patches] E nderuara Kompani!
Message-ID: <E1Cc6NH-0007Kx-00@server8324611291.serverpool.info>

A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 1571 bytes
Desc: not available
Url : http://mail.python.org/pipermail/patches/attachments/20041208/624e808a/attachment.ksh
From office at omtel.de  Wed Dec  8 19:17:19 2004
From: office at omtel.de (office@omtel.de)
Date: Thu Dec  9 01:32:01 2004
Subject: [Patches] E nderuara Kompani!
Message-ID: <E1Cc6NL-0007NH-00@server8324611291.serverpool.info>

A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 1571 bytes
Desc: not available
Url : http://mail.python.org/pipermail/patches/attachments/20041208/552928dd/attachment.ksh
From office at omtel.de  Wed Dec  8 19:17:13 2004
From: office at omtel.de (office@omtel.de)
Date: Thu Dec  9 02:53:03 2004
Subject: [Patches] E nderuara Kompani!
Message-ID: <E1Cc6NF-0007K2-00@server8324611291.serverpool.info>

A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 1571 bytes
Desc: not available
Url : http://mail.python.org/pipermail/patches/attachments/20041208/07c66237/attachment.ksh
From noreply at sourceforge.net  Thu Dec  9 23:09:18 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Dec  9 23:09:23 2004
Subject: [Patches] [ python-Patches-1071764 ] a new subprocess.call which
	raises an error on non-zero rc
Message-ID: <E1CcWTO-0002UE-HY@sc8-sf-web2.sourceforge.net>

Patches item #1071764, was opened at 2004-11-23 15:45
Message generated for change (Settings changed) made by astrand
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1071764&group_id=5470

Category: Library (Lib)
>Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Nick Craig-Wood (ncw)
>Assigned to: Peter ?strand (astrand)
Summary: a new subprocess.call which raises an error on non-zero rc

Initial Comment:
The attached patch introduces a 3rd utility function -
xcall() to the
subprocess module.  This function acts just like call
but raises
errors if the command had a non-zero return code.

This saves writing

if call(...):
    raise OSError(...)

It is most useful for shell script replacement
programming.  Checking
the return codes of commands called is often forgotten
in shell
programming.

When you've moved up to python because shell is too
limiting (usually
about 10 lines of shell in my case ;-) you want to make
sure that all
your commands work so you write robust code.

I consider raising an exception to be much more
pythonic than checking
a return code (ie "Errors should never pass silently"
from Zen of
Python)

Eg

# An easy to miss error

>>> subprocess.call(["mkdir", "a/b"])
mkdir: cannot create directory `a/b': No such file or
directory
1
>>> # user forgot to check non-zero return code

# becomes an impossible to miss exception

>>> subprocess.xcall(["mkdir", "a/b"])
mkdir: cannot create directory `a/b': No such file or
directory
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "subprocess.py", line 462, in xcall
    raise CalledProcessError(rc, "Command %s returned
non zero exit status" % args[0])
subprocess.CalledProcessError: [Errno 1] Command
['mkdir', 'a/b'] returned non zero exit status
>>> 

See attached patch for more!  Its been tested under
python 2.3 on
windows and linux.


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

Comment By: Peter ?strand (astrand)
Date: 2004-12-05 22:20

Message:
Logged In: YES 
user_id=344921

My suggested name is "check_call". 

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

Comment By: Peter ?strand (astrand)
Date: 2004-12-01 15:04

Message:
Logged In: YES 
user_id=344921

Since this is a new feature, the patch will go into trunk,
but not the 2.4 maint branch. 

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1071764&group_id=5470
From noreply at sourceforge.net  Sun Dec 12 02:38:33 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Dec 12 02:38:37 2004
Subject: [Patches] [ python-Patches-1043356 ] Enhancing '-m' to support
	packages (PEP 338)
Message-ID: <E1CdIgz-000754-UQ@sc8-sf-web4.sourceforge.net>

Patches item #1043356, was opened at 2004-10-09 07:44
Message generated for change (Comment added) made by ncoghlan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1043356&group_id=5470

Category: None
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Nick Coghlan (ncoghlan)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Enhancing '-m' to support packages (PEP 338)

Initial Comment:
Thomas Heller posted "python -m pychecker.checker
<script>' as an example where it is worthwhile to allow
execution of a script inside a package. This seems like
a compelling use case to me (making pychecker easy to
run is enough of a PITA that I confess I often don't
run it), and I'm sure there are other examples.

The only semantics that I can see working for packages
are the following:

python -m pychecker.checker

is equivalent to:

python execchecker.py

where execchecker.py is:

import sys, imp
import pychecker
info = imp.find_module("checker", pychecker.__path__)
sys.argv[0] = info[1]
execfile(info[0])

We *have* to do the import of the requested script's
containing package - otherwise, we can't obey Python's
packaging rules with respect to the use of __path__.

I will attach two versions.

The first will, when it fails to find a module for
itself, switch to executing something like "-m
execmodule". 'execmodule.py' would be a new stdlib
module to handle the above behaviour (initially not
providing any useful interfaces when directly
imported). Guido was certainly right when he said this
will be easier to enhance if written in Python - I
think this way (going to Python when it isn't a
top-level module) gives us the best of both worlds.

The second version will be pure C. The reason I'm going
to do that, is I expect the idea of adding a standard
library module for this to be controversial, especially
given the proximity to 2.4beta1. (I hope I'm wrong,
since I think the Python-C hybrid is a more flexible
solution, which can also be leveraged by other
interpreter implementations)

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

>Comment By: Nick Coghlan (ncoghlan)
Date: 2004-12-12 11:38

Message:
Logged In: YES 
user_id=1038590

The PEP now has a number (PEP 338) which I've added to the 
title of the tracker item. 
 
I've also attached an updated patch which matches the 
behaviour described in the PEP. 
 
Finally, I added a small archive with a simple package structure 
to demonstrate the feature. 
 
To try it out: 
  1. Download execmodule.py to your build environment's Lib 
directory 
  2. Apply the patch from the src directory with "patch -p0 -i 
PEP_338.diff" & rebuild 
  3. Extract the archive so it makes a "pep338" package inside 
the Lib directory. 
 
Then, "./python -m pep338.hi" and "./python -m 
pep338.subpkg.hi" should print out short messages along with 
the contents of sys.argv. 

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

Comment By: Nick Coghlan (ncoghlan)
Date: 2004-11-24 23:01

Message:
Logged In: YES 
user_id=1038590

I've put a PEP together for adding this in 2.5 - a draft was
posted to python-dev, but I'm still waiting for the PEP number.

Two points from the PEP draft:
1. The implementation will stay as a Python/C hybrid. It's
more useful that way (e.g. "scripts that run scripts" like
pychecker.checker or profile can easily be given '-m' style
arguments of their own)

2. The C portion of the implementation needs to change so
that argv[0] is never altered. The easiest way to do that is
to leave junk in sys.argv[0] when execmodule.py gets invoked
implicitly. I don't have a functional build machine at the
moment, which is why I haven't updated the patch.

The draft can be found here:
http://mail.python.org/pipermail/python-dev/2004-November/049837.html

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

Comment By: Nick Coghlan (ncoghlan)
Date: 2004-10-10 01:57

Message:
Logged In: YES 
user_id=1038590

execmodule has been posted to the cookbook:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/307772

I've also updated the attached version of execmodule.py to
match what I posted to the cookbook. The main difference is
to increase the similarity of the interface to that for
execfile - the dict arguments are called globals and locals,
and the module is correctly executed in the caller's
namespace if no globals are provided.

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

Comment By: Nick Coghlan (ncoghlan)
Date: 2004-10-10 00:17

Message:
Logged In: YES 
user_id=1038590

I agreee with Raymond - bumping the group to Python 2.5.

I'll put execmodule.py in the cookbook as a useful 2.4
recipe (getting the failure modes right was surprisingly
tricky, and I can see people wanting this capability)

At the moment, making this part of the standard library
would be understandably controversial. It will probably be
better to wait and see what the wider (i.e. non-python-dev)
community thinks of the basic version if '-m' before making
things too complex.

The intriguing possibilities of execmodule are simply that
it makes "execmodule('some_pkg.some_module') and
"execmodule('somemodule') available at the Python level. The
notion of using the Python namespace instead of the
filesystem (via execfile) to execute subscripts is an
interesting one.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-10-09 10:44

Message:
Logged In: YES 
user_id=80475

This should be taken back to python-dev.  Guido had strong 
reservations about even the simple version of the patch.  It 
is rapidly losing its innocence.  

Also, it's a little late in the game. The beta is due out on 
Tuesday (leaving no time for thorough review or opportunity 
for fixups if necessary).

The mention of "intriguing possibilities" will likely not help 
rally support.

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

Comment By: Nick Coghlan (ncoghlan)
Date: 2004-10-09 09:53

Message:
Logged In: YES 
user_id=1038590

run_package_Py.diff attached, and a new version of execmodule.py

If it fails to find the module requested with '-m', it
reinterprets the command line from "python -m <script>" to
"python -m execmodule <script>".

One obscure issue is that a command line like "python
-mpychecker.checker" will overwrite the C-level argv[0] with
the path to execmodule.py, whereas "python -m
pychecker.checker" will leave it alone (the path to
execmodule.py is stored in argv[1] in the second case).

This may interact oddly with anyone using Py_GetArgcArgv to
get the *original* command line arguments.

One possibility is to just leave junk in sys.argv[0] when
running execmodule automatically (execmodule just deletes it
anyway).

I'm out of time for today, so I doubt I'll be able to get to
a C version before the beta release.

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

Comment By: Nick Coghlan (ncoghlan)
Date: 2004-10-09 08:51

Message:
Logged In: YES 
user_id=1038590

execmodule.py attached.

You can experiment using "python -m execmodule <script>",
since I haven't written the C code to automatically hook
into this yet.

"from execmodule import execmodule" also has intriguing
possibilities. . .


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1043356&group_id=5470
From noreply at sourceforge.net  Sun Dec 12 17:20:44 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Dec 12 17:20:53 2004
Subject: [Patches] [ python-Patches-736962 ] Port tests to unittest (Part 2)
Message-ID: <E1CdWSi-00030K-Rq@sc8-sf-web4.sourceforge.net>

Patches item #736962, was opened at 2003-05-13 12:45
Message generated for change (Comment added) made by jlgijsbers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470

Category: Tests
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Walter D?rwald (doerwalter)
>Assigned to: Nobody/Anonymous (nobody)
Summary: Port tests to unittest (Part 2)

Initial Comment:
Here are the next test scripts ported to PyUnit:
test_winsound and test_array. For test_array many
additional tests have been added (code coverage is at 91%)

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

>Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-12-12 17:20

Message:
Logged In: YES 
user_id=469548

Alright, checked in as rev 1.17 of test_inspect.py.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2004-12-07 00:36

Message:
Logged In: YES 
user_id=89016

What I can say is that the test script passes on my box, so
if you're feeling confident just check it in. Now that
Python 2.4 is out the door a problem in the test shouldn't
be critical.

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

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-12-06 22:35

Message:
Logged In: YES 
user_id=469548

Just reviewed my test_inspect conversion again and didn't
find any faults. Does anyone have the time to review it or
should I just check it in? http://python.org/sf/1011890 is
waiting on this conversion, so I'm aching to go. :)

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

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-09-24 23:42

Message:
Logged In: YES 
user_id=469548

Checked in as rev 1.8 of test_unpack.py. Thanks for the review!

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

Comment By: Walter D?rwald (doerwalter)
Date: 2004-09-22 20:36

Message:
Logged In: YES 
user_id=89016

test_unpack_doctest.py looks good. Please check it in (as 
test_unpack.py)

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

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-09-08 17:37

Message:
Logged In: YES 
user_id=469548

Yeah, bug #1023798 reported that and Brett fixed it.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2004-09-07 22:34

Message:
Logged In: YES 
user_id=89016

I'm getting the following error from the new test__locale:
test test__locale failed -- Traceback (most recent call last):
  File "/home/walter/Achtung/Python-codec-
small/dist/src/Lib/test/test__locale.py", line 37, in 
test_lc_numeric
    "%r != %r (%s); "
  File "/home/walter/Achtung/Python-codec-
small/dist/src/Lib/locale.py", line 363, in getlocale
    return _parse_localename(localename)
  File "/home/walter/Achtung/Python-codec-
small/dist/src/Lib/locale.py", line 278, in _parse_localename
    raise ValueError, 'unknown locale: %s' % localename
ValueError: unknown locale: lv_LV

BTW, could someone have a look at Johannes' test_doctest 
and test_inspect patches?

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

Comment By: Brett Cannon (bcannon)
Date: 2004-09-07 04:32

Message:
Logged In: YES 
user_id=357491

OK, test__locale has been checked in.

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

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-30 13:00

Message:
Logged In: YES 
user_id=469548

Brett: that's just one of the drawbacks of doing data-driven
testing with unittest. I don't think it's terribly
important, so the test is OK to me.

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

Comment By: Brett Cannon (bcannon)
Date: 2004-08-27 05:44

Message:
Logged In: YES 
user_id=357491

Just attached a new version of test__locale.  Since it is so small of a file 
and the change so drastic I just uploaded the whole file.

Only drawback is before the test kept testing all locales when there was 
a failure while my implementation stops at the first failure discovered.  
Don't know if it is important to test all locales.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-08-24 18:59

Message:
Logged In: YES 
user_id=80475

Walter, I'm afraid I don't have time for these right now.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2004-08-20 18:39

Message:
Logged In: YES 
user_id=89016

Raymond, can you take a look at the patches?

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

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-20 17:06

Message:
Logged In: YES 
user_id=469548

Another one: ported test_inspect to unittest and moved out
the inspect fodder out into two modules instead of using the
ugly imp.load_source and TESTFN. I also did a bit of
rearrangement so that the TestCase classes mostly match the
sections in the library docs.

I used a separate module (inspect_fodder2)  and class for
the decorators tests. Those are kind of small now, but I'll
check in http://python.org/sf/1011890 after this port and
let it grow without having to update test_getfunctions().

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

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-19 17:14

Message:
Logged In: YES 
user_id=469548

Hum yes, that was me trying out how doctest fails. The
expected outcome should have been True. Can you try the
corrected version?

Test_zipfile has been checked in as rev 1.11.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2004-08-18 21:29

Message:
Logged In: YES 
user_id=89016

doctest tests should be OK. The error tests in test_unpack 
can be done with PyUnit too, you either use

self.assertRaises(ValueError, eval, "a,b = Seq()")

or

try:
   a,b = Seq()
except ValueError:
   pass
else:
   self.fail("failed")

test_zipfile_unittest.py looks OK, but should of course be 
named test_zipfile.py when you check it in.

test_unpack_doctest.py gives me:
**********************************************
************************
Failure in example: a == 4 and b == 5 and c == 6
from line #14 of test.test_unpack_doctest.doctests 
in /home/walter/Achtung/Python-
test/dist/src/Lib/test/test_unpack_doctest.pyc
Expected: False
Got: True
**********************************************
************************
1 items had failures:
   1 of  28 in test.test_unpack_doctest.doctests
***Test Failed*** 1 failures.
Traceback (most recent call last):
  File "Lib/test/test_unpack_doctest.py", line 133, in ?
    test_main(verbose=True)
  File "Lib/test/test_unpack_doctest.py", line 130, in test_main
    test_support.run_doctest(test_unpack_doctest, verbose)
  File "/home/walter/Achtung/Python-
test/dist/src/Lib/test/test_support.py", line 318, in 
run_doctest
    raise TestFailed("%d of %d doctests failed" % (f, t))
test.test_support.TestFailed: 1 of 28 doctests failed

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

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-18 15:23

Message:
Logged In: YES 
user_id=469548

Is there any problem with porting test scripts to doctest
instead of unittest? doctest is just perfect for test_unpack
(doctest version attached).

I've also ported test_zipfile to unittest (attached as well).

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

Comment By: Walter D?rwald (doerwalter)
Date: 2004-05-31 18:31

Message:
Logged In: YES 
user_id=89016

OK, checked in as:
Lib/test/mapping_tests.py 1.1
Lib/test/test_os.py 1.22
Lib/test/test_shelve.py 1.7
Lib/test/test_types.py 1.60
Lib/test/test_userdict.py 1.19
Lib/test/test_weakref.py 1.39

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-05-29 01:02

Message:
Logged In: YES 
user_id=80475

Looks good.


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

Comment By: Walter D?rwald (doerwalter)
Date: 2004-05-28 22:59

Message:
Logged In: YES 
user_id=89016

OK, I've updated the docstring for dict.update() 
(Object/dictobject.c 2.160)

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

Comment By: Walter D?rwald (doerwalter)
Date: 2004-05-27 21:04

Message:
Logged In: YES 
user_id=89016

dict_diff.txt is a patch that tries to share tests between 
test_dict, test_userdict, test_os, test_shelve and 
test_weakref.

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

Comment By: Tim Peters (tim_one)
Date: 2004-05-25 22:29

Message:
Logged In: YES 
user_id=31435

Don't really care myself.  Would be nice if the docstring for 
dict.update() matched the new realities, though <wink>.

BTW, there is a reliable and conventional way to detect 
whether the 'dict' argument was passed to UserDict.update:  
use a unique marker object instead of the universally visible 
None.  Like

_marker = object()

at module level, and

    ...(self, dict=_marker, ...)

in the method defn.  That can't be fooled without deliberate 
intent to deceive.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-05-25 22:21

Message:
Logged In: YES 
user_id=80475

IMO, it is fine as is.  I would be suprised if some code
were relying on UserDict.update(None) raising an exception.
 This sort of thing also comes up also in places like the
string and random modules whereever a function or method
with an optional argument gets wrapped by another function.
 The only way around this is to use *args and then you break
code that used the unfortunately named "dict" argument as a
keyword.



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

Comment By: Walter D?rwald (doerwalter)
Date: 2004-05-25 21:32

Message:
Logged In: YES 
user_id=89016

Merging test_dict and test_userdict revealed a difference
between dict and UserDict.UserDict:

>>> import UserDict
>>> d = UserDict.UserDict()
>>> d.update(None)
>>> d
{}
>>> d = {}
>>> d.update(None)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: iteration over non-sequence

Should we do anything about this?

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-05-20 18:03

Message:
Logged In: YES 
user_id=80475

test_dict is fine.

Consider beefing up the tests for update().  As of Py2.4, it
now takes all the same argument possibilites as dict():
   
     d.update(a=1, b=2)
     d.update([('a', 1), ('b', 2)])

Also, try to link in:
       from test_userdict import TestMappingProtocol

This was supposed to provide tests common to all mappings.
   

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

Comment By: Walter D?rwald (doerwalter)
Date: 2004-04-03 13:06

Message:
Logged In: YES 
user_id=89016

The attached test_dict.py moves the dict tests from 
test_types.py to a new PyUnit test script. Code coverage for 
dictobject.c is at 90.76% (up from 89.51%)

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

Comment By: Walter D?rwald (doerwalter)
Date: 2004-03-15 13:17

Message:
Logged In: YES 
user_id=89016

Checked in as:
Lib/test/output/test_binascii delete
Lib/test/test_binascii.py 1.17

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-13 21:26

Message:
Logged In: YES 
user_id=80475

Okay, this one is fine.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-12-19 00:49

Message:
Logged In: YES 
user_id=89016

Here's the next one: test_binascii.py. Code coverage in
binascii.c is at 92% (could be improved by enhancing
test_binhex.py).

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-12-13 23:46

Message:
Logged In: YES 
user_id=33168

Looked good to me, test_future_pyunit.diff checked in as:
 * Lib/test/badsyntax_future3.py 1.2
 * Lib/test/badsyntax_future4.py 1.2
 * Lib/test/badsyntax_future5.py 1.2
 * Lib/test/badsyntax_future6.py 1.2
 * Lib/test/badsyntax_future7.py 1.2
 * Lib/test/badsyntax_future8.py 1.1
 * Lib/test/badsyntax_future9.py 1.1
 * Lib/test/test_future.py 1.7
 * Lib/test/test_future1.py 1.3
 * Lib/test/test_future2.py 1.2
 * Lib/test/output/test_future 1.4

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-12-13 22:47

Message:
Logged In: YES 
user_id=33168

Walter, I didn't get a mail from SF either.  After you do a
cvs add, you need to use -N to cvs diff.  For example, cvs
diff -N new_file_added_to_cvs_but_not_committed.  If you
look carefully, you can see this in the patch on the diff
line for each file.  I'll take a look at the patch.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-12-13 21:18

Message:
Logged In: YES 
user_id=89016

Here is a version of test_future ported to PyUnit
(test_future_pyunit.diff). If this makes sense to you Neal,
please check it in.

(BTW, how did you convince CVS to include
badsyntax_future8.py and badsyntax_future9.py in the diff?
Doing a &quot;cvs add&quot; only results in &quot;
Lib/test/badsyntax_future8.py is a new entry, no comparison
available&quot;)

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-12-11 13:36

Message:
Logged In: YES 
user_id=89016

md5/weakref patch checked in as:
Lib/test/test_weakref.py 1.33
Lib/test/test_md5.py 1.5
Lib/test/output/test_md5 remove


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-12-11 07:05

Message:
Logged In: YES 
user_id=33168

Improve coverage for test_future too.  I'm not sure if test
future can be ported to PyUnit.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-12-11 06:52

Message:
Logged In: YES 
user_id=33168

Attached are two tests (in one file, I'm being lazy, sorry)
to improve test coverage for md5c.c and _weakref.c. 
test_md5 was ported to unittest, weakref, just adds two
little tests to get coverage up to 100%.  If you like, just
go ahead and check in.  You will need to remove
Lib/test/output/test_md5

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-12-08 12:42

Message:
Logged In: YES 
user_id=89016

Checked in as:
Lib/test/list_tests.py 1.1
Lib/test/seq_tests.py 1.1
Lib/test/test_list.py 1.1
Lib/test/test_tuple.py 1.1
Lib/test/test_types.py 1.56
Lib/test/test_userlist.py 1.11
Lib/test/output/test_types 1.3

Next will be test_binascii.py before I continue with
test_types.py.


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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-12-08 00:49

Message:
Logged In: YES 
user_id=80475

Looks good.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-11-27 20:48

Message:
Logged In: YES 
user_id=89016

Here the first part of the test_types port: list and tuple
tests have been moved to their own scripts: test_tuple.py
and test_list.py. Common tests for tuple, list and UserList
are shared (in seq_test.py and list_test.py)

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-02 03:53

Message:
Logged In: YES 
user_id=80475

Applied as:
   Lib/test/test_slice.py 1.5.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-01 01:52

Message:
Logged In: YES 
user_id=80475

Looks good.
I added a couple of minor tests.
Revised patch attached.
Okay to apply.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-08-31 21:49

Message:
Logged In: YES 
user_id=89016

Thanks! Here's another one: test_slice.py

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-08-31 01:04

Message:
Logged In: YES 
user_id=80475

Done.

See:
Lib/test/test_longexp.py 1.9; previous revision: 1.8
Lib/test/test_pep263.py 1.3; previous revision: 1.2
Lib/test/test_sets.py 1.27; previous revision: 1.26
Lib/test/test_structseq.py 1.5; previous revision: 1.4
Lib/test/output/test_longexp delete; previous revision: 1.3

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-08-30 19:10

Message:
Logged In: YES 
user_id=80475

Will do!

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-08-30 19:06

Message:
Logged In: YES 
user_id=89016

Here's test_structse.py converted with a few additional
tests. If all three scripts are OK, could you check them in
Raymond, as I'll be on vacation for three weeks?

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-08-09 17:47

Message:
Logged In: YES 
user_id=89016

Here are two simple ones: test_pep263 and test_longexp. I
can't think of any additional tests to add.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-23 15:38

Message:
Logged In: YES 
user_id=80475

Fixed Walter's review comments and
committed as Lib/test/test_compile.py 1.19

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-06-23 13:49

Message:
Logged In: YES 
user_id=89016

Are you sure, that the code path is the same in the new
test_argument_handling() as in the old test? I.e. is
&quot;eval('lambda a,a: 0')&quot; the same as &quot;exec 'def f(a, a): pass'&quot;?

The print statement in test_float_literals should be changed
to a comment.

Should the imports in test_unary_minus() be moved to the
start of the script?

Otherwise the test looks (and runs) OK.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-20 21:26

Message:
Logged In: YES 
user_id=80475

Here's one for you:

test_compile.py is ready.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-06-19 11:46

Message:
Logged In: YES 
user_id=89016

Maybe test_types.py should be split into several scripts:
test_dict, test_tuple, test_list, test_int, test_long etc.
Some of them already exist (like test_long), some don't. The
constructor tests from test_builtin should probably be moved
to the new test scripts as well. Furthermore we should try
to share as much testing functionality as possible (e.g.
between test_int and test_long, or between test_list and
test_userlist)

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-18 21:48

Message:
Logged In: YES 
user_id=80475

Great!
Can I suggest that test_types.py be next.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-06-18 16:27

Message:
Logged In: YES 
user_id=89016

Checked in as:
Lib/test/test_builtin.py 1.21
Lib/test/test_complex.py 1.10

(I've moved the constructor tests from test_builtin to
test_complex)

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-18 01:49

Message:
Logged In: YES 
user_id=80475

I added a few tests.  If they are fine with you, go ahead and 
commit.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-06-17 23:36

Message:
Logged In: YES 
user_id=89016

Here's the next one: text_complex.py.

There one test that's currently commented out, because it
crashes Python on Alpha (see http://www.python.org/sf/756093.

The old test scripts states that tests for the constructor
are in test_builtin, but I've added many tests to this
script, so this is no longer true. We could move the tests
to test_builtin, but IMHO that doesn't make sense, we'd
better move the rest of the constructor tests from
test_builtin to test_complex.

I'd like to have a version of assertAlmostEqual() in
unittest.py that can cope with complex numbers, but this
would have to be coordinated with the standalone version of
PyUnit (and it would probably have to wait until the 2.4
cycle starts) (I noticed that there is no assertAlmostEqual
in the code on pyunit.sf.net anyway.)

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-06-17 14:06

Message:
Logged In: YES 
user_id=89016

I'd like to keep this patch open, as it is an ongoing task
(the next test scripts to be converted will be test_complex
and then maybe test_marshal)

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

Comment By: Brett Cannon (bcannon)
Date: 2003-06-16 23:55

Message:
Logged In: YES 
user_id=357491

OK, all tests pass cleanly.  Applied as revision 1.6.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-06-16 21:51

Message:
Logged In: YES 
user_id=89016

The joys of unittesting: Breaking code to make it better! ;)

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-16 21:41

Message:
Logged In: YES 
user_id=80475

Okay, it runs fine here.  Once Brett confirms that it runs on 
the Mac, go ahead and load it.

P.S. Your improved test_mimetools.py helped detect a latent 
error in mimetools.py when it was run under Windows.  Tim 
made the fix this weekend.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-06-16 21:33

Message:
Logged In: YES 
user_id=89016

Strange, I didn't get this failure here, but I got it on my
laptop at home. I've removed the comparison with the
getatime() value from test_time(). I hope this fixes it.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-16 21:09

Message:
Logged In: YES 
user_id=80475


Walter, there is one failure left:
======================================
================================
FAIL: test_time (__main__.PosixPathTest)
-------------------------------------------------------------------
---
Traceback (most recent call last):
  File &quot;test_posixpath.py&quot;, line 125, in test_time
    self.assert_(
  File &quot;C:\PY23\lib\unittest.py&quot;, line 268, in failUnless
    if not expr: raise self.failureException, msg
AssertionError




Brett, after Walter revises the patch, just load the patch and 
make sure the test runs on the Mac.  Between the three of 
us, we can validate the suite on three different platforms.  
Cheers.



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

Comment By: Brett Cannon (bcannon)
Date: 2003-06-16 20:20

Message:
Logged In: YES 
user_id=357491

Just wanting to work me like a dog, huh, Raymond?  =)

And to clarify for my and Walter's benefit, when you say guards, 
you mean that the tests don't crap out and say they failed on 
Windows, right?  I thought posixpath was not meant to work 
under Windows.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-06-16 20:09

Message:
Logged In: YES 
user_id=89016

I didn't realize that test_posixpath must work on Windows
too. Here's a new version.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-16 18:04

Message:
Logged In: YES 
user_id=80475

The previous comment applied to another patch.
It should have said:

Assigning to Brett to make sure the patch runs on the Mac.  
Don't accept this one until it has guards that allow the tests 
to run on Windows.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-16 17:59

Message:
Logged In: YES 
user_id=80475

Assigning to Brett to give experience doing a detail review on 
this type of change.

* examine every line of the diff and consider whether there is 
any semantic change (exceptions raised, etc).

* apply the diff and run the test suite

* in the interactive mode, call-up each function and make 
sure it behaves as expected (this is necessary because the 
test coverage is very low).

* verify that the whitespace has been cleaned up.

* look for missing changes (such as use of +=)

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-16 17:44

Message:
Logged In: YES 
user_id=80475

The test file now has dependencies that do not apply to 
windows.  The failure messages are attached.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-06-16 14:48

Message:
Logged In: YES 
user_id=89016

Here's the next one: test_posixpath.py with many additional
tests.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-05-22 19:33

Message:
Logged In: YES 
user_id=89016

Checked in as:
Lib/test/output/test_mimetools delete
Lib/test/test_mimetools.py 1.4

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-05-22 18:18

Message:
Logged In: YES 
user_id=80475

test_mimetools.py is ready.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-05-22 17:05

Message:
Logged In: YES 
user_id=89016

I've attached a third version of test_mimetools.py that does
some checks for the mimetools.Message class.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-05-21 15:04

Message:
Logged In: YES 
user_id=80475

Attaching a slightly modified test_mimetools which covers 
more encodings and has a stronger set test.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-05-19 01:46

Message:
Logged In: YES 
user_id=89016

Agreed, this is too much magic for too little gain.

Back to business: Here is test_mimetools ported to PyUnit.
Tests for mimetools.Message are still missing. If you can
think of any tests please add them.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-05-18 05:18

Message:
Logged In: YES 
user_id=80475

Get the module with sys.modules:
  tests = test_support.findtestclasses(sys.modules
[__name__])
  test_support.unittest(*tests)

Yeah, the inheritance thing is a problem.  I was trying to 
avoid having to modify unittest.TestCase to have a 
metaclass.  The control of the module is kept in a 
separate SF project and one of its goals is to be backward 
compatible through 1.5.2 (meaning no metaclasses).

A possible workaround is to define a modified testcase in 
test_support so that people don't import unittest directly 
anymore:

test_support.py
-------------------------
import unittest
class SmartTestCase(unittest.TestCase):
    __metaclass__ = autotracktests
    pass

test_sets.py
------------------
class TestBasicOps(test_support.SmartTestCase):
    run = False
. . .
class TestBasicOpsEmpty(TestBasicOps):
    def setUp(self):
    . . .

Still, this is starting to seem a bit magical and tricky.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-05-18 04:52

Message:
Logged In: YES 
user_id=89016

But how do I pass the module object from inside the module?
And skipping abstract classes seems to be more work in this
version: If skipping is done via a class attribute, derived
classes have to explicitely reset this flag because of
interitance.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-05-18 03:59

Message:
Logged In: YES 
user_id=80475

Good call.

Instead of using metaclasses, perhaps add a module 
introspector function to test_support:

def findtestclasses(mod):
    tests = []
    for elem in dir(mod):
        member = getattr(mod, elem)
        if type(member) != type: continue
        if issubclass(member, unittest.TestCase):
            tests.append(member)
    return tests

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-05-18 03:45

Message:
Logged In: YES 
user_id=89016

But this can be solved with a special non-inheritable class
attribute:

class BaseTest(unittest.TestCase):
    run = False

Then the metaclass can do the following:
def __new__(cls, name, bases, dict):
    if &quot;run&quot; not in dict:
       dict[&quot;run&quot;]  = True
    cls = type.__new__(cls, name, bases, dict)
    if cls.run:
        tests.append(cls)
    return cls


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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-05-18 03:04

Message:
Logged In: YES 
user_id=80475

I don't think metaclasses or module introspection would 
help whenever there are classes that derive from TestCase 
but are not meant to be run directly (their subclasses have 
the setup/teardown/or class data).  test_sets.py has 
examples of that kind of thing.

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

Comment By: Walter D?rwald (doerwalter)
Date: 2003-05-18 02:50

Message:
Logged In: YES 
user_id=89016

Checked in as:
Lib/test/test_array.py 1.20
Lib/test/test_winsound.py 1.5
Lib/test/output/test_winsound delete

&gt; The approach of using tests.append() is elegant and
&gt; makes it easier to verify that no tests are being omitted.

The most elegant approach would probably be a metaclass that
collects all TestCase subclasses that get defined. Classes
that only serve as a base class could be skipped by
specifying a certain class attribute.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-05-18 01:35

Message:
Logged In: YES 
user_id=80475

The approach of using tests.append() is elegant and 
makes it easier to verify that no tests are being omitted.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470
From noreply at sourceforge.net  Sun Dec 12 17:47:19 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Dec 12 17:47:27 2004
Subject: [Patches] [ python-Patches-1011890 ] fix inspect.getsource breaking
	with line-continuation & more
Message-ID: <E1CdWsR-0003pj-Bw@sc8-sf-web1.sourceforge.net>

Patches item #1011890, was opened at 2004-08-19 03:11
Message generated for change (Comment added) made by jlgijsbers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1011890&group_id=5470

Category: Library (Lib)
Group: Python 2.4
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Simon Percivall (percivall)
Assigned to: Johannes Gijsbers (jlgijsbers)
Summary: fix inspect.getsource breaking with line-continuation & more

Initial Comment:
The patch makes changes to inspect.py in two places:

* the pattern to match against functions at line 436 is
modified: lambdas should be matched even if not
preceded by whitespace, as long as "lambda" isn't part
of another word.

* the BlockFinder class is heavily modified. Changes are: 
  - checking for "def", "class" or "lambda" names
before setting self.started to True. Then checking the
same line for word characters after the colon (if the
colon is on that line). If so, and the line does not
end with a line continuation marker, raise EndOfBlock
immediately.
  - adding self.passline to show that the line is to be
included and no more checking is necessary on that
line. Since a NEWLINE token is not generated when a
line continuation marker exists, this allows getsource
to continue with these functions even if the following
line would not be indented.

The patch might be making a mess of the simple code,
and code such as code it now handles will probably not
be seen often. Still, it fixes the first bug shown in
"www.python.org/sf/769569".

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

>Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-12-12 17:47

Message:
Logged In: YES 
user_id=469548

Well, it took a bit longer to get test_inspect ported to
unittest, but it's done now. I've also checked this in.
Thanks for the patch!

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

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-19 19:21

Message:
Logged In: YES 
user_id=469548

Looks very good. I've made some small changes:

- Moved the __main__ section into a test_main() block for
running by regrtest.py
- Used the run_unittest function from test_support.py
- De-abbreviated some of the test methods
- Used comments instead of docstrings: unittest prints the
docstring of a test method instead of the name of the test
method when failing, making the failing method harder to find.

Apart from that, it looks like checkin-quality to me. Still,
it's kind of ugly to have a two separate files and two
separate methods for testing the same module, so I guess
that means I'll be converting test_inspect to unittest. I'll
try to work on that tonight and post it to
http://python.org/sf/736962 tomorrow. I'll merge these tests
into the new test_inspect after it's checked in.

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

Comment By: Simon Percivall (percivall)
Date: 2004-08-19 03:25

Message:
Logged In: YES 
user_id=329382

BTW: inspect.py CVS HEAD passes three of the tests:
test_oll, test_tlli and test_onelinefunc.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1011890&group_id=5470
From noreply at sourceforge.net  Sun Dec 12 17:53:14 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Dec 12 17:53:19 2004
Subject: [Patches] [ python-Patches-1080684 ] repair typo
Message-ID: <E1CdWyA-00043x-PM@sc8-sf-web1.sourceforge.net>

Patches item #1080684, was opened at 2004-12-07 16:26
Message generated for change (Comment added) made by jlgijsbers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1080684&group_id=5470

Category: Documentation
Group: Python 2.5
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: George Yoshida (quiver)
Assigned to: Nobody/Anonymous (nobody)
Summary: repair typo

Initial Comment:
The attached patch fixes these typos:

- Doc/lib/libbase64.tex
  s/algorith/algorithm

- Doc/lib/libpickle.tex
  s/interchangable/interchangeable

- Doc/lib/libxmlrpclib.tex
  s/{_cmp__}/{__cmp__}

  leading underscore needs to be double, not single.

- Doc/ref/ref6.tex
  0/1 => False/True

  __debug__ variable is a boolean value since 
Python 2.3.
  I formatted the text width to 72, so the diff part 
might look a bit
  large. But basically, the change is only values of 
__debug__.

Thanks in advance.

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

>Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-12-12 17:53

Message:
Logged In: YES 
user_id=469548

Checked in on maint24 and trunk. Thanks for the patch!

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1080684&group_id=5470
From noreply at sourceforge.net  Mon Dec 13 01:14:16 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Dec 13 01:14:19 2004
Subject: [Patches] [ python-Patches-1084092 ] Description of message_set and
	command option to store()
Message-ID: <E1Cddqy-0003wO-Th@sc8-sf-web4.sourceforge.net>

Patches item #1084092, was opened at 2004-12-13 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=305470&aid=1084092&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Sean Reifschneider (jafo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Description of message_set and command option to store()

Initial Comment:
This patch includes a description of (as far as I can
tell) what the option message_set can be, and more
information about what the "command" option to store()
needs to be.  It also includes an example of using
store() to delete messages.  I also added a "close()"
before "logout()" in the example, since the
documentation says close is recommended before logout.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1084092&group_id=5470
From noreply at sourceforge.net  Mon Dec 13 03:57:58 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Dec 13 03:58:01 2004
Subject: [Patches] [ python-Patches-1071764 ] a new subprocess.call which
	raises an error on non-zero rc
Message-ID: <E1CdgPO-00080P-EU@sc8-sf-web2.sourceforge.net>

Patches item #1071764, was opened at 2004-11-23 15:45
Message generated for change (Comment added) made by astrand
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1071764&group_id=5470

Category: Library (Lib)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Nick Craig-Wood (ncw)
Assigned to: Peter ?strand (astrand)
Summary: a new subprocess.call which raises an error on non-zero rc

Initial Comment:
The attached patch introduces a 3rd utility function -
xcall() to the
subprocess module.  This function acts just like call
but raises
errors if the command had a non-zero return code.

This saves writing

if call(...):
    raise OSError(...)

It is most useful for shell script replacement
programming.  Checking
the return codes of commands called is often forgotten
in shell
programming.

When you've moved up to python because shell is too
limiting (usually
about 10 lines of shell in my case ;-) you want to make
sure that all
your commands work so you write robust code.

I consider raising an exception to be much more
pythonic than checking
a return code (ie "Errors should never pass silently"
from Zen of
Python)

Eg

# An easy to miss error

>>> subprocess.call(["mkdir", "a/b"])
mkdir: cannot create directory `a/b': No such file or
directory
1
>>> # user forgot to check non-zero return code

# becomes an impossible to miss exception

>>> subprocess.xcall(["mkdir", "a/b"])
mkdir: cannot create directory `a/b': No such file or
directory
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "subprocess.py", line 462, in xcall
    raise CalledProcessError(rc, "Command %s returned
non zero exit status" % args[0])
subprocess.CalledProcessError: [Errno 1] Command
['mkdir', 'a/b'] returned non zero exit status
>>> 

See attached patch for more!  Its been tested under
python 2.3 on
windows and linux.


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

>Comment By: Peter ?strand (astrand)
Date: 2004-12-13 03:57

Message:
Logged In: YES 
user_id=344921

If there are no objections, I will commit the "Adapted patch
against trunk". 

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

Comment By: Peter ?strand (astrand)
Date: 2004-12-05 22:20

Message:
Logged In: YES 
user_id=344921

My suggested name is "check_call". 

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

Comment By: Peter ?strand (astrand)
Date: 2004-12-01 15:04

Message:
Logged In: YES 
user_id=344921

Since this is a new feature, the patch will go into trunk,
but not the 2.4 maint branch. 

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1071764&group_id=5470
From noreply at sourceforge.net  Mon Dec 13 12:37:04 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Dec 13 12:37:11 2004
Subject: [Patches] [ python-Patches-1011890 ] fix inspect.getsource breaking
	with line-continuation & more
Message-ID: <E1CdoVk-0002Mg-RN@sc8-sf-web4.sourceforge.net>

Patches item #1011890, was opened at 2004-08-19 03:11
Message generated for change (Comment added) made by percivall
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1011890&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Simon Percivall (percivall)
Assigned to: Johannes Gijsbers (jlgijsbers)
Summary: fix inspect.getsource breaking with line-continuation & more

Initial Comment:
The patch makes changes to inspect.py in two places:

* the pattern to match against functions at line 436 is
modified: lambdas should be matched even if not
preceded by whitespace, as long as "lambda" isn't part
of another word.

* the BlockFinder class is heavily modified. Changes are: 
  - checking for "def", "class" or "lambda" names
before setting self.started to True. Then checking the
same line for word characters after the colon (if the
colon is on that line). If so, and the line does not
end with a line continuation marker, raise EndOfBlock
immediately.
  - adding self.passline to show that the line is to be
included and no more checking is necessary on that
line. Since a NEWLINE token is not generated when a
line continuation marker exists, this allows getsource
to continue with these functions even if the following
line would not be indented.

The patch might be making a mess of the simple code,
and code such as code it now handles will probably not
be seen often. Still, it fixes the first bug shown in
"www.python.org/sf/769569".

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

>Comment By: Simon Percivall (percivall)
Date: 2004-12-13 12:37

Message:
Logged In: YES 
user_id=329382

Shouldn't this be considered a bug fix though? What I mean is: Shouldn't 
the patch also be checked in to the 2.4 maintain branch? Perhaps the 
ported test_inspect is a problem, but the patch itself ...

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

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-12-12 17:47

Message:
Logged In: YES 
user_id=469548

Well, it took a bit longer to get test_inspect ported to
unittest, but it's done now. I've also checked this in.
Thanks for the patch!

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

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-19 19:21

Message:
Logged In: YES 
user_id=469548

Looks very good. I've made some small changes:

- Moved the __main__ section into a test_main() block for
running by regrtest.py
- Used the run_unittest function from test_support.py
- De-abbreviated some of the test methods
- Used comments instead of docstrings: unittest prints the
docstring of a test method instead of the name of the test
method when failing, making the failing method harder to find.

Apart from that, it looks like checkin-quality to me. Still,
it's kind of ugly to have a two separate files and two
separate methods for testing the same module, so I guess
that means I'll be converting test_inspect to unittest. I'll
try to work on that tonight and post it to
http://python.org/sf/736962 tomorrow. I'll merge these tests
into the new test_inspect after it's checked in.

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

Comment By: Simon Percivall (percivall)
Date: 2004-08-19 03:25

Message:
Logged In: YES 
user_id=329382

BTW: inspect.py CVS HEAD passes three of the tests:
test_oll, test_tlli and test_onelinefunc.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1011890&group_id=5470
From noreply at sourceforge.net  Fri Dec 17 20:52:39 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Dec 17 20:52:48 2004
Subject: [Patches] [ python-Patches-784089 ] A program to scan python files
	and list those require coding
Message-ID: <E1CfO9X-00063o-T3@sc8-sf-web2.sourceforge.net>

Patches item #784089, was opened at 2003-08-06 14:47
Message generated for change (Comment added) made by phd
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=784089&group_id=5470

Category: Demos and tools
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Oleg Broytmann (phd)
Assigned to: Raymond Hettinger (rhettinger)
Summary: A program to scan python files and list those require coding

Initial Comment:
A program to scan python files (recursively) and list
those that require coding directive (pseudocomment)
because there non-ASCII characters in the file
(including comments).

The program treats files as python files if the
extension is .py or there is &quot;python&quot; in the first line
of the file.


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

>Comment By: Oleg Broytmann (phd)
Date: 2004-12-17 22:52

Message:
Logged In: YES 
user_id=4799

Added pysource.py module and an alternative implementation
using the module. The pysource.py module is, probably, of a
general interest and can be added to the standard library.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-10-20 10:04

Message:
Logged In: YES 
user_id=80475

Will make a few cleanups, replace the recursion and fileext
guessing to a glob.glob format, and will add to Tools/scripts.

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

Comment By: Oleg Broytmann (phd)
Date: 2004-10-07 11:49

Message:
Logged In: YES 
user_id=4799

And don't forget to make it executable.

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

Comment By: A.M. Kuchling (akuchling)
Date: 2004-08-08 01:50

Message:
Logged In: YES 
user_id=11375

So, does something need to be done with this script, like adding it to the 
distribution?


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

Comment By: M.-A. Lemburg (lemburg)
Date: 2003-08-06 16:36

Message:
Logged In: YES 
user_id=38388

Thanks.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=784089&group_id=5470
From noreply at sourceforge.net  Sat Dec 18 05:36:05 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Dec 18 05:36:09 2004
Subject: [Patches] [ python-Patches-1084092 ] Description of args to
	IMAP4.store() in imaplib
Message-ID: <E1CfWK5-0006dd-Fg@sc8-sf-web2.sourceforge.net>

Patches item #1084092, was opened at 2004-12-12 16:14
Message generated for change (Settings changed) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1084092&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Sean Reifschneider (jafo)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Description of args to IMAP4.store() in imaplib

Initial Comment:
This patch includes a description of (as far as I can
tell) what the option message_set can be, and more
information about what the "command" option to store()
needs to be.  It also includes an example of using
store() to delete messages.  I also added a "close()"
before "logout()" in the example, since the
documentation says close is recommended before logout.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1084092&group_id=5470
From noreply at sourceforge.net  Sat Dec 18 20:55:48 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Dec 18 20:55:53 2004
Subject: [Patches] [ python-Patches-1084092 ] Description of args to
	IMAP4.store() in imaplib
Message-ID: <E1Cfkg8-0005Zo-AB@sc8-sf-web3.sourceforge.net>

Patches item #1084092, was opened at 2004-12-12 19:14
Message generated for change (Comment added) made by kuran
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1084092&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Sean Reifschneider (jafo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Description of args to IMAP4.store() in imaplib

Initial Comment:
This patch includes a description of (as far as I can
tell) what the option message_set can be, and more
information about what the "command" option to store()
needs to be.  It also includes an example of using
store() to delete messages.  I also added a "close()"
before "logout()" in the example, since the
documentation says close is recommended before logout.

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

Comment By: Jp Calderone (kuran)
Date: 2004-12-18 14:55

Message:
Logged In: YES 
user_id=366566

message_set may also take forms including a wildcard upper
bound ("*") and define multiple non-continuous ranges (comma
delimited).  For example,

    # all messages from 3 up
    3:*

    # 3, 4, 5, 7, 8, 9
    3:5,7:9

This seems worthy of note in the docstring.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1084092&group_id=5470
From noreply at sourceforge.net  Sat Dec 18 21:08:05 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Dec 18 21:08:09 2004
Subject: [Patches] [ python-Patches-1057417 ] New BaseSMTPServer module
Message-ID: <E1Cfks1-0005Tk-NK@sc8-sf-web1.sourceforge.net>

Patches item #1057417, was opened at 2004-10-30 13:55
Message generated for change (Comment added) made by kuran
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1057417&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark D. Roth (mdr0)
Assigned to: Nobody/Anonymous (nobody)
Summary: New BaseSMTPServer module

Initial Comment:
A new module that provides an SMTP server base class,
derived from the SocketServer class.

The class in this module does not implement a fully
functional SMTP server; it simply provides a framework
that subclasses can use to build their own
special-purpose SMTP servers.


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

Comment By: Jp Calderone (kuran)
Date: 2004-12-18 15:08

Message:
Logged In: YES 
user_id=366566

Regarding blocking process_message implementations: there
really is no issue here.  If a blocking operation needs to
be performed, then a thread can be created inside
process_message.  Nothing is gained by starting a thread any
earlier than this.  Arguably, it is even a loss since it is
more  computationally and resource intensive to do so.

Support for blocking message processing therefore does not
seem to be sufficient reason for including this module.  Are
there other advantages?


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

Comment By: Josiah Carlson (josiahcarlson)
Date: 2004-11-10 02:36

Message:
Logged In: YES 
user_id=341410

It still has a couple tabs, but I don't believe that is a
big deal.

I think it fits in with the standard SocketServer framework,
and that it would make sense to add it, but I don't have any
authority to make decisions.

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

Comment By: Mark D. Roth (mdr0)
Date: 2004-11-10 01:40

Message:
Logged In: YES 
user_id=994239

Here's a new version of BaseSMTPServer with the following
changes:

* Added lots of documentation.
* Changed code style to conform with PEP 8.
* Added allow_host() method.
* Added smtp_NOOP() method.
* Improved interface to process_message() and access-control
methods.

Please let me know what you think.  Thanks!

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

Comment By: Josiah Carlson (josiahcarlson)
Date: 2004-11-07 17:20

Message:
Logged In: YES 
user_id=341410

Hrm, nevemind, I just noticed mdr0's post.  I'll leave the
rest up to someone who has the authority to make decisions.

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

Comment By: Josiah Carlson (josiahcarlson)
Date: 2004-11-07 17:11

Message:
Logged In: YES 
user_id=341410

Re: features

Aside from NOOP (which is easily added), the provided
BaseSMTPServer seems to offer the same amount of
functionality as smtpd (ignoring DebuggingServer, PureProxy
and MailmanProxy, which are trivially borrowed from smtpd).


Re: What's the benefit...

Someone who wanted to use a synchronous SMTP server would
have one available.


I think that we should probably wait until the original
author answers how this relates to smtpd.py, and perhaps
decide then.

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

Comment By: Mark D. Roth (mdr0)
Date: 2004-11-07 02:11

Message:
Logged In: YES 
user_id=994239

Yes, I am aware of smtpd.py.  My understanding is (although
please correct me if I'm wrong) that the asyncore/asynchat
framework will not be able to service network clients if the
found_terminator() method performs an operation that blocks.
 The BaseSMTPServer class doesn't suffer from that problem,
because it's threaded.

If you're interested in integrating this module, I'd be
happy to clean it up to conform with the Python style
guidelines, add documentation, and implement the
allow_host() method.

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

Comment By: Just van Rossum (jvr)
Date: 2004-11-06 04:43

Message:
Logged In: YES 
user_id=92689

I just wanted to check whether the author _knows_ smtpd.py, 
since he doesn't mention it. Maybe I should put it more bluntly:

What's the benefit of having an incompatible, less 
featureful, threaded version of smtpd.py in the library?

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

Comment By: Josiah Carlson (josiahcarlson)
Date: 2004-11-06 04:19

Message:
Logged In: YES 
user_id=341410

1) Agreed completely.

2) smtpd.py is written using the asynchat/asyncore
framework.  This uses the single/multi-threaded/forked
SocketServer.TCPServer framework (various protocols have
both an asynchronous and synchronous version in the standard
library).

Other comments:
3) I also think documentation for this module is necessary,
as is a 3rd party review of the code and error messages.

4) SSL/TLS support should also be included, along with a
reasonable assortment of EHLO, HELP, etc., though smtpd also
should gain such support, so this is not a deal-breaker.

5) Perhaps smtpd should gain allow_sender() and
allow_recipient() methods, and both should gain allow_host()*.

*proper implementations of the above 3
allow_(sender|recipient|host) methods (with either
framework) would be sufficient to do temporary hostname
blacklisting on remote hosts trying to brute-force a local
account listing.

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

Comment By: Just van Rossum (jvr)
Date: 2004-11-06 02:40

Message:
Logged In: YES 
user_id=92689

1) If you're contributing code, it should follow the style guide 
(PEP 8)
2) How does this work relate to smtpd.py?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1057417&group_id=5470
From noreply at sourceforge.net  Sat Dec 18 21:20:02 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Dec 18 21:20:16 2004
Subject: [Patches] [ python-Patches-1053365 ] nntplib: add support for NNTP
	over SSL
Message-ID: <E1Cfl3a-0006Hm-9m@sc8-sf-web3.sourceforge.net>

Patches item #1053365, was opened at 2004-10-24 16:41
Message generated for change (Comment added) made by kuran
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1053365&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Reinhard Speyerer (rspsf)
Assigned to: Nobody/Anonymous (nobody)
Summary: nntplib: add support for NNTP over SSL

Initial Comment:
This patch adds support for NNTP over SSL to nntplib
(based on the SSL support recently added to poplib).


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

Comment By: Jp Calderone (kuran)
Date: 2004-12-18 15:20

Message:
Logged In: YES 
user_id=366566

I wonder why NNTP_SSL.getline() uses a regular expression to
find a newline.  Wouldn't it be simpler and more efficient
to rewrite the method like this (untested, but I bet it
works, and hopefully it gets the idea across anyway):

|  def getline(self):
|      newline = self.buffer.find('\n')
|      while newline == -1:
|          self._fillBuffer()
|          newline = self.buffer.find('\n')
|      line = self.buffer[:newline]
|      self.buffer = self.buffer[newline + 1:]
|      if line.endswith('\r'):
|          line = line[:-1]
|      return line

Also, wouldn't it be nice if the line handling code here
weren't a duplicate of the line handling code in at least
two other stdlib modules?  I don't mean to single out this
patch, but maybe instead of compounding the problem, this
could be taken as an opportunity to reduce the code
duplication in this area by doing some refactoring of the
various line-based protocol implementations to share code
for this common requirement.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1053365&group_id=5470
From noreply at sourceforge.net  Sat Dec 18 21:26:44 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Dec 18 21:26:46 2004
Subject: [Patches] [ python-Patches-1043706 ] External storage protocol for
	large email messages
Message-ID: <E1CflA4-0006TL-Jl@sc8-sf-web4.sourceforge.net>

Patches item #1043706, was opened at 2004-10-09 16:34
Message generated for change (Comment added) made by kuran
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1043706&group_id=5470

Category: Library (Lib)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Barry A. Warsaw (bwarsaw)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: External storage protocol for large email messages

Initial Comment:
In
http://mail.python.org/pipermail/email-sig/2004-October/000158.html
I spec'd out a protocol for storing the contents of
large email messages external to the object.  The
thread continues that this isn't completely adequate,
since we'll need a read interface as well, but that
gets problematic.  Follow the thread for details.

This patch implements storage_open(), storage_write()
and storage_close() -- it's a start, and hopefully
someone else can pick it up from here (although not in
time for Python 2.4).


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

Comment By: Jp Calderone (kuran)
Date: 2004-12-18 15:26

Message:
Logged In: YES 
user_id=366566

I'm having trouble finding the rest of that thread.  I see
the first post, as you linked to it, but no followups.

Am I missing something, or was the conversation continued
off-list?


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1043706&group_id=5470
From noreply at sourceforge.net  Sat Dec 18 21:33:50 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Dec 18 21:33:52 2004
Subject: [Patches] [ python-Patches-1043706 ] External storage protocol for
	large email messages
Message-ID: <E1CflGw-0006Iz-CQ@sc8-sf-web1.sourceforge.net>

Patches item #1043706, was opened at 2004-10-09 16:34
Message generated for change (Comment added) made by kuran
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1043706&group_id=5470

Category: Library (Lib)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Barry A. Warsaw (bwarsaw)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: External storage protocol for large email messages

Initial Comment:
In
http://mail.python.org/pipermail/email-sig/2004-October/000158.html
I spec'd out a protocol for storing the contents of
large email messages external to the object.  The
thread continues that this isn't completely adequate,
since we'll need a read interface as well, but that
gets problematic.  Follow the thread for details.

This patch implements storage_open(), storage_write()
and storage_close() -- it's a start, and hopefully
someone else can pick it up from here (although not in
time for Python 2.4).


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

Comment By: Jp Calderone (kuran)
Date: 2004-12-18 15:33

Message:
Logged In: YES 
user_id=366566

Ahh, nevermind, I see them now.

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

Comment By: Jp Calderone (kuran)
Date: 2004-12-18 15:26

Message:
Logged In: YES 
user_id=366566

I'm having trouble finding the rest of that thread.  I see
the first post, as you linked to it, but no followups.

Am I missing something, or was the conversation continued
off-list?


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1043706&group_id=5470
From noreply at sourceforge.net  Sun Dec 19 01:42:48 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Dec 19 01:42:51 2004
Subject: [Patches] [ python-Patches-755670 ] improve HTMLParser attribute
	processing regexps
Message-ID: <E1Cfp9s-0006ID-Sb@sc8-sf-web4.sourceforge.net>

Patches item #755670, was opened at 2003-06-16 20:09
Message generated for change (Comment added) made by titus
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755670&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Steven Rosenthal (smroid)
Assigned to: Nobody/Anonymous (nobody)
Summary: improve HTMLParser attribute processing regexps

Initial Comment:
HTML examples seen in the wild that cause parse errors
in HTMLParser include:

&lt;a width=&quot;100%&quot;cellspacing=0&gt;
  -- note lack of space between val and next attr name

&lt;a foo=&gt;
  -- trailing attribute has no value after =

&lt;a href=javascript:popup('/popup/html.html')&gt;
  -- javascript fragment with embedded quotes

My patch contains improvements to the 'attrfind' and
'locatestarttagend' regexps that allow these examples
to parse.

The existing test_htmlparser.py unit test continues to
pass, except for the one test case where it considers
&lt;a foo=&gt; to be an error.

I commented out that case and added new test cases to
cover the examples above.


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

Comment By: Titus Brown (titus)
Date: 2004-12-18 16:42

Message:
Logged In: YES 
user_id=23486

This patch allows developers to override the behavior of HTMLParser
when parsing malformed HTML.  Normally HTMLParser calls the function
self.error(), which raises an exception.  This patch adds appropriate
return values for situations where self.error has been redefined in
subclasses to *not* raise an exception.

It does not change the default behavior of HTMLParser and so presents
no backwards compatibility issues.

The patch itself consists of an added comment and two added lines of
code that call 'return' with appropriate values after a self.error call.
Nothing wrong with 'em.  I can't verify that the "junk characters" error
call will leave the parser in a good state, though, if execution returns
from error().

The library documentation could be updated to reflect the ability to 
override
error() behavior; I've written a short patch, available at

http://issola.caltech.edu/~t/transfer/HTMLParser-doc-error.patch

More problems exist with markupbase.py, upon which HTMLParser is 
based.
markupbase calls error() as well, and has some stickier situations.  See
comments in bug 917188 as well.

Comments in 683938 and 699079 suggest that raising an exception is the
correct response to the parse errors.  I recommend application of the
patch anyway, because it (a) doesn't change any behavior by default
and (b) may solve some problems for people.

An alternative would be to distinguish between unrecoverable errors
and recoverable errors by having two different functions, e.g. error() 
(for
recoverable errors) and _fail() (for unrecoverable errors).  By default
error() would call _fail() and internal code could be changed to call
_fail() where recovery is impossible.  This might alter behavior in
situations where subclasses override error() but then again that's not
legitimate to do anyway, at least not at the moment -- error() isn't
in the docs ;).

If nothing done, at least close patch 755660 and bug 736428 with a
comment saying that this behavior will not be addressed ;).


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

Comment By: Steven Rosenthal (smroid)
Date: 2003-06-17 20:22

Message:
Logged In: YES 
user_id=159908

This also fixes bugs 683938 and 699079.


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

Comment By: Steven Rosenthal (smroid)
Date: 2003-06-16 20:10

Message:
Logged In: YES 
user_id=159908

Base version for HTMLParser.py is 1.11.2.1; base version for
test_htmlparser.py is 1.8.8.1


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755670&group_id=5470
From noreply at sourceforge.net  Sun Dec 19 01:45:12 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Dec 19 01:45:14 2004
Subject: [Patches] [ python-Patches-755670 ] improve HTMLParser attribute
	processing regexps
Message-ID: <E1CfpCC-0006MD-J6@sc8-sf-web3.sourceforge.net>

Patches item #755670, was opened at 2003-06-16 20:09
Message generated for change (Comment added) made by titus
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755670&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Steven Rosenthal (smroid)
Assigned to: Nobody/Anonymous (nobody)
Summary: improve HTMLParser attribute processing regexps

Initial Comment:
HTML examples seen in the wild that cause parse errors
in HTMLParser include:

&lt;a width=&quot;100%&quot;cellspacing=0&gt;
  -- note lack of space between val and next attr name

&lt;a foo=&gt;
  -- trailing attribute has no value after =

&lt;a href=javascript:popup('/popup/html.html')&gt;
  -- javascript fragment with embedded quotes

My patch contains improvements to the 'attrfind' and
'locatestarttagend' regexps that allow these examples
to parse.

The existing test_htmlparser.py unit test continues to
pass, except for the one test case where it considers
&lt;a foo=&gt; to be an error.

I commented out that case and added new test cases to
cover the examples above.


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

Comment By: Titus Brown (titus)
Date: 2004-12-18 16:45

Message:
Logged In: YES 
user_id=23486

whoops, attached to wrong patch!  dangitall.  sorry...

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

Comment By: Titus Brown (titus)
Date: 2004-12-18 16:42

Message:
Logged In: YES 
user_id=23486

This patch allows developers to override the behavior of HTMLParser
when parsing malformed HTML.  Normally HTMLParser calls the function
self.error(), which raises an exception.  This patch adds appropriate
return values for situations where self.error has been redefined in
subclasses to *not* raise an exception.

It does not change the default behavior of HTMLParser and so presents
no backwards compatibility issues.

The patch itself consists of an added comment and two added lines of
code that call 'return' with appropriate values after a self.error call.
Nothing wrong with 'em.  I can't verify that the "junk characters" error
call will leave the parser in a good state, though, if execution returns
from error().

The library documentation could be updated to reflect the ability to 
override
error() behavior; I've written a short patch, available at

http://issola.caltech.edu/~t/transfer/HTMLParser-doc-error.patch

More problems exist with markupbase.py, upon which HTMLParser is 
based.
markupbase calls error() as well, and has some stickier situations.  See
comments in bug 917188 as well.

Comments in 683938 and 699079 suggest that raising an exception is the
correct response to the parse errors.  I recommend application of the
patch anyway, because it (a) doesn't change any behavior by default
and (b) may solve some problems for people.

An alternative would be to distinguish between unrecoverable errors
and recoverable errors by having two different functions, e.g. error() 
(for
recoverable errors) and _fail() (for unrecoverable errors).  By default
error() would call _fail() and internal code could be changed to call
_fail() where recovery is impossible.  This might alter behavior in
situations where subclasses override error() but then again that's not
legitimate to do anyway, at least not at the moment -- error() isn't
in the docs ;).

If nothing done, at least close patch 755660 and bug 736428 with a
comment saying that this behavior will not be addressed ;).


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

Comment By: Steven Rosenthal (smroid)
Date: 2003-06-17 20:22

Message:
Logged In: YES 
user_id=159908

This also fixes bugs 683938 and 699079.


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

Comment By: Steven Rosenthal (smroid)
Date: 2003-06-16 20:10

Message:
Logged In: YES 
user_id=159908

Base version for HTMLParser.py is 1.11.2.1; base version for
test_htmlparser.py is 1.8.8.1


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755670&group_id=5470
From noreply at sourceforge.net  Sun Dec 19 01:45:28 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Dec 19 01:45:31 2004
Subject: [Patches] [ python-Patches-755660 ] allow HTMLParser to continue
	after a parse error
Message-ID: <E1CfpCS-0006Z7-VZ@sc8-sf-web1.sourceforge.net>

Patches item #755660, was opened at 2003-06-16 19:27
Message generated for change (Comment added) made by titus
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755660&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Steven Rosenthal (smroid)
Assigned to: Nobody/Anonymous (nobody)
Summary: allow HTMLParser to continue after a parse error

Initial Comment:
The HTMLParser.error method raises HTMLParseError,
terminating the parse upon detection of a parse error.

This patch is to allow HTMLParser to continue parsing
if the error() method is overridden to not throw an
exception.

Doc impact is on the error() method. The existing
test_htmlparser.py unit test is unaffected by the patch.

The base file is HTMLParser.py, revision 1.11.2.1


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

Comment By: Titus Brown (titus)
Date: 2004-12-18 16:45

Message:
Logged In: YES 
user_id=23486

This patch allows developers to override the behavior of HTMLParser
when parsing malformed HTML.  Normally HTMLParser calls the function
self.error(), which raises an exception.  This patch adds appropriate
return values for situations where self.error has been redefined in
subclasses to *not* raise an exception.

It does not change the default behavior of HTMLParser and so presents
no backwards compatibility issues.

The patch itself consists of an added comment and two added lines of
code that call 'return' with appropriate values after a self.error call.
Nothing wrong with 'em.  I can't verify that the "junk characters" error
call will leave the parser in a good state, though, if execution returns
from error().

The library documentation could be updated to reflect the ability to 
override
error() behavior; I've written a short patch, available at

http://issola.caltech.edu/~t/transfer/HTMLParser-doc-error.patch

More problems exist with markupbase.py, upon which HTMLParser is 
based.
markupbase calls error() as well, and has some stickier situations.  See
comments in bug 917188 as well.

Comments in 683938 and 699079 suggest that raising an exception is the
correct response to the parse errors.  I recommend application of the
patch anyway, because it (a) doesn't change any behavior by default
and (b) may solve some problems for people.

An alternative would be to distinguish between unrecoverable errors
and recoverable errors by having two different functions, e.g. error() 
(for
recoverable errors) and _fail() (for unrecoverable errors).  By default
error() would call _fail() and internal code could be changed to call
_fail() where recovery is impossible.  This might alter behavior in
situations where subclasses override error() but then again that's not
legitimate to do anyway, at least not at the moment -- error() isn't
in the docs ;).

If nothing done, at least close patch 755660 and bug 736428 with a
comment saying that this behavior will not be addressed ;).


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

Comment By: Steven Rosenthal (smroid)
Date: 2003-06-17 20:13

Message:
Logged In: YES 
user_id=159908

this fixes bug #736428 (submitted by me earlier)


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755660&group_id=5470
From noreply at sourceforge.net  Sun Dec 19 06:42:20 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Dec 19 06:42:24 2004
Subject: [Patches] [ python-Patches-1087808 ] sgmllib.SGMLParser does not
	unescape attribute values; patch
Message-ID: <E1Cftpk-0004uY-V8@sc8-sf-web3.sourceforge.net>

Patches item #1087808, was opened at 2004-12-18 21:42
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1087808&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Titus Brown (titus)
Assigned to: Nobody/Anonymous (nobody)
Summary: sgmllib.SGMLParser does not unescape attribute values; patch

Initial Comment:
for example, in a form parsed by htmllib.HTMLParser (based on 
SGMLParser),

<option value="5&quot; big"> 5&quot; big

the value will not be unescaped to 5" while the printed
option will be.

Note that this behavior differs from that of 
HTMLParser.HTMLParser, which does a fine job.

See attached test script/test input for an example.

See attached patch for a fix: essentially I copied the code directly 
from HTMLParser.HTMLParser.

I don't think this patch should break anything; I can't imagine 
people were relying on this behavior!


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1087808&group_id=5470
From noreply at sourceforge.net  Sun Dec 19 07:44:47 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Dec 19 07:44:52 2004
Subject: [Patches] [ python-Patches-1055159 ] CGIHTTPServer can't redirect
Message-ID: <E1CfuoB-0006ee-Et@sc8-sf-web1.sourceforge.net>

Patches item #1055159, was opened at 2004-10-27 01:49
Message generated for change (Comment added) made by titus
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1055159&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Guettler (guettli)
Assigned to: Nobody/Anonymous (nobody)
Summary: CGIHTTPServer can't redirect

Initial Comment:
Please add this to the docstring of CGIHTTPServer:

It can't handle redirects (302) because it returns "200
Script output
follows" before the script is executed.



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

Comment By: Titus Brown (titus)
Date: 2004-12-18 22:44

Message:
Logged In: YES 
user_id=23486

Verified behavior on Linux -- Apache redirects appropriately,
but the same script run via CGIHTTPServer does not.  Plus
it makes sense given the implementation code in CGIHTTPServer.py ;).

Documentation patch to docs and docstring at

http://issola.caltech.edu/~t/transfer/patch-1055159-doc.diff

...if someone could attach it, please... tnx!

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1055159&group_id=5470
From noreply at sourceforge.net  Sun Dec 19 07:58:59 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Dec 19 07:59:05 2004
Subject: [Patches] [ python-Patches-755670 ] improve HTMLParser attribute
	processing regexps
Message-ID: <E1Cfv1v-0006lf-JT@sc8-sf-web3.sourceforge.net>

Patches item #755670, was opened at 2003-06-16 20:09
Message generated for change (Comment added) made by titus
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755670&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Steven Rosenthal (smroid)
Assigned to: Nobody/Anonymous (nobody)
Summary: improve HTMLParser attribute processing regexps

Initial Comment:
HTML examples seen in the wild that cause parse errors
in HTMLParser include:

&lt;a width=&quot;100%&quot;cellspacing=0&gt;
  -- note lack of space between val and next attr name

&lt;a foo=&gt;
  -- trailing attribute has no value after =

&lt;a href=javascript:popup('/popup/html.html')&gt;
  -- javascript fragment with embedded quotes

My patch contains improvements to the 'attrfind' and
'locatestarttagend' regexps that allow these examples
to parse.

The existing test_htmlparser.py unit test continues to
pass, except for the one test case where it considers
&lt;a foo=&gt; to be an error.

I commented out that case and added new test cases to
cover the examples above.


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

Comment By: Titus Brown (titus)
Date: 2004-12-18 22:58

Message:
Logged In: YES 
user_id=23486

I don't think HTMLParser should parse clearly invalid HTML without
complaining.  Perhaps such behavior should be overrideable (see patch
755660 & comments therein), but this patch changes behavior to parse 
invalid HTML w/o complaint.

Patch 699079, to "fix" similar behavior, was closed by adsr and bcannon 
because such behavior is correct.  Patch 683938 is also similar but is 
being kept open for some reason.

Recommend closing patch w/o applying.

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

Comment By: Titus Brown (titus)
Date: 2004-12-18 16:45

Message:
Logged In: YES 
user_id=23486

whoops, attached to wrong patch!  dangitall.  sorry...

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

Comment By: Titus Brown (titus)
Date: 2004-12-18 16:42

Message:
Logged In: YES 
user_id=23486

This patch allows developers to override the behavior of HTMLParser
when parsing malformed HTML.  Normally HTMLParser calls the function
self.error(), which raises an exception.  This patch adds appropriate
return values for situations where self.error has been redefined in
subclasses to *not* raise an exception.

It does not change the default behavior of HTMLParser and so presents
no backwards compatibility issues.

The patch itself consists of an added comment and two added lines of
code that call 'return' with appropriate values after a self.error call.
Nothing wrong with 'em.  I can't verify that the "junk characters" error
call will leave the parser in a good state, though, if execution returns
from error().

The library documentation could be updated to reflect the ability to 
override
error() behavior; I've written a short patch, available at

http://issola.caltech.edu/~t/transfer/HTMLParser-doc-error.patch

More problems exist with markupbase.py, upon which HTMLParser is 
based.
markupbase calls error() as well, and has some stickier situations.  See
comments in bug 917188 as well.

Comments in 683938 and 699079 suggest that raising an exception is the
correct response to the parse errors.  I recommend application of the
patch anyway, because it (a) doesn't change any behavior by default
and (b) may solve some problems for people.

An alternative would be to distinguish between unrecoverable errors
and recoverable errors by having two different functions, e.g. error() 
(for
recoverable errors) and _fail() (for unrecoverable errors).  By default
error() would call _fail() and internal code could be changed to call
_fail() where recovery is impossible.  This might alter behavior in
situations where subclasses override error() but then again that's not
legitimate to do anyway, at least not at the moment -- error() isn't
in the docs ;).

If nothing done, at least close patch 755660 and bug 736428 with a
comment saying that this behavior will not be addressed ;).


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

Comment By: Steven Rosenthal (smroid)
Date: 2003-06-17 20:22

Message:
Logged In: YES 
user_id=159908

This also fixes bugs 683938 and 699079.


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

Comment By: Steven Rosenthal (smroid)
Date: 2003-06-16 20:10

Message:
Logged In: YES 
user_id=159908

Base version for HTMLParser.py is 1.11.2.1; base version for
test_htmlparser.py is 1.8.8.1


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755670&group_id=5470
From noreply at sourceforge.net  Sun Dec 19 08:24:28 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Dec 19 08:24:32 2004
Subject: [Patches] [ python-Patches-1037974 ] urllib2 HTTP digest
	authentication fix
Message-ID: <E1CfvQa-0007SQ-Jk@sc8-sf-web3.sourceforge.net>

Patches item #1037974, was opened at 2004-09-30 12:10
Message generated for change (Comment added) made by titus
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1037974&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Mathieu Fenniak (mfenniak)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 HTTP digest authentication fix

Initial Comment:
Although the 'algorithm' component of the Authorization header is 
considered optional by RFC 2617, there are sites that do not 
function without providing algorithm notification.  Specifically, this 
problem is encounted with LiveJournal RSS feeds (where HTTP 
digest authentication can be used to view non-public livejournal 
entries).

This patch makes the algorithm flag always sent in the 
Authorization header.  The following test script demonstrates the 
problem for a LiveJournal RSS feed (username and password must 
be entered):

    import urllib2

    class PasswordMgr(object):
        def find_user_password(self, realm, authuri):
            return "someuser", "somepass"
        def add_password(self):
            pass

    rssURI = "http://livejournal.com/users/someuser/data/rss?
auth=digest"

    handler = urllib2.HTTPDigestAuthHandler(PasswordMgr())
    opener = urllib2.build_opener(handler)
    opener.open(rssURI)

With the attached patch, this works successfully.  Without it, it fails 
with an HTTP 401 error.

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

Comment By: Titus Brown (titus)
Date: 2004-12-18 23:24

Message:
Logged In: YES 
user_id=23486

Patch is simple (one line removed from current urllib2!).  I don't know 
much about http digest authentication, so I can't say anything about 
whether or not this correct; but I have verified that it fixes the 
LiveJournal behavior noted in the patch description (on Linux, under 
current CVS tree).  Moreover the MD5 
algorithm is the default, so this patch merely changes the behavior to be 
more verbose than it is currently -- it shouldn't break any existing actual 
functionality.

Recommend application of patch.



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

Comment By: Mathieu Fenniak (mfenniak)
Date: 2004-09-30 12:13

Message:
Logged In: YES 
user_id=1131071

Err, sorry, it appears I didn't attach the patch.  Here it is.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1037974&group_id=5470
From noreply at sourceforge.net  Sun Dec 19 08:35:52 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Dec 19 08:35:57 2004
Subject: [Patches] [ python-Patches-1028908 ] Changes to cookielib.py &
	friends for 2.4b1
Message-ID: <E1Cfvbc-00078D-LB@sc8-sf-web4.sourceforge.net>

Patches item #1028908, was opened at 2004-09-15 17:19
Message generated for change (Comment added) made by titus
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1028908&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: John J Lee (jjlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: Changes to cookielib.py & friends for 2.4b1

Initial Comment:
The patch contains uncontroversial changes to cookielib
and associated modules, documentation and tests.  Would
be unfortunate not to have these in 2.4.0.

1. Changes to keep cookielib in sync with ClientCookie
1.0 release.  This will make life simpler for people
migrating from ClientCookie (the package from whence
cookielib, and some recent urllib2 changes, came).

  a. Moved country-code pseudo-top-level domain (eg.
.co.uk) code into a separate method of
DefaultCookiePolicy to make life easier for subclassers
(.set_ok_countrycode_domain()).

  b. Added Cookie.nonstandard_attr_keys() method.

2. Added a new test.

3. Documentation corrections and clarifications
(including adding a prominent warning about current
lack of thread-safety, and a new example).

4. Small-scale refactoring in cookielib.py (including
moving magic_re to its rightful place in _LWPCookieJar.py).

5. Tiny code clarification in urllib2.py.

6. Removed coding declaration from test_cookielib.py,
in favour of escape sequences, since I discovered that
I don't understand coding declarations :-/


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

Comment By: Titus Brown (titus)
Date: 2004-12-18 23:35

Message:
Logged In: YES 
user_id=23486

Applied patch & ran 'make test' under Linux with latest from CVS.  
Everything works.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1028908&group_id=5470
From noreply at sourceforge.net  Sun Dec 19 09:20:50 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Dec 19 09:21:01 2004
Subject: [Patches] [ python-Patches-827559 ] SimpleHTTPServer
	directory-indexing &quot; bug&quot; fix
Message-ID: <E1CfwJ8-00005J-KW@sc8-sf-web3.sourceforge.net>

Patches item #827559, was opened at 2003-10-21 07:49
Message generated for change (Comment added) made by titus
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=827559&group_id=5470

Category: Library (Lib)
Group: Python 2.2.x
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris Gonnerman (solomoriah)
Assigned to: Nobody/Anonymous (nobody)
Summary: SimpleHTTPServer directory-indexing &quot;bug&quot; fix

Initial Comment:
The SimpleHTTPServer.py module, when presented with a
URL of the form:

      http://some.site.com/directory

should redirect the browser to:

      http://some.site.com/directory/

This is evidently a standard behavior of major
webservers (Apache and IIS at least).  SimpleHTTPServer
does not do this, but fortunately it is simple to
implement (patch attached, naturally).

I am providing a fix for 2.2 but this problem appears
to be in earlier versions, and is also in 2.3.  This
patch appears to work fine for 2.3.



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

Comment By: Titus Brown (titus)
Date: 2004-12-19 00:20

Message:
Logged In: YES 
user_id=23486

Clearly a bug, IMO: a reference to a directory name w/o a slash
will return the directory listing, but relative links do not then work.
(Does this need more explication or ???)

Patch works against latest CVS & fixes behavior.  Recommend 
application.

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

Comment By: Chris Gonnerman (solomoriah)
Date: 2003-11-13 21:28

Message:
Logged In: YES 
user_id=321948

Oops.  Allow me to clarify.  Directory names without a
trailing slash need to be redirected to the same name with
the trailing slash to avoid breaking relative links from the
page.

I use SimpleHTTPServer to test websites which will be
deployed via Apache.  Relative links on default directory
pages (index.html) are broken using SimpleHTTPServer but
work correctly on Apache.

This is a de facto standard at least (I haven't read the
RFC's but both IE and Mozilla expect this behavior).


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

Comment By: Martin v. L?wis (loewis)
Date: 2003-11-13 07:54

Message:
Logged In: YES 
user_id=21627

Why is this a bug? SimpleHTTPServer already returns the
directory content if only the directory name is given, with
or without trailing slash. I believe Apache does that only
as an implementation detail, and it is unfortunate that this
detail is exposed to clients.

So unless you can report a specific problem with the
approach taken by SimpleHTTPServer, I'm tempted to reject
this patch.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=827559&group_id=5470
From noreply at sourceforge.net  Sun Dec 19 09:26:56 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Dec 19 09:26:59 2004
Subject: [Patches] [ python-Patches-901480 ] urllib2.parse_http_list bugfix
	735248
Message-ID: <E1CfwP2-0000Bu-NZ@sc8-sf-web3.sourceforge.net>

Patches item #901480, was opened at 2004-02-20 15:34
Message generated for change (Comment added) made by titus
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=901480&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2.parse_http_list bugfix  735248

Initial Comment:
With unquoted elements, the current code forgets to 
throw away the already processed portion.

>>> urllib2.parse_http_list('a,b,c')
['a', 'a,b', 'a,b,c']

The current code does not handle escaped characters.
>>> len(urllib2.parse_http_list(r'"a"\,"b","c"'))
3

This patch replaces parse_http_list and adds a helper 
function.  I also added docstricts for these cases, and a 
few others (which the current code does get right, but 
which are not ...)


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

Comment By: Titus Brown (titus)
Date: 2004-12-19 00:26

Message:
Logged In: YES 
user_id=23486

Fix works against latest CVS. As noted it does fix bug 735248 and also 
works on quoted strings.

I made a context diff against the current CVS.  It's at

http://issola.caltech.edu/~t/transfer/patch-901480-parse.diff

This diff fixes a docstring & also allows direct application to the current 
CVS.

Recommend application.


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

Comment By: Jim Jewett (jimjjewett)
Date: 2004-02-20 15:42

Message:
Logged In: YES 
user_id=764593

The cutoff portion just said that the current code did get the 
remaining tests right, but I might have missed them myself if I 
hadn't been looking at the old code when I wrote it.  So I 
want them there for the next person.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=901480&group_id=5470
From noreply at sourceforge.net  Sun Dec 19 09:51:07 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Dec 19 09:51:14 2004
Subject: [Patches] [ python-Patches-810023 ] Fix for off-by-one bug in
	urllib.URLopener.retrieve
Message-ID: <E1CfwmR-00006E-2W@sc8-sf-web4.sourceforge.net>

Patches item #810023, was opened at 2003-09-20 22:13
Message generated for change (Comment added) made by titus
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=810023&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: J. Lewis Muir (jlmuir)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix for off-by-one bug in urllib.URLopener.retrieve

Initial Comment:
This patch fixes an off-by-one bug in the reporthook part of 
urllib.URLopener.retrieve and adds test cases to verify the 
fix.

The retrieve method reports reading one more block than it 
actually does. Here's an example. The file is empty. I expect 
the initial reporthook call on establishment of the network 
connection but not an additional call since the file is empty 
(no block was read):

&gt;&gt;&gt; import urllib
&gt;&gt;&gt; def reporter(count, blockSize, fileSize):
...     print &quot;c: %i, bs: %i, fs: %i&quot; % (count, blockSize, 
fileSize)
...
&gt;&gt;&gt; srcFile = file(&quot;/tmp/empty.txt&quot;, &quot;wb&quot;)
&gt;&gt;&gt; srcFile.close()
&gt;&gt;&gt; urllib.urlretrieve(&quot;file:///tmp/empty.txt&quot;, &quot;/tmp/new-
empty.txt&quot;, reporter)
c: 0, bs: 8192, fs: 0
c: 1, bs: 8192, fs: 0
('/tmp/new-empty.txt', &lt;mimetools.Message instance at 
0x5a4f58&gt;)
&gt;&gt;&gt;

As a second example, if the file contains 1 byte, the retrieve 
method claims it read 2 blocks when it really only read 1:

&gt;&gt;&gt; srcFile = file(&quot;/tmp/empty.txt&quot;, &quot;wb&quot;)
&gt;&gt;&gt; srcFile.write(&quot;x&quot;)
&gt;&gt;&gt; srcFile.close()
&gt;&gt;&gt; urllib.urlretrieve(&quot;file:///tmp/empty.txt&quot;, &quot;/tmp/new-
empty.txt&quot;, reporter)
c: 0, bs: 8192, fs: 1
c: 1, bs: 8192, fs: 1
c: 2, bs: 8192, fs: 1
('/tmp/new-empty.txt', &lt;mimetools.Message instance at 
0x5a50d0&gt;)
&gt;&gt;&gt;

This patch also includes some changes to 
test_urllib.urlretrieve_FileTests (where I added the test 
cases) to support creating more than one temporary file and 
making sure any created temporary files get deleted when 
the test case fixture is torn down.


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

Comment By: Titus Brown (titus)
Date: 2004-12-19 00:51

Message:
Logged In: YES 
user_id=23486

Patch needed slight modification to work against current HEAD; new 
patch at 

http://issola.caltech.edu/~t/transfer/transfer/patch-810023-
reporthook.diff

The new regression tests look reasonable.  I verified that the new 
regression tests FAILED against old urllib.py, and worked against patched 
urllib.py.  Recommend apply.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=810023&group_id=5470
From noreply at sourceforge.net  Sun Dec 19 10:13:35 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Dec 19 10:13:42 2004
Subject: [Patches] [ python-Patches-893642 ] SimpleXMLRPCServer.py optional
	allow_none argument
Message-ID: <E1Cfx8B-0000XA-Rp@sc8-sf-web4.sourceforge.net>

Patches item #893642, was opened at 2004-02-09 11:59
Message generated for change (Comment added) made by titus
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=893642&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Li Zou (lzou)
Assigned to: Nobody/Anonymous (nobody)
Summary: SimpleXMLRPCServer.py optional allow_none argument

Initial Comment:
xmlrpclip.ServerProxy support an optional allow_none 
argument while SimpleXMLRPCServer.py doesn't. This 
patch is a straightforward one to fix it.

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

Comment By: Titus Brown (titus)
Date: 2004-12-19 01:13

Message:
Logged In: YES 
user_id=23486

Updated patch to fix CGIXMLRPCRequestHandler & added patch to Lib/ 
documentation.

New diffs against current head available at

http://issola.caltech.edu/~t/transfer/patch-893642-xmlrpc.diff

This patch should not change any behavior.  It only allows overriding
of default behavior (which is to not allow_none).  Recommend apply.

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

Comment By: Mark McClain (mmcclain)
Date: 2004-02-17 13:57

Message:
Logged In: YES 
user_id=978042

The patch needs to address the CGIXMLDispatcher too. Otherwise it is the 
same as the one that I did last fall, but have been slow to post here.

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

Comment By: Mark McClain (mmcclain)
Date: 2004-02-17 13:54

Message:
Logged In: YES 
user_id=978042

The patch needs to address the CGIXMLDispatcher too. Otherwise it is the 
same as the one that I did last fall, but have been slow to post here.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=893642&group_id=5470
From noreply at sourceforge.net  Sun Dec 19 10:37:20 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Dec 19 10:37:32 2004
Subject: [Patches] [ python-Patches-1067760 ] fix for 1067728: Better
	handling of float arguments to seek
Message-ID: <E1CfxVA-0003U6-VV@sc8-sf-web2.sourceforge.net>

Patches item #1067760, was opened at 2004-11-16 17:28
Message generated for change (Comment added) made by titus
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1067760&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Robert Church (churchr)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix for 1067728: Better handling of float arguments to seek

Initial Comment:
Instead of converting all float arguments to ints, this
first attempts to 
convert the argument to a PyLong, and then the old
conversion code takes over.

The upshot is that the limit of floating point
arguments to seek() is raised from (2 ** 32) - 1 to
somewhere above (2 ** 62).

Perhaps a better way to handle this would be to not
accept floating point arguments to seek().

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

Comment By: Titus Brown (titus)
Date: 2004-12-19 01:37

Message:
Logged In: YES 
user_id=23486

The patch works against HEAD; updated for line numbers (there's a very 
similar set of line elsewhere in the file):

http://issola.caltech.edu/~t/transfer/patch-1067760-seek.diff

rhettinger thought the current behavior was reasonable (see bug 
1067728).  I'm not qualified to comment ;) but it seems odd that floats 
would have drastically different limits than longs.  This looks like a 
reasonable compromise IMO.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1067760&group_id=5470
From noreply at sourceforge.net  Sun Dec 19 10:38:46 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Dec 19 10:38:50 2004
Subject: [Patches] [ python-Patches-1067760 ] fix for 1067728: Better
	handling of float arguments to seek
Message-ID: <E1CfxWY-0001qW-J6@sc8-sf-web3.sourceforge.net>

Patches item #1067760, was opened at 2004-11-16 17:28
Message generated for change (Comment added) made by titus
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1067760&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Robert Church (churchr)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix for 1067728: Better handling of float arguments to seek

Initial Comment:
Instead of converting all float arguments to ints, this
first attempts to 
convert the argument to a PyLong, and then the old
conversion code takes over.

The upshot is that the limit of floating point
arguments to seek() is raised from (2 ** 32) - 1 to
somewhere above (2 ** 62).

Perhaps a better way to handle this would be to not
accept floating point arguments to seek().

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

Comment By: Titus Brown (titus)
Date: 2004-12-19 01:38

Message:
Logged In: YES 
user_id=23486

Sorry, I should add: patch works against head on Linux RH 9.0 (and 
should work everywhere).  Behavior tested with a script.

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

Comment By: Titus Brown (titus)
Date: 2004-12-19 01:37

Message:
Logged In: YES 
user_id=23486

The patch works against HEAD; updated for line numbers (there's a very 
similar set of line elsewhere in the file):

http://issola.caltech.edu/~t/transfer/patch-1067760-seek.diff

rhettinger thought the current behavior was reasonable (see bug 
1067728).  I'm not qualified to comment ;) but it seems odd that floats 
would have drastically different limits than longs.  This looks like a 
reasonable compromise IMO.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1067760&group_id=5470
From noreply at sourceforge.net  Sun Dec 19 19:11:35 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Dec 19 19:11:40 2004
Subject: [Patches] [ python-Patches-786743 ] Solaris 2.5.1 _SC_PAGESIZE vs.
	_SC_PAGE_SIZE
Message-ID: <E1Cg5Wp-0007Fx-6h@sc8-sf-web1.sourceforge.net>

Patches item #786743, was opened at 2003-08-11 17:21
Message generated for change (Settings changed) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=786743&group_id=5470

>Category: Build
>Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Harald Koenig (hkoenig)
>Assigned to: Martin v. L?wis (loewis)
Summary: Solaris 2.5.1 _SC_PAGESIZE vs. _SC_PAGE_SIZE

Initial Comment:
Modules/resource.c patch fixes a problem for Solaris
2.5.1 which
doesn't define _SC_PAGE_SIZE but _SC_PAGESIZE in unistd.h.

feel free to add a test to configure -- I won't touch
configure myself (sorry:)


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=786743&group_id=5470
From noreply at sourceforge.net  Sun Dec 19 19:12:14 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Dec 19 19:12:18 2004
Subject: [Patches] [ python-Patches-786737 ] patch for build with read-only
	$srcdir
Message-ID: <E1Cg5XS-0005Hl-1m@sc8-sf-web4.sourceforge.net>

Patches item #786737, was opened at 2003-08-11 17:17
Message generated for change (Settings changed) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=786737&group_id=5470

>Category: Build
>Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Harald Koenig (hkoenig)
>Assigned to: Martin v. L?wis (loewis)
Summary: patch for build with read-only $srcdir

Initial Comment:
trying to build with a read-only $srcdir tree 
and a tree of symlinks to $srcdir fails at two stages
without the attached patch.

the additional -IInclude is needed because
of graminit.h which gets generated in Includes
(since $srcdir/Includes is readonly!).

the change from LDSHARED to BLDSHARED
is necessary for AIX-4.3

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=786737&group_id=5470
From noreply at sourceforge.net  Sun Dec 19 21:54:43 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Dec 19 21:54:50 2004
Subject: [Patches] [ python-Patches-1053365 ] nntplib: add support for NNTP
	over SSL
Message-ID: <E1Cg84h-0002IA-Oc@sc8-sf-web4.sourceforge.net>

Patches item #1053365, was opened at 2004-10-24 20:41
Message generated for change (Comment added) made by rspsf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1053365&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Reinhard Speyerer (rspsf)
Assigned to: Nobody/Anonymous (nobody)
Summary: nntplib: add support for NNTP over SSL

Initial Comment:
This patch adds support for NNTP over SSL to nntplib
(based on the SSL support recently added to poplib).


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

>Comment By: Reinhard Speyerer (rspsf)
Date: 2004-12-19 20:54

Message:
Logged In: YES 
user_id=814251

NNTP_SSL.getline() uses a regular expression because the
NNTP_SSL code is a rather straightforward port of the
corresponding
SSL code from the poplib.py module.

I think it is a good idea to refactor the code to avoid code
duplication
in the various modules using SSL (and maybe also for the
different
authentication methods like AUTH CRAM_MD5 etc.), however
such a large refactoring is probably beyond the scope of a
submitted patch.





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

Comment By: Jp Calderone (kuran)
Date: 2004-12-18 20:20

Message:
Logged In: YES 
user_id=366566

I wonder why NNTP_SSL.getline() uses a regular expression to
find a newline.  Wouldn't it be simpler and more efficient
to rewrite the method like this (untested, but I bet it
works, and hopefully it gets the idea across anyway):

|  def getline(self):
|      newline = self.buffer.find('\n')
|      while newline == -1:
|          self._fillBuffer()
|          newline = self.buffer.find('\n')
|      line = self.buffer[:newline]
|      self.buffer = self.buffer[newline + 1:]
|      if line.endswith('\r'):
|          line = line[:-1]
|      return line

Also, wouldn't it be nice if the line handling code here
weren't a duplicate of the line handling code in at least
two other stdlib modules?  I don't mean to single out this
patch, but maybe instead of compounding the problem, this
could be taken as an opportunity to reduce the code
duplication in this area by doing some refactoring of the
various line-based protocol implementations to share code
for this common requirement.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1053365&group_id=5470
From noreply at sourceforge.net  Sun Dec 19 22:27:08 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Dec 19 22:27:11 2004
Subject: [Patches] [ python-Patches-1088078 ] Patch for bug 1088077
Message-ID: <E1Cg8a4-0004WQ-Fw@sc8-sf-web3.sourceforge.net>

Patches item #1088078, was opened at 2004-12-19 15:27
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1088078&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Meyer (mwm)
Assigned to: Nobody/Anonymous (nobody)
Summary: Patch for bug 1088077

Initial Comment:
This patches adds a setsane function to the tty module.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1088078&group_id=5470
From noreply at sourceforge.net  Mon Dec 20 01:00:03 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Dec 20 01:00:12 2004
Subject: [Patches] [ python-Patches-967763 ] fix bsddb memory leaks
Message-ID: <E1CgAy3-0001q7-R5@sc8-sf-web3.sourceforge.net>

Patches item #967763, was opened at 2004-06-06 13:51
Message generated for change (Comment added) made by greg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=967763&group_id=5470

Category: None
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Gregory P. Smith (greg)
Summary: fix bsddb memory leaks

Initial Comment:
only one of the changes fixed a leak reported by
valgrind, but i think all the changes are necessary.

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

>Comment By: Gregory P. Smith (greg)
Date: 2004-12-19 16:00

Message:
Logged In: YES 
user_id=413

fixed, committed to the release23-maint branch.

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

Comment By: Gregory P. Smith (greg)
Date: 2004-06-27 16:34

Message:
Logged In: YES 
user_id=413

fix committed.  Modules/_bsddb.c 1.32 and  Lib/bsddb/test/test_recno.py 1.8

patch attached.  marking as python 2.3 as this should be committed to the python 2.3 maintenance branch before 2.3.5 is released.


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

Comment By: Gregory P. Smith (greg)
Date: 2004-06-27 15:51

Message:
Logged In: YES 
user_id=413

DB_get and DBC_set_range were the two leaks that showed up in valgrind using the existing testsuite.  however there were plenty more possible leak cases (most of them in odd situations like out of memory or passing a non DBTxn object in the txn parameter).  

The most common trigger for a leak in various places would be an exception exit from a many functions when using integer keys (queue & recno databases).  I have a patch which i believe fixes all of these and more after a lot of code inspection that i'll commit once my valgrind run finishes and reveals no bsddb related leaks or double frees. (ugh running valgrind -v --leak-check=yes ./python Lib/bsddb/test/test_all.py on a 5 year old laptop is slow...)

"manual memory management... how quaint."

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-06-15 18:48

Message:
Logged In: YES 
user_id=33168

should FREE_DBT() be called clearTxn() and friends fail? 
one memory leak is caused in DB_get() by test_recno, line 75
(d.get(100)).  if the FREE_DBT()s at line 1392-1393 are
moved outside the if, so they always execute the leak goes
away.  i'm not sure if this is really the correct solution
though.

the other leak is in test_compat, don't know anything more.

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

Comment By: Gregory P. Smith (greg)
Date: 2004-06-14 18:47

Message:
Logged In: YES 
user_id=413

Thanks, I hadn't caught up on python-dev in a while.  What
happens if you apply my attached patch and rerun the test
under valgrind?

The 4 bytes leaked sounds exactly like what i was expecting
reading the code (an integer key causes make_key_dbt to
alloc a 32bit value).  in the DBC_set_range case without the
patch i believe it is likely that the integer is allocated
but the REALLOC flag is overridden in the old code with a
MALLOC causing BerkeleyDB to leak the old pointer and
allocate a new key for the return value (btree accessed
using an integer key).

8 bytes in 2 blocks leaked in DB_get is double what i
expected but without debug info showing the DB_get function
call arguments and database flags its hard to say what happened.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-06-14 18:36

Message:
Logged In: YES 
user_id=33168

I just run the regression tests.  Did you see my mail to
python-dev?  

http://mail.python.org/pipermail/python-dev/2004-June/045245.html

Here's the bsddb leaks reported by valgrind:

 4 bytes in 1 blocks are definitely lost in loss record 7 of 663
    at 0x3C01DA1D: malloc (vg_replace_malloc.c:109)
    by 0x3C928265: make_key_dbt (_bsddb.c:400)
    by 0x3C92DE4F: DBC_set_range (_bsddb.c:2911)

 8 bytes in 2 blocks are definitely lost in loss record 29
of 663
    at 0x3C01DA1D: malloc (vg_replace_malloc.c:109)
    by 0x3C928265: make_key_dbt (_bsddb.c:400)
    by 0x3C929088: DB_get (_bsddb.c:1349)


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

Comment By: Gregory P. Smith (greg)
Date: 2004-06-14 17:02

Message:
Logged In: YES 
user_id=413

make_key_dbt() will never return with an error leaving a
FREE_DBT(key) necessary.

however looking in depth at the code i believe it would have
been possible to have a leak when using integer keys and
exiting early with an error.  a patch (untested) that should
fix that is attached.  i'll test it out later.

do you have any memleak test cases by any chance?


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

Comment By: alan johnson (chomo)
Date: 2004-06-14 14:11

Message:
Logged In: YES 
user_id=943591

looks like the ones needed
anyway

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-06-13 13:56

Message:
Logged In: YES 
user_id=33168

Greg, just wanted to make sure you saw this.  It seems like
you're the only one working on bsddb these days.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=967763&group_id=5470
From noreply at sourceforge.net  Mon Dec 20 04:22:44 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Dec 20 04:22:48 2004
Subject: [Patches] [ python-Patches-606098 ] fast dictionary lookup by name
Message-ID: <E1CgE8C-0001Sy-P1@sc8-sf-web2.sourceforge.net>

Patches item #606098, was opened at 2002-09-07 13:36
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=606098&group_id=5470

Category: Build
Group: None
>Status: Closed
>Resolution: Out of Date
Priority: 3
Submitted By: Oren Tirosh (orenti)
Assigned to: Guido van Rossum (gvanrossum)
Summary: fast dictionary lookup by name

Initial Comment:
This patch speeds up dictionary lookup when the key
is an interned string.

Test results (Guido's tar from patch #597907)

Before:   
 builtin 2.01
 global 1.57
 local 1.87
 fastlocal 1.02

After:
 builtin 1.78
 global 1.63
 local 1.51
 fastlocal 1.06
  
Not as impressive as the last patch because this
version doesn't use the inline macro yet.

A dummy/negative entry is now defined as me_key !=
NULL and me_value == NULL. A dummy entry also has
me_hash set to -1 to shave a few more cycles in the
search.

Management of negative entries and the interaction
with table resizing still needs more work. If there
is not enough room for a new negative entry it is
simply ignored.

The bottlneck appears to be the first negative
lookup. It starts with a fast search that fails and
then falls back to a slow search and inserts a
negative entry.  This path is significantly slower
than without the patch. Subsequent lookups will be
much faster but many objects are created where
attributes or methods are looked up just once. 
The solution I am considering is to change
lookdict_string to lookdict_interned.  A dictionary
in this state has only interned string keys so the
fast search is guaranteed to produce the correct
result if the lookup key is also an interned string
with no fallback required.  This should also make it
easier to speed up PyDict_SetItem.


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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-19 22:22

Message:
Logged In: YES 
user_id=80475

Most of the benefits of this patch were already obtained by
the newer dict resizing scheme (quarupling size instead of
doubling) which made both successful and unsuccessful
lookups go faster.

Closing this until new research efforts show that additional
improvements are possible.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-12-30 17:42

Message:
Logged In: YES 
user_id=6380

New version of the patch, for current CVS.

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

Comment By: Oren Tirosh (orenti)
Date: 2002-12-30 17:05

Message:
Logged In: YES 
user_id=562624

According to my instrumented version pystone was something like 97.8% 
fastlocal lookups.  
 
I'm afraid I won't be able to continue my work on this patch any time soon. 
If anyone wants to take over I'll be happy to help. 
 

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-12-30 15:59

Message:
Logged In: YES 
user_id=6380

I don't see any improvement with pystone. That doesn't mean
much, but it means I'm not going to do this before releasing
2.3a1.


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-11-15 11:55

Message:
Logged In: YES 
user_id=6380

Assigned to me because it may relate to patch 597907.

But I have no time to sort through this, and it seems Oren's
priorities lie elsewhere. If someone can help out, please do!


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=606098&group_id=5470
From noreply at sourceforge.net  Mon Dec 20 04:25:48 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Dec 20 04:25:59 2004
Subject: [Patches] [ python-Patches-725569 ] Improved output for unittest
	failUnlessEqual
Message-ID: <E1CgEBA-0001YW-Ue@sc8-sf-web2.sourceforge.net>

Patches item #725569, was opened at 2003-04-22 05:33
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725569&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Duncan Booth (duncanb)
>Assigned to: Steve Purcell (purcell)
Summary: Improved output for unittest failUnlessEqual

Initial Comment:
The failUnlessEqual method in unittest.TestCase 
doesn't handle well the case where the objects being 
compared have a long string representation. The 
whole repr for each object is printed no matter how 
long, and no indication is given of where any 
differences occur.

This patch uses difflib on long representations to 
provide a short output that highlights where the first 
difference actually is. It also limits the output for each 
value to fit on a single line (with the differences 
indicated on the line following).

e.g.
FAIL: test_failunlessEqual4 (__main__.Test)
----------------------------------------------------------------------
TestFailed: failUnlessEqual
{'A': 65, 'C': 67, ...0, 'P ': 0, 'R': 82, 'U': 85, 'T': 84, 'W': 
87, 'V': 8...
                   ...    ^^   ^                                            ...
{'A': 65, 'C': 67, ...0, 'S': 83, 'R': 82, 'U': 85, 'T': 84, 'W': 
87, 'V': 8...
                   ...    ^   ^^                                            ...
  File &quot;F:\temp\test.py&quot;, line 59, in test_failunlessEqual4
    self.failUnlessEqual(d2, d1)

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

The attached file contains the changes, assuming that 
patch &quot;722638 Better output for unittest&quot; has already 
been applied.


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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-19 22:25

Message:
Logged In: YES 
user_id=80475

Steve, do you care to pronounce on this?

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-05-06 02:27

Message:
Logged In: YES 
user_id=80475

The patch should wrap &quot;import difflib&quot; in a try/except and 
revert to prior behavior upon an ImportError.  This will 
make sure unittest still runs on old Pythons.

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

Comment By: Duncan Booth (duncanb)
Date: 2003-04-25 05:35

Message:
Logged In: YES 
user_id=74031

Oops. I forgot to test for the case where the string didn't 
need shortening in the middle. New patch uploaded.

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

Comment By: Thomas Heller (theller)
Date: 2003-04-25 05:03

Message:
Logged In: YES 
user_id=11105

There's a bug in your patch:

!     else:
!         x, y = s[:LINELEN+1], t[:LINELEN+1]
!         left = 0

s and t are not defined here (UnboundLocal exception is raised),

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=725569&group_id=5470
From noreply at sourceforge.net  Mon Dec 20 04:49:57 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Dec 20 04:50:01 2004
Subject: [Patches] [ python-Patches-762920 ] API Functions for PyArray
Message-ID: <E1CgEYX-00074o-OO@sc8-sf-web4.sourceforge.net>

Patches item #762920, was opened at 2003-06-29 18:48
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=762920&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ralph (kohanman)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: API Functions for PyArray

Initial Comment:
I'd rather send and recieve PyArrays into my C modules
since I often end up with a foo(int count, type *data)
call anyway.  Sure, there's NumPy for this sort of
dirtywork, but this is so much more convienient.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=762920&group_id=5470
From noreply at sourceforge.net  Mon Dec 20 04:51:33 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Dec 20 04:51:40 2004
Subject: [Patches] [ python-Patches-760990 ] add time elapsed to gc debug
	output
Message-ID: <E1CgEa5-00076b-2K@sc8-sf-web4.sourceforge.net>

Patches item #760990, was opened at 2003-06-26 01:52
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=760990&group_id=5470

Category: Core (C code)
Group: Python 2.3
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: David Jeske (jeske)
Assigned to: Nobody/Anonymous (nobody)
Summary: add time elapsed to gc debug output

Initial Comment:
In debugging Python GC actions, it's really useful to 
know the amount of time Python spends doing the GC 
cycle (i.e. the pause time). 

I made a quick change to do this, and I've attached the 
patch. It needs to be fixed to be portable. I wanted to 
just call floattime() from timemodule.c, but it wasn't 
clear how to do this from gcmodule.c. It didn't seem like 
the right thing to do to copy the floattime() code from 
timemodule.c. I figured I would leave this simple detail to 
the experts.

My patch adds the gc time and the max gc time to 
the &quot;done&quot; line when debugging is enabled, making it look 
like this:

gc: collecting generation 0...
gc: objects in each generation: 702 5608 72421
gc: done. (0.000267006 s, max 0.151359 s)

I'd like to see this adopted in the gc module.

I also think it would be useful if there were a debugging 
mode to print out gc sweeps which take longer than a 
certain pause time, but I didn't make this change. 
However, it's possible to derive this from the logs.

(i.e. gc.debug_pauses(0.2) would print out a line for 
each gc pause over 0.2 seconds)


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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-19 22:51

Message:
Logged In: YES 
user_id=80475

Closing due to inaction.

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

Comment By: Tim Peters (tim_one)
Date: 2003-06-26 19:47

Message:
Logged In: YES 
user_id=31435

There's no uploaded file!  You have to check the
checkbox labeled &quot;Check to Upload &amp; Attach File&quot;
when you upload a file. In addition, even if you
*did* check this checkbox, a bug in SourceForge
prevents attaching a file when *creating* an issue.

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=305470&aid=760990&group_id=5470
From noreply at sourceforge.net  Mon Dec 20 04:53:13 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Dec 20 04:53:23 2004
Subject: [Patches] [ python-Patches-763580 ] Minor enhancements to Variable
	class
Message-ID: <E1CgEbh-00078n-9q@sc8-sf-web4.sourceforge.net>

Patches item #763580, was opened at 2003-06-30 19:18
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=763580&group_id=5470

Category: Tkinter
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Russell Owen (reowen)
>Assigned to: Martin v. L?wis (loewis)
Summary: Minor enhancements to Variable class

Initial Comment:
Here are two enhancements to the Variable class (and subclasses):

1) Variables now have a &quot;name&quot; argument. This works just like the name argument on almost every other Tkinter class. Its primary purpose is to allow the user to create a new Tkinter Variable given its tk name. 

Justification: at present there is no reasonable way to do this. One can create a new Tkinter Variable and then assign its name property, but that relies on knowing about internals and it has the ugly side effect of creating an unused tk variable

I admit that setvar and getvar can be used to work around the problem, but sometimes it's nicer to use a Tkinter Variable and often it's not convenient to pass the original Variable around to where it's needed.

One can get an original Tkinter widget back again given the corresponding tk widget's name. It's time to allow this for Tkinter Variables (and tkFont.Font objects, but that's a separate issue I submitted as a bug report with associated suggested simple fix).

2) Variables now have a &quot;value&quot; argument to specify the initial value. This shortens:
  avar = StringVar()
  avar.set(&quot;desired value&quot;)
to:
  avar = StringVar(&quot;desired value&quot;)

Justification: it's useful. It's also harmless in that it will not break any existing code. I think one can even do something like this in tcl (i.e. define a variable and set it at the same time) and it's certainly a normal thing to do in Python itself.

-- Russell

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-19 22:53

Message:
Logged In: YES 
user_id=80475

Martin, do you have any thoughts on this one?

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

Comment By: Russell Owen (reowen)
Date: 2003-07-01 12:30

Message:
Logged In: YES 
user_id=431773

Replacement patch. The difference is what to do if value is supplied and the variable already exists (not something existing users would ever see unless they were doing nasty stuff directly in tcl).  The old version treated value as an initial value, this new version always honors value if it is specified. I think this will be less surprising to the user (in those rare cases where it matters).

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=763580&group_id=5470
From noreply at sourceforge.net  Mon Dec 20 04:55:08 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Dec 20 04:55:41 2004
Subject: [Patches] [ python-Patches-810023 ] Fix for off-by-one bug in
	urllib.URLopener.retrieve
Message-ID: <E1CgEdY-0007C2-2C@sc8-sf-web4.sourceforge.net>

Patches item #810023, was opened at 2003-09-21 00:13
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=810023&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: J. Lewis Muir (jlmuir)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: Fix for off-by-one bug in urllib.URLopener.retrieve

Initial Comment:
This patch fixes an off-by-one bug in the reporthook part of 
urllib.URLopener.retrieve and adds test cases to verify the 
fix.

The retrieve method reports reading one more block than it 
actually does. Here's an example. The file is empty. I expect 
the initial reporthook call on establishment of the network 
connection but not an additional call since the file is empty 
(no block was read):

&gt;&gt;&gt; import urllib
&gt;&gt;&gt; def reporter(count, blockSize, fileSize):
...     print &quot;c: %i, bs: %i, fs: %i&quot; % (count, blockSize, 
fileSize)
...
&gt;&gt;&gt; srcFile = file(&quot;/tmp/empty.txt&quot;, &quot;wb&quot;)
&gt;&gt;&gt; srcFile.close()
&gt;&gt;&gt; urllib.urlretrieve(&quot;file:///tmp/empty.txt&quot;, &quot;/tmp/new-
empty.txt&quot;, reporter)
c: 0, bs: 8192, fs: 0
c: 1, bs: 8192, fs: 0
('/tmp/new-empty.txt', &lt;mimetools.Message instance at 
0x5a4f58&gt;)
&gt;&gt;&gt;

As a second example, if the file contains 1 byte, the retrieve 
method claims it read 2 blocks when it really only read 1:

&gt;&gt;&gt; srcFile = file(&quot;/tmp/empty.txt&quot;, &quot;wb&quot;)
&gt;&gt;&gt; srcFile.write(&quot;x&quot;)
&gt;&gt;&gt; srcFile.close()
&gt;&gt;&gt; urllib.urlretrieve(&quot;file:///tmp/empty.txt&quot;, &quot;/tmp/new-
empty.txt&quot;, reporter)
c: 0, bs: 8192, fs: 1
c: 1, bs: 8192, fs: 1
c: 2, bs: 8192, fs: 1
('/tmp/new-empty.txt', &lt;mimetools.Message instance at 
0x5a50d0&gt;)
&gt;&gt;&gt;

This patch also includes some changes to 
test_urllib.urlretrieve_FileTests (where I added the test 
cases) to support creating more than one temporary file and 
making sure any created temporary files get deleted when 
the test case fixture is torn down.


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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-19 22:55

Message:
Logged In: YES 
user_id=80475

Will review and apply after Xmas vacation.

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

Comment By: Titus Brown (titus)
Date: 2004-12-19 03:51

Message:
Logged In: YES 
user_id=23486

Patch needed slight modification to work against current HEAD; new 
patch at 

http://issola.caltech.edu/~t/transfer/transfer/patch-810023-
reporthook.diff

The new regression tests look reasonable.  I verified that the new 
regression tests FAILED against old urllib.py, and worked against patched 
urllib.py.  Recommend apply.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=810023&group_id=5470
From noreply at sourceforge.net  Mon Dec 20 04:57:45 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Dec 20 04:57:48 2004
Subject: [Patches] [ python-Patches-847857 ] Extend struct.unpack to produce
	nested tuples
Message-ID: <E1CgEg5-0007I0-4t@sc8-sf-web4.sourceforge.net>

Patches item #847857, was opened at 2003-11-23 17:24
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=847857&group_id=5470

Category: Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew F. Barnes (mfbarnes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Extend struct.unpack to produce nested tuples

Initial Comment:
This patch extends the struct.unpack format notation to
be able to express groups of data with parentheses.

For example:

&gt;&gt;&gt; data = struct.pack('iiii', 1, 2, 3, 4)
&gt;&gt;&gt; struct.unpack('i(ii)i', data)
(1, (2, 3), 4)

Integral repeat counts can also be applied to groups.

&gt;&gt;&gt; struct.unpack('2(ii)', data)
((1, 2), (3, 4))

In addition, struct.calcsize also handles parentheses
in format strings correctly.

&gt;&gt;&gt; struct.calcsize('4(ii)')
32

No changes were made to struct.pack.  It still treats
parentheses as illegal format characters.

I have not yet updated any documentation or tests
associated with struct.calcsize or struct.unpack.

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-19 22:57

Message:
Logged In: YES 
user_id=80475

What are the use cases to warrant this change?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=847857&group_id=5470
From noreply at sourceforge.net  Mon Dec 20 04:58:53 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Dec 20 04:59:06 2004
Subject: [Patches] [ python-Patches-851459 ] Argument passing from
	/usr/bin/idle2.3 to idle.py
Message-ID: <E1CgEhB-0007Jj-7J@sc8-sf-web4.sourceforge.net>

Patches item #851459, was opened at 2003-11-30 01:27
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=851459&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Humberto Di?genes (virtualspirit)
>Assigned to: Kurt B. Kaiser (kbk)
Summary: Argument passing from /usr/bin/idle2.3 to idle.py

Initial Comment:
/usr/bin/idle2.3 wrapper (from the 2.3.2-1pydotorg rpm) ignores 
command-line arguments when calling idle.py. Fixed only by adding 
&quot;$*&quot; to the script.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=851459&group_id=5470
From noreply at sourceforge.net  Mon Dec 20 05:05:01 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Dec 20 05:05:06 2004
Subject: [Patches] [ python-Patches-951915 ] fix bug in StringIO.truncate -
	length not changed
Message-ID: <E1CgEn7-0000aj-Ep@sc8-sf-web3.sourceforge.net>

Patches item #951915, was opened at 2004-05-11 09:07
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=951915&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 6
Submitted By: David Fraser (davidfraser)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: fix bug in StringIO.truncate - length not changed

Initial Comment:
If truncate() is called on a StringIO object, the
length is not changed, so that seek(0, 2) calls will go
beyond the correct end of the file.
This patch adds a line to update the length, and a test
to the test method that checks that it works.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-06-09 13:16

Message:
Logged In: YES 
user_id=80475

To avoid repeated string concatenation, the underlying data 
structure could be changed to an array.array object with a 
character typecode.

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

Comment By: Armin Rigo (arigo)
Date: 2004-05-12 11:59

Message:
Logged In: YES 
user_id=4771

David, it seems to me that f.truncate(huge_value) would incorrectly set f.len to huge_value with your patch.  Here is another patch fixing this and the other details I mentioned.  I also put the new test into test_StringIO.py instead.  Perhaps we should remove the if __name__=='__main__' bit, although it is nice as a quick example.

This makes me wonder if there is any reason left for which cStringIOs aren't subclassable, or if we care.

Alternatively, it makes me wonder if there wouldn't be a more efficient implementation of StringIO.py that would entierely avoid concatenating large strings, or if we care.  This might make StringIO at least as efficient as cStringIO for some cases, e.g. when writing a lot of strings a few kb each, by avoiding the copy overhead.

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

Comment By: Armin Rigo (arigo)
Date: 2004-05-12 10:34

Message:
Logged In: YES 
user_id=4771

StringIO.py needs to be reviewed.  I could spot several other (though more minor) problems in a couple of minutes.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=951915&group_id=5470
From noreply at sourceforge.net  Mon Dec 20 07:43:56 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Dec 20 07:44:04 2004
Subject: [Patches] [ python-Patches-847857 ] Extend struct.unpack to produce
	nested tuples
Message-ID: <E1CgHGu-0003UJ-SH@sc8-sf-web4.sourceforge.net>

Patches item #847857, was opened at 2003-11-23 16:24
Message generated for change (Comment added) made by mfbarnes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=847857&group_id=5470

Category: Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew F. Barnes (mfbarnes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Extend struct.unpack to produce nested tuples

Initial Comment:
This patch extends the struct.unpack format notation to
be able to express groups of data with parentheses.

For example:

&gt;&gt;&gt; data = struct.pack('iiii', 1, 2, 3, 4)
&gt;&gt;&gt; struct.unpack('i(ii)i', data)
(1, (2, 3), 4)

Integral repeat counts can also be applied to groups.

&gt;&gt;&gt; struct.unpack('2(ii)', data)
((1, 2), (3, 4))

In addition, struct.calcsize also handles parentheses
in format strings correctly.

&gt;&gt;&gt; struct.calcsize('4(ii)')
32

No changes were made to struct.pack.  It still treats
parentheses as illegal format characters.

I have not yet updated any documentation or tests
associated with struct.calcsize or struct.unpack.

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

>Comment By: Matthew F. Barnes (mfbarnes)
Date: 2004-12-20 00:43

Message:
Logged In: YES 
user_id=843448

I suggested this change on Python-Dev last year
(http://mail.python.org/pipermail/python-dev/2003-November/040391.html).
 The use case I put forth at the time was as follows:

Use Case:  I have a program written in C that contains a
bunch of aggregate data structures (arrays of structs,
structs containing arrays, etc.) and I'm transmitting these
structures over a socket connection to a Python program that
then unpacks the data using the struct module.  Problem is
that I have to unpack the incoming data as
a flat sequence of data elements, and then repartition the
sequence into nested sequences to better reflect how the
data is structured in the C program.  It would be more
convenient to express these groupings as I'm unpacking the
raw data.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-19 21:57

Message:
Logged In: YES 
user_id=80475

What are the use cases to warrant this change?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=847857&group_id=5470
From noreply at sourceforge.net  Mon Dec 20 10:25:19 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Dec 20 10:25:27 2004
Subject: [Patches] [ python-Patches-951915 ] fix bug in StringIO.truncate -
	length not changed
Message-ID: <E1CgJn5-0001lf-Jv@sc8-sf-web3.sourceforge.net>

Patches item #951915, was opened at 2004-05-11 14:07
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=951915&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 6
Submitted By: David Fraser (davidfraser)
Assigned to: Raymond Hettinger (rhettinger)
Summary: fix bug in StringIO.truncate - length not changed

Initial Comment:
If truncate() is called on a StringIO object, the
length is not changed, so that seek(0, 2) calls will go
beyond the correct end of the file.
This patch adds a line to update the length, and a test
to the test method that checks that it works.

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

>Comment By: Armin Rigo (arigo)
Date: 2004-12-20 09:25

Message:
Logged In: YES 
user_id=4771

The current implementation already delays concatenation and typically only uses a single ''.join() to build the final buffer, so it's reasonably efficient.

What I was musing about in my previous post is a way to entierely avoid the copy overhead and let all operations deal directly with a list of strings as the basic data structure (or maybe a tree of strings, or some more advanced structure).  Repeated writes of very small strings should probably still be consolidated into larger strings (e.g. of a few KBs) but no single huge string (or array) needs to be built at all.

But this is just musing aloud, and this thread is about a bug in StringIO.py, so we should probably focus on fixing it...

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-06-09 18:16

Message:
Logged In: YES 
user_id=80475

To avoid repeated string concatenation, the underlying data 
structure could be changed to an array.array object with a 
character typecode.

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

Comment By: Armin Rigo (arigo)
Date: 2004-05-12 16:59

Message:
Logged In: YES 
user_id=4771

David, it seems to me that f.truncate(huge_value) would incorrectly set f.len to huge_value with your patch.  Here is another patch fixing this and the other details I mentioned.  I also put the new test into test_StringIO.py instead.  Perhaps we should remove the if __name__=='__main__' bit, although it is nice as a quick example.

This makes me wonder if there is any reason left for which cStringIOs aren't subclassable, or if we care.

Alternatively, it makes me wonder if there wouldn't be a more efficient implementation of StringIO.py that would entierely avoid concatenating large strings, or if we care.  This might make StringIO at least as efficient as cStringIO for some cases, e.g. when writing a lot of strings a few kb each, by avoiding the copy overhead.

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

Comment By: Armin Rigo (arigo)
Date: 2004-05-12 15:34

Message:
Logged In: YES 
user_id=4771

StringIO.py needs to be reviewed.  I could spot several other (though more minor) problems in a couple of minutes.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=951915&group_id=5470
From noreply at sourceforge.net  Mon Dec 20 10:58:08 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Dec 20 10:59:18 2004
Subject: [Patches] [ python-Patches-951915 ] fix bug in StringIO.truncate -
	length not changed
Message-ID: <E1CgKIq-0000wh-3z@sc8-sf-web4.sourceforge.net>

Patches item #951915, was opened at 2004-05-11 16:07
Message generated for change (Comment added) made by davidfraser
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=951915&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 6
Submitted By: David Fraser (davidfraser)
Assigned to: Raymond Hettinger (rhettinger)
Summary: fix bug in StringIO.truncate - length not changed

Initial Comment:
If truncate() is called on a StringIO object, the
length is not changed, so that seek(0, 2) calls will go
beyond the correct end of the file.
This patch adds a line to update the length, and a test
to the test method that checks that it works.

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

>Comment By: David Fraser (davidfraser)
Date: 2004-12-20 11:58

Message:
Logged In: YES 
user_id=221678

Armin, are there any problems with your refined patch that
you are aware of? Once that is applied the other issues
could be looked at.

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

Comment By: Armin Rigo (arigo)
Date: 2004-12-20 11:25

Message:
Logged In: YES 
user_id=4771

The current implementation already delays concatenation and typically only uses a single ''.join() to build the final buffer, so it's reasonably efficient.

What I was musing about in my previous post is a way to entierely avoid the copy overhead and let all operations deal directly with a list of strings as the basic data structure (or maybe a tree of strings, or some more advanced structure).  Repeated writes of very small strings should probably still be consolidated into larger strings (e.g. of a few KBs) but no single huge string (or array) needs to be built at all.

But this is just musing aloud, and this thread is about a bug in StringIO.py, so we should probably focus on fixing it...

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-06-09 20:16

Message:
Logged In: YES 
user_id=80475

To avoid repeated string concatenation, the underlying data 
structure could be changed to an array.array object with a 
character typecode.

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

Comment By: Armin Rigo (arigo)
Date: 2004-05-12 18:59

Message:
Logged In: YES 
user_id=4771

David, it seems to me that f.truncate(huge_value) would incorrectly set f.len to huge_value with your patch.  Here is another patch fixing this and the other details I mentioned.  I also put the new test into test_StringIO.py instead.  Perhaps we should remove the if __name__=='__main__' bit, although it is nice as a quick example.

This makes me wonder if there is any reason left for which cStringIOs aren't subclassable, or if we care.

Alternatively, it makes me wonder if there wouldn't be a more efficient implementation of StringIO.py that would entierely avoid concatenating large strings, or if we care.  This might make StringIO at least as efficient as cStringIO for some cases, e.g. when writing a lot of strings a few kb each, by avoiding the copy overhead.

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

Comment By: Armin Rigo (arigo)
Date: 2004-05-12 17:34

Message:
Logged In: YES 
user_id=4771

StringIO.py needs to be reviewed.  I could spot several other (though more minor) problems in a couple of minutes.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=951915&group_id=5470
From noreply at sourceforge.net  Mon Dec 20 13:55:16 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Dec 20 13:55:21 2004
Subject: [Patches] [ python-Patches-951915 ] fix bug in StringIO.truncate -
	length not changed
Message-ID: <E1CgN4G-0007j3-PH@sc8-sf-web4.sourceforge.net>

Patches item #951915, was opened at 2004-05-11 14:07
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=951915&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 6
Submitted By: David Fraser (davidfraser)
Assigned to: Raymond Hettinger (rhettinger)
Summary: fix bug in StringIO.truncate - length not changed

Initial Comment:
If truncate() is called on a StringIO object, the
length is not changed, so that seek(0, 2) calls will go
beyond the correct end of the file.
This patch adds a line to update the length, and a test
to the test method that checks that it works.

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

>Comment By: Armin Rigo (arigo)
Date: 2004-12-20 12:55

Message:
Logged In: YES 
user_id=4771

The patch should be reviewed by someone and then applied if no further issue is discovered, I guess.

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

Comment By: David Fraser (davidfraser)
Date: 2004-12-20 09:58

Message:
Logged In: YES 
user_id=221678

Armin, are there any problems with your refined patch that
you are aware of? Once that is applied the other issues
could be looked at.

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

Comment By: Armin Rigo (arigo)
Date: 2004-12-20 09:25

Message:
Logged In: YES 
user_id=4771

The current implementation already delays concatenation and typically only uses a single ''.join() to build the final buffer, so it's reasonably efficient.

What I was musing about in my previous post is a way to entierely avoid the copy overhead and let all operations deal directly with a list of strings as the basic data structure (or maybe a tree of strings, or some more advanced structure).  Repeated writes of very small strings should probably still be consolidated into larger strings (e.g. of a few KBs) but no single huge string (or array) needs to be built at all.

But this is just musing aloud, and this thread is about a bug in StringIO.py, so we should probably focus on fixing it...

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-06-09 18:16

Message:
Logged In: YES 
user_id=80475

To avoid repeated string concatenation, the underlying data 
structure could be changed to an array.array object with a 
character typecode.

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

Comment By: Armin Rigo (arigo)
Date: 2004-05-12 16:59

Message:
Logged In: YES 
user_id=4771

David, it seems to me that f.truncate(huge_value) would incorrectly set f.len to huge_value with your patch.  Here is another patch fixing this and the other details I mentioned.  I also put the new test into test_StringIO.py instead.  Perhaps we should remove the if __name__=='__main__' bit, although it is nice as a quick example.

This makes me wonder if there is any reason left for which cStringIOs aren't subclassable, or if we care.

Alternatively, it makes me wonder if there wouldn't be a more efficient implementation of StringIO.py that would entierely avoid concatenating large strings, or if we care.  This might make StringIO at least as efficient as cStringIO for some cases, e.g. when writing a lot of strings a few kb each, by avoiding the copy overhead.

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

Comment By: Armin Rigo (arigo)
Date: 2004-05-12 15:34

Message:
Logged In: YES 
user_id=4771

StringIO.py needs to be reviewed.  I could spot several other (though more minor) problems in a couple of minutes.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=951915&group_id=5470
From noreply at sourceforge.net  Mon Dec 20 14:00:25 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Dec 20 14:00:28 2004
Subject: [Patches] [ python-Patches-1068277 ] os.path.exists returns False
	if no permission
Message-ID: <E1CgN9F-0004QF-Bk@sc8-sf-web2.sourceforge.net>

Patches item #1068277, was opened at 2004-11-17 21:20
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1068277&group_id=5470

Category: Documentation
Group: Python 2.5
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Robert Brewer (aminusfu)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.path.exists returns False if no permission

Initial Comment:
A single new sentence for os.path.exists description,
which makes it clear that it may return False even if
the path actually exists.

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

>Comment By: Armin Rigo (arigo)
Date: 2004-12-20 13:00

Message:
Logged In: YES 
user_id=4771

I don't see an obvious way to do it, but shouldn't os.path.exists() try harder to return the expected answer?

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2004-12-05 06:56

Message:
Logged In: YES 
user_id=3066

This should be committed on the trunk and release24-maint
branch.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1068277&group_id=5470
From noreply at sourceforge.net  Mon Dec 20 15:53:03 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Dec 20 15:53:06 2004
Subject: [Patches] [ python-Patches-1068277 ] os.path.exists returns False
	if no permission
Message-ID: <E1CgOuF-0000Gf-51@sc8-sf-web1.sourceforge.net>

Patches item #1068277, was opened at 2004-11-17 21:20
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1068277&group_id=5470

Category: Documentation
Group: Python 2.5
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Robert Brewer (aminusfu)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.path.exists returns False if no permission

Initial Comment:
A single new sentence for os.path.exists description,
which makes it clear that it may return False even if
the path actually exists.

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

>Comment By: Armin Rigo (arigo)
Date: 2004-12-20 14:53

Message:
Logged In: YES 
user_id=4771

Actually, what about the following ?

    def exists(path):
        return os.access(path, os.F_OK)

It returns True on all existing directory entries apart from broken links and links pointing within unreadable directories.

I don't see any similar nice solution for the more recent os.path.lexists()...  There are cases where the above exists() returns True but the current lexists() returns False, which is strange because lexists() is supposed to be a more permissive version of exists().

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

Comment By: Armin Rigo (arigo)
Date: 2004-12-20 13:00

Message:
Logged In: YES 
user_id=4771

I don't see an obvious way to do it, but shouldn't os.path.exists() try harder to return the expected answer?

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2004-12-05 06:56

Message:
Logged In: YES 
user_id=3066

This should be committed on the trunk and release24-maint
branch.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1068277&group_id=5470
From noreply at sourceforge.net  Mon Dec 20 21:53:23 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Dec 20 21:53:31 2004
Subject: [Patches] [ python-Patches-851459 ] Argument passing from
	/usr/bin/idle2.3 to idle.py
Message-ID: <E1CgUWx-00025s-6c@sc8-sf-web2.sourceforge.net>

Patches item #851459, was opened at 2003-11-30 01:27
Message generated for change (Comment added) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=851459&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Humberto Di?genes (virtualspirit)
>Assigned to: Sean Reifschneider (jafo)
Summary: Argument passing from /usr/bin/idle2.3 to idle.py

Initial Comment:
/usr/bin/idle2.3 wrapper (from the 2.3.2-1pydotorg rpm) ignores 
command-line arguments when calling idle.py. Fixed only by adding 
&quot;$*&quot; to the script.

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

>Comment By: Kurt B. Kaiser (kbk)
Date: 2004-12-20 15:53

Message:
Logged In: YES 
user_id=149084

Appears to be an issue with the Tools section of 
..../Misc/RPM/python-2.4.spec
Backport to release23-maint

Assigning to Sean Reifschneider

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=851459&group_id=5470
From noreply at sourceforge.net  Tue Dec 21 00:01:53 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Dec 21 00:01:56 2004
Subject: [Patches] [ python-Patches-1088716 ] msi.py patch to build mingw
	library
Message-ID: <E1CgWXJ-0002PG-Dd@sc8-sf-web4.sourceforge.net>

Patches item #1088716, was opened at 2004-12-20 23:01
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1088716&group_id=5470

Category: Build
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Paul Moore (pmoore)
Assigned to: Nobody/Anonymous (nobody)
Summary: msi.py patch to build mingw library

Initial Comment:
The attached patch updates the MSI build process to
build a mingw-compatible libpythonXX.a and install it
in the Python "libs" directory.

The additional step requires 2 executables, nm and
dlltool, to be available on PATH. These are part of the
binutils package of either mingw or cygwin. The build
should warn, and skip the inclusion of libpythonXX.a,
if the tools are not available.

Note: I do not have a Python build environment (no
Visual Studio .NET) and so cannot test this patch fully
- the msi.py script depends on VS.NET registry keys
that aren't available on my PC. I've checked that
libpythonXX.a is built correctly, but I can't ensure
that the MSI file gets built properly :-( Assistance in
testing this would be appreciated...

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1088716&group_id=5470
From noreply at sourceforge.net  Tue Dec 21 00:05:01 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Dec 21 00:05:15 2004
Subject: [Patches] [ python-Patches-1088716 ] msi.py patch to build mingw
	library
Message-ID: <E1CgWaL-0008BL-Mn@sc8-sf-web2.sourceforge.net>

Patches item #1088716, was opened at 2004-12-20 23:01
Message generated for change (Settings changed) made by pmoore
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1088716&group_id=5470

Category: Build
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Paul Moore (pmoore)
>Assigned to: Martin v. L?wis (loewis)
Summary: msi.py patch to build mingw library

Initial Comment:
The attached patch updates the MSI build process to
build a mingw-compatible libpythonXX.a and install it
in the Python "libs" directory.

The additional step requires 2 executables, nm and
dlltool, to be available on PATH. These are part of the
binutils package of either mingw or cygwin. The build
should warn, and skip the inclusion of libpythonXX.a,
if the tools are not available.

Note: I do not have a Python build environment (no
Visual Studio .NET) and so cannot test this patch fully
- the msi.py script depends on VS.NET registry keys
that aren't available on my PC. I've checked that
libpythonXX.a is built correctly, but I can't ensure
that the MSI file gets built properly :-( Assistance in
testing this would be appreciated...

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1088716&group_id=5470
From noreply at sourceforge.net  Tue Dec 21 00:57:05 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Dec 21 00:57:08 2004
Subject: [Patches] [ python-Patches-951915 ] fix bug in StringIO.truncate -
	length not changed
Message-ID: <E1CgXOj-0007u0-DN@sc8-sf-web3.sourceforge.net>

Patches item #951915, was opened at 2004-05-11 09:07
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=951915&group_id=5470

Category: Library (Lib)
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 6
Submitted By: David Fraser (davidfraser)
Assigned to: Raymond Hettinger (rhettinger)
Summary: fix bug in StringIO.truncate - length not changed

Initial Comment:
If truncate() is called on a StringIO object, the
length is not changed, so that seek(0, 2) calls will go
beyond the correct end of the file.
This patch adds a line to update the length, and a test
to the test method that checks that it works.

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-20 18:57

Message:
Logged In: YES 
user_id=80475

Applied as Lib/StringIO.py 1.38 and 1.37.2.1

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

Comment By: Armin Rigo (arigo)
Date: 2004-12-20 07:55

Message:
Logged In: YES 
user_id=4771

The patch should be reviewed by someone and then applied if no further issue is discovered, I guess.

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

Comment By: David Fraser (davidfraser)
Date: 2004-12-20 04:58

Message:
Logged In: YES 
user_id=221678

Armin, are there any problems with your refined patch that
you are aware of? Once that is applied the other issues
could be looked at.

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

Comment By: Armin Rigo (arigo)
Date: 2004-12-20 04:25

Message:
Logged In: YES 
user_id=4771

The current implementation already delays concatenation and typically only uses a single ''.join() to build the final buffer, so it's reasonably efficient.

What I was musing about in my previous post is a way to entierely avoid the copy overhead and let all operations deal directly with a list of strings as the basic data structure (or maybe a tree of strings, or some more advanced structure).  Repeated writes of very small strings should probably still be consolidated into larger strings (e.g. of a few KBs) but no single huge string (or array) needs to be built at all.

But this is just musing aloud, and this thread is about a bug in StringIO.py, so we should probably focus on fixing it...

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-06-09 13:16

Message:
Logged In: YES 
user_id=80475

To avoid repeated string concatenation, the underlying data 
structure could be changed to an array.array object with a 
character typecode.

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

Comment By: Armin Rigo (arigo)
Date: 2004-05-12 11:59

Message:
Logged In: YES 
user_id=4771

David, it seems to me that f.truncate(huge_value) would incorrectly set f.len to huge_value with your patch.  Here is another patch fixing this and the other details I mentioned.  I also put the new test into test_StringIO.py instead.  Perhaps we should remove the if __name__=='__main__' bit, although it is nice as a quick example.

This makes me wonder if there is any reason left for which cStringIOs aren't subclassable, or if we care.

Alternatively, it makes me wonder if there wouldn't be a more efficient implementation of StringIO.py that would entierely avoid concatenating large strings, or if we care.  This might make StringIO at least as efficient as cStringIO for some cases, e.g. when writing a lot of strings a few kb each, by avoiding the copy overhead.

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

Comment By: Armin Rigo (arigo)
Date: 2004-05-12 10:34

Message:
Logged In: YES 
user_id=4771

StringIO.py needs to be reviewed.  I could spot several other (though more minor) problems in a couple of minutes.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=951915&group_id=5470
From noreply at sourceforge.net  Tue Dec 21 01:00:04 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Dec 21 01:00:13 2004
Subject: [Patches] [ python-Patches-1062060 ] fix for 1016880
	urllib.urlretrieve silently truncates dwnld
Message-ID: <E1CgXRc-0001ZQ-U3@sc8-sf-web1.sourceforge.net>

Patches item #1062060, was opened at 2004-11-07 15:15
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062060&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Irmen de Jong (irmen)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix for 1016880 urllib.urlretrieve silently truncates dwnld

Initial Comment:
The patch makes urllib.urlretrieve raise an IOError if
the actual download size is different from the expected
size (taken from the content-length header). 

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-20 19:00

Message:
Logged In: YES 
user_id=80475

Irmin, please attach the new patch.

If you're having trouble with the docs, that's fine, just
include the text you want changed.

Do include tests with your patch.

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

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-12-06 16:48

Message:
Logged In: YES 
user_id=469548

Sorry Irmen, I'm a bit late with this, but now is the time
to get new "features" checked into the trunk. Could you add
a doc patch that explains the behavior as you did in your
previous message and a tests patch? I can check it in then.

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

Comment By: Irmen de Jong (irmen)
Date: 2004-11-07 15:54

Message:
Logged In: YES 
user_id=129426

NOTE:
urllib.patch2 may be a bit better. It fixes a misspelling,
and also is more relaxed about a 'wrong' download size.
To be more precise: it treats content-length as a lower
bound (just like wget and firefox appear to do). So if
there's more data to read, it  reads more data, but if less
data is available, it gives an IOError

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062060&group_id=5470
From noreply at sourceforge.net  Tue Dec 21 01:00:26 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Dec 21 01:00:31 2004
Subject: [Patches] [ python-Patches-1062060 ] fix for 1016880
	urllib.urlretrieve silently truncates dwnld
Message-ID: <E1CgXRy-000811-FR@sc8-sf-web3.sourceforge.net>

Patches item #1062060, was opened at 2004-11-07 15:15
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062060&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
>Priority: 6
Submitted By: Irmen de Jong (irmen)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix for 1016880 urllib.urlretrieve silently truncates dwnld

Initial Comment:
The patch makes urllib.urlretrieve raise an IOError if
the actual download size is different from the expected
size (taken from the content-length header). 

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-20 19:00

Message:
Logged In: YES 
user_id=80475

Irmin, please attach the new patch.

If you're having trouble with the docs, that's fine, just
include the text you want changed.

Do include tests with your patch.

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

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-12-06 16:48

Message:
Logged In: YES 
user_id=469548

Sorry Irmen, I'm a bit late with this, but now is the time
to get new "features" checked into the trunk. Could you add
a doc patch that explains the behavior as you did in your
previous message and a tests patch? I can check it in then.

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

Comment By: Irmen de Jong (irmen)
Date: 2004-11-07 15:54

Message:
Logged In: YES 
user_id=129426

NOTE:
urllib.patch2 may be a bit better. It fixes a misspelling,
and also is more relaxed about a 'wrong' download size.
To be more precise: it treats content-length as a lower
bound (just like wget and firefox appear to do). So if
there's more data to read, it  reads more data, but if less
data is available, it gives an IOError

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062060&group_id=5470
From noreply at sourceforge.net  Tue Dec 21 01:29:20 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Dec 21 01:32:36 2004
Subject: [Patches] [ python-Patches-810023 ] Fix for off-by-one bug in
	urllib.URLopener.retrieve
Message-ID: <E1CgXtw-00033e-90@sc8-sf-web1.sourceforge.net>

Patches item #810023, was opened at 2003-09-21 00:13
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=810023&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: J. Lewis Muir (jlmuir)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Fix for off-by-one bug in urllib.URLopener.retrieve

Initial Comment:
This patch fixes an off-by-one bug in the reporthook part of 
urllib.URLopener.retrieve and adds test cases to verify the 
fix.

The retrieve method reports reading one more block than it 
actually does. Here's an example. The file is empty. I expect 
the initial reporthook call on establishment of the network 
connection but not an additional call since the file is empty 
(no block was read):

&gt;&gt;&gt; import urllib
&gt;&gt;&gt; def reporter(count, blockSize, fileSize):
...     print &quot;c: %i, bs: %i, fs: %i&quot; % (count, blockSize, 
fileSize)
...
&gt;&gt;&gt; srcFile = file(&quot;/tmp/empty.txt&quot;, &quot;wb&quot;)
&gt;&gt;&gt; srcFile.close()
&gt;&gt;&gt; urllib.urlretrieve(&quot;file:///tmp/empty.txt&quot;, &quot;/tmp/new-
empty.txt&quot;, reporter)
c: 0, bs: 8192, fs: 0
c: 1, bs: 8192, fs: 0
('/tmp/new-empty.txt', &lt;mimetools.Message instance at 
0x5a4f58&gt;)
&gt;&gt;&gt;

As a second example, if the file contains 1 byte, the retrieve 
method claims it read 2 blocks when it really only read 1:

&gt;&gt;&gt; srcFile = file(&quot;/tmp/empty.txt&quot;, &quot;wb&quot;)
&gt;&gt;&gt; srcFile.write(&quot;x&quot;)
&gt;&gt;&gt; srcFile.close()
&gt;&gt;&gt; urllib.urlretrieve(&quot;file:///tmp/empty.txt&quot;, &quot;/tmp/new-
empty.txt&quot;, reporter)
c: 0, bs: 8192, fs: 1
c: 1, bs: 8192, fs: 1
c: 2, bs: 8192, fs: 1
('/tmp/new-empty.txt', &lt;mimetools.Message instance at 
0x5a50d0&gt;)
&gt;&gt;&gt;

This patch also includes some changes to 
test_urllib.urlretrieve_FileTests (where I added the test 
cases) to support creating more than one temporary file and 
making sure any created temporary files get deleted when 
the test case fixture is torn down.


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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-20 19:29

Message:
Logged In: YES 
user_id=80475

Titus, I'm having difficulty with your link, please attach
the revised patch or just email it to me (python at rcn.com).

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-19 22:55

Message:
Logged In: YES 
user_id=80475

Will review and apply after Xmas vacation.

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

Comment By: Titus Brown (titus)
Date: 2004-12-19 03:51

Message:
Logged In: YES 
user_id=23486

Patch needed slight modification to work against current HEAD; new 
patch at 

http://issola.caltech.edu/~t/transfer/transfer/patch-810023-
reporthook.diff

The new regression tests look reasonable.  I verified that the new 
regression tests FAILED against old urllib.py, and worked against patched 
urllib.py.  Recommend apply.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=810023&group_id=5470
From noreply at sourceforge.net  Tue Dec 21 03:25:31 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Dec 21 03:25:37 2004
Subject: [Patches] [ python-Patches-851459 ] Argument passing from
	/usr/bin/idle2.3 to idle.py
Message-ID: <E1CgZiN-0007PL-Gi@sc8-sf-web2.sourceforge.net>

Patches item #851459, was opened at 2003-11-30 06:27
Message generated for change (Comment added) made by jafo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=851459&group_id=5470

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Humberto Di?genes (virtualspirit)
Assigned to: Sean Reifschneider (jafo)
Summary: Argument passing from /usr/bin/idle2.3 to idle.py

Initial Comment:
/usr/bin/idle2.3 wrapper (from the 2.3.2-1pydotorg rpm) ignores 
command-line arguments when calling idle.py. Fixed only by adding 
&quot;$*&quot; to the script.

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

>Comment By: Sean Reifschneider (jafo)
Date: 2004-12-21 02:25

Message:
Logged In: YES 
user_id=81797

I went ahead and turned this into Python code and called
"execvp", passing the command arguments onto the idle call.
 This way there are no worries about how the shell handles
$* expansion.  The current CVS version results in something
looking like:

#!/usr/bin/env python2.4
import os, sys
os.execvp("/usr/bin/python2.4", ["/usr/bin/python2.4",
"/usr/lib/python2.4/idlelib/idle.py"] + sys.argv[1:])
print "Failed to exec Idle"
sys.exit(1)

(assuming default build settings)

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

Comment By: Kurt B. Kaiser (kbk)
Date: 2004-12-20 20:53

Message:
Logged In: YES 
user_id=149084

Appears to be an issue with the Tools section of 
..../Misc/RPM/python-2.4.spec
Backport to release23-maint

Assigning to Sean Reifschneider

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=851459&group_id=5470
From noreply at sourceforge.net  Tue Dec 21 06:15:48 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Dec 21 06:15:50 2004
Subject: [Patches] [ python-Patches-1088832 ] acknowledge signals in
	non-main threads
Message-ID: <E1CgcNA-0004gS-C3@sc8-sf-web1.sourceforge.net>

Patches item #1088832, was opened at 2004-12-21 00:15
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1088832&group_id=5470

Category: Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Langmead (langmead)
Assigned to: Nobody/Anonymous (nobody)
Summary: acknowledge signals in non-main threads

Initial Comment:
When a thread under Python 2.3 produces a synchronous signal 
(like a SIGSEGV) the signal is blocked and does not get handled by 
the Python interpreter. 

Python 2.4 corrected this behavior and signals sent to a thread are 
acknowledged, and then handled  the signal default behavior unless  
overridden with a signal handler. (in which case the python signal 
handler is run on the main thread.)

This is a patch for Python 2.3 for proper thread/signal behavior 
similar to  <https://sourceforge.net/tracker/?
func=detail&aid=960406&group_id=5470&atid=305470>. (This isn't 
one of the patches attached to the patch ticket, its the changes that 
mwh made in the CVS revisions listed, plus the further corrections 
in later revisions of the affected files.)

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1088832&group_id=5470
From noreply at sourceforge.net  Tue Dec 21 06:17:30 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Dec 21 06:17:35 2004
Subject: [Patches] [ python-Patches-1088832 ] acknowledge signals in
	non-main threads
Message-ID: <E1CgcOo-0006os-03@sc8-sf-web4.sourceforge.net>

Patches item #1088832, was opened at 2004-12-21 00:15
Message generated for change (Comment added) made by langmead
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1088832&group_id=5470

Category: Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Langmead (langmead)
>Assigned to: Michael Hudson (mwh)
Summary: acknowledge signals in non-main threads

Initial Comment:
When a thread under Python 2.3 produces a synchronous signal 
(like a SIGSEGV) the signal is blocked and does not get handled by 
the Python interpreter. 

Python 2.4 corrected this behavior and signals sent to a thread are 
acknowledged, and then handled  the signal default behavior unless  
overridden with a signal handler. (in which case the python signal 
handler is run on the main thread.)

This is a patch for Python 2.3 for proper thread/signal behavior 
similar to  <https://sourceforge.net/tracker/?
func=detail&aid=960406&group_id=5470&atid=305470>. (This isn't 
one of the patches attached to the patch ticket, its the changes that 
mwh made in the CVS revisions listed, plus the further corrections 
in later revisions of the affected files.)

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

>Comment By: Andrew Langmead (langmead)
Date: 2004-12-21 00:17

Message:
Logged In: YES 
user_id=119306

Since mwh did the work for Python 2.4 threading, he might be the best 
person to judge this patch.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1088832&group_id=5470
From noreply at sourceforge.net  Tue Dec 21 15:54:23 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Dec 21 15:54:57 2004
Subject: [Patches] [ python-Patches-1088832 ] acknowledge signals in
	non-main threads
Message-ID: <E1CglP5-0000wK-2P@sc8-sf-web3.sourceforge.net>

Patches item #1088832, was opened at 2004-12-21 05:15
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1088832&group_id=5470

Category: Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Langmead (langmead)
>Assigned to: Anthony Baxter (anthonybaxter)
Summary: acknowledge signals in non-main threads

Initial Comment:
When a thread under Python 2.3 produces a synchronous signal 
(like a SIGSEGV) the signal is blocked and does not get handled by 
the Python interpreter. 

Python 2.4 corrected this behavior and signals sent to a thread are 
acknowledged, and then handled  the signal default behavior unless  
overridden with a signal handler. (in which case the python signal 
handler is run on the main thread.)

This is a patch for Python 2.3 for proper thread/signal behavior 
similar to  <https://sourceforge.net/tracker/?
func=detail&aid=960406&group_id=5470&atid=305470>. (This isn't 
one of the patches attached to the patch ticket, its the changes that 
mwh made in the CVS revisions listed, plus the further corrections 
in later revisions of the affected files.)

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

>Comment By: Michael Hudson (mwh)
Date: 2004-12-21 14:54

Message:
Logged In: YES 
user_id=6656

I'd be a little bit scared about applying this patch to the
2.3 branch, to be honest.  I wonder what Anthony thinks?

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

Comment By: Andrew Langmead (langmead)
Date: 2004-12-21 05:17

Message:
Logged In: YES 
user_id=119306

Since mwh did the work for Python 2.4 threading, he might be the best 
person to judge this patch.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1088832&group_id=5470
From noreply at sourceforge.net  Wed Dec 22 08:06:12 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Dec 22 08:06:17 2004
Subject: [Patches] [ python-Patches-1087808 ] sgmllib.SGMLParser does not
	unescape attribute values; patch
Message-ID: <E1Ch0ZY-00040U-Vj@sc8-sf-web3.sourceforge.net>

Patches item #1087808, was opened at 2004-12-19 06:42
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1087808&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Titus Brown (titus)
Assigned to: Nobody/Anonymous (nobody)
Summary: sgmllib.SGMLParser does not unescape attribute values; patch

Initial Comment:
for example, in a form parsed by htmllib.HTMLParser (based on 
SGMLParser),

<option value="5&quot; big"> 5&quot; big

the value will not be unescaped to 5" while the printed
option will be.

Note that this behavior differs from that of 
HTMLParser.HTMLParser, which does a fine job.

See attached test script/test input for an example.

See attached patch for a fix: essentially I copied the code directly 
from HTMLParser.HTMLParser.

I don't think this patch should break anything; I can't imagine 
people were relying on this behavior!


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

Comment By: Martin v. L?wis (loewis)
Date: 2004-12-22 08:06

Message:
Logged In: YES 
user_id=21627

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file. In addition, even if you
*did* check this checkbox, a bug in SourceForge
prevents attaching a file when *creating* an issue.

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=305470&aid=1087808&group_id=5470
From noreply at sourceforge.net  Wed Dec 22 08:06:54 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Dec 22 08:06:56 2004
Subject: [Patches] [ python-Patches-1087808 ] sgmllib.SGMLParser does not
	unescape attribute values; patch
Message-ID: <E1Ch0aE-0007bZ-4A@sc8-sf-web2.sourceforge.net>

Patches item #1087808, was opened at 2004-12-19 06:42
Message generated for change (Settings changed) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1087808&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
>Priority: 7
Submitted By: Titus Brown (titus)
>Assigned to: Martin v. L?wis (loewis)
Summary: sgmllib.SGMLParser does not unescape attribute values; patch

Initial Comment:
for example, in a form parsed by htmllib.HTMLParser (based on 
SGMLParser),

<option value="5&quot; big"> 5&quot; big

the value will not be unescaped to 5" while the printed
option will be.

Note that this behavior differs from that of 
HTMLParser.HTMLParser, which does a fine job.

See attached test script/test input for an example.

See attached patch for a fix: essentially I copied the code directly 
from HTMLParser.HTMLParser.

I don't think this patch should break anything; I can't imagine 
people were relying on this behavior!


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

Comment By: Martin v. L?wis (loewis)
Date: 2004-12-22 08:06

Message:
Logged In: YES 
user_id=21627

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file. In addition, even if you
*did* check this checkbox, a bug in SourceForge
prevents attaching a file when *creating* an issue.

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=305470&aid=1087808&group_id=5470
From noreply at sourceforge.net  Wed Dec 22 08:14:00 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Dec 22 08:14:08 2004
Subject: [Patches] [ python-Patches-1087808 ] sgmllib.SGMLParser does not
	unescape attribute values; patch
Message-ID: <E1Ch0h6-0007oR-Au@sc8-sf-web2.sourceforge.net>

Patches item #1087808, was opened at 2004-12-18 21:42
Message generated for change (Comment added) made by titus
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1087808&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 7
Submitted By: Titus Brown (titus)
Assigned to: Martin v. L?wis (loewis)
Summary: sgmllib.SGMLParser does not unescape attribute values; patch

Initial Comment:
for example, in a form parsed by htmllib.HTMLParser (based on 
SGMLParser),

<option value="5&quot; big"> 5&quot; big

the value will not be unescaped to 5" while the printed
option will be.

Note that this behavior differs from that of 
HTMLParser.HTMLParser, which does a fine job.

See attached test script/test input for an example.

See attached patch for a fix: essentially I copied the code directly 
from HTMLParser.HTMLParser.

I don't think this patch should break anything; I can't imagine 
people were relying on this behavior!


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

>Comment By: Titus Brown (titus)
Date: 2004-12-21 23:13

Message:
Logged In: YES 
user_id=23486

Whoops.  Dangitall.

Also at

http://issola.caltech.edu/~t/transfer/sgmllib.diff



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

Comment By: Martin v. L?wis (loewis)
Date: 2004-12-21 23:06

Message:
Logged In: YES 
user_id=21627

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file. In addition, even if you
*did* check this checkbox, a bug in SourceForge
prevents attaching a file when *creating* an issue.

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=305470&aid=1087808&group_id=5470
From noreply at sourceforge.net  Wed Dec 22 08:15:54 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Dec 22 08:16:01 2004
Subject: [Patches] [ python-Patches-1087808 ] sgmllib.SGMLParser does not
	unescape attribute values; patch
Message-ID: <E1Ch0iw-0001DW-0b@sc8-sf-web1.sourceforge.net>

Patches item #1087808, was opened at 2004-12-18 21:42
Message generated for change (Comment added) made by titus
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1087808&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 7
Submitted By: Titus Brown (titus)
Assigned to: Martin v. L?wis (loewis)
Summary: sgmllib.SGMLParser does not unescape attribute values; patch

Initial Comment:
for example, in a form parsed by htmllib.HTMLParser (based on 
SGMLParser),

<option value="5&quot; big"> 5&quot; big

the value will not be unescaped to 5" while the printed
option will be.

Note that this behavior differs from that of 
HTMLParser.HTMLParser, which does a fine job.

See attached test script/test input for an example.

See attached patch for a fix: essentially I copied the code directly 
from HTMLParser.HTMLParser.

I don't think this patch should break anything; I can't imagine 
people were relying on this behavior!


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

>Comment By: Titus Brown (titus)
Date: 2004-12-21 23:15

Message:
Logged In: YES 
user_id=23486

oh, and here's the example.

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

Comment By: Titus Brown (titus)
Date: 2004-12-21 23:13

Message:
Logged In: YES 
user_id=23486

Whoops.  Dangitall.

Also at

http://issola.caltech.edu/~t/transfer/sgmllib.diff



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

Comment By: Martin v. L?wis (loewis)
Date: 2004-12-21 23:06

Message:
Logged In: YES 
user_id=21627

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file. In addition, even if you
*did* check this checkbox, a bug in SourceForge
prevents attaching a file when *creating* an issue.

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=305470&aid=1087808&group_id=5470
From noreply at sourceforge.net  Wed Dec 22 08:57:31 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Dec 22 08:57:34 2004
Subject: [Patches] [ python-Patches-1087808 ] sgmllib.SGMLParser does not
	unescape attribute values; patch
Message-ID: <E1Ch1ND-0001P0-26@sc8-sf-web4.sourceforge.net>

Patches item #1087808, was opened at 2004-12-19 06:42
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1087808&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 7
Submitted By: Titus Brown (titus)
Assigned to: Martin v. L?wis (loewis)
Summary: sgmllib.SGMLParser does not unescape attribute values; patch

Initial Comment:
for example, in a form parsed by htmllib.HTMLParser (based on 
SGMLParser),

<option value="5&quot; big"> 5&quot; big

the value will not be unescaped to 5" while the printed
option will be.

Note that this behavior differs from that of 
HTMLParser.HTMLParser, which does a fine job.

See attached test script/test input for an example.

See attached patch for a fix: essentially I copied the code directly 
from HTMLParser.HTMLParser.

I don't think this patch should break anything; I can't imagine 
people were relying on this behavior!


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

>Comment By: Martin v. L?wis (loewis)
Date: 2004-12-22 08:57

Message:
Logged In: YES 
user_id=21627

Please use unified or context diffs when submitting patches.

The patch is incorrect: Instead of hard-coding the list of
known entities, sgmllib should use self.entitydefs to
determine the set of entity names that are supported. As a
result, the algorithm should also replace, say, &auml; if it
occurs in an HTML attribute.

Then the question is what should happen on unknown entity
references. One cannot really call unknown_entityref, since
implementations of that will expect that the entity
reference was in content, not in an attribute. So it would
probably best to leave unknown entity references alone.

Notice that in SGML (and HTML) the semicolon after the
entity name is not mandatory, but can be omitted if the
entity name is not followed by a letter or digit. So you
probably should use the regular expression entityref to find
references.

Please also provide a documentation patch that explains
precisely how the attribute value is created from what is in
the input document (i.e. some entity references replaced, no
character references replaced, etc).


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

Comment By: Titus Brown (titus)
Date: 2004-12-22 08:15

Message:
Logged In: YES 
user_id=23486

oh, and here's the example.

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

Comment By: Titus Brown (titus)
Date: 2004-12-22 08:13

Message:
Logged In: YES 
user_id=23486

Whoops.  Dangitall.

Also at

http://issola.caltech.edu/~t/transfer/sgmllib.diff



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

Comment By: Martin v. L?wis (loewis)
Date: 2004-12-22 08:06

Message:
Logged In: YES 
user_id=21627

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file. In addition, even if you
*did* check this checkbox, a bug in SourceForge
prevents attaching a file when *creating* an issue.

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=305470&aid=1087808&group_id=5470
From noreply at sourceforge.net  Wed Dec 22 09:32:03 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Dec 22 09:32:11 2004
Subject: [Patches] [ python-Patches-1087808 ] sgmllib.SGMLParser does not
	unescape attribute values; patch
Message-ID: <E1Ch1ud-0002bm-Os@sc8-sf-web4.sourceforge.net>

Patches item #1087808, was opened at 2004-12-18 21:42
Message generated for change (Comment added) made by titus
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1087808&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 7
Submitted By: Titus Brown (titus)
Assigned to: Martin v. L?wis (loewis)
Summary: sgmllib.SGMLParser does not unescape attribute values; patch

Initial Comment:
for example, in a form parsed by htmllib.HTMLParser (based on 
SGMLParser),

<option value="5&quot; big"> 5&quot; big

the value will not be unescaped to 5" while the printed
option will be.

Note that this behavior differs from that of 
HTMLParser.HTMLParser, which does a fine job.

See attached test script/test input for an example.

See attached patch for a fix: essentially I copied the code directly 
from HTMLParser.HTMLParser.

I don't think this patch should break anything; I can't imagine 
people were relying on this behavior!


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

>Comment By: Titus Brown (titus)
Date: 2004-12-22 00:32

Message:
Logged In: YES 
user_id=23486

I'm happy to do so -- note that this will expand the patch to include 
HTMLParser.py, as well.

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

Comment By: Martin v. L?wis (loewis)
Date: 2004-12-21 23:57

Message:
Logged In: YES 
user_id=21627

Please use unified or context diffs when submitting patches.

The patch is incorrect: Instead of hard-coding the list of
known entities, sgmllib should use self.entitydefs to
determine the set of entity names that are supported. As a
result, the algorithm should also replace, say, &auml; if it
occurs in an HTML attribute.

Then the question is what should happen on unknown entity
references. One cannot really call unknown_entityref, since
implementations of that will expect that the entity
reference was in content, not in an attribute. So it would
probably best to leave unknown entity references alone.

Notice that in SGML (and HTML) the semicolon after the
entity name is not mandatory, but can be omitted if the
entity name is not followed by a letter or digit. So you
probably should use the regular expression entityref to find
references.

Please also provide a documentation patch that explains
precisely how the attribute value is created from what is in
the input document (i.e. some entity references replaced, no
character references replaced, etc).


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

Comment By: Titus Brown (titus)
Date: 2004-12-21 23:15

Message:
Logged In: YES 
user_id=23486

oh, and here's the example.

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

Comment By: Titus Brown (titus)
Date: 2004-12-21 23:13

Message:
Logged In: YES 
user_id=23486

Whoops.  Dangitall.

Also at

http://issola.caltech.edu/~t/transfer/sgmllib.diff



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

Comment By: Martin v. L?wis (loewis)
Date: 2004-12-21 23:06

Message:
Logged In: YES 
user_id=21627

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file. In addition, even if you
*did* check this checkbox, a bug in SourceForge
prevents attaching a file when *creating* an issue.

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=305470&aid=1087808&group_id=5470
From noreply at sourceforge.net  Wed Dec 22 14:16:58 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Dec 22 14:17:02 2004
Subject: [Patches] [ python-Patches-1087808 ] sgmllib.SGMLParser does not
	unescape attribute values; patch
Message-ID: <E1Ch6MM-0000Wm-PS@sc8-sf-web3.sourceforge.net>

Patches item #1087808, was opened at 2004-12-19 06:42
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1087808&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 7
Submitted By: Titus Brown (titus)
Assigned to: Martin v. L?wis (loewis)
Summary: sgmllib.SGMLParser does not unescape attribute values; patch

Initial Comment:
for example, in a form parsed by htmllib.HTMLParser (based on 
SGMLParser),

<option value="5&quot; big"> 5&quot; big

the value will not be unescaped to 5" while the printed
option will be.

Note that this behavior differs from that of 
HTMLParser.HTMLParser, which does a fine job.

See attached test script/test input for an example.

See attached patch for a fix: essentially I copied the code directly 
from HTMLParser.HTMLParser.

I don't think this patch should break anything; I can't imagine 
people were relying on this behavior!


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

>Comment By: Martin v. L?wis (loewis)
Date: 2004-12-22 14:16

Message:
Logged In: YES 
user_id=21627

Not necessarily: self.entityrefs is already updated in 
HTMLParser, so this should work for the base class.

One issue might be with encodings, e.g. if the document 
encoding is not Latin-1. In this case, one might not want to 
replace &auml; with its Latin-1 equivalent, so you might need 
to provide a hook where a subclass can chose not to perform 
entity expansion, or perform more of it (perhaps also with a 
possibility to perform character reference expansion).

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

Comment By: Titus Brown (titus)
Date: 2004-12-22 09:32

Message:
Logged In: YES 
user_id=23486

I'm happy to do so -- note that this will expand the patch to include 
HTMLParser.py, as well.

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

Comment By: Martin v. L?wis (loewis)
Date: 2004-12-22 08:57

Message:
Logged In: YES 
user_id=21627

Please use unified or context diffs when submitting patches.

The patch is incorrect: Instead of hard-coding the list of
known entities, sgmllib should use self.entitydefs to
determine the set of entity names that are supported. As a
result, the algorithm should also replace, say, &auml; if it
occurs in an HTML attribute.

Then the question is what should happen on unknown entity
references. One cannot really call unknown_entityref, since
implementations of that will expect that the entity
reference was in content, not in an attribute. So it would
probably best to leave unknown entity references alone.

Notice that in SGML (and HTML) the semicolon after the
entity name is not mandatory, but can be omitted if the
entity name is not followed by a letter or digit. So you
probably should use the regular expression entityref to find
references.

Please also provide a documentation patch that explains
precisely how the attribute value is created from what is in
the input document (i.e. some entity references replaced, no
character references replaced, etc).


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

Comment By: Titus Brown (titus)
Date: 2004-12-22 08:15

Message:
Logged In: YES 
user_id=23486

oh, and here's the example.

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

Comment By: Titus Brown (titus)
Date: 2004-12-22 08:13

Message:
Logged In: YES 
user_id=23486

Whoops.  Dangitall.

Also at

http://issola.caltech.edu/~t/transfer/sgmllib.diff



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

Comment By: Martin v. L?wis (loewis)
Date: 2004-12-22 08:06

Message:
Logged In: YES 
user_id=21627

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file. In addition, even if you
*did* check this checkbox, a bug in SourceForge
prevents attaching a file when *creating* an issue.

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=305470&aid=1087808&group_id=5470
From noreply at sourceforge.net  Wed Dec 22 15:09:17 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Dec 22 15:09:22 2004
Subject: [Patches] [ python-Patches-1088716 ] msi.py patch to build mingw
	library
Message-ID: <E1Ch7Az-0000Km-SM@sc8-sf-web1.sourceforge.net>

Patches item #1088716, was opened at 2004-12-21 00:01
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1088716&group_id=5470

Category: Build
Group: Python 2.4
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Paul Moore (pmoore)
Assigned to: Martin v. L?wis (loewis)
Summary: msi.py patch to build mingw library

Initial Comment:
The attached patch updates the MSI build process to
build a mingw-compatible libpythonXX.a and install it
in the Python "libs" directory.

The additional step requires 2 executables, nm and
dlltool, to be available on PATH. These are part of the
binutils package of either mingw or cygwin. The build
should warn, and skip the inclusion of libpythonXX.a,
if the tools are not available.

Note: I do not have a Python build environment (no
Visual Studio .NET) and so cannot test this patch fully
- the msi.py script depends on VS.NET registry keys
that aren't available on my PC. I've checked that
libpythonXX.a is built correctly, but I can't ensure
that the MSI file gets built properly :-( Assistance in
testing this would be appreciated...

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

>Comment By: Martin v. L?wis (loewis)
Date: 2004-12-22 15:09

Message:
Logged In: YES 
user_id=21627

Thanks for the patch, committed as msi.py 1.20 and 1.16.2.4.

I built a package at

http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-
2.4.12774.msi

Please try this out, and confirm that you can, with this 
package, build extensions with cygwin, without further 
changes.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1088716&group_id=5470
From noreply at sourceforge.net  Wed Dec 22 15:19:26 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Dec 22 15:19:30 2004
Subject: [Patches] [ python-Patches-1055159 ] CGIHTTPServer can't redirect
Message-ID: <E1Ch7Ko-0000nZ-1a@sc8-sf-web1.sourceforge.net>

Patches item #1055159, was opened at 2004-10-27 08:49
Message generated for change (Comment added) made by jhylton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1055159&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Guettler (guettli)
>Assigned to: Jeremy Hylton (jhylton)
Summary: CGIHTTPServer can't redirect

Initial Comment:
Please add this to the docstring of CGIHTTPServer:

It can't handle redirects (302) because it returns "200
Script output
follows" before the script is executed.



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

>Comment By: Jeremy Hylton (jhylton)
Date: 2004-12-22 14:19

Message:
Logged In: YES 
user_id=31392

Applied as rev 1.7 of libcgihttp.tex and rev 1.36 of
CGIHTTPServer.py


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

Comment By: Titus Brown (titus)
Date: 2004-12-19 06:44

Message:
Logged In: YES 
user_id=23486

Verified behavior on Linux -- Apache redirects appropriately,
but the same script run via CGIHTTPServer does not.  Plus
it makes sense given the implementation code in CGIHTTPServer.py ;).

Documentation patch to docs and docstring at

http://issola.caltech.edu/~t/transfer/patch-1055159-doc.diff

...if someone could attach it, please... tnx!

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1055159&group_id=5470
From noreply at sourceforge.net  Wed Dec 22 15:20:11 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Dec 22 15:20:20 2004
Subject: [Patches] [ python-Patches-1055159 ] CGIHTTPServer can't redirect
Message-ID: <E1Ch7LX-0000po-OB@sc8-sf-web1.sourceforge.net>

Patches item #1055159, was opened at 2004-10-27 08:49
Message generated for change (Settings changed) made by jhylton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1055159&group_id=5470

Category: Library (Lib)
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Thomas Guettler (guettli)
Assigned to: Jeremy Hylton (jhylton)
Summary: CGIHTTPServer can't redirect

Initial Comment:
Please add this to the docstring of CGIHTTPServer:

It can't handle redirects (302) because it returns "200
Script output
follows" before the script is executed.



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

Comment By: Jeremy Hylton (jhylton)
Date: 2004-12-22 14:19

Message:
Logged In: YES 
user_id=31392

Applied as rev 1.7 of libcgihttp.tex and rev 1.36 of
CGIHTTPServer.py


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

Comment By: Titus Brown (titus)
Date: 2004-12-19 06:44

Message:
Logged In: YES 
user_id=23486

Verified behavior on Linux -- Apache redirects appropriately,
but the same script run via CGIHTTPServer does not.  Plus
it makes sense given the implementation code in CGIHTTPServer.py ;).

Documentation patch to docs and docstring at

http://issola.caltech.edu/~t/transfer/patch-1055159-doc.diff

...if someone could attach it, please... tnx!

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1055159&group_id=5470
From noreply at sourceforge.net  Wed Dec 22 15:27:53 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Dec 22 15:27:57 2004
Subject: [Patches] [ python-Patches-1037974 ] urllib2 HTTP digest
	authentication fix
Message-ID: <E1Ch7Sz-00019F-Qu@sc8-sf-web1.sourceforge.net>

Patches item #1037974, was opened at 2004-09-30 19:10
Message generated for change (Comment added) made by jhylton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1037974&group_id=5470

Category: Library (Lib)
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Mathieu Fenniak (mfenniak)
>Assigned to: Jeremy Hylton (jhylton)
Summary: urllib2 HTTP digest authentication fix

Initial Comment:
Although the 'algorithm' component of the Authorization header is 
considered optional by RFC 2617, there are sites that do not 
function without providing algorithm notification.  Specifically, this 
problem is encounted with LiveJournal RSS feeds (where HTTP 
digest authentication can be used to view non-public livejournal 
entries).

This patch makes the algorithm flag always sent in the 
Authorization header.  The following test script demonstrates the 
problem for a LiveJournal RSS feed (username and password must 
be entered):

    import urllib2

    class PasswordMgr(object):
        def find_user_password(self, realm, authuri):
            return "someuser", "somepass"
        def add_password(self):
            pass

    rssURI = "http://livejournal.com/users/someuser/data/rss?
auth=digest"

    handler = urllib2.HTTPDigestAuthHandler(PasswordMgr())
    opener = urllib2.build_opener(handler)
    opener.open(rssURI)

With the attached patch, this works successfully.  Without it, it fails 
with an HTTP 401 error.

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

>Comment By: Jeremy Hylton (jhylton)
Date: 2004-12-22 14:27

Message:
Logged In: YES 
user_id=31392

Fixed in rev 1.78 of urllib2

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

Comment By: Titus Brown (titus)
Date: 2004-12-19 07:24

Message:
Logged In: YES 
user_id=23486

Patch is simple (one line removed from current urllib2!).  I don't know 
much about http digest authentication, so I can't say anything about 
whether or not this correct; but I have verified that it fixes the 
LiveJournal behavior noted in the patch description (on Linux, under 
current CVS tree).  Moreover the MD5 
algorithm is the default, so this patch merely changes the behavior to be 
more verbose than it is currently -- it shouldn't break any existing actual 
functionality.

Recommend application of patch.



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

Comment By: Mathieu Fenniak (mfenniak)
Date: 2004-09-30 19:13

Message:
Logged In: YES 
user_id=1131071

Err, sorry, it appears I didn't attach the patch.  Here it is.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1037974&group_id=5470
From noreply at sourceforge.net  Wed Dec 22 15:29:52 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Dec 22 15:29:55 2004
Subject: [Patches] [ python-Patches-1028908 ] Changes to cookielib.py &
	friends for 2.4b1
Message-ID: <E1Ch7Uu-0001GI-M6@sc8-sf-web1.sourceforge.net>

Patches item #1028908, was opened at 2004-09-16 00:19
Message generated for change (Settings changed) made by jhylton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1028908&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: John J Lee (jjlee)
>Assigned to: Jeremy Hylton (jhylton)
Summary: Changes to cookielib.py & friends for 2.4b1

Initial Comment:
The patch contains uncontroversial changes to cookielib
and associated modules, documentation and tests.  Would
be unfortunate not to have these in 2.4.0.

1. Changes to keep cookielib in sync with ClientCookie
1.0 release.  This will make life simpler for people
migrating from ClientCookie (the package from whence
cookielib, and some recent urllib2 changes, came).

  a. Moved country-code pseudo-top-level domain (eg.
.co.uk) code into a separate method of
DefaultCookiePolicy to make life easier for subclassers
(.set_ok_countrycode_domain()).

  b. Added Cookie.nonstandard_attr_keys() method.

2. Added a new test.

3. Documentation corrections and clarifications
(including adding a prominent warning about current
lack of thread-safety, and a new example).

4. Small-scale refactoring in cookielib.py (including
moving magic_re to its rightful place in _LWPCookieJar.py).

5. Tiny code clarification in urllib2.py.

6. Removed coding declaration from test_cookielib.py,
in favour of escape sequences, since I discovered that
I don't understand coding declarations :-/


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

Comment By: Titus Brown (titus)
Date: 2004-12-19 07:35

Message:
Logged In: YES 
user_id=23486

Applied patch & ran 'make test' under Linux with latest from CVS.  
Everything works.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1028908&group_id=5470
From noreply at sourceforge.net  Wed Dec 22 15:41:45 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Dec 22 15:41:52 2004
Subject: [Patches] [ python-Patches-1028908 ] Changes to cookielib.py &
	friends for 2.4b1
Message-ID: <E1Ch7gP-0000Kt-6i@sc8-sf-web4.sourceforge.net>

Patches item #1028908, was opened at 2004-09-16 00:19
Message generated for change (Comment added) made by jhylton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1028908&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: John J Lee (jjlee)
Assigned to: Jeremy Hylton (jhylton)
Summary: Changes to cookielib.py & friends for 2.4b1

Initial Comment:
The patch contains uncontroversial changes to cookielib
and associated modules, documentation and tests.  Would
be unfortunate not to have these in 2.4.0.

1. Changes to keep cookielib in sync with ClientCookie
1.0 release.  This will make life simpler for people
migrating from ClientCookie (the package from whence
cookielib, and some recent urllib2 changes, came).

  a. Moved country-code pseudo-top-level domain (eg.
.co.uk) code into a separate method of
DefaultCookiePolicy to make life easier for subclassers
(.set_ok_countrycode_domain()).

  b. Added Cookie.nonstandard_attr_keys() method.

2. Added a new test.

3. Documentation corrections and clarifications
(including adding a prominent warning about current
lack of thread-safety, and a new example).

4. Small-scale refactoring in cookielib.py (including
moving magic_re to its rightful place in _LWPCookieJar.py).

5. Tiny code clarification in urllib2.py.

6. Removed coding declaration from test_cookielib.py,
in favour of escape sequences, since I discovered that
I don't understand coding declarations :-/


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

>Comment By: Jeremy Hylton (jhylton)
Date: 2004-12-22 14:41

Message:
Logged In: YES 
user_id=31392

Is it safe to add these as bug fixes for 2.4.1?  It looks
okay to me, but I wanted to be sure that wasn't some API
change that was signficant.


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

Comment By: Titus Brown (titus)
Date: 2004-12-19 07:35

Message:
Logged In: YES 
user_id=23486

Applied patch & ran 'make test' under Linux with latest from CVS.  
Everything works.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1028908&group_id=5470
From noreply at sourceforge.net  Wed Dec 22 19:15:25 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Dec 22 19:15:45 2004
Subject: [Patches] [ python-Patches-851459 ] Argument passing from
	/usr/bin/idle2.3 to idle.py
Message-ID: <E1ChB1B-000582-6q@sc8-sf-web3.sourceforge.net>

Patches item #851459, was opened at 2003-11-30 01:27
Message generated for change (Comment added) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=851459&group_id=5470

Category: None
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Humberto Di?genes (virtualspirit)
Assigned to: Sean Reifschneider (jafo)
Summary: Argument passing from /usr/bin/idle2.3 to idle.py

Initial Comment:
/usr/bin/idle2.3 wrapper (from the 2.3.2-1pydotorg rpm) ignores 
command-line arguments when calling idle.py. Fixed only by adding 
&quot;$*&quot; to the script.

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

>Comment By: Kurt B. Kaiser (kbk)
Date: 2004-12-22 13:15

Message:
Logged In: YES 
user_id=149084

This really ought to get into release24-maint and probably
release23-maint if you think anyone will ever build an rpm
from 2.3.5 (which is due out soon).

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

Comment By: Sean Reifschneider (jafo)
Date: 2004-12-20 21:25

Message:
Logged In: YES 
user_id=81797

I went ahead and turned this into Python code and called
"execvp", passing the command arguments onto the idle call.
 This way there are no worries about how the shell handles
$* expansion.  The current CVS version results in something
looking like:

#!/usr/bin/env python2.4
import os, sys
os.execvp("/usr/bin/python2.4", ["/usr/bin/python2.4",
"/usr/lib/python2.4/idlelib/idle.py"] + sys.argv[1:])
print "Failed to exec Idle"
sys.exit(1)

(assuming default build settings)

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

Comment By: Kurt B. Kaiser (kbk)
Date: 2004-12-20 15:53

Message:
Logged In: YES 
user_id=149084

Appears to be an issue with the Tools section of 
..../Misc/RPM/python-2.4.spec
Backport to release23-maint

Assigning to Sean Reifschneider

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=851459&group_id=5470
From noreply at sourceforge.net  Wed Dec 22 21:58:05 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Dec 22 21:58:12 2004
Subject: [Patches] [ python-Patches-1088716 ] msi.py patch to build mingw
	library
Message-ID: <E1ChDYb-0001Pv-LP@sc8-sf-web1.sourceforge.net>

Patches item #1088716, was opened at 2004-12-20 23:01
Message generated for change (Comment added) made by pmoore
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1088716&group_id=5470

Category: Build
Group: Python 2.4
Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Paul Moore (pmoore)
Assigned to: Martin v. L?wis (loewis)
Summary: msi.py patch to build mingw library

Initial Comment:
The attached patch updates the MSI build process to
build a mingw-compatible libpythonXX.a and install it
in the Python "libs" directory.

The additional step requires 2 executables, nm and
dlltool, to be available on PATH. These are part of the
binutils package of either mingw or cygwin. The build
should warn, and skip the inclusion of libpythonXX.a,
if the tools are not available.

Note: I do not have a Python build environment (no
Visual Studio .NET) and so cannot test this patch fully
- the msi.py script depends on VS.NET registry keys
that aren't available on my PC. I've checked that
libpythonXX.a is built correctly, but I can't ensure
that the MSI file gets built properly :-( Assistance in
testing this would be appreciated...

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

>Comment By: Paul Moore (pmoore)
Date: 2004-12-22 20:58

Message:
Logged In: YES 
user_id=113328

I can confirm that with this package, and no other Python
extensions installed, I can build extensions with mingw, out
of the box.

Looks great - thanks!

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

Comment By: Martin v. L?wis (loewis)
Date: 2004-12-22 14:09

Message:
Logged In: YES 
user_id=21627

Thanks for the patch, committed as msi.py 1.20 and 1.16.2.4.

I built a package at

http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-
2.4.12774.msi

Please try this out, and confirm that you can, with this 
package, build extensions with cygwin, without further 
changes.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1088716&group_id=5470
From noreply at sourceforge.net  Thu Dec 23 09:29:12 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Dec 23 09:29:17 2004
Subject: [Patches] [ python-Patches-1067760 ] fix for 1067728: Better
	handling of float arguments to seek
Message-ID: <E1ChOLQ-0007aD-HG@sc8-sf-web1.sourceforge.net>

Patches item #1067760, was opened at 2004-11-16 17:28
Message generated for change (Comment added) made by titus
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1067760&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Robert Church (churchr)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix for 1067728: Better handling of float arguments to seek

Initial Comment:
Instead of converting all float arguments to ints, this
first attempts to 
convert the argument to a PyLong, and then the old
conversion code takes over.

The upshot is that the limit of floating point
arguments to seek() is raised from (2 ** 32) - 1 to
somewhere above (2 ** 62).

Perhaps a better way to handle this would be to not
accept floating point arguments to seek().

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

Comment By: Titus Brown (titus)
Date: 2004-12-23 00:29

Message:
Logged In: YES 
user_id=23486

Bob Ippolito pointed out that nowadays float-->int conversion of
arguments is deprecated; a DeprecationWarning wasn't being raised 
because conversion was done manually in seek.  Patch to fix this
at

http://issola.caltech.edu/~t/transfer/patch-1067760-seekwarn.diff

Linux RH 9.0 works, regression tests run w/o problem.

The patch is against the current HEAD but can probably be backported w/
o a problem.

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

Comment By: Titus Brown (titus)
Date: 2004-12-19 01:38

Message:
Logged In: YES 
user_id=23486

Sorry, I should add: patch works against head on Linux RH 9.0 (and 
should work everywhere).  Behavior tested with a script.

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

Comment By: Titus Brown (titus)
Date: 2004-12-19 01:37

Message:
Logged In: YES 
user_id=23486

The patch works against HEAD; updated for line numbers (there's a very 
similar set of line elsewhere in the file):

http://issola.caltech.edu/~t/transfer/patch-1067760-seek.diff

rhettinger thought the current behavior was reasonable (see bug 
1067728).  I'm not qualified to comment ;) but it seems odd that floats 
would have drastically different limits than longs.  This looks like a 
reasonable compromise IMO.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1067760&group_id=5470
From noreply at sourceforge.net  Thu Dec 23 13:35:53 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Dec 23 13:35:59 2004
Subject: [Patches] [ python-Patches-1028908 ] Changes to cookielib.py &
	friends for 2.4b1
Message-ID: <E1ChSC9-0000gr-60@sc8-sf-web1.sourceforge.net>

Patches item #1028908, was opened at 2004-09-16 01:19
Message generated for change (Comment added) made by jjlee
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1028908&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: John J Lee (jjlee)
Assigned to: Jeremy Hylton (jhylton)
Summary: Changes to cookielib.py & friends for 2.4b1

Initial Comment:
The patch contains uncontroversial changes to cookielib
and associated modules, documentation and tests.  Would
be unfortunate not to have these in 2.4.0.

1. Changes to keep cookielib in sync with ClientCookie
1.0 release.  This will make life simpler for people
migrating from ClientCookie (the package from whence
cookielib, and some recent urllib2 changes, came).

  a. Moved country-code pseudo-top-level domain (eg.
.co.uk) code into a separate method of
DefaultCookiePolicy to make life easier for subclassers
(.set_ok_countrycode_domain()).

  b. Added Cookie.nonstandard_attr_keys() method.

2. Added a new test.

3. Documentation corrections and clarifications
(including adding a prominent warning about current
lack of thread-safety, and a new example).

4. Small-scale refactoring in cookielib.py (including
moving magic_re to its rightful place in _LWPCookieJar.py).

5. Tiny code clarification in urllib2.py.

6. Removed coding declaration from test_cookielib.py,
in favour of escape sequences, since I discovered that
I don't understand coding declarations :-/


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

>Comment By: John J Lee (jjlee)
Date: 2004-12-23 12:35

Message:
Logged In: YES 
user_id=261020

Yes, it's safe for 2.4.1.  There's one new method, but I
guess that's OK?


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

Comment By: Jeremy Hylton (jhylton)
Date: 2004-12-22 14:41

Message:
Logged In: YES 
user_id=31392

Is it safe to add these as bug fixes for 2.4.1?  It looks
okay to me, but I wanted to be sure that wasn't some API
change that was signficant.


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

Comment By: Titus Brown (titus)
Date: 2004-12-19 07:35

Message:
Logged In: YES 
user_id=23486

Applied patch & ran 'make test' under Linux with latest from CVS.  
Everything works.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1028908&group_id=5470
From noreply at sourceforge.net  Thu Dec 23 18:43:41 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Dec 23 18:44:43 2004
Subject: [Patches] [ python-Patches-968728 ] Py_HUGE_VAL HUGE_VAL HUGE
	undefined
Message-ID: <E1ChX01-00015Y-OJ@sc8-sf-web4.sourceforge.net>

Patches item #968728, was opened at 2004-06-08 08:48
Message generated for change (Comment added) made by cross
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=968728&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Michael Schloh von Bennewitz (michaesc)
Assigned to: Nobody/Anonymous (nobody)
Summary: Py_HUGE_VAL HUGE_VAL HUGE undefined

Initial Comment:
In Python 2.3.4 (as well as the trunk revision on CVS), Py_HUGE_VAL 
is conditionally defined as HUGE_VAL. On at least Solaris 10 x86 and 
Solaris 10 SPARC, this causes a build failure.

I'm ashamed to say that I wasn't able to 100% diagnose this problem (I 
didn't have time). My first guess was that somehow HUGE_VAL was not 
getting properly defined on Solaris 10 due to its rewritten 
/usr/include/iso/math_iso.h file (now conditionally defining HUGE_VAL 
depending on a _STDC_C99 and _XOPEN_SOURCE definition).

Because I noticed that the identifier HUGE is unconditionally defined 
on Solaris 10 and seemingly all earlier Solaris releases, I tried using 
that instead and the build problem disappeared.

You can make your own conclusion as to whether my fix is correct, or if 
there is a better way to solve this problem. There may be a faulty 
assumption made by configure or in some Makefile of how the compiler 
is being used, or maybe python depends on a certain GCC release.

  CC: GCC 3.4.0
  CXX: GCC 3.4.0
  CFLAGS:   -O2 -pipe
  CXXFLAGS:   -O2 -pipe
  CPPFLAGS: None 
  Make:     GNU Make 3.80
  LDFLAGS:  None

  mich@dev:/tmp/Python-2.3.4$ ./configure --prefix=/cw
  checking MACHDEP... freebsd4
  checking EXTRAPLATDIR... 
  checking for --without-gcc... no
  checking for --with-cxx=<compiler>... no
  ...

The OpenPKG Python package and patch:
http://cvs.openpkg.org/dir?d=openpkg-src/python
http://cvs.openpkg.org/rlog?f=openpkg-src/python/python.patch

Lots of luck, and thanks for maintaining Python.

Regards,
Michael, OpenPKG
http://www.openpkg.org/


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

Comment By: Chris P. Ross (cross)
Date: 2004-12-23 17:43

Message:
Logged In: YES 
user_id=12814

Hi.  I found this today as well.  However, a little research
shows that what it's defined to (__builtin_huge_val) is
actually a function pointer, not a number.  So, if I changed
Py_HUGE_VAL to be #def'd to HUGE_VAL(), it worked just find
on my Solaris 10 machine.

What does the c89 and c99 spec say that HUGE_VAL macro
should be?  A number?  Or is having it be a function
reference legal?



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

Comment By: Hye-Shik Chang (perky)
Date: 2004-07-17 14:05

Message:
Logged In: YES 
user_id=55188

This doesn't look like a bug in Python per Tim's comment.

(Reviewed by Seo Sanghyeon and me at KLDP CodeFest)

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

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

Message:
Logged In: YES 
user_id=31435

I don't see a reason to call this a Python bug.  The C89 and 
C99 standards both require that math.h supply the HUGE_VAL 
macro.  If the compilation system you're using doesn't do so, 
it's a bug in that system, and should be fixed there.  Python 
doesn't ask for much, but does require an ANSI C compiler.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=968728&group_id=5470
From noreply at sourceforge.net  Thu Dec 23 19:08:00 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Dec 23 19:08:02 2004
Subject: [Patches] [ python-Patches-1090482 ] Patch for bug 999042.
Message-ID: <E1ChXNY-0008Jd-17@sc8-sf-web1.sourceforge.net>

Patches item #1090482, was opened at 2004-12-23 18:07
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1090482&group_id=5470

Category: Parser/Compiler
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Darek Suchojad (dsuch)
Assigned to: Nobody/Anonymous (nobody)
Summary: Patch for bug 999042.

Initial Comment:
Hello, I believe this one-line patch fixes [999042]
"Compiler module doesn't handle global statement
correctly" bug.  Without setting the 'optimized' flag
compiler.pycodegen.CodeGenerator._nameOp always emits
STORE_NAME and not STORE_GLOBAL opcode. After applying
test_compiler passes fine.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1090482&group_id=5470
From noreply at sourceforge.net  Thu Dec 23 19:09:45 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Dec 23 19:10:43 2004
Subject: [Patches] [ python-Patches-968728 ] Py_HUGE_VAL HUGE_VAL HUGE
	undefined
Message-ID: <E1ChXPF-0007eo-8K@sc8-sf-web3.sourceforge.net>

Patches item #968728, was opened at 2004-06-08 04:48
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=968728&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Michael Schloh von Bennewitz (michaesc)
Assigned to: Nobody/Anonymous (nobody)
Summary: Py_HUGE_VAL HUGE_VAL HUGE undefined

Initial Comment:
In Python 2.3.4 (as well as the trunk revision on CVS), Py_HUGE_VAL 
is conditionally defined as HUGE_VAL. On at least Solaris 10 x86 and 
Solaris 10 SPARC, this causes a build failure.

I'm ashamed to say that I wasn't able to 100% diagnose this problem (I 
didn't have time). My first guess was that somehow HUGE_VAL was not 
getting properly defined on Solaris 10 due to its rewritten 
/usr/include/iso/math_iso.h file (now conditionally defining HUGE_VAL 
depending on a _STDC_C99 and _XOPEN_SOURCE definition).

Because I noticed that the identifier HUGE is unconditionally defined 
on Solaris 10 and seemingly all earlier Solaris releases, I tried using 
that instead and the build problem disappeared.

You can make your own conclusion as to whether my fix is correct, or if 
there is a better way to solve this problem. There may be a faulty 
assumption made by configure or in some Makefile of how the compiler 
is being used, or maybe python depends on a certain GCC release.

  CC: GCC 3.4.0
  CXX: GCC 3.4.0
  CFLAGS:   -O2 -pipe
  CXXFLAGS:   -O2 -pipe
  CPPFLAGS: None 
  Make:     GNU Make 3.80
  LDFLAGS:  None

  mich@dev:/tmp/Python-2.3.4$ ./configure --prefix=/cw
  checking MACHDEP... freebsd4
  checking EXTRAPLATDIR... 
  checking for --without-gcc... no
  checking for --with-cxx=<compiler>... no
  ...

The OpenPKG Python package and patch:
http://cvs.openpkg.org/dir?d=openpkg-src/python
http://cvs.openpkg.org/rlog?f=openpkg-src/python/python.patch

Lots of luck, and thanks for maintaining Python.

Regards,
Michael, OpenPKG
http://www.openpkg.org/


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

>Comment By: Tim Peters (tim_one)
Date: 2004-12-23 13:09

Message:
Logged In: YES 
user_id=31435

>From C99:

"""
The macro

HUGE_VAL

expands to a positive double constant expression, not 
necessarily representable as a float.

...

(footnote) HUGE_VAL, HUGE_VALF, and HUGE_VALL can be 
positive infinities in an implementation that
supports infinities.
"""

Of course a function pointer is not "a positive double 
constant expression", so doesn't meet the standard's 
requirements.

Some Googling suggested that the "-Xc or -Xa compliation 
options" may be needed to get standard behavior on Solaris, 
but that's just hearsay and I really have no idea.  Reports of 
HUGE_VAL creating compilation problems on Solaris for other 
projects are also easy to find.

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

Comment By: Chris P. Ross (cross)
Date: 2004-12-23 12:43

Message:
Logged In: YES 
user_id=12814

Hi.  I found this today as well.  However, a little research
shows that what it's defined to (__builtin_huge_val) is
actually a function pointer, not a number.  So, if I changed
Py_HUGE_VAL to be #def'd to HUGE_VAL(), it worked just find
on my Solaris 10 machine.

What does the c89 and c99 spec say that HUGE_VAL macro
should be?  A number?  Or is having it be a function
reference legal?



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

Comment By: Hye-Shik Chang (perky)
Date: 2004-07-17 10:05

Message:
Logged In: YES 
user_id=55188

This doesn't look like a bug in Python per Tim's comment.

(Reviewed by Seo Sanghyeon and me at KLDP CodeFest)

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

Comment By: Tim Peters (tim_one)
Date: 2004-06-08 15:02

Message:
Logged In: YES 
user_id=31435

I don't see a reason to call this a Python bug.  The C89 and 
C99 standards both require that math.h supply the HUGE_VAL 
macro.  If the compilation system you're using doesn't do so, 
it's a bug in that system, and should be fixed there.  Python 
doesn't ask for much, but does require an ANSI C compiler.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=968728&group_id=5470
From noreply at sourceforge.net  Thu Dec 23 19:40:36 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Dec 23 19:41:35 2004
Subject: [Patches] [ python-Patches-968728 ] Py_HUGE_VAL HUGE_VAL HUGE
	undefined
Message-ID: <E1ChXt6-000473-Rg@sc8-sf-web2.sourceforge.net>

Patches item #968728, was opened at 2004-06-08 08:48
Message generated for change (Comment added) made by cross
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=968728&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Michael Schloh von Bennewitz (michaesc)
Assigned to: Nobody/Anonymous (nobody)
Summary: Py_HUGE_VAL HUGE_VAL HUGE undefined

Initial Comment:
In Python 2.3.4 (as well as the trunk revision on CVS), Py_HUGE_VAL 
is conditionally defined as HUGE_VAL. On at least Solaris 10 x86 and 
Solaris 10 SPARC, this causes a build failure.

I'm ashamed to say that I wasn't able to 100% diagnose this problem (I 
didn't have time). My first guess was that somehow HUGE_VAL was not 
getting properly defined on Solaris 10 due to its rewritten 
/usr/include/iso/math_iso.h file (now conditionally defining HUGE_VAL 
depending on a _STDC_C99 and _XOPEN_SOURCE definition).

Because I noticed that the identifier HUGE is unconditionally defined 
on Solaris 10 and seemingly all earlier Solaris releases, I tried using 
that instead and the build problem disappeared.

You can make your own conclusion as to whether my fix is correct, or if 
there is a better way to solve this problem. There may be a faulty 
assumption made by configure or in some Makefile of how the compiler 
is being used, or maybe python depends on a certain GCC release.

  CC: GCC 3.4.0
  CXX: GCC 3.4.0
  CFLAGS:   -O2 -pipe
  CXXFLAGS:   -O2 -pipe
  CPPFLAGS: None 
  Make:     GNU Make 3.80
  LDFLAGS:  None

  mich@dev:/tmp/Python-2.3.4$ ./configure --prefix=/cw
  checking MACHDEP... freebsd4
  checking EXTRAPLATDIR... 
  checking for --without-gcc... no
  checking for --with-cxx=<compiler>... no
  ...

The OpenPKG Python package and patch:
http://cvs.openpkg.org/dir?d=openpkg-src/python
http://cvs.openpkg.org/rlog?f=openpkg-src/python/python.patch

Lots of luck, and thanks for maintaining Python.

Regards,
Michael, OpenPKG
http://www.openpkg.org/


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

Comment By: Chris P. Ross (cross)
Date: 2004-12-23 18:40

Message:
Logged In: YES 
user_id=12814

Oops.  My bad.  I failed to mention that I'm using gcc 3.4.x
on Solaris 10.   I assume those options are for the Forte
suite (or whatever they're calling it now).

Hmm.  I wonder how to tell sun that they're header isn't
compliant?  I wonder if it fails in the same way with Forte?

I should try to find out...  It *is* a beta OS after-all.  :-)

Thanks!


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

Comment By: Tim Peters (tim_one)
Date: 2004-12-23 18:09

Message:
Logged In: YES 
user_id=31435

>From C99:

"""
The macro

HUGE_VAL

expands to a positive double constant expression, not 
necessarily representable as a float.

...

(footnote) HUGE_VAL, HUGE_VALF, and HUGE_VALL can be 
positive infinities in an implementation that
supports infinities.
"""

Of course a function pointer is not "a positive double 
constant expression", so doesn't meet the standard's 
requirements.

Some Googling suggested that the "-Xc or -Xa compliation 
options" may be needed to get standard behavior on Solaris, 
but that's just hearsay and I really have no idea.  Reports of 
HUGE_VAL creating compilation problems on Solaris for other 
projects are also easy to find.

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

Comment By: Chris P. Ross (cross)
Date: 2004-12-23 17:43

Message:
Logged In: YES 
user_id=12814

Hi.  I found this today as well.  However, a little research
shows that what it's defined to (__builtin_huge_val) is
actually a function pointer, not a number.  So, if I changed
Py_HUGE_VAL to be #def'd to HUGE_VAL(), it worked just find
on my Solaris 10 machine.

What does the c89 and c99 spec say that HUGE_VAL macro
should be?  A number?  Or is having it be a function
reference legal?



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

Comment By: Hye-Shik Chang (perky)
Date: 2004-07-17 14:05

Message:
Logged In: YES 
user_id=55188

This doesn't look like a bug in Python per Tim's comment.

(Reviewed by Seo Sanghyeon and me at KLDP CodeFest)

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

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

Message:
Logged In: YES 
user_id=31435

I don't see a reason to call this a Python bug.  The C89 and 
C99 standards both require that math.h supply the HUGE_VAL 
macro.  If the compilation system you're using doesn't do so, 
it's a bug in that system, and should be fixed there.  Python 
doesn't ask for much, but does require an ANSI C compiler.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=968728&group_id=5470
From noreply at sourceforge.net  Thu Dec 23 21:25:12 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Dec 23 21:26:30 2004
Subject: [Patches] [ python-Patches-968728 ] Py_HUGE_VAL HUGE_VAL HUGE
	undefined
Message-ID: <E1ChZWK-0005YA-QN@sc8-sf-web1.sourceforge.net>

Patches item #968728, was opened at 2004-06-08 09:48
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=968728&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Michael Schloh von Bennewitz (michaesc)
Assigned to: Nobody/Anonymous (nobody)
Summary: Py_HUGE_VAL HUGE_VAL HUGE undefined

Initial Comment:
In Python 2.3.4 (as well as the trunk revision on CVS), Py_HUGE_VAL 
is conditionally defined as HUGE_VAL. On at least Solaris 10 x86 and 
Solaris 10 SPARC, this causes a build failure.

I'm ashamed to say that I wasn't able to 100% diagnose this problem (I 
didn't have time). My first guess was that somehow HUGE_VAL was not 
getting properly defined on Solaris 10 due to its rewritten 
/usr/include/iso/math_iso.h file (now conditionally defining HUGE_VAL 
depending on a _STDC_C99 and _XOPEN_SOURCE definition).

Because I noticed that the identifier HUGE is unconditionally defined 
on Solaris 10 and seemingly all earlier Solaris releases, I tried using 
that instead and the build problem disappeared.

You can make your own conclusion as to whether my fix is correct, or if 
there is a better way to solve this problem. There may be a faulty 
assumption made by configure or in some Makefile of how the compiler 
is being used, or maybe python depends on a certain GCC release.

  CC: GCC 3.4.0
  CXX: GCC 3.4.0
  CFLAGS:   -O2 -pipe
  CXXFLAGS:   -O2 -pipe
  CPPFLAGS: None 
  Make:     GNU Make 3.80
  LDFLAGS:  None

  mich@dev:/tmp/Python-2.3.4$ ./configure --prefix=/cw
  checking MACHDEP... freebsd4
  checking EXTRAPLATDIR... 
  checking for --without-gcc... no
  checking for --with-cxx=<compiler>... no
  ...

The OpenPKG Python package and patch:
http://cvs.openpkg.org/dir?d=openpkg-src/python
http://cvs.openpkg.org/rlog?f=openpkg-src/python/python.patch

Lots of luck, and thanks for maintaining Python.

Regards,
Michael, OpenPKG
http://www.openpkg.org/


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

>Comment By: Michael Hudson (mwh)
Date: 2004-12-23 20:25

Message:
Logged In: YES 
user_id=6656

Maaybe the parens are meant to be present in the macro definition?  
That would make some kind of sense, apart from probably still not 
meeting the letter of the standard (don't think the result of a function call 
is a "constant expression", somehow).

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

Comment By: Chris P. Ross (cross)
Date: 2004-12-23 18:40

Message:
Logged In: YES 
user_id=12814

Oops.  My bad.  I failed to mention that I'm using gcc 3.4.x
on Solaris 10.   I assume those options are for the Forte
suite (or whatever they're calling it now).

Hmm.  I wonder how to tell sun that they're header isn't
compliant?  I wonder if it fails in the same way with Forte?

I should try to find out...  It *is* a beta OS after-all.  :-)

Thanks!


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

Comment By: Tim Peters (tim_one)
Date: 2004-12-23 18:09

Message:
Logged In: YES 
user_id=31435

>From C99:

"""
The macro

HUGE_VAL

expands to a positive double constant expression, not 
necessarily representable as a float.

...

(footnote) HUGE_VAL, HUGE_VALF, and HUGE_VALL can be 
positive infinities in an implementation that
supports infinities.
"""

Of course a function pointer is not "a positive double 
constant expression", so doesn't meet the standard's 
requirements.

Some Googling suggested that the "-Xc or -Xa compliation 
options" may be needed to get standard behavior on Solaris, 
but that's just hearsay and I really have no idea.  Reports of 
HUGE_VAL creating compilation problems on Solaris for other 
projects are also easy to find.

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

Comment By: Chris P. Ross (cross)
Date: 2004-12-23 17:43

Message:
Logged In: YES 
user_id=12814

Hi.  I found this today as well.  However, a little research
shows that what it's defined to (__builtin_huge_val) is
actually a function pointer, not a number.  So, if I changed
Py_HUGE_VAL to be #def'd to HUGE_VAL(), it worked just find
on my Solaris 10 machine.

What does the c89 and c99 spec say that HUGE_VAL macro
should be?  A number?  Or is having it be a function
reference legal?



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

Comment By: Hye-Shik Chang (perky)
Date: 2004-07-17 15:05

Message:
Logged In: YES 
user_id=55188

This doesn't look like a bug in Python per Tim's comment.

(Reviewed by Seo Sanghyeon and me at KLDP CodeFest)

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

Comment By: Tim Peters (tim_one)
Date: 2004-06-08 20:02

Message:
Logged In: YES 
user_id=31435

I don't see a reason to call this a Python bug.  The C89 and 
C99 standards both require that math.h supply the HUGE_VAL 
macro.  If the compilation system you're using doesn't do so, 
it's a bug in that system, and should be fixed there.  Python 
doesn't ask for much, but does require an ANSI C compiler.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=968728&group_id=5470
From noreply at sourceforge.net  Thu Dec 23 23:14:11 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Dec 23 23:14:14 2004
Subject: [Patches] [ python-Patches-995939 ] Avoid calling tp_compare with
	different types
Message-ID: <E1ChbDn-0004W3-Gv@sc8-sf-web2.sourceforge.net>

Patches item #995939, was opened at 2004-07-22 14:14
Message generated for change (Settings changed) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=995939&group_id=5470

Category: Core (C code)
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Dima Dorfman (ddorfman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Avoid calling tp_compare with different types

Initial Comment:
C implementations of the tp_compare slot usually expect both of their 
arguments to have the type for which that slot is defined (this isn't 
documented anywhere that I can find, but many core types assume this, 
and extension authors are likely to do the same). A problem occurs if a 
user-defined nb_coerce slot (__coerce__) returns objects with different 
types. Avoid the problem by refusing to call a non-Python tp_compare 
unless the arguments have the same type. Indiscriminately calling 
tp_compare with different types is wrong as long as there are 
implementations that don't check the type of the second argument, but 
Python implementations should be allowed to receive a different type.

Other options for fixing the problem:
  - Make PyNumber_CoerceEx require that the results have the same 
type. This would prevent a user-defined __coerce__ from 
communicating an arbitrary object to a user-defined __cmp__. 
Furthermore, there are uses for coerce besides comparison, and those 
uses might not require identical types.
  - Change tp_compare implementations to check the type of the 
second argument. This might be the most desirable long-term solution, 
but as I understand it, tp_richcompare is preferred over tp_compare for 
new code, and old (current) code is likely assuming that the types are 
the same.

Addresses bug #980352


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

>Comment By: Armin Rigo (arigo)
Date: 2004-12-23 22:14

Message:
Logged In: YES 
user_id=4771

I added a minor change after the coercion, to accept two 
objects not necessarily of the same type but with the same 
tp_compare.

Applied as planned in the 2.5 CVS as:

    Objects/object.c  rev 2.225
    Lib/test/test_coercion.py  rev 1.8


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

Comment By: Armin Rigo (arigo)
Date: 2004-08-12 16:27

Message:
Logged In: YES 
user_id=4771

Sorry, I did not read well enough what object.c was doing. 
I agree now that your patch should protect again all
crashes, and that the concern is whether it is too restrictive.

Before rich comparison, there was no obvious sane way to
directly compare objects of different types in C extension
types.  I remember having the problem back in Python 1.5.2;
at the time I solved the problem with an nb_coerce that
returned "fake" objects of a common type, and a tp_compare
that decoded these fake objects.  Now I see that it would
have been simpler to solve the problem by either:

1) writing a nb_coerce that doesn't do anything (but which
is implemented; otherwise tp_compare don't get called at all).
This is what would be broken by the present patch.

2) easier yet, just making sure that both types have the
same tp_compare slot.  We don't need nb_coerce at all in
this case.  The tp_compare would check for the type of both
arguments anyway.  The present patch wouldn't break that.

There is no other reasonable safe way that I can of to fix
the problem (1)...  But admitedly the whole issue is a bit
far-fetched.  So I'd suggest that the issue is deferred
until Python 2.4 is out, and then we put the patch into the
pre-2.5 CVS head.  It's a bit late in the 2.4 release
process to risk breaking potential C extension modules.

A note about the patch: in the first comment you say that v
and w have different types, but that's potentially wrong --
they could have the same type but no tp_compare slot.

The new single test introduced after PyNumber_CoerceEx()
might be too restrictive: it would be enough if v and w have
the same tp_compare slot after coercion.  Pushing things a
bit over the edge of sanity, we might ask "what if coercion
returns old-style instances, or something with
_PyObject_SlotCompare?".  So maybe we should try the whole
try_3way_compare again after coercion (without of course
trying to coerce more than once!).


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

Comment By: Dima Dorfman (ddorfman)
Date: 2004-08-05 09:29

Message:
Logged In: YES 
user_id=908995

The patch is intended to be complete, but it's certainly possible that I 
missed something. Every other call to tp_compare checks that the 
operands have the same type or the same compare function; the only 
exceptions are if one of operands passes PyInstance_Check or if it's 
_PyObject_SlotCompare (it's treated specially in try_3way_compare).

I'm actually more concerned about restricting too much than having 
missing something. The tests I wrote try to make sure that the 
user-visible changes are limited to the absence of a crash, but I'm not 
sure that I didn't accidently break some code that used to work.

Comparing subclasses of builtins to builtins still works, too. On line 599 
of the post-patch object.c, we see:

	/* If both have the same (non-NULL) tp_compare, use it. */
	if (f != NULL && f == w->ob_type->tp_compare) {
		c = (*f)(v, w);
		return adjust_tp_compare(c);
	}

which takes care of that case.

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

Comment By: Armin Rigo (arigo)
Date: 2004-08-03 09:36

Message:
Logged In: YES 
user_id=4771

Is your patch complete?  There seem to be a lot of places in object.c that call tp_compare slots.  Shouldn't we try to make sure that none of these places can ever be called with two different types?

It also looks like we have to do something special about a value of &_PyObject_SlotCompare in tp_compare, because this function from typeobject.c checks itself the type of its arguments and does specific things with them.  This should be thought about.

Moreover there is the issue of the user subclassing built-in types, e.g. PyInt_Type.tp_compare is capable of comparing different user subclasses of "int" for each other.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=995939&group_id=5470
From noreply at sourceforge.net  Fri Dec 24 15:10:27 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Dec 24 15:10:34 2004
Subject: [Patches] [ python-Patches-1062060 ] fix for 1016880
	urllib.urlretrieve silently truncates dwnld
Message-ID: <E1Chq9D-0007Xp-RI@sc8-sf-web1.sourceforge.net>

Patches item #1062060, was opened at 2004-11-07 21:15
Message generated for change (Comment added) made by irmen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062060&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 6
Submitted By: Irmen de Jong (irmen)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix for 1016880 urllib.urlretrieve silently truncates dwnld

Initial Comment:
The patch makes urllib.urlretrieve raise an IOError if
the actual download size is different from the expected
size (taken from the content-length header). 

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

>Comment By: Irmen de Jong (irmen)
Date: 2004-12-24 15:10

Message:
Logged In: YES 
user_id=129426

Yes I'm having trouble building the docs from source, so I
will just add the text that I would like to change in the docs.
When I have some time left (it's Christmas after all :) )
I'll also create a regression test for the new behavior.
In the meantime, the "urllib.patch" may be deleted because
"urllib.patch2" is the correct patch (I seem to be unable to
delete the attachment myself)

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-21 01:00

Message:
Logged In: YES 
user_id=80475

Irmin, please attach the new patch.

If you're having trouble with the docs, that's fine, just
include the text you want changed.

Do include tests with your patch.

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

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-12-06 22:48

Message:
Logged In: YES 
user_id=469548

Sorry Irmen, I'm a bit late with this, but now is the time
to get new "features" checked into the trunk. Could you add
a doc patch that explains the behavior as you did in your
previous message and a tests patch? I can check it in then.

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

Comment By: Irmen de Jong (irmen)
Date: 2004-11-07 21:54

Message:
Logged In: YES 
user_id=129426

NOTE:
urllib.patch2 may be a bit better. It fixes a misspelling,
and also is more relaxed about a 'wrong' download size.
To be more precise: it treats content-length as a lower
bound (just like wget and firefox appear to do). So if
there's more data to read, it  reads more data, but if less
data is available, it gives an IOError

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062060&group_id=5470
From noreply at sourceforge.net  Fri Dec 24 15:30:38 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Dec 24 15:30:42 2004
Subject: [Patches] [ python-Patches-1062060 ] fix for 1016880
	urllib.urlretrieve silently truncates dwnld
Message-ID: <E1ChqSk-0000Nz-04@sc8-sf-web4.sourceforge.net>

Patches item #1062060, was opened at 2004-11-07 21:15
Message generated for change (Comment added) made by irmen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062060&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 6
Submitted By: Irmen de Jong (irmen)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix for 1016880 urllib.urlretrieve silently truncates dwnld

Initial Comment:
The patch makes urllib.urlretrieve raise an IOError if
the actual download size is different from the expected
size (taken from the content-length header). 

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

>Comment By: Irmen de Jong (irmen)
Date: 2004-12-24 15:30

Message:
Logged In: YES 
user_id=129426

Suggested addition to the doc of urllib (liburllib.tex, if
I'm not mistaken):

"""

urlretrieve will raise IOError when it detects that the
amount of data available 
was less than the expected amount (which is the size
reported by a Content-Length
header). This can occur, for example, when the download is
interrupted.

The Content-Length is treated as a lower bound (just like
tools such as wget and 
Ffirefox appear to do): if there's more data to read,
urlretrieve reads more data, but 
if less data is available, it raises IOError.

If no Content-Length header was supplied, urlretrieve can
not check the size
of the data it has downloaded, and just returns it. In this
case you
just have to assume that the download was successful.
"""

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

Comment By: Irmen de Jong (irmen)
Date: 2004-12-24 15:10

Message:
Logged In: YES 
user_id=129426

Yes I'm having trouble building the docs from source, so I
will just add the text that I would like to change in the docs.
When I have some time left (it's Christmas after all :) )
I'll also create a regression test for the new behavior.
In the meantime, the "urllib.patch" may be deleted because
"urllib.patch2" is the correct patch (I seem to be unable to
delete the attachment myself)

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-21 01:00

Message:
Logged In: YES 
user_id=80475

Irmin, please attach the new patch.

If you're having trouble with the docs, that's fine, just
include the text you want changed.

Do include tests with your patch.

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

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-12-06 22:48

Message:
Logged In: YES 
user_id=469548

Sorry Irmen, I'm a bit late with this, but now is the time
to get new "features" checked into the trunk. Could you add
a doc patch that explains the behavior as you did in your
previous message and a tests patch? I can check it in then.

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

Comment By: Irmen de Jong (irmen)
Date: 2004-11-07 21:54

Message:
Logged In: YES 
user_id=129426

NOTE:
urllib.patch2 may be a bit better. It fixes a misspelling,
and also is more relaxed about a 'wrong' download size.
To be more precise: it treats content-length as a lower
bound (just like wget and firefox appear to do). So if
there's more data to read, it  reads more data, but if less
data is available, it gives an IOError

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062060&group_id=5470
From noreply at sourceforge.net  Sat Dec 25 01:12:11 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Dec 25 01:12:16 2004
Subject: [Patches] [ python-Patches-1090958 ] _AEModule.c patch
Message-ID: <E1ChzXX-0006g2-8n@sc8-sf-web4.sourceforge.net>

Patches item #1090958, was opened at 2004-12-25 00:12
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1090958&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: has (hhas)
Assigned to: Jack Jansen (jackjansen)
Summary: _AEModule.c patch

Initial Comment:
_AEModule.c patch to fix broken AEReplaceDescData and add 
AEInstallCoercionHandler, AERemoveCoercionHandler and 
AEGetCoercionHandler.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1090958&group_id=5470
From noreply at sourceforge.net  Mon Dec 27 13:13:55 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Dec 27 13:13:57 2004
Subject: [Patches] [ python-Patches-1091679 ] py-compile DESTDIR support to
	compile in correct paths
Message-ID: <E1Citl5-00051P-Bq@sc8-sf-web2.sourceforge.net>

Patches item #1091679, was opened at 2004-12-27 13:13
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1091679&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Vander Stichele (thomasvs)
Assigned to: Nobody/Anonymous (nobody)
Summary: py-compile DESTDIR support to compile in correct paths

Initial Comment:
Lots of rpms of python software have the wrong ?file
path? compiled into their byte-compiled versions. So
when you get tracbacks, you see stuff like
?/usr/src/rpm/BUILD? or similar in the paths of the
installed python file. I?ve run into this for several
packages, but was too lazy to look at it.

I added a ?destdir option to py-compile.

I *think* this should go into automake, but I was asked
by Sean Reifschneider to put it here.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1091679&group_id=5470
From noreply at sourceforge.net  Mon Dec 27 13:14:24 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Dec 27 13:14:32 2004
Subject: [Patches] [ python-Patches-1091679 ] py-compile DESTDIR support to
	compile in correct paths
Message-ID: <E1CitlY-000529-Qo@sc8-sf-web2.sourceforge.net>

Patches item #1091679, was opened at 2004-12-27 13:13
Message generated for change (Settings changed) made by thomasvs
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1091679&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Vander Stichele (thomasvs)
>Assigned to: Sean Reifschneider (jafo)
Summary: py-compile DESTDIR support to compile in correct paths

Initial Comment:
Lots of rpms of python software have the wrong ?file
path? compiled into their byte-compiled versions. So
when you get tracbacks, you see stuff like
?/usr/src/rpm/BUILD? or similar in the paths of the
installed python file. I?ve run into this for several
packages, but was too lazy to look at it.

I added a ?destdir option to py-compile.

I *think* this should go into automake, but I was asked
by Sean Reifschneider to put it here.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1091679&group_id=5470
From noreply at sourceforge.net  Mon Dec 27 17:24:38 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Dec 27 17:24:47 2004
Subject: [Patches] [ python-Patches-1091679 ] py-compile DESTDIR support to
	compile in correct paths
Message-ID: <E1Cixfi-00036O-4K@sc8-sf-web4.sourceforge.net>

Patches item #1091679, was opened at 2004-12-27 13:13
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1091679&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Vander Stichele (thomasvs)
Assigned to: Sean Reifschneider (jafo)
Summary: py-compile DESTDIR support to compile in correct paths

Initial Comment:
Lots of rpms of python software have the wrong ?file
path? compiled into their byte-compiled versions. So
when you get tracbacks, you see stuff like
?/usr/src/rpm/BUILD? or similar in the paths of the
installed python file. I?ve run into this for several
packages, but was too lazy to look at it.

I added a ?destdir option to py-compile.

I *think* this should go into automake, but I was asked
by Sean Reifschneider to put it here.

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

>Comment By: Martin v. L?wis (loewis)
Date: 2004-12-27 17:24

Message:
Logged In: YES 
user_id=21627

What is the rationale for putting it, beyond that Sean
Reifschneider said so? py-compile is not part of Python, AFAICT.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1091679&group_id=5470
From noreply at sourceforge.net  Mon Dec 27 17:36:08 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Dec 27 17:36:14 2004
Subject: [Patches] [ python-Patches-1091679 ] py-compile DESTDIR support to
	compile in correct paths
Message-ID: <E1Cixqq-0003ad-Vf@sc8-sf-web4.sourceforge.net>

Patches item #1091679, was opened at 2004-12-27 13:13
Message generated for change (Comment added) made by thomasvs
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1091679&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Vander Stichele (thomasvs)
Assigned to: Sean Reifschneider (jafo)
Summary: py-compile DESTDIR support to compile in correct paths

Initial Comment:
Lots of rpms of python software have the wrong ?file
path? compiled into their byte-compiled versions. So
when you get tracbacks, you see stuff like
?/usr/src/rpm/BUILD? or similar in the paths of the
installed python file. I?ve run into this for several
packages, but was too lazy to look at it.

I added a ?destdir option to py-compile.

I *think* this should go into automake, but I was asked
by Sean Reifschneider to put it here.

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

>Comment By: Thomas Vander Stichele (thomasvs)
Date: 2004-12-27 17:36

Message:
Logged In: YES 
user_id=197434

There is no other rationale.  He asked me to log it here, so
I did.

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

Comment By: Martin v. L?wis (loewis)
Date: 2004-12-27 17:24

Message:
Logged In: YES 
user_id=21627

What is the rationale for putting it, beyond that Sean
Reifschneider said so? py-compile is not part of Python, AFAICT.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1091679&group_id=5470
From noreply at sourceforge.net  Tue Dec 28 20:50:53 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Dec 28 20:50:56 2004
Subject: [Patches] [ python-Patches-678531 ] zlib module needs decompress
	flush.
Message-ID: <E1CjNMr-00078I-0z@sc8-sf-web4.sourceforge.net>

Patches item #678531, was opened at 2003-01-31 22:13
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=678531&group_id=5470

Category: Modules
Group: None
Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Scott David Daniels (scott_daniels)
Assigned to: Nobody/Anonymous (nobody)
Summary: zlib module needs decompress flush.

Initial Comment:
Python 2.3 current (should work on 2,1 and 2.2 as well)
OS: Win2K

The zlibmodule.c sources mistakenly don't implement 
flush() on decompression objects.  The assumption is
that all data will have been extracted once all of the 
source is available.
This patch simply implements flush in the obvious way.
As mentioned in bug #640230, the previous test did not
successfully test the decompression object.

I'll attach in a subsequent patch a PyUnit-style
test_zlib.py 
that exercises zlib and checks the buffer flushing (because
I don't see how to attach two files).

-Scott




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

>Comment By: A.M. Kuchling (akuchling)
Date: 2004-12-28 14:50

Message:
Logged In: YES 
user_id=11375

Looking at the code much later, I'm wondering why the
flush() method takes a single integer argument that's used
as the starting size of the output buffer.  This argument
isn't documented and doesn't seem to be invoked by the test
suite (I thought it might be an internal testing feature). 
Scott, was this argument added intentionally?


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-03 15:53

Message:
Logged In: YES 
user_id=6380

All checked in. Thanks!

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=678531&group_id=5470
From noreply at sourceforge.net  Wed Dec 29 00:48:13 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Dec 29 00:48:22 2004
Subject: [Patches] [ python-Patches-1091679 ] py-compile DESTDIR support to
	compile in correct paths
Message-ID: <E1CjR4X-0006Ng-Sw@sc8-sf-web2.sourceforge.net>

Patches item #1091679, was opened at 2004-12-27 12:13
Message generated for change (Comment added) made by jafo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1091679&group_id=5470

Category: None
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Thomas Vander Stichele (thomasvs)
Assigned to: Sean Reifschneider (jafo)
Summary: py-compile DESTDIR support to compile in correct paths

Initial Comment:
Lots of rpms of python software have the wrong ?file
path? compiled into their byte-compiled versions. So
when you get tracbacks, you see stuff like
?/usr/src/rpm/BUILD? or similar in the paths of the
installed python file. I?ve run into this for several
packages, but was too lazy to look at it.

I added a ?destdir option to py-compile.

I *think* this should go into automake, but I was asked
by Sean Reifschneider to put it here.

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

>Comment By: Sean Reifschneider (jafo)
Date: 2004-12-28 23:48

Message:
Logged In: YES 
user_id=81797

Ugh, you're right.  I was thinking compileall.  It looks
like py-compile is part of automake, and according to:

   http://sources.redhat.com/automake/#lists

it should be submitted by e-mail to:

   automake-patches@gnu.org

I can send this for you if you would prefer.  I'll close
this for the moment.

Thanks,
Sean

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

Comment By: Thomas Vander Stichele (thomasvs)
Date: 2004-12-27 16:36

Message:
Logged In: YES 
user_id=197434

There is no other rationale.  He asked me to log it here, so
I did.

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

Comment By: Martin v. L?wis (loewis)
Date: 2004-12-27 16:24

Message:
Logged In: YES 
user_id=21627

What is the rationale for putting it, beyond that Sean
Reifschneider said so? py-compile is not part of Python, AFAICT.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1091679&group_id=5470
From noreply at sourceforge.net  Wed Dec 29 09:00:18 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Dec 29 09:00:29 2004
Subject: [Patches] [ python-Patches-1067760 ] fix for 1067728: Better
	handling of float arguments to seek
Message-ID: <E1CjYkk-0000Bp-J0@sc8-sf-web1.sourceforge.net>

Patches item #1067760, was opened at 2004-11-16 17:28
Message generated for change (Comment added) made by titus
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1067760&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Robert Church (churchr)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix for 1067728: Better handling of float arguments to seek

Initial Comment:
Instead of converting all float arguments to ints, this
first attempts to 
convert the argument to a PyLong, and then the old
conversion code takes over.

The upshot is that the limit of floating point
arguments to seek() is raised from (2 ** 32) - 1 to
somewhere above (2 ** 62).

Perhaps a better way to handle this would be to not
accept floating point arguments to seek().

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

Comment By: Titus Brown (titus)
Date: 2004-12-29 00:00

Message:
Logged In: YES 
user_id=23486

Updated patch to check return value of PyErr_Warn in case 'python -W 
error'  is specified.  No other objections raised on python-dev...

revised patch still at
http://issola.caltech.edu/~t/transfer/patch-1067760-seekwarn.diff

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

Comment By: Titus Brown (titus)
Date: 2004-12-23 00:29

Message:
Logged In: YES 
user_id=23486

Bob Ippolito pointed out that nowadays float-->int conversion of
arguments is deprecated; a DeprecationWarning wasn't being raised 
because conversion was done manually in seek.  Patch to fix this
at

http://issola.caltech.edu/~t/transfer/patch-1067760-seekwarn.diff

Linux RH 9.0 works, regression tests run w/o problem.

The patch is against the current HEAD but can probably be backported w/
o a problem.

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

Comment By: Titus Brown (titus)
Date: 2004-12-19 01:38

Message:
Logged In: YES 
user_id=23486

Sorry, I should add: patch works against head on Linux RH 9.0 (and 
should work everywhere).  Behavior tested with a script.

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

Comment By: Titus Brown (titus)
Date: 2004-12-19 01:37

Message:
Logged In: YES 
user_id=23486

The patch works against HEAD; updated for line numbers (there's a very 
similar set of line elsewhere in the file):

http://issola.caltech.edu/~t/transfer/patch-1067760-seek.diff

rhettinger thought the current behavior was reasonable (see bug 
1067728).  I'm not qualified to comment ;) but it seems odd that floats 
would have drastically different limits than longs.  This looks like a 
reasonable compromise IMO.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1067760&group_id=5470
From noreply at sourceforge.net  Thu Dec 30 13:50:06 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Dec 30 13:50:09 2004
Subject: [Patches] [ python-Patches-1093253 ] Refactoring Python/import.c
Message-ID: <E1Cjzkk-0002oo-AH@sc8-sf-web3.sourceforge.net>

Patches item #1093253, was opened at 2004-12-30 13:50
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1093253&group_id=5470

Category: Core (C code)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Nobody/Anonymous (nobody)
Summary: Refactoring Python/import.c

Initial Comment:
This patch refactores Python/import.c.

find_module() was changed to return an PyObject*
pointer which contains the module's pathname, instead
of filling out a char* buffer.

load_module() accepts the PyObject* pathname instead of
a char*.

The patch is probably missing some error checking, and
the 8 character hack for loading extensions on OS2 is
not implemented, but the test case runs without errors
on Windows XP pro.

If a change in spirit of this patch is accepted, I'm
willing to further work on it so that eventually
unicode entries on sys.path, which can not be encoded
with the default file system encodings, will work as
expected (currently they don't).

See also:
http://mail.python.org/pipermail/python-list/2004-December/256969.html

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1093253&group_id=5470
From noreply at sourceforge.net  Thu Dec 30 21:57:32 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Dec 30 21:57:34 2004
Subject: [Patches] [ python-Patches-1093468 ] socket leak in SocketServer
Message-ID: <E1Ck7MS-0007vk-1X@sc8-sf-web1.sourceforge.net>

Patches item #1093468, was opened at 2004-12-30 12:57
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1093468&group_id=5470

Category: Library (Lib)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Shannon -jj Behrens (jjinux)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket leak in SocketServer

Initial Comment:
Found in Python 2.3.4 but still present in 2.5.
FreeBSD 4.9

Summary:
Fixed a socket leak in
SocketServer.StreamRequestHandler that happens during
certain exceptions.

Longer version:
SocketServer.StreamRequestHandler.setup sets up
self.rfile and self.wfile.  The parent class,
SocketServer.BaseRequestHandler.__init__ does not call
self.finish() if there is an exception thrown in
self.handle().  Hence, such an exception leads to a
leaked socket, because
SocketServer.StreamRequestHandler.finish never gets
called.  This is a one line patch that fixes that.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1093468&group_id=5470
From noreply at sourceforge.net  Fri Dec 31 03:22:08 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Dec 31 03:22:11 2004
Subject: [Patches] [ python-Patches-1093585 ] sanity check for readline
	remove/replace
Message-ID: <E1CkCQa-0000lN-1t@sc8-sf-web3.sourceforge.net>

Patches item #1093585, was opened at 2004-12-30 21:22
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1093585&group_id=5470

Category: Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: DSM (dsm001)
Assigned to: Nobody/Anonymous (nobody)
Summary: sanity check for readline remove/replace

Initial Comment:
Fix bug 1086603 (segfault in readline) by checking for
negative input indices in remove_history_item and
replace_history_item; GNU code doesn't always return NULL.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1093585&group_id=5470
From noreply at sourceforge.net  Fri Dec 31 10:46:28 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Dec 31 10:46:35 2004
Subject: [Patches] [ python-Patches-1011890 ] fix inspect.getsource breaking
	with line-continuation & more
Message-ID: <E1CkJMa-0007ZQ-Vf@sc8-sf-web2.sourceforge.net>

Patches item #1011890, was opened at 2004-08-19 03:11
Message generated for change (Comment added) made by jlgijsbers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1011890&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Simon Percivall (percivall)
Assigned to: Johannes Gijsbers (jlgijsbers)
Summary: fix inspect.getsource breaking with line-continuation & more

Initial Comment:
The patch makes changes to inspect.py in two places:

* the pattern to match against functions at line 436 is
modified: lambdas should be matched even if not
preceded by whitespace, as long as "lambda" isn't part
of another word.

* the BlockFinder class is heavily modified. Changes are: 
  - checking for "def", "class" or "lambda" names
before setting self.started to True. Then checking the
same line for word characters after the colon (if the
colon is on that line). If so, and the line does not
end with a line continuation marker, raise EndOfBlock
immediately.
  - adding self.passline to show that the line is to be
included and no more checking is necessary on that
line. Since a NEWLINE token is not generated when a
line continuation marker exists, this allows getsource
to continue with these functions even if the following
line would not be indented.

The patch might be making a mess of the simple code,
and code such as code it now handles will probably not
be seen often. Still, it fixes the first bug shown in
"www.python.org/sf/769569".

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

>Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-12-31 10:46

Message:
Logged In: YES 
user_id=469548

Sorry for getting to this so late, but it's still before
2.4.1, right? I've checked in the patch as rev. 1.58.2.1.

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

Comment By: Simon Percivall (percivall)
Date: 2004-12-13 12:37

Message:
Logged In: YES 
user_id=329382

Shouldn't this be considered a bug fix though? What I mean is: Shouldn't 
the patch also be checked in to the 2.4 maintain branch? Perhaps the 
ported test_inspect is a problem, but the patch itself ...

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

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-12-12 17:47

Message:
Logged In: YES 
user_id=469548

Well, it took a bit longer to get test_inspect ported to
unittest, but it's done now. I've also checked this in.
Thanks for the patch!

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

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-19 19:21

Message:
Logged In: YES 
user_id=469548

Looks very good. I've made some small changes:

- Moved the __main__ section into a test_main() block for
running by regrtest.py
- Used the run_unittest function from test_support.py
- De-abbreviated some of the test methods
- Used comments instead of docstrings: unittest prints the
docstring of a test method instead of the name of the test
method when failing, making the failing method harder to find.

Apart from that, it looks like checkin-quality to me. Still,
it's kind of ugly to have a two separate files and two
separate methods for testing the same module, so I guess
that means I'll be converting test_inspect to unittest. I'll
try to work on that tonight and post it to
http://python.org/sf/736962 tomorrow. I'll merge these tests
into the new test_inspect after it's checked in.

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

Comment By: Simon Percivall (percivall)
Date: 2004-08-19 03:25

Message:
Logged In: YES 
user_id=329382

BTW: inspect.py CVS HEAD passes three of the tests:
test_oll, test_tlli and test_onelinefunc.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1011890&group_id=5470
From noreply at sourceforge.net  Fri Dec 31 14:57:04 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Dec 31 14:57:08 2004
Subject: [Patches] [ python-Patches-1093253 ] Refactoring Python/import.c
Message-ID: <E1CkNH6-0003ez-CC@sc8-sf-web3.sourceforge.net>

Patches item #1093253, was opened at 2004-12-30 12:50
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1093253&group_id=5470

Category: Core (C code)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Nobody/Anonymous (nobody)
Summary: Refactoring Python/import.c

Initial Comment:
This patch refactores Python/import.c.

find_module() was changed to return an PyObject*
pointer which contains the module's pathname, instead
of filling out a char* buffer.

load_module() accepts the PyObject* pathname instead of
a char*.

The patch is probably missing some error checking, and
the 8 character hack for loading extensions on OS2 is
not implemented, but the test case runs without errors
on Windows XP pro.

If a change in spirit of this patch is accepted, I'm
willing to further work on it so that eventually
unicode entries on sys.path, which can not be encoded
with the default file system encodings, will work as
expected (currently they don't).

See also:
http://mail.python.org/pipermail/python-list/2004-December/256969.html

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

>Comment By: Michael Hudson (mwh)
Date: 2004-12-31 13:57

Message:
Logged In: YES 
user_id=6656

Applied the patch and built on OS X.  This was the result:

$ ./python.exe 
'import site' failed; use -v for traceback
../Python/import.c:1496: failed assertion `dirlen <= MAXPATHLEN'
Abort trap

dirlen is 796092779, which seems fishy :)  An uninitialized variable, 
maybe?  Haven't looked, really...


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1093253&group_id=5470
From noreply at sourceforge.net  Fri Dec 31 15:11:47 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Dec 31 15:11:52 2004
Subject: [Patches] [ python-Patches-1093253 ] Refactoring Python/import.c
Message-ID: <E1CkNVL-0006DW-QL@sc8-sf-web1.sourceforge.net>

Patches item #1093253, was opened at 2004-12-30 13:50
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1093253&group_id=5470

Category: Core (C code)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Nobody/Anonymous (nobody)
Summary: Refactoring Python/import.c

Initial Comment:
This patch refactores Python/import.c.

find_module() was changed to return an PyObject*
pointer which contains the module's pathname, instead
of filling out a char* buffer.

load_module() accepts the PyObject* pathname instead of
a char*.

The patch is probably missing some error checking, and
the 8 character hack for loading extensions on OS2 is
not implemented, but the test case runs without errors
on Windows XP pro.

If a change in spirit of this patch is accepted, I'm
willing to further work on it so that eventually
unicode entries on sys.path, which can not be encoded
with the default file system encodings, will work as
expected (currently they don't).

See also:
http://mail.python.org/pipermail/python-list/2004-December/256969.html

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

>Comment By: Thomas Heller (theller)
Date: 2004-12-31 15:11

Message:
Logged In: YES 
user_id=11105

Yes, I overlooked that the initialization of the variables
is inside an #if defined(MS_WINDOWS) block.
Probably it would be better to leave the signature of
case_ok() as before and call it through a wrapper which
converts the arguments.

I will prepare a new patch in a few days.

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

Comment By: Michael Hudson (mwh)
Date: 2004-12-31 14:57

Message:
Logged In: YES 
user_id=6656

Applied the patch and built on OS X.  This was the result:

$ ./python.exe 
'import site' failed; use -v for traceback
../Python/import.c:1496: failed assertion `dirlen <= MAXPATHLEN'
Abort trap

dirlen is 796092779, which seems fishy :)  An uninitialized variable, 
maybe?  Haven't looked, really...


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1093253&group_id=5470
From noreply at sourceforge.net  Fri Dec 31 15:17:17 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Dec 31 15:17:21 2004
Subject: [Patches] [ python-Patches-1093253 ] Refactoring Python/import.c
Message-ID: <E1CkNaf-0006Tw-0O@sc8-sf-web2.sourceforge.net>

Patches item #1093253, was opened at 2004-12-30 12:50
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1093253&group_id=5470

Category: Core (C code)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Nobody/Anonymous (nobody)
Summary: Refactoring Python/import.c

Initial Comment:
This patch refactores Python/import.c.

find_module() was changed to return an PyObject*
pointer which contains the module's pathname, instead
of filling out a char* buffer.

load_module() accepts the PyObject* pathname instead of
a char*.

The patch is probably missing some error checking, and
the 8 character hack for loading extensions on OS2 is
not implemented, but the test case runs without errors
on Windows XP pro.

If a change in spirit of this patch is accepted, I'm
willing to further work on it so that eventually
unicode entries on sys.path, which can not be encoded
with the default file system encodings, will work as
expected (currently they don't).

See also:
http://mail.python.org/pipermail/python-list/2004-December/256969.html

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

>Comment By: Michael Hudson (mwh)
Date: 2004-12-31 14:17

Message:
Logged In: YES 
user_id=6656

Perhaps there should be multiple implementations of case_ok ... i.e.

#if PLAT1
int case_ok(...)
{
...
}
#elif PLAT2
int case_ok(...)
{
...
}
#endif

the current spaghetti is confusing, even by the standards of import.c...

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

Comment By: Thomas Heller (theller)
Date: 2004-12-31 14:11

Message:
Logged In: YES 
user_id=11105

Yes, I overlooked that the initialization of the variables
is inside an #if defined(MS_WINDOWS) block.
Probably it would be better to leave the signature of
case_ok() as before and call it through a wrapper which
converts the arguments.

I will prepare a new patch in a few days.

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

Comment By: Michael Hudson (mwh)
Date: 2004-12-31 13:57

Message:
Logged In: YES 
user_id=6656

Applied the patch and built on OS X.  This was the result:

$ ./python.exe 
'import site' failed; use -v for traceback
../Python/import.c:1496: failed assertion `dirlen <= MAXPATHLEN'
Abort trap

dirlen is 796092779, which seems fishy :)  An uninitialized variable, 
maybe?  Haven't looked, really...


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1093253&group_id=5470
From noreply at sourceforge.net  Fri Dec 31 22:01:44 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Dec 31 22:01:47 2004
Subject: [Patches] [ python-Patches-1093896 ] miscellaneous doc typos
Message-ID: <E1CkTu4-000169-7s@sc8-sf-web1.sourceforge.net>

Patches item #1093896, was opened at 2004-12-31 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=305470&aid=1093896&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: DSM (dsm001)
Assigned to: Nobody/Anonymous (nobody)
Summary: miscellaneous doc typos

Initial Comment:
Various copyedits for docs.

[We'll see if I escape Skitt's law or not!]


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

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