From noreply at sourceforge.net  Mon Jul  2 16:33:37 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 02 Jul 2007 07:33:37 -0700
Subject: [Patches] [ python-Patches-1741308 ] Fix Decimal.sqrt bugs
	described in #1725899
Message-ID: <E1I5My9-0003rd-Nb@sc8-sf-web22.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Mark Dickinson (marketdickinson)
Assigned to: Facundo Batista (facundobatista)
Summary: Fix Decimal.sqrt bugs described in #1725899

Initial Comment:
This patch fixes a number of (yet-to-be-confirmed-as-) bugs in Decimal.sqrt();  see bug report 1725899 for details of these.

As a side benefit the modified version of Decimal.sqrt() runs significantly faster than the original, since it's based on integer arithmetic instead of carrying out Newton's method entirely in decimal;  on my iBook G4 the speedup is between 20 and 25 times with the default precision.

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

>Comment By: Mark Dickinson (marketdickinson)
Date: 2007-07-02 14:33

Message:
Logged In: YES 
user_id=703403
Originator: YES

Here's an updated patch, with:
 -- several hundred extra testcases, in a new file
squareroot_extra.decTest
 -- fixes for two bugs in the previous patch; one where the context
rounding mode was occasionally used instead of ROUND-HALF-EVEN, and one
involving underflow to 0.
 -- a fix for the following problem in Decimal._fixexponents():  (should I
submit a separate patch for this instead?)

>>> from decimal import *
>>> getcontext().Emax = 9
>>> getcontext().Emin = -9
>>> getcontext()._clamp = 1
>>> +Decimal("1E10")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/local/lib/python2.5/decimal.py", line 935, in __pos__
    ans = self._fix(context)
  File "/opt/local/lib/python2.5/decimal.py", line 1530, in _fix
    ans = self._fixexponents(context)
  File "/opt/local/lib/python2.5/decimal.py", line 1565, in _fixexponents
    ans = ans._rescale(Etop, context=context)
  File "/opt/local/lib/python2.5/decimal.py", line 1913, in _rescale
    return context._raise_error(InvalidOperation, 'Rescale > prec')
  File "/opt/local/lib/python2.5/decimal.py", line 2325, in _raise_error
    raise error, explanation
decimal.InvalidOperation: Rescale > prec

I've been in contact with Cowlishaw;  he's agreed that it looks as though
the C reference implementation needs a few changes, but hasn't had a chance
to look at things properly yet;  I've sent him the extra testcases above as
well.  Please let me know if there's anything else I can do to help.

Mark

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

Comment By: Facundo Batista (facundobatista)
Date: 2007-06-22 12:29

Message:
Logged In: YES 
user_id=752496
Originator: NO

Yes, I'll handle this and the mentioned bug. Thanks.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-06-22 07:09

Message:
Logged In: YES 
user_id=33168
Originator: NO

Facundo, could you take a look?

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

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

From noreply at sourceforge.net  Mon Jul  2 16:34:40 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 02 Jul 2007 07:34:40 -0700
Subject: [Patches] [ python-Patches-1741308 ] Fix Decimal.sqrt bugs
	described in #1725899
Message-ID: <E1I5MzA-0000k9-7v@sc8-sf-web21.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Mark Dickinson (marketdickinson)
Assigned to: Facundo Batista (facundobatista)
Summary: Fix Decimal.sqrt bugs described in #1725899

Initial Comment:
This patch fixes a number of (yet-to-be-confirmed-as-) bugs in Decimal.sqrt();  see bug report 1725899 for details of these.

As a side benefit the modified version of Decimal.sqrt() runs significantly faster than the original, since it's based on integer arithmetic instead of carrying out Newton's method entirely in decimal;  on my iBook G4 the speedup is between 20 and 25 times with the default precision.

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

>Comment By: Mark Dickinson (marketdickinson)
Date: 2007-07-02 14:34

Message:
Logged In: YES 
user_id=703403
Originator: YES

File Added: decimal_sqrt_2.patch

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

Comment By: Mark Dickinson (marketdickinson)
Date: 2007-07-02 14:33

Message:
Logged In: YES 
user_id=703403
Originator: YES

Here's an updated patch, with:
 -- several hundred extra testcases, in a new file
squareroot_extra.decTest
 -- fixes for two bugs in the previous patch; one where the context
rounding mode was occasionally used instead of ROUND-HALF-EVEN, and one
involving underflow to 0.
 -- a fix for the following problem in Decimal._fixexponents():  (should I
submit a separate patch for this instead?)

>>> from decimal import *
>>> getcontext().Emax = 9
>>> getcontext().Emin = -9
>>> getcontext()._clamp = 1
>>> +Decimal("1E10")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/local/lib/python2.5/decimal.py", line 935, in __pos__
    ans = self._fix(context)
  File "/opt/local/lib/python2.5/decimal.py", line 1530, in _fix
    ans = self._fixexponents(context)
  File "/opt/local/lib/python2.5/decimal.py", line 1565, in _fixexponents
    ans = ans._rescale(Etop, context=context)
  File "/opt/local/lib/python2.5/decimal.py", line 1913, in _rescale
    return context._raise_error(InvalidOperation, 'Rescale > prec')
  File "/opt/local/lib/python2.5/decimal.py", line 2325, in _raise_error
    raise error, explanation
decimal.InvalidOperation: Rescale > prec

I've been in contact with Cowlishaw;  he's agreed that it looks as though
the C reference implementation needs a few changes, but hasn't had a chance
to look at things properly yet;  I've sent him the extra testcases above as
well.  Please let me know if there's anything else I can do to help.

Mark

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

Comment By: Facundo Batista (facundobatista)
Date: 2007-06-22 12:29

Message:
Logged In: YES 
user_id=752496
Originator: NO

Yes, I'll handle this and the mentioned bug. Thanks.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-06-22 07:09

Message:
Logged In: YES 
user_id=33168
Originator: NO

Facundo, could you take a look?

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

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

From noreply at sourceforge.net  Mon Jul  2 18:36:34 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 02 Jul 2007 09:36:34 -0700
Subject: [Patches] [ python-Patches-1746656 ] IPv6 Interface naming/indexing
	functions
Message-ID: <E1I5Ot8-0007r4-Ec@sc8-sf-web24.sourceforge.net>

Patches item #1746656, was opened at 2007-07-02 18:36
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=1746656&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Michael Meier (meiermic)
Assigned to: Nobody/Anonymous (nobody)
Summary: IPv6 Interface naming/indexing functions

Initial Comment:
The Python socket module does not feature the functions declared in net/if.h even though they are essential to support IPv6 multicast to a reasonable extent. 

This patch adds a straightforward intertace to the three functions if_nameindex(), if_nametoindex() and if_indextoname().

I didn't add a testcase as I don't know what to test ;)


The patch seems to work on Ubuntu 7.04.


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

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

From rwq at grupogdev.com.mx  Wed Jul  4 09:35:52 2007
From: rwq at grupogdev.com.mx (Becky)
Date: Wed, 4 Jul 2007 08:35:52 +0100
Subject: [Patches] Fwd: complaint.3121c2a8ebeed.pdf
Message-ID: <468B4DD8.2060105@aha.org>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: complaint.3121c2a8ebeed.pdf
Type: application/pdf
Size: 13146 bytes
Desc: not available
Url : http://mail.python.org/pipermail/patches/attachments/20070704/6ad674a9/attachment.pdf 

From noreply at sourceforge.net  Wed Jul  4 11:54:37 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 04 Jul 2007 02:54:37 -0700
Subject: [Patches] [ python-Patches-1747670 ] Limiting data copy in xmlrpclib
Message-ID: <E1I61ZF-0007gR-2l@sc8-sf-web24.sourceforge.net>

Patches item #1747670, was opened at 2007-07-04 11:54
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=1747670&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Gael Le Mignot (kilobug)
Assigned to: Nobody/Anonymous (nobody)
Summary: Limiting data copy in xmlrpclib

Initial Comment:
Data going through the xmlrpclib are copied many times in Python. This creates problem when submitting blob of data in XML-RPC (I know the protocol is not aimed for that, but sometimes it's useful).

This little patch try to limit memory usage of xmlrpclib by adding a few optimizations.

I did the patch on Python 2.4 because it's what our customer is using, but it should work on Python 2.5 or more recent too.

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

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

From lhj at iname.com  Thu Jul  5 17:27:10 2007
From: lhj at iname.com (inbred)
Date: Thu, 5 Jul 2007 09:27:10 -0600
Subject: [Patches] Fwd: E-mail_56b9282e3.pdf
Message-ID: <468D0DCE.6050303@ptd.net>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: E-mail_56b9282e3.pdf
Type: application/pdf
Size: 15372 bytes
Desc: not available
Url : http://mail.python.org/pipermail/patches/attachments/20070705/96752b4e/attachment.pdf 

From noreply at sourceforge.net  Fri Jul  6 07:25:25 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 05 Jul 2007 22:25:25 -0700
Subject: [Patches] [ python-Patches-1492704 ] distinct error type from
	shutil.move()
Message-ID: <E1I6gJp-00009U-1I@sc8-sf-web24.sourceforge.net>

Patches item #1492704, was opened at 2006-05-21 20:08
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1492704&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Zooko O'Whielacronx (zooko)
Assigned to: Anthony Baxter (anthonybaxter)
Summary: distinct error type from shutil.move()

Initial Comment:
I need to call shutil.move() and be able to tell the
difference between an error such as access denied and
an error due to the two arguments being the same file.


--- old-dw/src/Lib/shutil.py    2006-05-22
00:06:02.000000000 -0300
+++ new-dw/src/Lib/shutil.py    2006-05-22
00:06:02.000000000 -0300
@@ -16,6 +16,9 @@
 class Error(exceptions.EnvironmentError):
     pass

+class SameFileError(Error):
+    pass
+
 def copyfileobj(fsrc, fdst, length=16*1024):
     """copy data from file-like object fsrc to
file-like object fdst"""
     while 1:
@@ -39,7 +42,7 @@
 def copyfile(src, dst):
     """Copy data from src to dst"""
     if _samefile(src, dst):
-        raise Error, "`%s` and `%s` are the same file"
% (src, dst)
+        raise SameFileError, "`%s` and `%s` are the
same file" % (src, dst)

     fsrc = None
     fdst = None



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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2007-07-05 22:25

Message:
Logged In: YES 
user_id=33168
Originator: NO

In order for patches to be applied, they require tests and doc updates as
appropriate.  Can you supply these updates and attach a patch with all the
changes?

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

Comment By: Zooko O'Whielacronx (zooko)
Date: 2007-06-28 08:08

Message:
Logged In: YES 
user_id=52562
Originator: YES

Dear Pythonistas: please apply this patch.  There is no reason not to, and
it enables programmers to use shutil more cleanly.


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

Comment By: Zooko O'Whielacronx (zooko)
Date: 2006-07-06 15:55

Message:
Logged In: YES 
user_id=52562

I'm not sure how to draw attention to my patch, so I will
try assigning it to anthonybaxter.  That ought to get attention.

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

Comment By: Zooko O'Whielacronx (zooko)
Date: 2006-07-06 15:53

Message:
Logged In: YES 
user_id=52562

Please apply.  This patch is completely backwards-compatible
and makes possible some uses of shutil.move().

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

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

From indi at egl.net  Fri Jul  6 10:46:02 2007
From: indi at egl.net (Waller Stanley)
Date: Fri, 6 Jul 2007 04:46:02 -0400
Subject: [Patches] E-mail.AFOSF.pdf attached
Message-ID: <468E014A.8020404@epix.net>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: E-mail.AFOSF.pdf
Type: application/pdf
Size: 20637 bytes
Desc: not available
Url : http://mail.python.org/pipermail/patches/attachments/20070706/77e612e6/attachment-0001.pdf 

From noreply at sourceforge.net  Fri Jul  6 12:06:20 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 06 Jul 2007 03:06:20 -0700
Subject: [Patches] [ python-Patches-1748960 ] Extra optional argument to
	os.path.expandvars
Message-ID: <E1I6khg-0000Fq-T0@sc8-sf-web24.sourceforge.net>

Patches item #1748960, was opened at 2007-07-06 12:06
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=1748960&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Geoffrey Bache (gjb1002)
Assigned to: Nobody/Anonymous (nobody)
Summary: Extra optional argument to os.path.expandvars

Initial Comment:
I've several times wanted to expand a string in the way that os.path.expandvars does, but without modifying the actual environment.

If for example I have 

inputString = "$ROOT/${SUBDIR}/some/path"

and I want to find expanded versions of this, I have to do something like

os.environ["ROOT"] = "/users/geoff"
os.environ["SUBDIR"] = "subdir"
fullPath = os.path.expandvars(inputString)

The problem is that my program is multithreaded and I don't want to globally change os.environ. All I want is the information "fullPath". I'd like to be able to create a local "env" dictionary and pass it to os.path.expandvars as an optional second argument.

I attach a patch for posixpath.py and ntpath.py, though this is untested and is intended to show what I mean in practice.


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

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

From noreply at sourceforge.net  Fri Jul  6 17:54:38 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 06 Jul 2007 08:54:38 -0700
Subject: [Patches] [ python-Patches-1748960 ] Extra optional argument to
	os.path.expandvars
Message-ID: <E1I6q8k-0004TC-TA@sc8-sf-web22.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Geoffrey Bache (gjb1002)
Assigned to: Nobody/Anonymous (nobody)
Summary: Extra optional argument to os.path.expandvars

Initial Comment:
I've several times wanted to expand a string in the way that os.path.expandvars does, but without modifying the actual environment.

If for example I have 

inputString = "$ROOT/${SUBDIR}/some/path"

and I want to find expanded versions of this, I have to do something like

os.environ["ROOT"] = "/users/geoff"
os.environ["SUBDIR"] = "subdir"
fullPath = os.path.expandvars(inputString)

The problem is that my program is multithreaded and I don't want to globally change os.environ. All I want is the information "fullPath". I'd like to be able to create a local "env" dictionary and pass it to os.path.expandvars as an optional second argument.

I attach a patch for posixpath.py and ntpath.py, though this is untested and is intended to show what I mean in practice.


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

>Comment By: Geoffrey Bache (gjb1002)
Date: 2007-07-06 17:54

Message:
Logged In: YES 
user_id=769182
Originator: YES

I've now attached a better patch, which is tested at least on UNIX for
now. Decided it was better if the optional argument was a function to
replace os.getenv, as then it can be called only on demand and there isn't
a need to set up information unnecessarily, or call any code more than
once.

File Added: patch

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

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

From noreply at sourceforge.net  Fri Jul  6 19:51:17 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 06 Jul 2007 10:51:17 -0700
Subject: [Patches] [ python-Patches-1744382 ] Read Write lock
Message-ID: <E1I6rxd-0006vd-CS@sc8-sf-web24.sourceforge.net>

Patches item #1744382, was opened at 2007-06-27 20:08
Message generated for change (Comment added) made by loupgaroublond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1744382&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Modules
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Yaakov Nemoy (loupgaroublond)
Assigned to: Nobody/Anonymous (nobody)
Summary: Read Write lock

Initial Comment:
This is a Lock for handling both multiple readers and a single or multiple writers.  It allows any number of readers to acquire a 'lock' via a modified semaphore.  It also allows any number of writers to try to acquire a lock, which signals the lock to block new readers from acquiring, until the writers have had a chance to do their business.  Through a simple lock, multiple writers can wait in line, although only one writer can actually write at a time.

It also lets the developer use the 'with' statement, via  methods that return contextmanagers.

I actually had a couple of unimplemented ideas.

A) Writers can specify a deadline (or even use a default) such that after the deadline passes, the lock can use a callback to rollback/kill/pause readers, so that the writer doesn't wait an eternity.

B) Allowing the semaphore to have an upper limit of allowed readers (or anythings), Since I don't need it, i never programmed it, but it should be fairly trivial to implement if there is any demand.

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

>Comment By: Yaakov Nemoy (loupgaroublond)
Date: 2007-07-06 19:51

Message:
Logged In: YES 
user_id=1487908
Originator: YES

Out of those four deliverables, i have three (albeit the easiest). 
Attached is a copy of the newly dubbed ReadWriteLock along with his pal
ReverseSemaphore, and two new helper objects ReadLock and WriteLock (can
you do the java equivalent of anonymous inner classes?).  This is a patch
on the copy of threading.py that is delivered with Fedora 7 aka:
Version: 2.5
Release: 12.fc7

which was done for convenience (my convenience that is, and certainly not
yours ;))

The naming convention has been changed to follow that of Java's, the
acquire/release pattern notwithstanding.  There is some documentation via
docstrings, as I wasn't sure of the best way to document this module.

The last point, unit testing, I am not sure as the best way to go about a
multithreaded unit test.  I can look into it later, but honestly, it's
friday, and there are two days left till monday.

Please let me know if I am on the right track here at least.

Yaakov
File Added: threading.py

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

Comment By: Martin v. L?wis (loewis)
Date: 2007-06-30 19:38

Message:
Logged In: YES 
user_id=21627
Originator: NO

The patch is unacceptable in its current form:
- it should be provided as a patch to threading.py, not as a separate
module
- it should have a name that follows "the convention", which seems to be
that 
  it should have "reader" and "writer" in its name (or "rw"). See how C#
and
  Java do it (and other libraries you can find that provide such a
mechanism)
- it needs documentation
- it needs tests.

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

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

From noreply at sourceforge.net  Fri Jul  6 23:58:16 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 06 Jul 2007 14:58:16 -0700
Subject: [Patches] [ python-Patches-1744382 ] Read Write lock
Message-ID: <E1I6voe-00019a-6c@sc8-sf-web23.sourceforge.net>

Patches item #1744382, was opened at 2007-06-27 20:08
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1744382&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Modules
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Yaakov Nemoy (loupgaroublond)
Assigned to: Nobody/Anonymous (nobody)
Summary: Read Write lock

Initial Comment:
This is a Lock for handling both multiple readers and a single or multiple writers.  It allows any number of readers to acquire a 'lock' via a modified semaphore.  It also allows any number of writers to try to acquire a lock, which signals the lock to block new readers from acquiring, until the writers have had a chance to do their business.  Through a simple lock, multiple writers can wait in line, although only one writer can actually write at a time.

It also lets the developer use the 'with' statement, via  methods that return contextmanagers.

I actually had a couple of unimplemented ideas.

A) Writers can specify a deadline (or even use a default) such that after the deadline passes, the lock can use a callback to rollback/kill/pause readers, so that the writer doesn't wait an eternity.

B) Allowing the semaphore to have an upper limit of allowed readers (or anythings), Since I don't need it, i never programmed it, but it should be fairly trivial to implement if there is any demand.

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

>Comment By: Martin v. L?wis (loewis)
Date: 2007-07-06 23:58

Message:
Logged In: YES 
user_id=21627
Originator: NO

I'm skeptical about the implementation strategy chosen, in particular
about the notion of a reversed semaphore, which I have never heard of. Is
there prior art for such a construct?
Traditionally, rw locks provide certain fairness guarantees - why doesn't
this implementation? To put it more bluntly: why is that so extravagant?

As for the style of the patch itself:
- please provide it as a unified or context diff. Making it relative to
some released 2.5 version is fine.
- please drop the redundant pass statements
- documentation patches should be made against Doc/lib/libthreading.tex.
If you cannot write LaTeX, just adding sections in plain text is fine.
- tests should be added to Lib/test/test_threading.py

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

Comment By: Yaakov Nemoy (loupgaroublond)
Date: 2007-07-06 19:51

Message:
Logged In: YES 
user_id=1487908
Originator: YES

Out of those four deliverables, i have three (albeit the easiest). 
Attached is a copy of the newly dubbed ReadWriteLock along with his pal
ReverseSemaphore, and two new helper objects ReadLock and WriteLock (can
you do the java equivalent of anonymous inner classes?).  This is a patch
on the copy of threading.py that is delivered with Fedora 7 aka:
Version: 2.5
Release: 12.fc7

which was done for convenience (my convenience that is, and certainly not
yours ;))

The naming convention has been changed to follow that of Java's, the
acquire/release pattern notwithstanding.  There is some documentation via
docstrings, as I wasn't sure of the best way to document this module.

The last point, unit testing, I am not sure as the best way to go about a
multithreaded unit test.  I can look into it later, but honestly, it's
friday, and there are two days left till monday.

Please let me know if I am on the right track here at least.

Yaakov
File Added: threading.py

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

Comment By: Martin v. L?wis (loewis)
Date: 2007-06-30 19:38

Message:
Logged In: YES 
user_id=21627
Originator: NO

The patch is unacceptable in its current form:
- it should be provided as a patch to threading.py, not as a separate
module
- it should have a name that follows "the convention", which seems to be
that 
  it should have "reader" and "writer" in its name (or "rw"). See how C#
and
  Java do it (and other libraries you can find that provide such a
mechanism)
- it needs documentation
- it needs tests.

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

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

From ajdif at jdpa.com  Sat Jul  7 08:58:00 2007
From: ajdif at jdpa.com (magnolia)
Date: Sat, 7 Jul 2007 01:58:00 -0500
Subject: [Patches] info_4606227352608.pdf attached
Message-ID: <468F3978.8000300@bnet.net.tr>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: info_4606227352608.pdf
Type: application/pdf
Size: 23134 bytes
Desc: not available
Url : http://mail.python.org/pipermail/patches/attachments/20070707/c9ca126a/attachment-0001.pdf 

From noreply at sourceforge.net  Sat Jul  7 16:06:30 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 07 Jul 2007 07:06:30 -0700
Subject: [Patches] [ python-Patches-1194378 ] sendmsg() and recvmsg() for C
	socket module
Message-ID: <E1I7Ave-00008K-KF@sc8-sf-web24.sourceforge.net>

Patches item #1194378, was opened at 2005-05-03 11:19
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1194378&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 3
Private: No
Submitted By: Heiko Wundram (hwundram)
Assigned to: Nobody/Anonymous (nobody)
>Summary: sendmsg() and recvmsg() for C socket module

Initial Comment:
The following tar.bz2 contains a feature enhancement
proposal for the socket module to create wrappings of
the recvmsg and sendmsg primitives. These are sometimes
useful, especially when dealing with ancillary
messages, such as communicating the process, user and
group id of a remote process to a server for proper
identification.

These functions have so far been available in a
separate module (python-eunuchs from the twisted
project), but as they are standard POSIX and have been
available on *BSD, AIX, Linux and several other OSs for
some time they should be integrated into the core
socket module.

The attached file contains patches for configure.in the
socket module, socket.py and pyconfig.h.in. I've yet to
write a test-suite, and the documentation could use
some reworking.

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

Comment By: TH (therve)
Date: 2007-03-06 14:13

Message:
Logged In: YES 
user_id=1038797
Originator: NO

That's really great, it's a shame this patch didn't get much interest. Do
you feel like adding test to this, it would probably psuh for its inclusion
?

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

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

From noreply at sourceforge.net  Sat Jul  7 18:31:29 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 07 Jul 2007 09:31:29 -0700
Subject: [Patches] [ python-Patches-1749662 ] New byte packing format for
	the struct module
Message-ID: <E1I7DBx-0001Uk-9u@sc8-sf-web23.sourceforge.net>

Patches item #1749662, was opened at 2007-07-07 11:31
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=1749662&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Modules
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Robert Zeh (razeh)
Assigned to: Nobody/Anonymous (nobody)
Summary: New byte packing format for the struct module

Initial Comment:
Added a new byte packing format to the struct module for network ordered structures but native packing.

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

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

From noreply at sourceforge.net  Sat Jul  7 20:33:01 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 07 Jul 2007 11:33:01 -0700
Subject: [Patches] [ python-Patches-1739468 ] Add a -z interpreter flag to
	execute a zip file
Message-ID: <E1I7F5Z-0007fc-9X@sc8-sf-web24.sourceforge.net>

Patches item #1739468, was opened at 2007-06-19 03:40
Message generated for change (Comment added) made by andy-chu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1739468&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: andy-chu (andy-chu)
Assigned to: Nick Coghlan (ncoghlan)
Summary: Add a -z interpreter flag to execute a zip file

Initial Comment:
The motivation for this is that distributing a zip file is a very light and easy way to distribute a python program with multiple packages/modules.  I have done this on Linux, Mac and Windows and it works very nicely -- except that you need a few extra files to bootstrap it: set PYTHONPATH to the zip file and run the main function.

With this small patch, you get rid of the need for extra files.  At the bottom is a demo on Linux.

On Windows, you can do a similar thing by making a file that is both a zip file and a batch file.  The batch file will pass %~f0 (itself) to the -z flag of the Python interpreter.

I ran this by Guido and he seemed to think it was a fine idea.  At Google, we have numerous platform-specific hacks in a program called "autopar" to solve this problem.

I have included the basic patch, but if you guys agree with this, I will add some tests and documentation.  And I think it might be useful to include something in the Tools/ directory to do what update_zip.sh does below (add a __zipmain__ module and a shebang/batch file header to a zip file, to make it executable)?

I think this may also help to fix a bug with eggs:

http://peak.telecommunity.com/DevCenter/setuptools#eggsecutable-scripts

IMPORTANT NOTE: Eggs with an "eggsecutable" header cannot be renamed, or invoked via symlinks. They must be invoked using their original filename, in order to ensure that, once running, pkg_resources will know what project and version is in use. The header script will check this and exit with an error if the .egg file has been renamed or is invoked via a symlink that changes its base name.



andychu testdata$ ls
__zipmain__.py  foo.py  foo.pyc  foo.zip  foo_exe.zip  header.txt  update_zip.sh


# The main program you're going to run in "development mode"

andychu testdata$ ./foo.py foo bar
argv: ['./foo.py', 'foo', 'bar']


# Same program, packaged into a zip file

andychu testdata$ ./foo_exe.zip foo bar
argv: ['-c', 'foo', 'bar']


# Contents of the zip file

andychu testdata$ unzip -l foo_exe.zip
Archive:  foo_exe.zip
warning [foo_exe.zip]:  51 extra bytes at beginning or within zipfile
  (attempting to process anyway)
  Length     Date   Time    Name
 --------    ----   ----    ----
      243  06-18-07 20:01   __zipmain__.py
      301  06-18-07 19:58   foo.py
 --------                   -------
      544                   2 files


# Demo script to build an executable zip file.

andychu testdata$ cat header.txt
#!/usr/local/google/clients/python/trunk/python -z


andychu testdata$ cat update_zip.sh
#!/bin/bash

# Make a regular zip file.
zip foo.zip foo.py __zipmain__.py

# Add a shebang line to it.
cat header.txt foo.zip > foo_exe.zip

# Make it executable.
chmod 750 foo_exe.zip


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

>Comment By: andy-chu (andy-chu)
Date: 2007-07-07 18:33

Message:
Logged In: YES 
user_id=1821575
Originator: YES

Nick, have you had a chance to look this over again?  I mainly care about
the -z flag support.  The makepyz.py script is just a demo, though I think
it is useful as documentation as well.


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

Comment By: Nick Coghlan (ncoghlan)
Date: 2007-06-29 14:40

Message:
Logged In: YES 
user_id=1038590
Originator: NO

I'm going to be off the net for a few days - I'll have a look at the
updated patch when I get back late next week,

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

Comment By: andy-chu (andy-chu)
Date: 2007-06-28 05:17

Message:
Logged In: YES 
user_id=1821575
Originator: YES

Here is a script that documents how to make such files.  I think the
important part is just documenting the format.  Then people can write
whatever tools they need around it.  Many people could get by with this
simple tool, but others might want something more elaborate.

Demo:

andychu testprog$ find
.
./__init__.py
./package1
./package1/__init__.py
./package1/foo.py
./package1/lib.py
./package1/__init__.pyc
./package1/lib.pyc
./package1/foo.pyc

andychu testprog$ find -name "*.py" | xargs ../Tools/scripts/makepyz.py -a
zip,pyz,unix -z foo.zip -p package1 -m foo -y
/usr/local/google/clients/python/trunk/python
Added ./__init__.py to foo.zip
Added ./package1/__init__.py to foo.zip
Added ./package1/foo.py to foo.zip
Added ./package1/lib.py to foo.zip
Added __zipmain__.py to foo.zip
Prepended #!/usr/local/google/clients/python/trunk/python -z to foo.zip.
chmod foo.zip 0700

andychu testprog$ ./foo.zip
lib module here
argv: ['-c']
andychu testprog$ echo $?
3

File Added: makepyz.py

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

Comment By: andy-chu (andy-chu)
Date: 2007-06-27 05:35

Message:
Logged In: YES 
user_id=1821575
Originator: YES

Nick, I've updated the code to use a new runpy.run_zip function, which
calls run_module.  This does make it a bit cleaner.

Let me know what you think.  If the code is good I'll write some tests and
documentation.

Also, I'm not sure if the '-c' is really appropriate in sys.argv, but that
seems to be what the -m flag uses.  It seems like it might make sense to
have sys.argv[0] be the zip file, if it is really a first class
executable.

And I think a script to build one of these files would be appropriate,
which I can add.  You could pass it the main module and main function, and
it would generate a __zipmain__ stub and add it to the zip file.  And it is
a good idea if the file is cross platform, so a .pyz extension would work.

Sorry the delayed response, I was a bit busy at work this week... but I'll
respond sooner this time. : )

Example:

andychu trunk$ testdata/foo_exe.zip foo bar
__name__: __main__
argv: ['-c', 'foo', 'bar']
andychu trunk$ echo $?
3

File Added: runzip7.diff

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

Comment By: andy-chu (andy-chu)
Date: 2007-06-21 00:54

Message:
Logged In: YES 
user_id=1821575
Originator: YES

Nick, you're right, I think it can use run_module and be in the runpy
module.  Let me make those changes and send you another patch.


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

Comment By: Nick Coghlan (ncoghlan)
Date: 2007-06-19 11:21

Message:
Logged In: YES 
user_id=1038590
Originator: NO

I like the general idea, but it should be possible to use runpy.run_module
to get __name__ set correctly (as that is what happens when you execute a
module from a zipfile with -m). Another advantage of using run_module is
that it would allow runzip() to take a second argument (possibly defaulting
to "__zipmain__") which would specify the module to be executed from the
zipfile (the remaining 3 run_module arguments could also be passed in, and
set appropriately from main.c).

Adding the new function as runpy.run_zip() (instead of adding a new
module) would also be good.

For Windows, an alternative to making the zip file both a batch and a zip
file would be to adopt a .pyz extension convention for these files - the
file associations can then be set up to invoke the script appropriately
with python -z (similar to the way that .pyw files are associated with
pythonw instead of the standard python executable). That way the same file
could be executed on both Linux (via an embedded shebang line) and on
Windows (via filename association), as is the case with standard .py Python
scripts.

My final question is whether the change to sys.path should be reverted
once the module execution is complete - my suspicion is that it should, but
I need to look into it a bit more before giving a definite answer (for the
command line flag case, this behaviour obviously doesn't matter - it is
only significant if the Python method is invoked directly in the context of
a larger program).

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

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

From noreply at sourceforge.net  Sun Jul  8 10:15:58 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 08 Jul 2007 01:15:58 -0700
Subject: [Patches] [ python-Patches-1739468 ] Add a -z interpreter flag to
	execute a zip file
Message-ID: <E1I7Rvy-00035a-Mu@sc8-sf-web22.sourceforge.net>

Patches item #1739468, was opened at 2007-06-19 13:40
Message generated for change (Comment added) made by ncoghlan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1739468&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: andy-chu (andy-chu)
Assigned to: Nick Coghlan (ncoghlan)
Summary: Add a -z interpreter flag to execute a zip file

Initial Comment:
The motivation for this is that distributing a zip file is a very light and easy way to distribute a python program with multiple packages/modules.  I have done this on Linux, Mac and Windows and it works very nicely -- except that you need a few extra files to bootstrap it: set PYTHONPATH to the zip file and run the main function.

With this small patch, you get rid of the need for extra files.  At the bottom is a demo on Linux.

On Windows, you can do a similar thing by making a file that is both a zip file and a batch file.  The batch file will pass %~f0 (itself) to the -z flag of the Python interpreter.

I ran this by Guido and he seemed to think it was a fine idea.  At Google, we have numerous platform-specific hacks in a program called "autopar" to solve this problem.

I have included the basic patch, but if you guys agree with this, I will add some tests and documentation.  And I think it might be useful to include something in the Tools/ directory to do what update_zip.sh does below (add a __zipmain__ module and a shebang/batch file header to a zip file, to make it executable)?

I think this may also help to fix a bug with eggs:

http://peak.telecommunity.com/DevCenter/setuptools#eggsecutable-scripts

IMPORTANT NOTE: Eggs with an "eggsecutable" header cannot be renamed, or invoked via symlinks. They must be invoked using their original filename, in order to ensure that, once running, pkg_resources will know what project and version is in use. The header script will check this and exit with an error if the .egg file has been renamed or is invoked via a symlink that changes its base name.



andychu testdata$ ls
__zipmain__.py  foo.py  foo.pyc  foo.zip  foo_exe.zip  header.txt  update_zip.sh


# The main program you're going to run in "development mode"

andychu testdata$ ./foo.py foo bar
argv: ['./foo.py', 'foo', 'bar']


# Same program, packaged into a zip file

andychu testdata$ ./foo_exe.zip foo bar
argv: ['-c', 'foo', 'bar']


# Contents of the zip file

andychu testdata$ unzip -l foo_exe.zip
Archive:  foo_exe.zip
warning [foo_exe.zip]:  51 extra bytes at beginning or within zipfile
  (attempting to process anyway)
  Length     Date   Time    Name
 --------    ----   ----    ----
      243  06-18-07 20:01   __zipmain__.py
      301  06-18-07 19:58   foo.py
 --------                   -------
      544                   2 files


# Demo script to build an executable zip file.

andychu testdata$ cat header.txt
#!/usr/local/google/clients/python/trunk/python -z


andychu testdata$ cat update_zip.sh
#!/bin/bash

# Make a regular zip file.
zip foo.zip foo.py __zipmain__.py

# Add a shebang line to it.
cat header.txt foo.zip > foo_exe.zip

# Make it executable.
chmod 750 foo_exe.zip


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

>Comment By: Nick Coghlan (ncoghlan)
Date: 2007-07-08 18:15

Message:
Logged In: YES 
user_id=1038590
Originator: NO

The new patch looks much better - the only thing is that run_zip needs to
do sys.path.pop(0) to correctly remove the zipfile from the front of the
path.

However, I do see your point about whether or not including the current
directory on sys.path is the right thing to do for this case - it may be
better to set <zipfile_name>/__zipmain__.py as argv[0] before invoking
PySys_SetArgv, and then use __zipmain__ as the module to be executed on the
same code path as the -m switch normally uses.

Rather than continuing this discussion here on SF, it may be best to post
your proposal to python-dev. I personally like the idea, but a new idiom
for running Python scripts will need broader support than just me. Getting
input from the py2exe and py2app folks that can be found on python-dev
would also be good. 

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

Comment By: andy-chu (andy-chu)
Date: 2007-07-08 04:33

Message:
Logged In: YES 
user_id=1821575
Originator: YES

Nick, have you had a chance to look this over again?  I mainly care about
the -z flag support.  The makepyz.py script is just a demo, though I think
it is useful as documentation as well.


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

Comment By: Nick Coghlan (ncoghlan)
Date: 2007-06-30 00:40

Message:
Logged In: YES 
user_id=1038590
Originator: NO

I'm going to be off the net for a few days - I'll have a look at the
updated patch when I get back late next week,

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

Comment By: andy-chu (andy-chu)
Date: 2007-06-28 15:17

Message:
Logged In: YES 
user_id=1821575
Originator: YES

Here is a script that documents how to make such files.  I think the
important part is just documenting the format.  Then people can write
whatever tools they need around it.  Many people could get by with this
simple tool, but others might want something more elaborate.

Demo:

andychu testprog$ find
.
./__init__.py
./package1
./package1/__init__.py
./package1/foo.py
./package1/lib.py
./package1/__init__.pyc
./package1/lib.pyc
./package1/foo.pyc

andychu testprog$ find -name "*.py" | xargs ../Tools/scripts/makepyz.py -a
zip,pyz,unix -z foo.zip -p package1 -m foo -y
/usr/local/google/clients/python/trunk/python
Added ./__init__.py to foo.zip
Added ./package1/__init__.py to foo.zip
Added ./package1/foo.py to foo.zip
Added ./package1/lib.py to foo.zip
Added __zipmain__.py to foo.zip
Prepended #!/usr/local/google/clients/python/trunk/python -z to foo.zip.
chmod foo.zip 0700

andychu testprog$ ./foo.zip
lib module here
argv: ['-c']
andychu testprog$ echo $?
3

File Added: makepyz.py

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

Comment By: andy-chu (andy-chu)
Date: 2007-06-27 15:35

Message:
Logged In: YES 
user_id=1821575
Originator: YES

Nick, I've updated the code to use a new runpy.run_zip function, which
calls run_module.  This does make it a bit cleaner.

Let me know what you think.  If the code is good I'll write some tests and
documentation.

Also, I'm not sure if the '-c' is really appropriate in sys.argv, but that
seems to be what the -m flag uses.  It seems like it might make sense to
have sys.argv[0] be the zip file, if it is really a first class
executable.

And I think a script to build one of these files would be appropriate,
which I can add.  You could pass it the main module and main function, and
it would generate a __zipmain__ stub and add it to the zip file.  And it is
a good idea if the file is cross platform, so a .pyz extension would work.

Sorry the delayed response, I was a bit busy at work this week... but I'll
respond sooner this time. : )

Example:

andychu trunk$ testdata/foo_exe.zip foo bar
__name__: __main__
argv: ['-c', 'foo', 'bar']
andychu trunk$ echo $?
3

File Added: runzip7.diff

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

Comment By: andy-chu (andy-chu)
Date: 2007-06-21 10:54

Message:
Logged In: YES 
user_id=1821575
Originator: YES

Nick, you're right, I think it can use run_module and be in the runpy
module.  Let me make those changes and send you another patch.


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

Comment By: Nick Coghlan (ncoghlan)
Date: 2007-06-19 21:21

Message:
Logged In: YES 
user_id=1038590
Originator: NO

I like the general idea, but it should be possible to use runpy.run_module
to get __name__ set correctly (as that is what happens when you execute a
module from a zipfile with -m). Another advantage of using run_module is
that it would allow runzip() to take a second argument (possibly defaulting
to "__zipmain__") which would specify the module to be executed from the
zipfile (the remaining 3 run_module arguments could also be passed in, and
set appropriately from main.c).

Adding the new function as runpy.run_zip() (instead of adding a new
module) would also be good.

For Windows, an alternative to making the zip file both a batch and a zip
file would be to adopt a .pyz extension convention for these files - the
file associations can then be set up to invoke the script appropriately
with python -z (similar to the way that .pyw files are associated with
pythonw instead of the standard python executable). That way the same file
could be executed on both Linux (via an embedded shebang line) and on
Windows (via filename association), as is the case with standard .py Python
scripts.

My final question is whether the change to sys.path should be reverted
once the module execution is complete - my suspicion is that it should, but
I need to look into it a bit more before giving a definite answer (for the
command line flag case, this behaviour obviously doesn't matter - it is
only significant if the Python method is invoked directly in the context of
a larger program).

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

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

From noreply at sourceforge.net  Sun Jul  8 11:33:32 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 08 Jul 2007 02:33:32 -0700
Subject: [Patches] [ python-Patches-1749857 ] itertools.getitem()
Message-ID: <E1I7T92-0001KL-L1@sc8-sf-web24.sourceforge.net>

Patches item #1749857, was opened at 2007-07-08 11:33
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=1749857&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Modules
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Walter D?rwald (doerwalter)
Assigned to: Raymond Hettinger (rhettinger)
Summary: itertools.getitem()

Initial Comment:
This patch adds itertools.getitem() which is basically equivalent to the following python code:

_default = object()

def getitem(iterable, index, default=_default):
   try:
      return list(iterable)[index]
   except IndexError:
      if default is _default:
         raise
      return default

but without materializing the complete list. Negative indexes are supported too.

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

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

From noreply at sourceforge.net  Mon Jul  9 08:06:00 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 08 Jul 2007 23:06:00 -0700
Subject: [Patches] [ python-Patches-1693258 ] Fix for duplicate
	"preferences" menu-OS X
Message-ID: <E1I7mNk-0003LR-1h@sc8-sf-web23.sourceforge.net>

Patches item #1693258, was opened at 2007-04-03 00:15
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1693258&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Kevin Walzer (wordtech)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: Fix for duplicate "preferences" menu-OS X

Initial Comment:
Version 8.4.14 of  Tcl/Tk Aqua (for OS X) hard-codes a "Preferences" item in the Apple menu. As a result, IDLE now has two "Preferences" items--the active one that is coded by default, and an inactive item that is hard-coded by Tk. 

The attached patch to macosxSupport.py checks the installed version of Tk, and if it is 8.4.14, substitutes the hard-coded Tk "preferences" menu and binds IDLE's "preferences" dialog to this menu item. If Tk is version 8.4.13 or less, leave the menu alone.

This patch addresses Python bug #1691411  opened at 2007-03-30.

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

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2007-07-09 08:05

Message:
Logged In: YES 
user_id=580910
Originator: NO

This patch looks fine.

Commited as 56204 (trunk) and 56205 (2.5.x)

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

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

From noreply at sourceforge.net  Mon Jul  9 10:28:52 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 09 Jul 2007 01:28:52 -0700
Subject: [Patches] [ python-Patches-1737832 ] EasyDialogs patch to remove
	aepack dependency
Message-ID: <E1I7oc0-0003Jl-UQ@sc8-sf-web24.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: has (hhas)
>Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: EasyDialogs patch to remove aepack dependency

Initial Comment:
Patch for Python 2.5 that eliminates the aepack dependency from the EasyDialogs module, allowing aetools & co. to be removed without breaking EasyDialogs.

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

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2007-07-09 10:28

Message:
Logged In: YES 
user_id=580910
Originator: NO

Patches looks sane (although I don't actually know much about Carbon). I'm
going to apply after I've done some testing.

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

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

From noreply at sourceforge.net  Mon Jul  9 10:35:08 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 09 Jul 2007 01:35:08 -0700
Subject: [Patches] [ python-Patches-1673122 ] Mac OS X: libtool
Message-ID: <E1I7oi4-0004yJ-M5@sc8-sf-web22.sourceforge.net>

Patches item #1673122, was opened at 2007-03-03 21:33
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1673122&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.6
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: Witten (herrwitten)
>Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: Mac OS X: libtool

Initial Comment:
When the framewok is built on Mac OS X, the Mac OS X specific libtool is used.

However, if the GNU libtool is on the PATH first, python refuses to build.

This patch simply specifies the Mac OS X libtool with an absolute path by updating the Makefile.pre.in file.

That way, someone can have GNU libtool on the PATH first and still build python.

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

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2007-07-09 10:35

Message:
Logged In: YES 
user_id=580910
Originator: NO

Looks fine. I'm going to apply this one.

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

Comment By: Jim Jewett (jimjjewett)
Date: 2007-03-19 04:10

Message:
Logged In: YES 
user_id=764593
Originator: NO

This fix is probably worth a News entry as well. 

Jorend:  If you want it applied sooner, you can edit the wiki page at 

http://wiki.python.org/moin/PatchTriage

saying that you have reviewed it and recommend that it be applied.

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

Comment By: Witten (herrwitten)
Date: 2007-03-08 15:25

Message:
Logged In: YES 
user_id=1595909
Originator: YES

Great!

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

Comment By: Jason Orendorff (jorend)
Date: 2007-03-08 05:36

Message:
Logged In: YES 
user_id=18139
Originator: NO

It works.


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

Comment By: Jason Orendorff (jorend)
Date: 2007-03-07 16:38

Message:
Logged In: YES 
user_id=18139
Originator: NO

OK, I don't see why not.

I'll try this out tonight, just to make sure it works.


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

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

From noreply at sourceforge.net  Mon Jul  9 10:41:34 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 09 Jul 2007 01:41:34 -0700
Subject: [Patches] [ python-Patches-1673122 ] Mac OS X: libtool
Message-ID: <E1I7ooI-0005l7-8I@sc8-sf-web24.sourceforge.net>

Patches item #1673122, was opened at 2007-03-03 21:33
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1673122&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.6
>Status: Closed
>Resolution: Accepted
Priority: 7
Private: No
Submitted By: Witten (herrwitten)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: Mac OS X: libtool

Initial Comment:
When the framewok is built on Mac OS X, the Mac OS X specific libtool is used.

However, if the GNU libtool is on the PATH first, python refuses to build.

This patch simply specifies the Mac OS X libtool with an absolute path by updating the Makefile.pre.in file.

That way, someone can have GNU libtool on the PATH first and still build python.

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

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2007-07-09 10:41

Message:
Logged In: YES 
user_id=580910
Originator: NO

Applied as 56206 (2.5.x) and 56207 (trunk)

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

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2007-07-09 10:35

Message:
Logged In: YES 
user_id=580910
Originator: NO

Looks fine. I'm going to apply this one.

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

Comment By: Jim Jewett (jimjjewett)
Date: 2007-03-19 04:10

Message:
Logged In: YES 
user_id=764593
Originator: NO

This fix is probably worth a News entry as well. 

Jorend:  If you want it applied sooner, you can edit the wiki page at 

http://wiki.python.org/moin/PatchTriage

saying that you have reviewed it and recommend that it be applied.

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

Comment By: Witten (herrwitten)
Date: 2007-03-08 15:25

Message:
Logged In: YES 
user_id=1595909
Originator: YES

Great!

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

Comment By: Jason Orendorff (jorend)
Date: 2007-03-08 05:36

Message:
Logged In: YES 
user_id=18139
Originator: NO

It works.


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

Comment By: Jason Orendorff (jorend)
Date: 2007-03-07 16:38

Message:
Logged In: YES 
user_id=18139
Originator: NO

OK, I don't see why not.

I'll try this out tonight, just to make sure it works.


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

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

From ffjy at it-connect.de  Tue Jul 10 00:13:21 2007
From: ffjy at it-connect.de (Customer Support)
Date: Tue, 10 Jul 2007 00:13:21 +0200
Subject: [Patches] Virus Activity Detected!
Message-ID: <3383e1a7a85955ab65e8517a32e6b9ea@>

An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/patches/attachments/20070710/b7c7640f/attachment.htm 

From noreply at sourceforge.net  Tue Jul 10 06:14:47 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 09 Jul 2007 21:14:47 -0700
Subject: [Patches] [ python-Patches-1750931 ] make build_opener raise
	exception when not passed a handler
Message-ID: <E1I877f-0002YC-Pz@sc8-sf-web23.sourceforge.net>

Patches item #1750931, was opened at 2007-07-10 04: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=1750931&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Robert Renaud (silentstrike)
Assigned to: Nobody/Anonymous (nobody)
Summary: make build_opener raise exception when not passed a handler

Initial Comment:
A bug bit me where I had code that looked like

urllib2.build_opener(func_returning_cookie_jar())

instead of

urllib2.build_opener(HTTPCookieProcessor(func_returning_cookie_jar())

the subsequent http request went through just fine, except it didn't send the cookie.  Nothing complained, except me, now.

Throwing the exception deeper in the code made the unittest fail, so I suspect the "silently ignore handlers which don't actually do any handling" behavior might be by design, but it seems terrible to me.

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

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

From noreply at sourceforge.net  Tue Jul 10 23:56:35 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 10 Jul 2007 14:56:35 -0700
Subject: [Patches] [ python-Patches-1751493 ] struni: fix for test_cmd_line
Message-ID: <E1I8NhD-0006xE-Tv@sc8-sf-web23.sourceforge.net>

Patches item #1751493, was opened at 2007-07-10 23:56
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=1751493&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Tests
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Christian Heimes (tiran)
Assigned to: Nobody/Anonymous (nobody)
Summary: struni: fix for test_cmd_line

Initial Comment:
Some unit tests were failing because subprocess's stdout returns bytes and not strings.

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

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

From noreply at sourceforge.net  Wed Jul 11 00:25:12 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 10 Jul 2007 15:25:12 -0700
Subject: [Patches] [ python-Patches-1751515 ] struni: Replace assert_(==)
	with failUnlessEqual
Message-ID: <E1I8O8u-0005Lp-1l@sc8-sf-web21.sourceforge.net>

Patches item #1751515, was opened at 2007-07-11 00:25
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=1751515&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Tests
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Christian Heimes (tiran)
Assigned to: Nobody/Anonymous (nobody)
Summary: struni: Replace assert_(==) with failUnlessEqual

Initial Comment:
Patch for py3k-struni branch

It replaces assert_(foo == bar) and failUnless(foo == bar) with failUnlessEqual(foo, bar). It makes debugging the error MUCH easier to see both values.


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

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

From noreply at sourceforge.net  Wed Jul 11 00:48:41 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 10 Jul 2007 15:48:41 -0700
Subject: [Patches] [ python-Patches-1751519 ] curses - new window methods:
	addchstr and addchnstr
Message-ID: <E1I8OVd-0004N3-5a@sc8-sf-web23.sourceforge.net>

Patches item #1751519, was opened at 2007-07-11 00:48
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=1751519&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Wojciech Mula (wmula)
Assigned to: Nobody/Anonymous (nobody)
Summary: curses - new window methods: addchstr and addchnstr

Initial Comment:
This patch add two window methods: addchstr and addchnstr and also module attribute chtype_size.  Methods use addstr convention i.e. calling with/without new cursors coords is allowed.

Methods accept any buffer-object (string, array, ctypes string buffer) of length n*chtype_size.

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

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

From noreply at sourceforge.net  Wed Jul 11 00:52:53 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 10 Jul 2007 15:52:53 -0700
Subject: [Patches] [ python-Patches-1751519 ] curses - new window methods:
	addchstr and addchnstr
Message-ID: <E1I8OZh-0002iH-VV@sc8-sf-web24.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Wojciech Mula (wmula)
Assigned to: Nobody/Anonymous (nobody)
Summary: curses - new window methods: addchstr and addchnstr

Initial Comment:
This patch add two window methods: addchstr and addchnstr and also module attribute chtype_size.  Methods use addstr convention i.e. calling with/without new cursors coords is allowed.

Methods accept any buffer-object (string, array, ctypes string buffer) of length n*chtype_size.

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

>Comment By: Wojciech Mula (wmula)
Date: 2007-07-11 00:52

Message:
Logged In: YES 
user_id=1146248
Originator: YES

File Added: test_addchstr.py

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

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

From noreply at sourceforge.net  Wed Jul 11 02:01:21 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 10 Jul 2007 17:01:21 -0700
Subject: [Patches] [ python-Patches-1751515 ] struni: Replace assert_(==)
	with failUnlessEqual
Message-ID: <E1I8Pdx-000477-Vg@sc8-sf-web23.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Tests
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Christian Heimes (tiran)
Assigned to: Nobody/Anonymous (nobody)
Summary: struni: Replace assert_(==) with failUnlessEqual

Initial Comment:
Patch for py3k-struni branch

It replaces assert_(foo == bar) and failUnless(foo == bar) with failUnlessEqual(foo, bar). It makes debugging the error MUCH easier to see both values.


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

>Comment By: Christian Heimes (tiran)
Date: 2007-07-11 02:01

Message:
Logged In: YES 
user_id=560817
Originator: YES

File Added: newpatch.diff

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

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

From noreply at sourceforge.net  Wed Jul 11 08:25:44 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 10 Jul 2007 23:25:44 -0700
Subject: [Patches] [ python-Patches-1739468 ] Add a -z interpreter flag to
	execute a zip file
Message-ID: <E1I8Vdw-00044R-8E@sc8-sf-web21.sourceforge.net>

Patches item #1739468, was opened at 2007-06-19 03:40
Message generated for change (Comment added) made by andy-chu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1739468&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: andy-chu (andy-chu)
Assigned to: Nick Coghlan (ncoghlan)
Summary: Add a -z interpreter flag to execute a zip file

Initial Comment:
The motivation for this is that distributing a zip file is a very light and easy way to distribute a python program with multiple packages/modules.  I have done this on Linux, Mac and Windows and it works very nicely -- except that you need a few extra files to bootstrap it: set PYTHONPATH to the zip file and run the main function.

With this small patch, you get rid of the need for extra files.  At the bottom is a demo on Linux.

On Windows, you can do a similar thing by making a file that is both a zip file and a batch file.  The batch file will pass %~f0 (itself) to the -z flag of the Python interpreter.

I ran this by Guido and he seemed to think it was a fine idea.  At Google, we have numerous platform-specific hacks in a program called "autopar" to solve this problem.

I have included the basic patch, but if you guys agree with this, I will add some tests and documentation.  And I think it might be useful to include something in the Tools/ directory to do what update_zip.sh does below (add a __zipmain__ module and a shebang/batch file header to a zip file, to make it executable)?

I think this may also help to fix a bug with eggs:

http://peak.telecommunity.com/DevCenter/setuptools#eggsecutable-scripts

IMPORTANT NOTE: Eggs with an "eggsecutable" header cannot be renamed, or invoked via symlinks. They must be invoked using their original filename, in order to ensure that, once running, pkg_resources will know what project and version is in use. The header script will check this and exit with an error if the .egg file has been renamed or is invoked via a symlink that changes its base name.



andychu testdata$ ls
__zipmain__.py  foo.py  foo.pyc  foo.zip  foo_exe.zip  header.txt  update_zip.sh


# The main program you're going to run in "development mode"

andychu testdata$ ./foo.py foo bar
argv: ['./foo.py', 'foo', 'bar']


# Same program, packaged into a zip file

andychu testdata$ ./foo_exe.zip foo bar
argv: ['-c', 'foo', 'bar']


# Contents of the zip file

andychu testdata$ unzip -l foo_exe.zip
Archive:  foo_exe.zip
warning [foo_exe.zip]:  51 extra bytes at beginning or within zipfile
  (attempting to process anyway)
  Length     Date   Time    Name
 --------    ----   ----    ----
      243  06-18-07 20:01   __zipmain__.py
      301  06-18-07 19:58   foo.py
 --------                   -------
      544                   2 files


# Demo script to build an executable zip file.

andychu testdata$ cat header.txt
#!/usr/local/google/clients/python/trunk/python -z


andychu testdata$ cat update_zip.sh
#!/bin/bash

# Make a regular zip file.
zip foo.zip foo.py __zipmain__.py

# Add a shebang line to it.
cat header.txt foo.zip > foo_exe.zip

# Make it executable.
chmod 750 foo_exe.zip


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

>Comment By: andy-chu (andy-chu)
Date: 2007-07-11 06:25

Message:
Logged In: YES 
user_id=1821575
Originator: YES

Good point, however I decided to set sys.path[0] and sys.argv[0] a little
differently, based on some more testing, as you can see explained in the
new patch I just uploaded.

Those are details; I'll post to python-dev and see what people think of
the general idea.  If it's accepted then we can figure out the details. 
For now I made the function very specific to the -z flag.

I'm not sure I have a use case for invoking a zip file from another python
module.  If we were to put that back in, it might be better to have 2
separate functions anyway, since this one is only 3 lines basically.


File Added: runzip8.diff

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

Comment By: Nick Coghlan (ncoghlan)
Date: 2007-07-08 08:15

Message:
Logged In: YES 
user_id=1038590
Originator: NO

The new patch looks much better - the only thing is that run_zip needs to
do sys.path.pop(0) to correctly remove the zipfile from the front of the
path.

However, I do see your point about whether or not including the current
directory on sys.path is the right thing to do for this case - it may be
better to set <zipfile_name>/__zipmain__.py as argv[0] before invoking
PySys_SetArgv, and then use __zipmain__ as the module to be executed on the
same code path as the -m switch normally uses.

Rather than continuing this discussion here on SF, it may be best to post
your proposal to python-dev. I personally like the idea, but a new idiom
for running Python scripts will need broader support than just me. Getting
input from the py2exe and py2app folks that can be found on python-dev
would also be good. 

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

Comment By: andy-chu (andy-chu)
Date: 2007-07-07 18:33

Message:
Logged In: YES 
user_id=1821575
Originator: YES

Nick, have you had a chance to look this over again?  I mainly care about
the -z flag support.  The makepyz.py script is just a demo, though I think
it is useful as documentation as well.


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

Comment By: Nick Coghlan (ncoghlan)
Date: 2007-06-29 14:40

Message:
Logged In: YES 
user_id=1038590
Originator: NO

I'm going to be off the net for a few days - I'll have a look at the
updated patch when I get back late next week,

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

Comment By: andy-chu (andy-chu)
Date: 2007-06-28 05:17

Message:
Logged In: YES 
user_id=1821575
Originator: YES

Here is a script that documents how to make such files.  I think the
important part is just documenting the format.  Then people can write
whatever tools they need around it.  Many people could get by with this
simple tool, but others might want something more elaborate.

Demo:

andychu testprog$ find
.
./__init__.py
./package1
./package1/__init__.py
./package1/foo.py
./package1/lib.py
./package1/__init__.pyc
./package1/lib.pyc
./package1/foo.pyc

andychu testprog$ find -name "*.py" | xargs ../Tools/scripts/makepyz.py -a
zip,pyz,unix -z foo.zip -p package1 -m foo -y
/usr/local/google/clients/python/trunk/python
Added ./__init__.py to foo.zip
Added ./package1/__init__.py to foo.zip
Added ./package1/foo.py to foo.zip
Added ./package1/lib.py to foo.zip
Added __zipmain__.py to foo.zip
Prepended #!/usr/local/google/clients/python/trunk/python -z to foo.zip.
chmod foo.zip 0700

andychu testprog$ ./foo.zip
lib module here
argv: ['-c']
andychu testprog$ echo $?
3

File Added: makepyz.py

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

Comment By: andy-chu (andy-chu)
Date: 2007-06-27 05:35

Message:
Logged In: YES 
user_id=1821575
Originator: YES

Nick, I've updated the code to use a new runpy.run_zip function, which
calls run_module.  This does make it a bit cleaner.

Let me know what you think.  If the code is good I'll write some tests and
documentation.

Also, I'm not sure if the '-c' is really appropriate in sys.argv, but that
seems to be what the -m flag uses.  It seems like it might make sense to
have sys.argv[0] be the zip file, if it is really a first class
executable.

And I think a script to build one of these files would be appropriate,
which I can add.  You could pass it the main module and main function, and
it would generate a __zipmain__ stub and add it to the zip file.  And it is
a good idea if the file is cross platform, so a .pyz extension would work.

Sorry the delayed response, I was a bit busy at work this week... but I'll
respond sooner this time. : )

Example:

andychu trunk$ testdata/foo_exe.zip foo bar
__name__: __main__
argv: ['-c', 'foo', 'bar']
andychu trunk$ echo $?
3

File Added: runzip7.diff

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

Comment By: andy-chu (andy-chu)
Date: 2007-06-21 00:54

Message:
Logged In: YES 
user_id=1821575
Originator: YES

Nick, you're right, I think it can use run_module and be in the runpy
module.  Let me make those changes and send you another patch.


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

Comment By: Nick Coghlan (ncoghlan)
Date: 2007-06-19 11:21

Message:
Logged In: YES 
user_id=1038590
Originator: NO

I like the general idea, but it should be possible to use runpy.run_module
to get __name__ set correctly (as that is what happens when you execute a
module from a zipfile with -m). Another advantage of using run_module is
that it would allow runzip() to take a second argument (possibly defaulting
to "__zipmain__") which would specify the module to be executed from the
zipfile (the remaining 3 run_module arguments could also be passed in, and
set appropriately from main.c).

Adding the new function as runpy.run_zip() (instead of adding a new
module) would also be good.

For Windows, an alternative to making the zip file both a batch and a zip
file would be to adopt a .pyz extension convention for these files - the
file associations can then be set up to invoke the script appropriately
with python -z (similar to the way that .pyw files are associated with
pythonw instead of the standard python executable). That way the same file
could be executed on both Linux (via an embedded shebang line) and on
Windows (via filename association), as is the case with standard .py Python
scripts.

My final question is whether the change to sys.path should be reverted
once the module execution is complete - my suspicion is that it should, but
I need to look into it a bit more before giving a definite answer (for the
command line flag case, this behaviour obviously doesn't matter - it is
only significant if the Python method is invoked directly in the context of
a larger program).

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

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

From noreply at sourceforge.net  Wed Jul 11 08:56:56 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 10 Jul 2007 23:56:56 -0700
Subject: [Patches] [ python-Patches-1751493 ] struni: fix for test_cmd_line
Message-ID: <E1I8W88-0006G3-1K@sc8-sf-web24.sourceforge.net>

Patches item #1751493, was opened at 2007-07-10 17:56
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1751493&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Tests
Group: Python 3000
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Christian Heimes (tiran)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: struni: fix for test_cmd_line

Initial Comment:
Some unit tests were failing because subprocess's stdout returns bytes and not strings.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-11 02:56

Message:
Logged In: YES 
user_id=6380
Originator: NO

Thanks!

Committed revision 56250.


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

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

From noreply at sourceforge.net  Wed Jul 11 12:49:17 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 11 Jul 2007 03:49:17 -0700
Subject: [Patches] [ python-Patches-1751800 ] Dict comprehensions
Message-ID: <E1I8Zkz-0005nr-WC@sc8-sf-web22.sourceforge.net>

Patches item #1751800, was opened at 2007-07-11 12:49
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=1751800&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Thomas Wouters (twouters)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Dict comprehensions

Initial Comment:
Dict comprehensions, implemented somewhat like:

d = {}
for key, value in gen():
  d[key] = value

A version that passes the generator directly to dict() might be faster (although it would have to generate tuples instead of two separate items on the stack, which may negate the benefit of doing the actual dict assignment in C) -- and of course the danger of passing the generator to a local or global 'dict' variable instead of the builtin 'dict'.

Includes tests, but not compiler-package or documentation changes (yet).


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

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

From noreply at sourceforge.net  Wed Jul 11 12:51:03 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 11 Jul 2007 03:51:03 -0700
Subject: [Patches] [ python-Patches-1751801 ] Patch for Windows build
Message-ID: <E1I8Zmh-00061Y-MW@sc8-sf-web22.sourceforge.net>

Patches item #1751801, was opened at 2007-07-11 12:51
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=1751801&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Thomas Heller (theller)
Assigned to: Nobody/Anonymous (nobody)
Summary: Patch for Windows build

Initial Comment:
In Modules/_fileio.c, HAVE_FTRUNCATE is undefined for Windows.

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

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

From noreply at sourceforge.net  Wed Jul 11 13:46:17 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 11 Jul 2007 04:46:17 -0700
Subject: [Patches] [ python-Patches-1751800 ] Dict comprehensions
Message-ID: <E1I8ae9-0006rs-Fc@sc8-sf-web23.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Thomas Wouters (twouters)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Dict comprehensions

Initial Comment:
Dict comprehensions, implemented somewhat like:

d = {}
for key, value in gen():
  d[key] = value

A version that passes the generator directly to dict() might be faster (although it would have to generate tuples instead of two separate items on the stack, which may negate the benefit of doing the actual dict assignment in C) -- and of course the danger of passing the generator to a local or global 'dict' variable instead of the builtin 'dict'.

Includes tests, but not compiler-package or documentation changes (yet).


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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-07-11 11:46

Message:
Logged In: YES 
user_id=849994
Originator: NO

I tested the patch shallowly, works fine. I think this is a good feature
to have, even if only for completeness.
The tests don't seem to be included.

compiler package changes won't be needed, as it has been removed from
Py3k,
but probably changes to parsermodule.c.

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

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

From noreply at sourceforge.net  Wed Jul 11 14:11:43 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 11 Jul 2007 05:11:43 -0700
Subject: [Patches] [ python-Patches-1751515 ] struni: Replace assert_(==)
	with failUnlessEqual
Message-ID: <E1I8b2l-0006et-JX@sc8-sf-web22.sourceforge.net>

Patches item #1751515, was opened at 2007-07-10 18:25
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1751515&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Tests
Group: Python 3000
Status: Open
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Christian Heimes (tiran)
>Assigned to: Thomas Wouters (twouters)
Summary: struni: Replace assert_(==) with failUnlessEqual

Initial Comment:
Patch for py3k-struni branch

It replaces assert_(foo == bar) and failUnless(foo == bar) with failUnlessEqual(foo, bar). It makes debugging the error MUCH easier to see both values.


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-11 08:11

Message:
Logged In: YES 
user_id=6380
Originator: NO

check it in!

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

Comment By: Christian Heimes (tiran)
Date: 2007-07-10 20:01

Message:
Logged In: YES 
user_id=560817
Originator: YES

File Added: newpatch.diff

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

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

From noreply at sourceforge.net  Wed Jul 11 14:12:49 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 11 Jul 2007 05:12:49 -0700
Subject: [Patches] [ python-Patches-1751800 ] Dict comprehensions
Message-ID: <E1I8b3p-0004gg-7q@sc8-sf-web24.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 3000
Status: Open
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Thomas Wouters (twouters)
>Assigned to: Thomas Wouters (twouters)
Summary: Dict comprehensions

Initial Comment:
Dict comprehensions, implemented somewhat like:

d = {}
for key, value in gen():
  d[key] = value

A version that passes the generator directly to dict() might be faster (although it would have to generate tuples instead of two separate items on the stack, which may negate the benefit of doing the actual dict assignment in C) -- and of course the danger of passing the generator to a local or global 'dict' variable instead of the builtin 'dict'.

Includes tests, but not compiler-package or documentation changes (yet).


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-11 08:12

Message:
Logged In: YES 
user_id=6380
Originator: NO

Check it in!  (This one I meant, not the other one which was my mistake.)

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

Comment By: Georg Brandl (gbrandl)
Date: 2007-07-11 07:46

Message:
Logged In: YES 
user_id=849994
Originator: NO

I tested the patch shallowly, works fine. I think this is a good feature
to have, even if only for completeness.
The tests don't seem to be included.

compiler package changes won't be needed, as it has been removed from
Py3k,
but probably changes to parsermodule.c.

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

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

From noreply at sourceforge.net  Wed Jul 11 14:25:19 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 11 Jul 2007 05:25:19 -0700
Subject: [Patches] [ python-Patches-1751800 ] Dict comprehensions
Message-ID: <E1I8bFv-000693-P8@sc8-sf-web24.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 3000
>Status: Closed
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Thomas Wouters (twouters)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: Dict comprehensions

Initial Comment:
Dict comprehensions, implemented somewhat like:

d = {}
for key, value in gen():
  d[key] = value

A version that passes the generator directly to dict() might be faster (although it would have to generate tuples instead of two separate items on the stack, which may negate the benefit of doing the actual dict assignment in C) -- and of course the danger of passing the generator to a local or global 'dict' variable instead of the builtin 'dict'.

Includes tests, but not compiler-package or documentation changes (yet).


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

>Comment By: Thomas Wouters (twouters)
Date: 2007-07-11 14:25

Message:
Logged In: YES 
user_id=34209
Originator: YES

Verbally accepted by Guido (honest), and checked in.


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-11 14:12

Message:
Logged In: YES 
user_id=6380
Originator: NO

Check it in!  (This one I meant, not the other one which was my mistake.)

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

Comment By: Georg Brandl (gbrandl)
Date: 2007-07-11 13:46

Message:
Logged In: YES 
user_id=849994
Originator: NO

I tested the patch shallowly, works fine. I think this is a good feature
to have, even if only for completeness.
The tests don't seem to be included.

compiler package changes won't be needed, as it has been removed from
Py3k,
but probably changes to parsermodule.c.

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

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

From noreply at sourceforge.net  Wed Jul 11 14:27:22 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 11 Jul 2007 05:27:22 -0700
Subject: [Patches] [ python-Patches-1751515 ] struni: Replace assert_(==)
	with failUnlessEqual
Message-ID: <E1I8bHu-0007JZ-Mv@sc8-sf-web21.sourceforge.net>

Patches item #1751515, was opened at 2007-07-10 18:25
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1751515&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Tests
Group: Python 3000
>Status: Closed
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Christian Heimes (tiran)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: struni: Replace assert_(==) with failUnlessEqual

Initial Comment:
Patch for py3k-struni branch

It replaces assert_(foo == bar) and failUnless(foo == bar) with failUnlessEqual(foo, bar). It makes debugging the error MUCH easier to see both values.


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-11 08:27

Message:
Logged In: YES 
user_id=6380
Originator: NO

Sorry, that was meant for another patch.

I've checked this one in now, after changing failUnlessEqual with
assertEqual (the double negative trips me up in reading code using
failUnlessXXX all the time).

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-11 08:11

Message:
Logged In: YES 
user_id=6380
Originator: NO

check it in!

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

Comment By: Christian Heimes (tiran)
Date: 2007-07-10 20:01

Message:
Logged In: YES 
user_id=560817
Originator: YES

File Added: newpatch.diff

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

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

From noreply at sourceforge.net  Wed Jul 11 14:33:19 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 11 Jul 2007 05:33:19 -0700
Subject: [Patches] [ python-Patches-1751801 ] Patch for Windows build
Message-ID: <E1I8bNf-00072I-Az@sc8-sf-web24.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Thomas Heller (theller)
Assigned to: Nobody/Anonymous (nobody)
Summary: Patch for Windows build

Initial Comment:
In Modules/_fileio.c, HAVE_FTRUNCATE is undefined for Windows.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-11 08:33

Message:
Logged In: YES 
user_id=6380
Originator: NO

Looks fine. Can you check this in yourself?

Nit: I note that the line added for _fileio to PC/config.c is improperly
indented (space/tab issue?).

Note that this will make various tests using f.truncate() fail.  At some
point we need to implement it using the same APIs as were used in the old
file object.

Also, my hope is that eventually we'll have a Windows specific version of
_fileio.c instead of this code, using all-native Windows API calls.  (Any
volunteers?)

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

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

From noreply at sourceforge.net  Wed Jul 11 14:36:50 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 11 Jul 2007 05:36:50 -0700
Subject: [Patches] [ python-Patches-1724999 ] dict size changes during iter
Message-ID: <E1I8bR4-0007Nl-AL@sc8-sf-web24.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Tkinter
Group: Python 3000
>Status: Pending
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Ali Gholami Rudi (aligrudi)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: dict size changes during iter

Initial Comment:
In p3yk branch and Ubuntu 2.6.20-15

In::

  from Tkinter import *


  root = Tk()
  toplevel = Toplevel()
  def destroy():
      toplevel.destroy()
  button = Button(toplevel, text='Press Me',
                  command=destroy)
  button.pack()
  toplevel.focus_set()

  root.mainloop()

When the button is pressed I get::

  Exception in Tkinter callback
  Traceback (most recent call last):
    File "/usr/local/lib/python3.0/lib-tk/Tkinter.py", line 1403, in __call__
      return self.func(*args)
    File "mod.py", line 7, in destroy
      toplevel.destroy()
    File "/usr/local/lib/python3.0/lib-tk/Tkinter.py", line 1935, in destroy
      for c in self.children.values(): c.destroy()
  RuntimeError: dictionary changed size during iteration

The attached patch solves this.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-11 08:36

Message:
Logged In: YES 
user_id=6380
Originator: NO

Committed revision 56263.


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

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

From noreply at sourceforge.net  Wed Jul 11 14:38:25 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 11 Jul 2007 05:38:25 -0700
Subject: [Patches] [ python-Patches-1718153 ] PEP 3123 implementation
Message-ID: <E1I8bSb-0001IN-Sq@sc8-sf-web22.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Martin v. L?wis (loewis)
Assigned to: Nobody/Anonymous (nobody)
Summary: PEP 3123 implementation

Initial Comment:
This patch implements the changes need for PEP 3123, in Py3k. Rather than checking this into the 3k branch, a backport of those bulk of the patch to 2.6 should be made, omitting the actual changes to PyObject_HEAD

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-11 08:38

Message:
Logged In: YES 
user_id=6380
Originator: NO

Is this ready to be committed?

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

Comment By: Martin v. L?wis (loewis)
Date: 2007-05-23 17:55

Message:
Logged In: YES 
user_id=21627
Originator: YES

I don't think API compatibility between 2.5 and 3.0 should be a
requirement - I expect that there will be much more breakage, making such
compatibility very difficult for other reasons.

Anyway, for everything that can be done with a macro (including
HEAD_INIT), code that wants compatibility with 2.5 and earlier should do

#ifndef MACRO
#define MACRO 2.6-content of macro
#endif

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-23 01:29

Message:
Logged In: YES 
user_id=33168
Originator: NO

I like this patch would like it to be applied to 2.6.  However, I'm
concerned about extension modules maintaining compatibility for 2.5 and
3.0.  What would that look like (ie, an extension module that can compile
with both versions)?  How would the modules need to be changed to support
both versions?  For Py_{Type,Refcnt,Size}, it looks pretty straightforward
to define the macros in 2.x and things should work fine.  But I'm not sure
about the HEAD_INIT macros.

Martin, did you try disabling the -fno-strict-aliasing with this patch to
see if there were any warnings?

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

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

From noreply at sourceforge.net  Wed Jul 11 14:39:23 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 11 Jul 2007 05:39:23 -0700
Subject: [Patches] [ python-Patches-1713889 ] Patch for PEP 3109
Message-ID: <E1I8bTX-0001PO-Py@sc8-sf-web22.sourceforge.net>

Patches item #1713889, was opened at 2007-05-06 14:41
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1713889&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 3000
>Status: Closed
>Resolution: Rejected
Priority: 5
Private: No
Submitted By: wpy (wpy)
Assigned to: Collin Winter (collinwinter)
Summary: Patch for PEP 3109

Initial Comment:
The patch modify the raise statement, according to PEP
3109 and script fix_raise.py (available in sandbox 
directory of SVN).
Compile all ok, but it's not complete: now, exiting from 
Python interpreter, there is Segmentation fault.
I think to work on this problem in next days.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-11 08:39

Message:
Logged In: YES 
user_id=6380
Originator: NO

Closing this for lack of progress.  (Collin, how's your own version coming
along?)

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

Comment By: Collin Winter (collinwinter)
Date: 2007-05-11 12:40

Message:
Logged In: YES 
user_id=1344176
Originator: NO

The patch to Python/compile.c is still obviously incorrect, even more so
than before. Try this:

>>> assert True is False
>>>

And of course, this little gem:

>>> assert True is False, "um really?"
Traceback (most recent call last):
TypeError: exceptions must derive from BaseException
>>>

Your unwillingness, inability or disinclination to properly test your
patch is wasting my time.

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

Comment By: wpy (wpy)
Date: 2007-05-11 11:08

Message:
Logged In: YES 
user_id=1373701
Originator: YES

I have corrected the patch.

1) In the patch, I would to put also the modifications to
.py files of distribution? I don't thought... So the patch become very
big!!!
If you want, I do it.
The patch concerns to implementation (C source files) only!...

2) In the new patch I dropped the code for "__traceback__ part" of
the PEP 3109. Therefore, after application of the fix_raise.py script to
library some modules not works whatever.
File Added: pep3109-2.patch

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

Comment By: wpy (wpy)
Date: 2007-05-11 05:24

Message:
Logged In: YES 
user_id=1373701
Originator: YES

OK, today I will work on this problems.
I hope to release a new patch in short time.

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

Comment By: Collin Winter (collinwinter)
Date: 2007-05-11 01:14

Message:
Logged In: YES 
user_id=1344176
Originator: NO

Issues:

0) The patch does not apply cleanly; please update it.
1) The patch is incorrect. It does not address the fact that compiling a
2-arg assert statement emits "RAISE_VARARGS 2".
2) The patch is spectacularly untested: because of (1), the interpreter
crashes almost immediately when running regrtest.py.
3) Even if you fix (1), the patch is not refcount-correct: regrtest.py
crashes after test_dict due to a refcounting error.

Also: the patch implements the "e.__traceback__ = T" implicit assignment.
The last I knew, there had never been a formal decision on whether to go
ahead with that part of the PEP (there having been quite an uproar and
whatnot). Guido: we may have kicked this particular can as far down the
road as it's going to go. As soon as we come to a final decision on this, I
have a tested, refcount-safe implementation that I'll put up on SF.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-05-08 20:10

Message:
Logged In: YES 
user_id=6380
Originator: NO

Collin, can you review this?

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

Comment By: wpy (wpy)
Date: 2007-05-08 10:12

Message:
Logged In: YES 
user_id=1373701
Originator: YES

I have correct all errors.

I hope that it is useful.
File Added: pep3109.patch

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

Comment By: wpy (wpy)
Date: 2007-05-07 13:56

Message:
Logged In: YES 
user_id=1373701
Originator: YES

File Added: pep3109-2.patch

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

Comment By: wpy (wpy)
Date: 2007-05-07 13:06

Message:
Logged In: YES 
user_id=1373701
Originator: YES

With compiler (GCC) options "-g3 -ggdb3" there isn't Segmentation fault.
With default option "-g" yes....

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

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

From noreply at sourceforge.net  Wed Jul 11 14:47:54 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 11 Jul 2007 05:47:54 -0700
Subject: [Patches] [ python-Patches-1751801 ] Patch for Windows build
Message-ID: <E1I8bbm-0002JH-JL@sc8-sf-web22.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 3000
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Thomas Heller (theller)
Assigned to: Nobody/Anonymous (nobody)
Summary: Patch for Windows build

Initial Comment:
In Modules/_fileio.c, HAVE_FTRUNCATE is undefined for Windows.

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

>Comment By: Thomas Heller (theller)
Date: 2007-07-11 14:47

Message:
Logged In: YES 
user_id=11105
Originator: YES

Committed as SVN rev. 56264, after fixing the indentation of the added
lines in config.c.
Note that config.c is indented partly with tabs, partly with spaces
anyway.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-11 14:33

Message:
Logged In: YES 
user_id=6380
Originator: NO

Looks fine. Can you check this in yourself?

Nit: I note that the line added for _fileio to PC/config.c is improperly
indented (space/tab issue?).

Note that this will make various tests using f.truncate() fail.  At some
point we need to implement it using the same APIs as were used in the old
file object.

Also, my hope is that eventually we'll have a Windows specific version of
_fileio.c instead of this code, using all-native Windows API calls.  (Any
volunteers?)

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

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

From noreply at sourceforge.net  Wed Jul 11 15:08:34 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 11 Jul 2007 06:08:34 -0700
Subject: [Patches] [ python-Patches-1706989 ] Implementation of
	@abstractmethod for PEP 3119
Message-ID: <E1I8bvm-0003gZ-5n@sc8-sf-web21.sourceforge.net>

Patches item #1706989, was opened at 2007-04-24 18:45
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1706989&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 3000
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Implementation of @abstractmethod for PEP 3119

Initial Comment:
This implements a new builtin, abstractmethod, which when used as a method decorator declares the method to be abstract, causing the class to be abstract (i.e. it cannot be instantiated).  A subclass of an abstract class is still abstract unless it overrides all abstract base methods.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-11 09:08

Message:
Logged In: YES 
user_id=6380
Originator: YES

Something like this was submitted quite a while ago.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-04-25 12:51

Message:
Logged In: YES 
user_id=6380
Originator: YES

Neil: The intention is that only methods can be abstract.  I don't think
we should attempt to only check the __isabstractmethod__ attribute for
objects that we know are methods; that would be an expensive check to make
(you'd have to call __get__ if it exists) and since this is a __magic__
attribute, you void your warrantee if you mess with it. :-)

In this version (v3), I've fixed the C nits and done the refactoring you
suggested, and also added an optimization: check_abstracts() returns
immediately if the base class doesn't have the ABSTRACT flag set.
File Added: abstract.diff

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-04-25 01:35

Message:
Logged In: YES 
user_id=33168
Originator: NO

Perhaps this is a better question for the PEP rather than the impl, but
can attributes be abstract?

class Foo:
  abstract_override_me = ???

If so, then __isabstractmethod__ might be better named as: 
__isabstract__.  I think this might work:

class Abstract:
  __isabstractmethod__ = True

class Foo:
  abstract_override_me = Abstract()

Do you want arbitrary objects to be able to declare their abstractness or
should the impl also check that an attribute is callable?

check_new_abstracts() should return a Py_ssize_t since it returns the size
of a container (set).  The return value is already captured in a
Py_ssize_t, so it's just the signature (and prototype) that should change.

PySet_Add()s return value isn't checked in check_new_abstracts().  It
might be nice to factor out the common code between the two new functions
into a static helper function.  That would get rid of the PySet_Add
problem.

By calling: PyObject_GetAttrString(meth, "__isabstractmethod__"), that
means a new string object is allocated and then thrown away with each call.
 This could be improved by creating an interned string for
"__isabstractmethod__".  (I realize this is only when types are created
which shouldn't be too often.)

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-04-24 19:31

Message:
Logged In: YES 
user_id=6380
Originator: YES

Here's a version that compiles with C89 (GCC 2.96) and doesn't leak the
'fast' object.
File Added: abstract.diff

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

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

From noreply at sourceforge.net  Wed Jul 11 16:57:59 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 11 Jul 2007 07:57:59 -0700
Subject: [Patches] [ python-Patches-1751958 ] struni: gettext fixes
Message-ID: <E1I8ddf-0001Gn-R7@sc8-sf-web22.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Modules
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Christian Heimes (tiran)
Assigned to: Nobody/Anonymous (nobody)
Summary: struni: gettext fixes

Initial Comment:
Fixes for the gettext module. I tested the fixes with the Zope3 zope.app.locales packages. The mo files are loaded and parsed w/o any problem. The translation with gettext.gettext is working as expected.

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

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

From noreply at sourceforge.net  Wed Jul 11 17:07:48 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 11 Jul 2007 08:07:48 -0700
Subject: [Patches] [ python-Patches-1751965 ] Typo in
	Lib/lib-tk/ScrolledText.py
Message-ID: <E1I8dnA-0001cQ-CQ@sc8-sf-web24.sourceforge.net>

Patches item #1751965, was opened at 2007-07-11 18:37
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=1751965&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Tkinter
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ali Gholami Rudi (aligrudi)
Assigned to: Martin v. L?wis (loewis)
Summary: Typo in Lib/lib-tk/ScrolledText.py

Initial Comment:
It should be ``isinstance()``.  A patch is attached.

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

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

From noreply at sourceforge.net  Wed Jul 11 17:10:59 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 11 Jul 2007 08:10:59 -0700
Subject: [Patches] [ python-Patches-1751965 ] Typo in
	Lib/lib-tk/ScrolledText.py
Message-ID: <E1I8dqF-0002lj-D6@sc8-sf-web22.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Tkinter
Group: Python 3000
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Ali Gholami Rudi (aligrudi)
Assigned to: Martin v. L?wis (loewis)
Summary: Typo in Lib/lib-tk/ScrolledText.py

Initial Comment:
It should be ``isinstance()``.  A patch is attached.

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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-07-11 15:10

Message:
Logged In: YES 
user_id=849994
Originator: NO

Thanks, fixed in rev. 56274.

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

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

From noreply at sourceforge.net  Wed Jul 11 17:16:26 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 11 Jul 2007 08:16:26 -0700
Subject: [Patches] [ python-Patches-1736190 ] asyncore/asynchat patches
Message-ID: <E1I8dvW-0003Rm-RC@sc8-sf-web22.sourceforge.net>

Patches item #1736190, was opened at 2007-06-13 02:37
Message generated for change (Comment added) made by billiejoex
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1736190&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Josiah Carlson (josiahcarlson)
Assigned to: Josiah Carlson (josiahcarlson)
Summary: asyncore/asynchat patches

Initial Comment:
There are a handful of outstanding asyncore/asynchat related bugs in the tracker.  This patch seeks to handle all of the issues with the exception of windows-specific socket errors from 658749 .

In particular, it takes pieces of patches 909005 and 1736101, to address some issues raised there, as well as the bugs: 539444, 760475, 777588, 889153, 953599, 1025525, and 1063924.

In some cases where it could potentially handle fewer exceptions (see the send method), I have opted to handle more of them due to testing actually producing them.

It adds test cases from patch 909005.

It adds two new sample methods to asynchat.async_chat _get_data and _collect_incoming_data to be used as examples for handling incoming buffers.

It removes the simple_producer and fifo classes from asynchat, but accepts work-alikes to the asynchat.async_chat.push_with_producer method.

It further fixes an unreported violated invariant in asynchat.async_chat.handle_read() .

It also produces a useful error message when asyncore.dispatcher.handle_expt_evt is called if the base handle_expt has not been overwritten.


This patch should be applied to the trunk.  The new methods, and removal of the two classes should not be included in patches to 2.5 maintenance (don't add the methods and don't remove the classes).  Basically everything else should work as it did before (with better error handling), unless someone was monkey-patching asyncore.dispatcher.handle_expt .

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

Comment By: billiejoex (billiejoex)
Date: 2007-07-11 17:16

Message:
Logged In: YES 
user_id=1357589
Originator: NO

Good work. I would only rencommend to include documentation for
asyncore.close_all function, actually not documented yet.

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

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

From noreply at sourceforge.net  Wed Jul 11 20:01:18 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 11 Jul 2007 11:01:18 -0700
Subject: [Patches] [ python-Patches-1752132 ] opcode.h incorrectly describes
	arg of SETUP_*
Message-ID: <E1I8gV4-0005fE-4S@sc8-sf-web24.sourceforge.net>

Patches item #1752132, was opened at 2007-07-11 14: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=1752132&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Christopher Tur Lesniewski-Laas (ctl)
Assigned to: Nobody/Anonymous (nobody)
Summary: opcode.h incorrectly describes arg of SETUP_*

Initial Comment:
The argument to the SETUP_* opcodes is not an absolute offset as described in the comment.  It is a relative offset.  This one line patch corrects the comment.

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

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

From noreply at sourceforge.net  Wed Jul 11 21:37:04 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 11 Jul 2007 12:37:04 -0700
Subject: [Patches] [ python-Patches-1752173 ] Use the bytes type in asynchat
Message-ID: <E1I8hzk-0001UU-BJ@sc8-sf-web22.sourceforge.net>

Patches item #1752173, was opened at 2007-07-11 15:37
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=1752173&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alexandre Vassalotti (avassalotti)
Assigned to: Nobody/Anonymous (nobody)
Summary: Use the bytes type in asynchat

Initial Comment:
The unit test in py3k-struni was failing because asynchat.py was trying concatenate str and bytes strings. My solution is to make asynchat use and return only bytes strings.

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

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

From noreply at sourceforge.net  Wed Jul 11 21:40:10 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 11 Jul 2007 12:40:10 -0700
Subject: [Patches] [ python-Patches-1752175 ] fixing 2.5.1 build with
	unicode and dynamic loading disabled
Message-ID: <E1I8i2k-0003oi-1V@sc8-sf-web23.sourceforge.net>

Patches item #1752175, was opened at 2007-07-11 21:40
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=1752175&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alexander Neundorf (neundorf)
Assigned to: Nobody/Anonymous (nobody)
Summary: fixing 2.5.1 build with unicode and dynamic loading disabled

Initial Comment:
I'm currently porting python to some 
platforms with limited capabilities and so I thought it would be a good idea 
to subscribe here.
While doing the porting, I found two small problems in Python 2.5.1:

If Py_USING_UNICODE is disabled, in Python/ast.c decode_unicode() still calls 
unicode-related functions, which leads to undefined references when linking.

If HAVE_DYNAMIC_LOADING is disabled, in Python/import.c 
_PyImport_DynLoadFiletab is still initialized, which also leads to undefined 
references when linking, since then no source file which defines this 
variable is used.


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

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

From noreply at sourceforge.net  Wed Jul 11 21:42:01 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 11 Jul 2007 12:42:01 -0700
Subject: [Patches] [ python-Patches-1752132 ] opcode.h incorrectly describes
	arg of SETUP_*
Message-ID: <E1I8i4X-0001xk-Bn@sc8-sf-web22.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 2.6
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Christopher Tur Lesniewski-Laas (ctl)
Assigned to: Nobody/Anonymous (nobody)
Summary: opcode.h incorrectly describes arg of SETUP_*

Initial Comment:
The argument to the SETUP_* opcodes is not an absolute offset as described in the comment.  It is a relative offset.  This one line patch corrects the comment.

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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-07-11 19:42

Message:
Logged In: YES 
user_id=849994
Originator: NO

Thanks, committed as rev. 56280, 56281 (2.5).

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

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

From noreply at sourceforge.net  Wed Jul 11 21:46:29 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 11 Jul 2007 12:46:29 -0700
Subject: [Patches] [ python-Patches-1752184 ] PyHeapTypeObject fix
Message-ID: <E1I8i8r-0004AU-21@sc8-sf-web22.sourceforge.net>

Patches item #1752184, was opened at 2007-07-11 21:46
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=1752184&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Thomas Heller (theller)
Assigned to: Guido van Rossum (gvanrossum)
Summary: PyHeapTypeObject fix

Initial Comment:
This patch makes sure that the PyHeapTypeObject's ht_name member always contains a PyUnicode_Object.  Other code relies on this.

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

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

From noreply at sourceforge.net  Wed Jul 11 22:02:08 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 11 Jul 2007 13:02:08 -0700
Subject: [Patches] [ python-Patches-1752195 ] struni: for for poll, pep263,
	bigmem and a bit pickletool
Message-ID: <E1I8iO0-0002cl-Dp@sc8-sf-web24.sourceforge.net>

Patches item #1752195, was opened at 2007-07-11 22:02
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=1752195&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Tests
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Christian Heimes (tiran)
Assigned to: Nobody/Anonymous (nobody)
Summary: struni: for for poll, pep263, bigmem and a bit pickletool 

Initial Comment:
The patch fixes three unit test modules and some unit tests of pickletools.

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

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

From noreply at sourceforge.net  Wed Jul 11 22:56:45 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 11 Jul 2007 13:56:45 -0700
Subject: [Patches] [ python-Patches-1752225 ] struni: _fileio fixes for
	Windows
Message-ID: <E1I8jEr-0003gT-J3@sc8-sf-web21.sourceforge.net>

Patches item #1752225, was opened at 2007-07-11 22:56
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=1752225&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Amaury Forgeot d'Arc (amauryf)
Assigned to: Nobody/Anonymous (nobody)
Summary: struni: _fileio fixes for Windows

Initial Comment:
Theses patches correct two problems in the _fileio module on Windows:
- fileio-1.diff: Support for wide filenames: we use _wopen() with a unicode string.
- fileio-2.diff: Replaces ftruncate with Win32 API functions. Code borrowed from fileobject.c


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

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

From noreply at sourceforge.net  Wed Jul 11 22:58:24 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 11 Jul 2007 13:58:24 -0700
Subject: [Patches] [ python-Patches-1752225 ] struni: _fileio fixes for
	Windows
Message-ID: <E1I8jGS-0003uV-9I@sc8-sf-web21.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Amaury Forgeot d'Arc (amauryf)
>Assigned to: Thomas Heller (theller)
Summary: struni: _fileio fixes for Windows

Initial Comment:
Theses patches correct two problems in the _fileio module on Windows:
- fileio-1.diff: Support for wide filenames: we use _wopen() with a unicode string.
- fileio-2.diff: Replaces ftruncate with Win32 API functions. Code borrowed from fileobject.c


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

>Comment By: Amaury Forgeot d'Arc (amauryf)
Date: 2007-07-11 22:58

Message:
Logged In: YES 
user_id=389140
Originator: YES

File Added: fileio-2.diff

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

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

From noreply at sourceforge.net  Wed Jul 11 23:08:12 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 11 Jul 2007 14:08:12 -0700
Subject: [Patches] [ python-Patches-1752229 ] Use the Unicode API in
	dlmodule.c
Message-ID: <E1I8jPw-00053T-L5@sc8-sf-web21.sourceforge.net>

Patches item #1752229, was opened at 2007-07-11 17:08
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=1752229&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Modules
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alexandre Vassalotti (avassalotti)
Assigned to: Nobody/Anonymous (nobody)
Summary: Use the Unicode API in dlmodule.c

Initial Comment:
Fix failing test in py3k-struni.

The patch simply replaces PyString_* calls with PyUnicode_*

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

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

From noreply at sourceforge.net  Wed Jul 11 23:15:46 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 11 Jul 2007 14:15:46 -0700
Subject: [Patches] [ python-Patches-1752184 ] PyHeapTypeObject fix
Message-ID: <E1I8jXG-0005sJ-DL@sc8-sf-web21.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Thomas Heller (theller)
Assigned to: Guido van Rossum (gvanrossum)
Summary: PyHeapTypeObject fix

Initial Comment:
This patch makes sure that the PyHeapTypeObject's ht_name member always contains a PyUnicode_Object.  Other code relies on this.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-11 17:15

Message:
Logged In: YES 
user_id=6380
Originator: NO

You're right there's a refcount leak.  Can you rework the patch to avoid
this?  One way would be to remove the later INCREF(value) and move that
into the code for when value is already a unicode. Then all the error
returns from them on must DECREF(value).

Also, the test for null bytes is not correct if there can be non-ASCII
characters in the name (as Martin will eventually implement), since it is
comparing the strlen() of the 8-bit string (which is UTF-8) with the length
of the Unicode string.  I wonder if we shouldn't add a generic API that
checks for null characters in a string, as I expect we'll need this in
other places too and the correct idiom is much more complicated now.

I also think that you might be able to simply insist on unicode, rather
than accepting both string and unicode.  That way we'll find any remaining
offenders more quickly (probably there aren't many).

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

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

From noreply at sourceforge.net  Wed Jul 11 23:31:35 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 11 Jul 2007 14:31:35 -0700
Subject: [Patches] [ python-Patches-1752184 ] PyHeapTypeObject fix
Message-ID: <E1I8jmZ-0004Jj-5X@sc8-sf-web24.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Thomas Heller (theller)
Assigned to: Guido van Rossum (gvanrossum)
Summary: PyHeapTypeObject fix

Initial Comment:
This patch makes sure that the PyHeapTypeObject's ht_name member always contains a PyUnicode_Object.  Other code relies on this.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-11 17:31

Message:
Logged In: YES 
user_id=6380
Originator: NO

Some test results: with this patch, test_ast fails weirdly:
test test_ast crashed -- <type 'SystemError'>: bad format char passed to
Py_BuildValue

I added assert(PyUnicode_Check(value)); to the top of the function and it
never triggered during any of the unit tests (I am in a debug build).  So
that's a safe assumption.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-11 17:15

Message:
Logged In: YES 
user_id=6380
Originator: NO

You're right there's a refcount leak.  Can you rework the patch to avoid
this?  One way would be to remove the later INCREF(value) and move that
into the code for when value is already a unicode. Then all the error
returns from them on must DECREF(value).

Also, the test for null bytes is not correct if there can be non-ASCII
characters in the name (as Martin will eventually implement), since it is
comparing the strlen() of the 8-bit string (which is UTF-8) with the length
of the Unicode string.  I wonder if we shouldn't add a generic API that
checks for null characters in a string, as I expect we'll need this in
other places too and the correct idiom is much more complicated now.

I also think that you might be able to simply insist on unicode, rather
than accepting both string and unicode.  That way we'll find any remaining
offenders more quickly (probably there aren't many).

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

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

From noreply at sourceforge.net  Wed Jul 11 23:43:34 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 11 Jul 2007 14:43:34 -0700
Subject: [Patches] [ python-Patches-1718153 ] PEP 3123 implementation
Message-ID: <E1I8jyA-0005fB-C2@sc8-sf-web24.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Martin v. L?wis (loewis)
Assigned to: Nobody/Anonymous (nobody)
Summary: PEP 3123 implementation

Initial Comment:
This patch implements the changes need for PEP 3123, in Py3k. Rather than checking this into the 3k branch, a backport of those bulk of the patch to 2.6 should be made, omitting the actual changes to PyObject_HEAD

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

>Comment By: Martin v. L?wis (loewis)
Date: 2007-07-11 23:43

Message:
Logged In: YES 
user_id=21627
Originator: YES

Depends on the precise procedure to follow. I have a patch that works for
2.6 (but it's not included here); should I commit that?

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-11 14:38

Message:
Logged In: YES 
user_id=6380
Originator: NO

Is this ready to be committed?

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

Comment By: Martin v. L?wis (loewis)
Date: 2007-05-23 23:55

Message:
Logged In: YES 
user_id=21627
Originator: YES

I don't think API compatibility between 2.5 and 3.0 should be a
requirement - I expect that there will be much more breakage, making such
compatibility very difficult for other reasons.

Anyway, for everything that can be done with a macro (including
HEAD_INIT), code that wants compatibility with 2.5 and earlier should do

#ifndef MACRO
#define MACRO 2.6-content of macro
#endif

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-23 07:29

Message:
Logged In: YES 
user_id=33168
Originator: NO

I like this patch would like it to be applied to 2.6.  However, I'm
concerned about extension modules maintaining compatibility for 2.5 and
3.0.  What would that look like (ie, an extension module that can compile
with both versions)?  How would the modules need to be changed to support
both versions?  For Py_{Type,Refcnt,Size}, it looks pretty straightforward
to define the macros in 2.x and things should work fine.  But I'm not sure
about the HEAD_INIT macros.

Martin, did you try disabling the -fno-strict-aliasing with this patch to
see if there were any warnings?

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

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

From noreply at sourceforge.net  Thu Jul 12 01:12:06 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 11 Jul 2007 16:12:06 -0700
Subject: [Patches] [ python-Patches-1752270 ] urllib2 1750931 alternative
	patch
Message-ID: <E1I8lLq-0002PA-SR@sc8-sf-web21.sourceforge.net>

Patches item #1752270, was opened at 2007-07-12 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=1752270&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: John J Lee (jjlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 1750931 alternative patch

Initial Comment:
This is an alternative patch to http://python.org/sf/1750931 .  Please continue discussion there.


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

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

From noreply at sourceforge.net  Thu Jul 12 01:16:24 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 11 Jul 2007 16:16:24 -0700
Subject: [Patches] [ python-Patches-1750931 ] make build_opener raise
	exception when not passed a handler
Message-ID: <E1I8lQ0-0002re-Se@sc8-sf-web21.sourceforge.net>

Patches item #1750931, was opened at 2007-07-10 05:14
Message generated for change (Comment added) made by jjlee
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1750931&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Robert Renaud (silentstrike)
Assigned to: Nobody/Anonymous (nobody)
Summary: make build_opener raise exception when not passed a handler

Initial Comment:
A bug bit me where I had code that looked like

urllib2.build_opener(func_returning_cookie_jar())

instead of

urllib2.build_opener(HTTPCookieProcessor(func_returning_cookie_jar())

the subsequent http request went through just fine, except it didn't send the cookie.  Nothing complained, except me, now.

Throwing the exception deeper in the code made the unittest fail, so I suspect the "silently ignore handlers which don't actually do any handling" behavior might be by design, but it seems terrible to me.

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

Comment By: John J Lee (jjlee)
Date: 2007-07-12 00:16

Message:
Logged In: YES 
user_id=261020
Originator: NO

Patch #1752270 seems more idiomatic (TypeError, not ValueError) and mildly
less intrusive (it does not change the return value of
urllib2.OpenerDirector.add_handler()).  Also, your patch adds a backwards
incompatibility which the new one does not: Currently a correct call to
urllib2.build_opener() may return successfully without adding all of its
handler arguments to the returned urllib2.OpenerDirector, since a
urllib2.BaseHandler instance may have no appropriate methods (no
.http_open(), etc. etc.).  Your patch causes build_opener() (but not
.add_handler()) to raise ValueError in that case.  One could argue that it
should raise an exception, but there is still scope for breakage, e.g.
since these attributes may be added at runtime, and the number of added
attributes may happen to be zero (and in fact, urllib2.ProxyHandler falls
into this category).

I think the docs do not need to be updated if my revised patch is applied,
since they already state that urllib2.OpenerDirector.add_handler() accepts
only urllib2.BaseHandler instances (and typically the possibility of a
TypeError being raised is not explicitly documented in stdlib docs).


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

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

From noreply at sourceforge.net  Thu Jul 12 01:52:48 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 11 Jul 2007 16:52:48 -0700
Subject: [Patches] [ python-Patches-1750931 ] make build_opener raise
	exception when not passed a handler
Message-ID: <E1I8lzE-0003Cs-PX@sc8-sf-web23.sourceforge.net>

Patches item #1750931, was opened at 2007-07-10 04:14
Message generated for change (Comment added) made by silentstrike
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1750931&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 2.6
Status: Open
>Resolution: Rejected
Priority: 5
Private: No
Submitted By: Robert Renaud (silentstrike)
Assigned to: Nobody/Anonymous (nobody)
Summary: make build_opener raise exception when not passed a handler

Initial Comment:
A bug bit me where I had code that looked like

urllib2.build_opener(func_returning_cookie_jar())

instead of

urllib2.build_opener(HTTPCookieProcessor(func_returning_cookie_jar())

the subsequent http request went through just fine, except it didn't send the cookie.  Nothing complained, except me, now.

Throwing the exception deeper in the code made the unittest fail, so I suspect the "silently ignore handlers which don't actually do any handling" behavior might be by design, but it seems terrible to me.

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

>Comment By: Robert Renaud (silentstrike)
Date: 2007-07-11 23:52

Message:
Logged In: YES 
user_id=235882
Originator: YES

Your patch looks good to me, I have no objection so long as this error
will be caught instead of failing without complaint.  I am rejecting my
patch in favor of yours.  Thanks for looking into this.

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

Comment By: John J Lee (jjlee)
Date: 2007-07-11 23:16

Message:
Logged In: YES 
user_id=261020
Originator: NO

Patch #1752270 seems more idiomatic (TypeError, not ValueError) and mildly
less intrusive (it does not change the return value of
urllib2.OpenerDirector.add_handler()).  Also, your patch adds a backwards
incompatibility which the new one does not: Currently a correct call to
urllib2.build_opener() may return successfully without adding all of its
handler arguments to the returned urllib2.OpenerDirector, since a
urllib2.BaseHandler instance may have no appropriate methods (no
.http_open(), etc. etc.).  Your patch causes build_opener() (but not
.add_handler()) to raise ValueError in that case.  One could argue that it
should raise an exception, but there is still scope for breakage, e.g.
since these attributes may be added at runtime, and the number of added
attributes may happen to be zero (and in fact, urllib2.ProxyHandler falls
into this category).

I think the docs do not need to be updated if my revised patch is applied,
since they already state that urllib2.OpenerDirector.add_handler() accepts
only urllib2.BaseHandler instances (and typically the possibility of a
TypeError being raised is not explicitly documented in stdlib docs).


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

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

From noreply at sourceforge.net  Thu Jul 12 01:57:21 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 11 Jul 2007 16:57:21 -0700
Subject: [Patches] [ python-Patches-1675455 ] Use getaddrinfo() in
	urllib2.py for IPv6 support
Message-ID: <E1I8m3d-00072C-P5@sc8-sf-web21.sourceforge.net>

Patches item #1675455, was opened at 2007-03-07 05:19
Message generated for change (Comment added) made by jjlee
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1675455&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: David Cantrell (dcantrell-rh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Use getaddrinfo() in urllib2.py for IPv6 support

Initial Comment:
A number of base Python modules use gethostbyname() when they should be using getaddrinfo().  The big limitation hit when using gethostbyname() is the lack of IPv6 support.

This first patch is for urllib2.py.  It replaces all uses of gethostbyname() with getaddrinfo() instead.  getaddrinfo() returns a 5-tuple, so additional code needs to wrap a getaddrinfo() call when replacing gethostbyname() calls.  Still should be pretty simple to read.

I'd like to see this patch added to the next stable release of Python, if at all possible.  I am working up patches for the other modules I see in the Lib/ subdirectory that could use getaddrinfo() instead of gethostbyname().

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

Comment By: John J Lee (jjlee)
Date: 2007-07-12 00:57

Message:
Logged In: YES 
user_id=261020
Originator: NO

* Where are the tests?  A functional test, perhaps in test_urllib2net.py,
for IPv6 support in urllib2 would be especially welcome, I think.
* Why does .check_host() not begin with an underscore?
* "check_host" is a poor name.  How about "_is_localhost"?
* locals is a built-in function, hence usually considered good style not
to use it as a name.
* Is is necessary to call make_host_tuple(searchlist) twice?
* The patch appears to fix several bugs at once (e.g. adding a try: /
except: suite around a large part of an existing method to catch
socket.error).


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

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

From noreply at sourceforge.net  Thu Jul 12 01:57:32 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 11 Jul 2007 16:57:32 -0700
Subject: [Patches] [ python-Patches-1752317 ] reference leak in
	_PyUnicode_AsDefaultEncodedString
Message-ID: <E1I8m3o-0003kg-5R@sc8-sf-web23.sourceforge.net>

Patches item #1752317, was opened at 2007-07-12 01: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=1752317&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Amaury Forgeot d'Arc (amauryf)
Assigned to: Nobody/Anonymous (nobody)
Summary: reference leak in _PyUnicode_AsDefaultEncodedString

Initial Comment:
If I understand correctlty, _PyUnicode_AsDefaultEncodedString creates and caches a utf8 translation of the string. It returns a borrowed reference to this.
But the stored value (in ->defenc) has a refcount of 2, and will never be released when the unicode object is freed.

The effect is obvious in debug build: the total references count used to increase by 1 for each function call.

The patch is easy:

Index: Objects/unicodeobject.c
=======================================================
--- Objects/unicodeobject.c     (revision 56284)
+++ Objects/unicodeobject.c     (working copy)
@@ -1207,7 +1213,6 @@
                                    PyBytes_Size(b));
     Py_DECREF(b);
     if (!errors) {
-        Py_XINCREF(v);
         ((PyUnicodeObject *)unicode)->defenc = v;
     }
     return v;



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

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

From noreply at sourceforge.net  Thu Jul 12 02:00:34 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 11 Jul 2007 17:00:34 -0700
Subject: [Patches] [ python-Patches-1752317 ] reference leak in
	_PyUnicode_AsDefaultEncodedString
Message-ID: <E1I8m6k-00045I-4i@sc8-sf-web23.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Amaury Forgeot d'Arc (amauryf)
Assigned to: Nobody/Anonymous (nobody)
Summary: reference leak in _PyUnicode_AsDefaultEncodedString

Initial Comment:
If I understand correctlty, _PyUnicode_AsDefaultEncodedString creates and caches a utf8 translation of the string. It returns a borrowed reference to this.
But the stored value (in ->defenc) has a refcount of 2, and will never be released when the unicode object is freed.

The effect is obvious in debug build: the total references count used to increase by 1 for each function call.

The patch is easy:

Index: Objects/unicodeobject.c
=======================================================
--- Objects/unicodeobject.c     (revision 56284)
+++ Objects/unicodeobject.c     (working copy)
@@ -1207,7 +1213,6 @@
                                    PyBytes_Size(b));
     Py_DECREF(b);
     if (!errors) {
-        Py_XINCREF(v);
         ((PyUnicodeObject *)unicode)->defenc = v;
     }
     return v;



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

>Comment By: Amaury Forgeot d'Arc (amauryf)
Date: 2007-07-12 02:00

Message:
Logged In: YES 
user_id=389140
Originator: YES

Of course, sourceforge ate the spaces again... sorry.
Here is the patch again:

Index: Objects/unicodeobject.c
===================================================================
--- Objects/unicodeobject.c     (revision 56284)
+++ Objects/unicodeobject.c     (working copy)
@@ -1207,7 +1207,6 @@
                                    PyBytes_Size(b));
     Py_DECREF(b);
     if (!errors) {
-        Py_XINCREF(v);
         ((PyUnicodeObject *)unicode)->defenc = v;
     }
     return v;


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

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

From noreply at sourceforge.net  Thu Jul 12 02:03:23 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 11 Jul 2007 17:03:23 -0700
Subject: [Patches] [ python-Patches-1752317 ] reference leak in
	_PyUnicode_AsDefaultEncodedString
Message-ID: <E1I8m9T-0004Ph-B7@sc8-sf-web23.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Amaury Forgeot d'Arc (amauryf)
>Assigned to: Thomas Heller (theller)
Summary: reference leak in _PyUnicode_AsDefaultEncodedString

Initial Comment:
If I understand correctlty, _PyUnicode_AsDefaultEncodedString creates and caches a utf8 translation of the string. It returns a borrowed reference to this.
But the stored value (in ->defenc) has a refcount of 2, and will never be released when the unicode object is freed.

The effect is obvious in debug build: the total references count used to increase by 1 for each function call.

The patch is easy:

Index: Objects/unicodeobject.c
=======================================================
--- Objects/unicodeobject.c     (revision 56284)
+++ Objects/unicodeobject.c     (working copy)
@@ -1207,7 +1213,6 @@
                                    PyBytes_Size(b));
     Py_DECREF(b);
     if (!errors) {
-        Py_XINCREF(v);
         ((PyUnicodeObject *)unicode)->defenc = v;
     }
     return v;



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

Comment By: Amaury Forgeot d'Arc (amauryf)
Date: 2007-07-12 02:00

Message:
Logged In: YES 
user_id=389140
Originator: YES

Of course, sourceforge ate the spaces again... sorry.
Here is the patch again:

Index: Objects/unicodeobject.c
===================================================================
--- Objects/unicodeobject.c     (revision 56284)
+++ Objects/unicodeobject.c     (working copy)
@@ -1207,7 +1207,6 @@
                                    PyBytes_Size(b));
     Py_DECREF(b);
     if (!errors) {
-        Py_XINCREF(v);
         ((PyUnicodeObject *)unicode)->defenc = v;
     }
     return v;


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

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

From noreply at sourceforge.net  Thu Jul 12 02:26:32 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 11 Jul 2007 17:26:32 -0700
Subject: [Patches] [ python-Patches-1752332 ] getaddrinfo no longer used in
	httplib
Message-ID: <E1I8mVs-0004t8-TR@sc8-sf-web22.sourceforge.net>

Patches item #1752332, was opened at 2007-07-12 01: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=1752332&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: John J Lee (jjlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: getaddrinfo no longer used in httplib

Initial Comment:
The docs for module socket refer to the source of httplib as an example of the proper usage of socket.getaddrinfo().  httplib no longer uses that function directly, since that code moved into module socket.  This patch updates the reference to point to module socket instead of to httplib.

Not a backport candidate.


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

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

From noreply at sourceforge.net  Thu Jul 12 03:24:23 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 11 Jul 2007 18:24:23 -0700
Subject: [Patches] [ python-Patches-1752229 ] Use the Unicode API in
	dlmodule.c
Message-ID: <E1I8nPr-0002vK-HN@sc8-sf-web22.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Modules
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alexandre Vassalotti (avassalotti)
Assigned to: Nobody/Anonymous (nobody)
Summary: Use the Unicode API in dlmodule.c

Initial Comment:
Fix failing test in py3k-struni.

The patch simply replaces PyString_* calls with PyUnicode_*

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2007-07-11 18:24

Message:
Logged In: YES 
user_id=33168
Originator: NO

Isn't dl supposed to go away?

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

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

From noreply at sourceforge.net  Thu Jul 12 07:34:13 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 11 Jul 2007 22:34:13 -0700
Subject: [Patches] [ python-Patches-1739468 ] Add a -z interpreter flag to
	execute a zip file
Message-ID: <E1I8rJd-00026p-J8@sc8-sf-web24.sourceforge.net>

Patches item #1739468, was opened at 2007-06-19 05:40
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1739468&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: andy-chu (andy-chu)
Assigned to: Nick Coghlan (ncoghlan)
Summary: Add a -z interpreter flag to execute a zip file

Initial Comment:
The motivation for this is that distributing a zip file is a very light and easy way to distribute a python program with multiple packages/modules.  I have done this on Linux, Mac and Windows and it works very nicely -- except that you need a few extra files to bootstrap it: set PYTHONPATH to the zip file and run the main function.

With this small patch, you get rid of the need for extra files.  At the bottom is a demo on Linux.

On Windows, you can do a similar thing by making a file that is both a zip file and a batch file.  The batch file will pass %~f0 (itself) to the -z flag of the Python interpreter.

I ran this by Guido and he seemed to think it was a fine idea.  At Google, we have numerous platform-specific hacks in a program called "autopar" to solve this problem.

I have included the basic patch, but if you guys agree with this, I will add some tests and documentation.  And I think it might be useful to include something in the Tools/ directory to do what update_zip.sh does below (add a __zipmain__ module and a shebang/batch file header to a zip file, to make it executable)?

I think this may also help to fix a bug with eggs:

http://peak.telecommunity.com/DevCenter/setuptools#eggsecutable-scripts

IMPORTANT NOTE: Eggs with an "eggsecutable" header cannot be renamed, or invoked via symlinks. They must be invoked using their original filename, in order to ensure that, once running, pkg_resources will know what project and version is in use. The header script will check this and exit with an error if the .egg file has been renamed or is invoked via a symlink that changes its base name.



andychu testdata$ ls
__zipmain__.py  foo.py  foo.pyc  foo.zip  foo_exe.zip  header.txt  update_zip.sh


# The main program you're going to run in "development mode"

andychu testdata$ ./foo.py foo bar
argv: ['./foo.py', 'foo', 'bar']


# Same program, packaged into a zip file

andychu testdata$ ./foo_exe.zip foo bar
argv: ['-c', 'foo', 'bar']


# Contents of the zip file

andychu testdata$ unzip -l foo_exe.zip
Archive:  foo_exe.zip
warning [foo_exe.zip]:  51 extra bytes at beginning or within zipfile
  (attempting to process anyway)
  Length     Date   Time    Name
 --------    ----   ----    ----
      243  06-18-07 20:01   __zipmain__.py
      301  06-18-07 19:58   foo.py
 --------                   -------
      544                   2 files


# Demo script to build an executable zip file.

andychu testdata$ cat header.txt
#!/usr/local/google/clients/python/trunk/python -z


andychu testdata$ cat update_zip.sh
#!/bin/bash

# Make a regular zip file.
zip foo.zip foo.py __zipmain__.py

# Add a shebang line to it.
cat header.txt foo.zip > foo_exe.zip

# Make it executable.
chmod 750 foo_exe.zip


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

>Comment By: Martin v. L?wis (loewis)
Date: 2007-07-12 07:34

Message:
Logged In: YES 
user_id=21627
Originator: NO

I don't see the need for that on Linux: you can do the same thing already
with a shell script.
In the example below, foo.zip contains foo.py.

martin at mira:~$ cat runzip.sh
#!/bin/sh
export PYTHONPATH=$0
exec python -c 'import foo;foo.main()'
# THE END

martin at mira:~$ cat runzip.sh foo.zip >bar
martin at mira:~$ chmod +x bar.zip
martin at mira:~$ ./bar
hello

So unless that adds a functionality that I'm missing, I'm -1 on this
patch.

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

Comment By: andy-chu (andy-chu)
Date: 2007-07-11 08:25

Message:
Logged In: YES 
user_id=1821575
Originator: YES

Good point, however I decided to set sys.path[0] and sys.argv[0] a little
differently, based on some more testing, as you can see explained in the
new patch I just uploaded.

Those are details; I'll post to python-dev and see what people think of
the general idea.  If it's accepted then we can figure out the details. 
For now I made the function very specific to the -z flag.

I'm not sure I have a use case for invoking a zip file from another python
module.  If we were to put that back in, it might be better to have 2
separate functions anyway, since this one is only 3 lines basically.


File Added: runzip8.diff

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

Comment By: Nick Coghlan (ncoghlan)
Date: 2007-07-08 10:15

Message:
Logged In: YES 
user_id=1038590
Originator: NO

The new patch looks much better - the only thing is that run_zip needs to
do sys.path.pop(0) to correctly remove the zipfile from the front of the
path.

However, I do see your point about whether or not including the current
directory on sys.path is the right thing to do for this case - it may be
better to set <zipfile_name>/__zipmain__.py as argv[0] before invoking
PySys_SetArgv, and then use __zipmain__ as the module to be executed on the
same code path as the -m switch normally uses.

Rather than continuing this discussion here on SF, it may be best to post
your proposal to python-dev. I personally like the idea, but a new idiom
for running Python scripts will need broader support than just me. Getting
input from the py2exe and py2app folks that can be found on python-dev
would also be good. 

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

Comment By: andy-chu (andy-chu)
Date: 2007-07-07 20:33

Message:
Logged In: YES 
user_id=1821575
Originator: YES

Nick, have you had a chance to look this over again?  I mainly care about
the -z flag support.  The makepyz.py script is just a demo, though I think
it is useful as documentation as well.


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

Comment By: Nick Coghlan (ncoghlan)
Date: 2007-06-29 16:40

Message:
Logged In: YES 
user_id=1038590
Originator: NO

I'm going to be off the net for a few days - I'll have a look at the
updated patch when I get back late next week,

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

Comment By: andy-chu (andy-chu)
Date: 2007-06-28 07:17

Message:
Logged In: YES 
user_id=1821575
Originator: YES

Here is a script that documents how to make such files.  I think the
important part is just documenting the format.  Then people can write
whatever tools they need around it.  Many people could get by with this
simple tool, but others might want something more elaborate.

Demo:

andychu testprog$ find
.
./__init__.py
./package1
./package1/__init__.py
./package1/foo.py
./package1/lib.py
./package1/__init__.pyc
./package1/lib.pyc
./package1/foo.pyc

andychu testprog$ find -name "*.py" | xargs ../Tools/scripts/makepyz.py -a
zip,pyz,unix -z foo.zip -p package1 -m foo -y
/usr/local/google/clients/python/trunk/python
Added ./__init__.py to foo.zip
Added ./package1/__init__.py to foo.zip
Added ./package1/foo.py to foo.zip
Added ./package1/lib.py to foo.zip
Added __zipmain__.py to foo.zip
Prepended #!/usr/local/google/clients/python/trunk/python -z to foo.zip.
chmod foo.zip 0700

andychu testprog$ ./foo.zip
lib module here
argv: ['-c']
andychu testprog$ echo $?
3

File Added: makepyz.py

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

Comment By: andy-chu (andy-chu)
Date: 2007-06-27 07:35

Message:
Logged In: YES 
user_id=1821575
Originator: YES

Nick, I've updated the code to use a new runpy.run_zip function, which
calls run_module.  This does make it a bit cleaner.

Let me know what you think.  If the code is good I'll write some tests and
documentation.

Also, I'm not sure if the '-c' is really appropriate in sys.argv, but that
seems to be what the -m flag uses.  It seems like it might make sense to
have sys.argv[0] be the zip file, if it is really a first class
executable.

And I think a script to build one of these files would be appropriate,
which I can add.  You could pass it the main module and main function, and
it would generate a __zipmain__ stub and add it to the zip file.  And it is
a good idea if the file is cross platform, so a .pyz extension would work.

Sorry the delayed response, I was a bit busy at work this week... but I'll
respond sooner this time. : )

Example:

andychu trunk$ testdata/foo_exe.zip foo bar
__name__: __main__
argv: ['-c', 'foo', 'bar']
andychu trunk$ echo $?
3

File Added: runzip7.diff

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

Comment By: andy-chu (andy-chu)
Date: 2007-06-21 02:54

Message:
Logged In: YES 
user_id=1821575
Originator: YES

Nick, you're right, I think it can use run_module and be in the runpy
module.  Let me make those changes and send you another patch.


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

Comment By: Nick Coghlan (ncoghlan)
Date: 2007-06-19 13:21

Message:
Logged In: YES 
user_id=1038590
Originator: NO

I like the general idea, but it should be possible to use runpy.run_module
to get __name__ set correctly (as that is what happens when you execute a
module from a zipfile with -m). Another advantage of using run_module is
that it would allow runzip() to take a second argument (possibly defaulting
to "__zipmain__") which would specify the module to be executed from the
zipfile (the remaining 3 run_module arguments could also be passed in, and
set appropriately from main.c).

Adding the new function as runpy.run_zip() (instead of adding a new
module) would also be good.

For Windows, an alternative to making the zip file both a batch and a zip
file would be to adopt a .pyz extension convention for these files - the
file associations can then be set up to invoke the script appropriately
with python -z (similar to the way that .pyw files are associated with
pythonw instead of the standard python executable). That way the same file
could be executed on both Linux (via an embedded shebang line) and on
Windows (via filename association), as is the case with standard .py Python
scripts.

My final question is whether the change to sys.path should be reverted
once the module execution is complete - my suspicion is that it should, but
I need to look into it a bit more before giving a definite answer (for the
command line flag case, this behaviour obviously doesn't matter - it is
only significant if the Python method is invoked directly in the context of
a larger program).

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

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

From noreply at sourceforge.net  Thu Jul 12 09:08:52 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Jul 2007 00:08:52 -0700
Subject: [Patches] [ python-Patches-1718153 ] PEP 3123 implementation
Message-ID: <E1I8snE-0004CG-7E@sc8-sf-web24.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Martin v. L?wis (loewis)
Assigned to: Nobody/Anonymous (nobody)
Summary: PEP 3123 implementation

Initial Comment:
This patch implements the changes need for PEP 3123, in Py3k. Rather than checking this into the 3k branch, a backport of those bulk of the patch to 2.6 should be made, omitting the actual changes to PyObject_HEAD

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-12 03:08

Message:
Logged In: YES 
user_id=6380
Originator: NO

Hm. How fully backwards compatible is the patch? As part of the Py3k
transition strategy, I've been trying to paint a picture of the transition
from 2.x to 2.6 as super-easy, because we're not changing any existing
functionality, we're just adding Py3k forward compatibility features that
are easily ignoreable. Even if only 5% of 3rd party extension modules were
to need work because of this change, that would already defeat the purpose
IMO.

OTOH I'm all for doing this in 3.0.  If the 2.6 changes are fully
compatible I have no objection in doing it there as well.

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

Comment By: Martin v. L?wis (loewis)
Date: 2007-07-11 17:43

Message:
Logged In: YES 
user_id=21627
Originator: YES

Depends on the precise procedure to follow. I have a patch that works for
2.6 (but it's not included here); should I commit that?

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-11 08:38

Message:
Logged In: YES 
user_id=6380
Originator: NO

Is this ready to be committed?

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

Comment By: Martin v. L?wis (loewis)
Date: 2007-05-23 17:55

Message:
Logged In: YES 
user_id=21627
Originator: YES

I don't think API compatibility between 2.5 and 3.0 should be a
requirement - I expect that there will be much more breakage, making such
compatibility very difficult for other reasons.

Anyway, for everything that can be done with a macro (including
HEAD_INIT), code that wants compatibility with 2.5 and earlier should do

#ifndef MACRO
#define MACRO 2.6-content of macro
#endif

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-23 01:29

Message:
Logged In: YES 
user_id=33168
Originator: NO

I like this patch would like it to be applied to 2.6.  However, I'm
concerned about extension modules maintaining compatibility for 2.5 and
3.0.  What would that look like (ie, an extension module that can compile
with both versions)?  How would the modules need to be changed to support
both versions?  For Py_{Type,Refcnt,Size}, it looks pretty straightforward
to define the macros in 2.x and things should work fine.  But I'm not sure
about the HEAD_INIT macros.

Martin, did you try disabling the -fno-strict-aliasing with this patch to
see if there were any warnings?

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

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

From noreply at sourceforge.net  Thu Jul 12 09:44:43 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Jul 2007 00:44:43 -0700
Subject: [Patches] [ python-Patches-1752229 ] Use the Unicode API in
	dlmodule.c
Message-ID: <E1I8tLv-0002Q3-PJ@sc8-sf-web21.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Modules
Group: Python 3000
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Alexandre Vassalotti (avassalotti)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: Use the Unicode API in dlmodule.c

Initial Comment:
Fix failing test in py3k-struni.

The patch simply replaces PyString_* calls with PyUnicode_*

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-12 03:44

Message:
Logged In: YES 
user_id=6380
Originator: NO

Committed revision 56287.

(Neal: I dunno; but the test works again. :-)

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-07-11 21:24

Message:
Logged In: YES 
user_id=33168
Originator: NO

Isn't dl supposed to go away?

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

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

From noreply at sourceforge.net  Thu Jul 12 09:53:18 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Jul 2007 00:53:18 -0700
Subject: [Patches] [ python-Patches-1752317 ] reference leak in
	_PyUnicode_AsDefaultEncodedString
Message-ID: <E1I8tUE-0003Qq-Sf@sc8-sf-web21.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 3000
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Amaury Forgeot d'Arc (amauryf)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: reference leak in _PyUnicode_AsDefaultEncodedString

Initial Comment:
If I understand correctlty, _PyUnicode_AsDefaultEncodedString creates and caches a utf8 translation of the string. It returns a borrowed reference to this.
But the stored value (in ->defenc) has a refcount of 2, and will never be released when the unicode object is freed.

The effect is obvious in debug build: the total references count used to increase by 1 for each function call.

The patch is easy:

Index: Objects/unicodeobject.c
=======================================================
--- Objects/unicodeobject.c     (revision 56284)
+++ Objects/unicodeobject.c     (working copy)
@@ -1207,7 +1213,6 @@
                                    PyBytes_Size(b));
     Py_DECREF(b);
     if (!errors) {
-        Py_XINCREF(v);
         ((PyUnicodeObject *)unicode)->defenc = v;
     }
     return v;



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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-12 03:53

Message:
Logged In: YES 
user_id=6380
Originator: NO

Good analysis!  Fixed.

Committed revision 56288.


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

Comment By: Amaury Forgeot d'Arc (amauryf)
Date: 2007-07-11 20:00

Message:
Logged In: YES 
user_id=389140
Originator: YES

Of course, sourceforge ate the spaces again... sorry.
Here is the patch again:

Index: Objects/unicodeobject.c
===================================================================
--- Objects/unicodeobject.c     (revision 56284)
+++ Objects/unicodeobject.c     (working copy)
@@ -1207,7 +1207,6 @@
                                    PyBytes_Size(b));
     Py_DECREF(b);
     if (!errors) {
-        Py_XINCREF(v);
         ((PyUnicodeObject *)unicode)->defenc = v;
     }
     return v;


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

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

From noreply at sourceforge.net  Thu Jul 12 09:54:24 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Jul 2007 00:54:24 -0700
Subject: [Patches] [ python-Patches-1617699 ] slice-object support for
	ctypes Pointer/Array
Message-ID: <E1I8tVI-0001bJ-Em@sc8-sf-web23.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Modules
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Thomas Wouters (twouters)
Assigned to: Thomas Heller (theller)
Summary: slice-object support for ctypes Pointer/Array

Initial Comment:
Support for slicing ctypes' Pointer and Array types with slice objects, although only for step=1 case.
(Backported from p3yk-noslice branch.)


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

>Comment By: Thomas Wouters (twouters)
Date: 2007-07-12 09:54

Message:
Logged In: YES 
user_id=34209
Originator: YES

Thomas, do you consider non-step-1 slicing important? I'd really like to
get the noslice branch merged into p3yk soon-ish, and I need to know which
bits I need to commit to the trunk first (to avoid merge conflicts for the
rest of the lifetime of the 2.x codebase.)

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

Comment By: Thomas Wouters (twouters)
Date: 2007-01-15 12:48

Message:
Logged In: YES 
user_id=34209
Originator: YES

The point is that simple slicing will go away, and extended slices (with
sliceobjects) are used in various places, and currently can't be passed on
to ctypes arrays and pointers. That is to say, a Python class defining
__getitem__ but not __getslice__ still supports slice syntax, but it can't
do 'pointer[sliceobj]' -- it would have to do
'pointer[sliceobj.start:sliceobj.end]'. Also, because simple slices will go
away, this code will have to be added to the p3yk branch in any case;
having it in the trunk just makes for easier maintenance.

Oh, and the non-support for steps other than 1 is not a fundamental issue,
I just couldn't bear to write the code for that if you didn't think it
would be useful, as I'd already written the same logic and arithmetic for
array, tupleseq, mmap and I forget what else :P You can consider this code
half-done, if you wish; I'll get to it again soon enough.

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

Comment By: Thomas Heller (theller)
Date: 2007-01-12 21:48

Message:
Logged In: YES 
user_id=11105
Originator: NO

Thomas, a question:  Since steps != 1 are not supported, does this patch
have any value?
IIUC, array[x:y] returns exactly the same as array[x:y:1] for all x and y
values.

Formally, the patch is missing unittests and documentation ;-).

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

Comment By: Thomas Heller (theller)
Date: 2006-12-20 19:45

Message:
Logged In: YES 
user_id=11105
Originator: NO

Unfortunately I'm unable to review or work on this patch *this year*.  I
will definitely take a look in January.  Sorry.

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

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

From noreply at sourceforge.net  Thu Jul 12 09:57:51 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Jul 2007 00:57:51 -0700
Subject: [Patches] [ python-Patches-1681002 ] binary and new-style octal
	literals
Message-ID: <E1I8tYd-0003tN-Ah@sc8-sf-web21.sourceforge.net>

Patches item #1681002, was opened at 2007-03-14 21:55
Message generated for change (Comment added) made by twouters
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681002&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 2.6
>Status: Closed
>Resolution: Out of Date
Priority: 3
Private: No
Submitted By: Thomas Wouters (twouters)
Assigned to: Guido van Rossum (gvanrossum)
Summary: binary and new-style octal literals

Initial Comment:
Incomplete patch that adds '0t777' and '0b101010' style literals. It lacks a NEWS item, documentation and compiler-package changes (although it may not need any.) 2to3 recipe also not included.


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

>Comment By: Thomas Wouters (twouters)
Date: 2007-07-12 09:57

Message:
Logged In: YES 
user_id=34209
Originator: YES

Out of date and fixed already by another patch.


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

Comment By: Collin Winter (collinwinter)
Date: 2007-03-21 23:34

Message:
Logged In: YES 
user_id=1344176
Originator: NO

Georg has worked up a 2to3 fixer that implements the 0777 -> 0o777 and
assorted other numeric literal fix-ups, called fix_numliterals. 2to3 will
support 0b101010 literals just as soon as I type up a commit message.

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

Comment By: Thomas Wouters (twouters)
Date: 2007-03-14 22:06

Message:
Logged In: YES 
user_id=34209
Originator: YES

The compiler package does indeed not need any changes, as it still uses
Python's own tokenizer. And in case there's any doubt, I'm still -1 on this
change :) (But unfortunately the easy implementation of it didn't exactly
give me new ammo.)

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

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

From noreply at sourceforge.net  Thu Jul 12 09:59:25 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Jul 2007 00:59:25 -0700
Subject: [Patches] [ python-Patches-1752173 ] Use the bytes type in asynchat
Message-ID: <E1I8ta9-00047W-Tj@sc8-sf-web21.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 3000
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Alexandre Vassalotti (avassalotti)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: Use the bytes type in asynchat

Initial Comment:
The unit test in py3k-struni was failing because asynchat.py was trying concatenate str and bytes strings. My solution is to make asynchat use and return only bytes strings.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-12 03:59

Message:
Logged In: YES 
user_id=6380
Originator: NO

Committed revision 56290.

Thanks!

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

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

From noreply at sourceforge.net  Thu Jul 12 10:04:33 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Jul 2007 01:04:33 -0700
Subject: [Patches] [ python-Patches-1751958 ] struni: gettext fixes
Message-ID: <E1I8tf7-0004ha-DJ@sc8-sf-web21.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Modules
Group: Python 3000
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Christian Heimes (tiran)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: struni: gettext fixes

Initial Comment:
Fixes for the gettext module. I tested the fixes with the Zope3 zope.app.locales packages. The mo files are loaded and parsed w/o any problem. The translation with gettext.gettext is working as expected.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-12 04:04

Message:
Logged In: YES 
user_id=6380
Originator: NO

Committed revision 56292.


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

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

From noreply at sourceforge.net  Thu Jul 12 10:05:59 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Jul 2007 01:05:59 -0700
Subject: [Patches] [ python-Patches-1750931 ] make build_opener raise
	exception when not passed a handler
Message-ID: <E1I8tgV-00029z-HX@sc8-sf-web24.sourceforge.net>

Patches item #1750931, was opened at 2007-07-10 04:14
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1750931&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 2.6
>Status: Closed
Resolution: Rejected
Priority: 5
Private: No
Submitted By: Robert Renaud (silentstrike)
Assigned to: Nobody/Anonymous (nobody)
Summary: make build_opener raise exception when not passed a handler

Initial Comment:
A bug bit me where I had code that looked like

urllib2.build_opener(func_returning_cookie_jar())

instead of

urllib2.build_opener(HTTPCookieProcessor(func_returning_cookie_jar())

the subsequent http request went through just fine, except it didn't send the cookie.  Nothing complained, except me, now.

Throwing the exception deeper in the code made the unittest fail, so I suspect the "silently ignore handlers which don't actually do any handling" behavior might be by design, but it seems terrible to me.

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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-07-12 08:05

Message:
Logged In: YES 
user_id=849994
Originator: NO

Committed #1752270.

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

Comment By: Robert Renaud (silentstrike)
Date: 2007-07-11 23:52

Message:
Logged In: YES 
user_id=235882
Originator: YES

Your patch looks good to me, I have no objection so long as this error
will be caught instead of failing without complaint.  I am rejecting my
patch in favor of yours.  Thanks for looking into this.

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

Comment By: John J Lee (jjlee)
Date: 2007-07-11 23:16

Message:
Logged In: YES 
user_id=261020
Originator: NO

Patch #1752270 seems more idiomatic (TypeError, not ValueError) and mildly
less intrusive (it does not change the return value of
urllib2.OpenerDirector.add_handler()).  Also, your patch adds a backwards
incompatibility which the new one does not: Currently a correct call to
urllib2.build_opener() may return successfully without adding all of its
handler arguments to the returned urllib2.OpenerDirector, since a
urllib2.BaseHandler instance may have no appropriate methods (no
.http_open(), etc. etc.).  Your patch causes build_opener() (but not
.add_handler()) to raise ValueError in that case.  One could argue that it
should raise an exception, but there is still scope for breakage, e.g.
since these attributes may be added at runtime, and the number of added
attributes may happen to be zero (and in fact, urllib2.ProxyHandler falls
into this category).

I think the docs do not need to be updated if my revised patch is applied,
since they already state that urllib2.OpenerDirector.add_handler() accepts
only urllib2.BaseHandler instances (and typically the possibility of a
TypeError being raised is not explicitly documented in stdlib docs).


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

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

From noreply at sourceforge.net  Thu Jul 12 10:06:11 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Jul 2007 01:06:11 -0700
Subject: [Patches] [ python-Patches-1752270 ] urllib2 1750931 alternative
	patch
Message-ID: <E1I8tgh-0002G7-Em@sc8-sf-web24.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: John J Lee (jjlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 1750931 alternative patch

Initial Comment:
This is an alternative patch to http://python.org/sf/1750931 .  Please continue discussion there.


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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-07-12 08:06

Message:
Logged In: YES 
user_id=849994
Originator: NO

Committed in rev. 56293, 56294 (2.5).

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

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

From noreply at sourceforge.net  Thu Jul 12 10:11:42 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Jul 2007 01:11:42 -0700
Subject: [Patches] [ python-Patches-1739696 ] Patch inspect.py for
	IronPython / Jython Compatibility
Message-ID: <E1I8tm2-0002pv-Dj@sc8-sf-web24.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Mike Foord (mjfoord)
Assigned to: Collin Winter (collinwinter)
Summary: Patch inspect.py for IronPython / Jython Compatibility

Initial Comment:
Attached is a context patch against SVN head for the inspect module.

It moves getting a reference to 'code.co_code' into the body of the loop responsible for inspecting anonymous (tuple) arguments.

In IronPython, accessing 'co_code' raises a NotImplementedError - meaning that inspect.get_argspec is broken.

This patch means that *except* for functions with anonymous tuple arguments, it will work again - whilst maintaining full compatibility with the previous behaviour.

(A soimilar patch against Python 2.4.4 is in the IronPython Community Edition by Seo Sanghyeon.)

Jython has a similar patch to overcome the same issue by the way. See http://jython.svn.sourceforge.net/viewvc/jython?view=rev&revision=3200

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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-07-12 08:11

Message:
Logged In: YES 
user_id=849994
Originator: NO

Committed as rev. 56296, 56297 (2.5).

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

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

From noreply at sourceforge.net  Thu Jul 12 10:13:10 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Jul 2007 01:13:10 -0700
Subject: [Patches] [ python-Patches-1735030 ] Fix selectmodule.c compilation
	on GNU/Hurd
Message-ID: <E1I8tnS-00033n-6v@sc8-sf-web24.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Modules
Group: None
>Status: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: Michael Banck (mbanck)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix selectmodule.c compilation on GNU/Hurd

Initial Comment:
This patch (by Wouter van Heyst) fixes compilation of python2.5 on the Hurd (and other systems?)

It fixes the following build error:

gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/build/buildd/python2.5-2.5/./Include -I../Include -I. -I/build/buildd/python2.5-2.5/Include -I/build/buildd/python2.5-2.5/build-static -c /build/buildd/python2.5-2.5/Modules/selectmodule.c -o build/temp.gnu-0.3-i686-AT386-2.5/build/buildd/python2.5-2.5/Modules/selectmodule.o
/build/buildd/python2.5-2.5/Modules/selectmodule.c:676: error: 'select_poll' undeclared here (not in a function)
/build/buildd/python2.5-2.5/Modules/selectmodule.c:676: error: 'poll_doc' undeclared here (not in a function)
/build/buildd/python2.5-2.5/Modules/selectmodule.c: In function 'initselect':
/build/buildd/python2.5-2.5/Modules/selectmodule.c:709: error: 'poll_Type' undeclared (first use in this function)
/build/buildd/python2.5-2.5/Modules/selectmodule.c:709: error: (Each undeclared identifier is reported only once
/build/buildd/python2.5-2.5/Modules/selectmodule.c:709: error: for each function it appears in.)
/build/buildd/python2.5-2.5/Modules/selectmodule.c:709: error: request for member 'ob_type' in something not a structure or union
/build/buildd/python2.5-2.5/Modules/selectmodule.c:709: warning: statement with no effect

We hope this does not break other platforms, does this look OK?

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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-07-12 08:13

Message:
Logged In: YES 
user_id=849994
Originator: NO

Closing for now. If it's really Python's fault, you can reopen this.

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

Comment By: Michael Banck (mbanck)
Date: 2007-06-28 16:09

Message:
Logged In: YES 
user_id=196016
Originator: YES

Hrm, upon further analysis, it looks likely that poll() really is not
conforming to POSIX on GNU/Hurd and should get fixed, rather than
HAVE_BROKEN_POLL code be changed.

I have submitted this upstream to the Hurd developers, the patch should
not be applied in the meantime (and might be obsolete).

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

Comment By: Michael Banck (mbanck)
Date: 2007-06-12 12:55

Message:
Logged In: YES 
user_id=196016
Originator: YES

Yes, python2.5 builds fine otherwise (at least the Debian package, I am
not sure whether we applied local changes earlier).  This HAVE_BROKEN_POLL
issue was the only regression from python2.4 as far as the Debian GNU/Hurd
port was concerned.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-06-12 02:54

Message:
Logged In: YES 
user_id=33168
Originator: NO

Is this only change required for Hurd?  I'm not sure, but HAVE_BROKEN_POLL
might have a specific meaning on OS X.  So there might be a problem with
this patch.  I'd need to look at the whole file to verify.  I'll try to
remember to do that later.

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

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

From noreply at sourceforge.net  Thu Jul 12 10:15:23 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Jul 2007 01:15:23 -0700
Subject: [Patches] [ python-Patches-1752195 ] struni: for for poll, pep263,
	bigmem and a bit pickletool
Message-ID: <E1I8tpb-0003Hg-Ff@sc8-sf-web24.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Tests
Group: Python 3000
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Christian Heimes (tiran)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: struni: for for poll, pep263, bigmem and a bit pickletool 

Initial Comment:
The patch fixes three unit test modules and some unit tests of pickletools.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-12 04:15

Message:
Logged In: YES 
user_id=6380
Originator: NO

I disagree with the pickletools fix; something should be changed not to
return 8-bit strings.

Your fix for test_pep263.py was not included due to the file being marked
as binary.  But it was already committed previously by Thomas Heller so no
need to follow up.

The poll fix was already applied.

I tweaked the bigmem fix slightly and submitted it: Committed revision
56295.



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

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

From noreply at sourceforge.net  Thu Jul 12 10:16:15 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Jul 2007 01:16:15 -0700
Subject: [Patches] [ python-Patches-1718153 ] PEP 3123 implementation
Message-ID: <E1I8tqR-0003YK-NQ@sc8-sf-web22.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Martin v. L?wis (loewis)
Assigned to: Nobody/Anonymous (nobody)
Summary: PEP 3123 implementation

Initial Comment:
This patch implements the changes need for PEP 3123, in Py3k. Rather than checking this into the 3k branch, a backport of those bulk of the patch to 2.6 should be made, omitting the actual changes to PyObject_HEAD

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

>Comment By: Martin v. L?wis (loewis)
Date: 2007-07-12 10:16

Message:
Logged In: YES 
user_id=21627
Originator: YES

The 2.6 version of the patch is fully backwards-compatible. It provides a
few new macros, and reformulates a lot of code to use these macros. The 3.0
version of the same macros looks different; for 2.6, these macros don't
have to be used - but I propose to use them in the core anyhow to avoid the
two code bases diverging.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-12 09:08

Message:
Logged In: YES 
user_id=6380
Originator: NO

Hm. How fully backwards compatible is the patch? As part of the Py3k
transition strategy, I've been trying to paint a picture of the transition
from 2.x to 2.6 as super-easy, because we're not changing any existing
functionality, we're just adding Py3k forward compatibility features that
are easily ignoreable. Even if only 5% of 3rd party extension modules were
to need work because of this change, that would already defeat the purpose
IMO.

OTOH I'm all for doing this in 3.0.  If the 2.6 changes are fully
compatible I have no objection in doing it there as well.

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

Comment By: Martin v. L?wis (loewis)
Date: 2007-07-11 23:43

Message:
Logged In: YES 
user_id=21627
Originator: YES

Depends on the precise procedure to follow. I have a patch that works for
2.6 (but it's not included here); should I commit that?

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-11 14:38

Message:
Logged In: YES 
user_id=6380
Originator: NO

Is this ready to be committed?

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

Comment By: Martin v. L?wis (loewis)
Date: 2007-05-23 23:55

Message:
Logged In: YES 
user_id=21627
Originator: YES

I don't think API compatibility between 2.5 and 3.0 should be a
requirement - I expect that there will be much more breakage, making such
compatibility very difficult for other reasons.

Anyway, for everything that can be done with a macro (including
HEAD_INIT), code that wants compatibility with 2.5 and earlier should do

#ifndef MACRO
#define MACRO 2.6-content of macro
#endif

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-23 07:29

Message:
Logged In: YES 
user_id=33168
Originator: NO

I like this patch would like it to be applied to 2.6.  However, I'm
concerned about extension modules maintaining compatibility for 2.5 and
3.0.  What would that look like (ie, an extension module that can compile
with both versions)?  How would the modules need to be changed to support
both versions?  For Py_{Type,Refcnt,Size}, it looks pretty straightforward
to define the macros in 2.x and things should work fine.  But I'm not sure
about the HEAD_INIT macros.

Martin, did you try disabling the -fno-strict-aliasing with this patch to
see if there were any warnings?

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

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

From noreply at sourceforge.net  Thu Jul 12 10:18:03 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Jul 2007 01:18:03 -0700
Subject: [Patches] [ python-Patches-1726195 ] Patch to vs 2005 build
Message-ID: <E1I8tsB-0003az-KC@sc8-sf-web24.sourceforge.net>

Patches item #1726195, was opened at 2007-05-26 20:09
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1726195&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 2.5
>Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Joseph Armbruster (joearmbruster)
Assigned to: Kristj?n Valur (krisvale)
Summary: Patch to vs 2005 build

Initial Comment:
As per the removal of the rgbimgmodule due to deprecation in the trunk:

http://svn.python.org/projects/python/trunk

---Begin SVN log---
r55458 | brett.cannon | 2007-05-20 03:09:50 -0400 (Sun, 20 May 2007) | 2 lines

Remove the rgbimg module.  It has been deprecated since Python 2.5.
---End SVN log---


The PCbuild8 solution needs to be corrected.  A patch is attached.

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

Comment By: Kristj?n Valur (krisvale)
Date: 2007-05-29 10:39

Message:
Logged In: YES 
user_id=1262199
Originator: NO

Fixed in trunk.

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

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

From noreply at sourceforge.net  Thu Jul 12 10:22:33 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Jul 2007 01:22:33 -0700
Subject: [Patches] [ python-Patches-1665292 ] Datetime enhancements
Message-ID: <E1I8twX-00045Y-8m@sc8-sf-web24.sourceforge.net>

Patches item #1665292, was opened at 2007-02-21 14:55
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1665292&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 2.6
>Status: Closed
>Resolution: Rejected
Priority: 5
Private: No
Submitted By: Christian Heimes (tiran)
Assigned to: Nobody/Anonymous (nobody)
Summary: Datetime enhancements

Initial Comment:
I'm proposing some small enhancements to the datetime module:

Add a totimestamp() method to datetime.datetime that returns the seconds since 1/1/1970 00:00:00. The datetime class has already a fromtimestamp() factory but is missing a totimestamp() method.

Add a __int__() and __float__() method to datetime.timedelta which return the seconds (seconds + 86400 * days) as int and seconds + miliseconds as float. It would save some typing if somebody needs an integer representation of a timedelta object :]

The datetime module is implemented in C. I've never written a Python C extension so I can't help with a patch.

Thx

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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-07-12 08:22

Message:
Logged In: YES 
user_id=849994
Originator: NO

Agreed. (A separate patch can be submitted for totimestamp().)

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

Comment By: Bj?rn Lindqvist (sonderblade)
Date: 2007-06-06 16:52

Message:
Logged In: YES 
user_id=51702
Originator: NO

Seems like it is safe to close this patch. If you need a timedelta in
seconds it isn't that much work to write td.days*86400+td.seconds to
convert it to an int. Converting it to a float doesn't seem useful enough.

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

Comment By: Jason Orendorff (jorend)
Date: 2007-04-20 22:19

Message:
Logged In: YES 
user_id=18139
Originator: NO

tiran, having timedelta objects comparable with numbers is going a bit too
far.  You end up with:

timedelta(0, 1) == 1   but   hash(timedelta(0, 1)) != hash(1)

This breaks dictionaries.


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

Comment By: Christian Heimes (tiran)
Date: 2007-03-23 02:38

Message:
Logged In: YES 
user_id=560817
Originator: YES

Here is a new patch. I've updated the documentation and enhanced the
compare function to compare with ints, longs and floats. This part of the
patch should be complete. I'm going to submit a different patch for the
other features later. Shall I start a new tracker entry?
File Added: timedelta_intfloat.diff

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

Comment By: Johann C. Rocholl (jcrocholl)
Date: 2007-03-09 16:33

Message:
Logged In: YES 
user_id=656137
Originator: NO

The patch confuses microseconds with milliseconds.
The divisor in delta_float should be 1000000.0, not 1000.0.
The result of the last test should be 86401.000001, not 86401.001.

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

Comment By: Christian Heimes (tiran)
Date: 2007-02-21 16:16

Message:
Logged In: YES 
user_id=560817
Originator: YES

File Added: timedelta.patch

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

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

From noreply at sourceforge.net  Thu Jul 12 10:26:59 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Jul 2007 01:26:59 -0700
Subject: [Patches] [ python-Patches-1718153 ] PEP 3123 implementation
Message-ID: <E1I8u0p-0004Xi-Rb@sc8-sf-web24.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 3000
Status: Open
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Martin v. L?wis (loewis)
>Assigned to: Martin v. L?wis (loewis)
Summary: PEP 3123 implementation

Initial Comment:
This patch implements the changes need for PEP 3123, in Py3k. Rather than checking this into the 3k branch, a backport of those bulk of the patch to 2.6 should be made, omitting the actual changes to PyObject_HEAD

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-12 04:26

Message:
Logged In: YES 
user_id=6380
Originator: NO

OK, sounds like this is fully compatible with 2.5.  So we will have two
compatibility ranges: [2.5, 2.6] and [2.6, 3.0] (but these use different
code variants).

To submit it, I propose the following procedure:

1. merge trunk -> p3yk (this should be easy as we've done this regularly
and recently)

2. merge p3yk -> py3k-struni (ditto)

3. submit this patch to the trunk

4. merge trunk -> p3yk (I fear this will require lots of conflict
resolutions)

5. merge p3yk -> py3k-struni (I expect some but not many conflicts)

I hope you can do all these; you know most about the code so you're most
likely to be able to pull off #4 successfully.

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

Comment By: Martin v. L?wis (loewis)
Date: 2007-07-12 04:16

Message:
Logged In: YES 
user_id=21627
Originator: YES

The 2.6 version of the patch is fully backwards-compatible. It provides a
few new macros, and reformulates a lot of code to use these macros. The 3.0
version of the same macros looks different; for 2.6, these macros don't
have to be used - but I propose to use them in the core anyhow to avoid the
two code bases diverging.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-12 03:08

Message:
Logged In: YES 
user_id=6380
Originator: NO

Hm. How fully backwards compatible is the patch? As part of the Py3k
transition strategy, I've been trying to paint a picture of the transition
from 2.x to 2.6 as super-easy, because we're not changing any existing
functionality, we're just adding Py3k forward compatibility features that
are easily ignoreable. Even if only 5% of 3rd party extension modules were
to need work because of this change, that would already defeat the purpose
IMO.

OTOH I'm all for doing this in 3.0.  If the 2.6 changes are fully
compatible I have no objection in doing it there as well.

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

Comment By: Martin v. L?wis (loewis)
Date: 2007-07-11 17:43

Message:
Logged In: YES 
user_id=21627
Originator: YES

Depends on the precise procedure to follow. I have a patch that works for
2.6 (but it's not included here); should I commit that?

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-11 08:38

Message:
Logged In: YES 
user_id=6380
Originator: NO

Is this ready to be committed?

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

Comment By: Martin v. L?wis (loewis)
Date: 2007-05-23 17:55

Message:
Logged In: YES 
user_id=21627
Originator: YES

I don't think API compatibility between 2.5 and 3.0 should be a
requirement - I expect that there will be much more breakage, making such
compatibility very difficult for other reasons.

Anyway, for everything that can be done with a macro (including
HEAD_INIT), code that wants compatibility with 2.5 and earlier should do

#ifndef MACRO
#define MACRO 2.6-content of macro
#endif

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-23 01:29

Message:
Logged In: YES 
user_id=33168
Originator: NO

I like this patch would like it to be applied to 2.6.  However, I'm
concerned about extension modules maintaining compatibility for 2.5 and
3.0.  What would that look like (ie, an extension module that can compile
with both versions)?  How would the modules need to be changed to support
both versions?  For Py_{Type,Refcnt,Size}, it looks pretty straightforward
to define the macros in 2.x and things should work fine.  But I'm not sure
about the HEAD_INIT macros.

Martin, did you try disabling the -fno-strict-aliasing with this patch to
see if there were any warnings?

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

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

From noreply at sourceforge.net  Thu Jul 12 10:39:07 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Jul 2007 01:39:07 -0700
Subject: [Patches] [ python-Patches-1673759 ] '%G' string formatting doesn't
	catch same errors as '%g'
Message-ID: <E1I8uCZ-0006iM-A5@sc8-sf-web23.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 2.5
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Eric V. Smith (ericvsmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: '%G' string formatting doesn't catch same errors as '%g'

Initial Comment:
See http://python.org/sf/1673757



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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-07-12 08:39

Message:
Logged In: YES 
user_id=849994
Originator: NO

Committed in rev. 56298, 56299 (2.5).

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

Comment By: Bj?rn Lindqvist (sonderblade)
Date: 2007-06-04 23:11

Message:
Logged In: YES 
user_id=51702
Originator: NO

Shouldn't this be committed now?

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-03-18 03:57

Message:
Logged In: YES 
user_id=6380
Originator: NO

Changing the category to 2.5; since the bug appears in 2.5 and 2.6, this
should be applied to 2.5 and to the trunk (i.e. 2.6) and then it will
automatically be merged into 3.0 when the next merge is done.

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

Comment By: Paul Hankin (paulhankin)
Date: 2007-03-10 21:50

Message:
Logged In: YES 
user_id=1740099
Originator: NO

lgtm

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

Comment By: Eric V. Smith (ericvsmith)
Date: 2007-03-10 18:58

Message:
Logged In: YES 
user_id=411198
Originator: YES

Improved summary.

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

Comment By: Eric V. Smith (ericvsmith)
Date: 2007-03-10 18:57

Message:
Logged In: YES 
user_id=411198
Originator: YES

Thanks for the catch on the line length.  I've updated the patch and
attached it.

File Added: 1673757-1.diff

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

Comment By: Paul Hankin (paulhankin)
Date: 2007-03-10 18:01

Message:
Logged In: YES 
user_id=1740099
Originator: NO

Your change in Objects/stringobject.c and Objects/unicodeobject.c goes
over the 79 character line limit.

Otherwise looks ok - compiles, runs, tests look correct and pass.

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

Comment By: Eric V. Smith (ericvsmith)
Date: 2007-03-06 11:10

Message:
Logged In: YES 
user_id=411198
Originator: YES

Updated diff file attached, with correct filenames and with updated tests.
File Added: 1673757.diff

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

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

From noreply at sourceforge.net  Thu Jul 12 11:06:51 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Jul 2007 02:06:51 -0700
Subject: [Patches] [ python-Patches-1731659 ] Improve doc for time.strptime
Message-ID: <E1I8udP-0002K4-Ko@sc8-sf-web23.sourceforge.net>

Patches item #1731659, was opened at 2007-06-05 20:14
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1731659&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Bj?rn Lindqvist (sonderblade)
Assigned to: Nobody/Anonymous (nobody)
Summary: Improve doc for time.strptime

Initial Comment:
Here is a patch that adds a small example to time.strptime (and adds a paragraph break). I found the function hard to understand, an example would have helped.

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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-07-12 09:06

Message:
Logged In: YES 
user_id=849994
Originator: NO

Committed in rev. 56302, 56303 (2.5).

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

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

From noreply at sourceforge.net  Thu Jul 12 11:24:22 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Jul 2007 02:24:22 -0700
Subject: [Patches] [ python-Patches-1731169 ] Expect skips by platform
Message-ID: <E1I8uuM-0004KZ-A7@sc8-sf-web23.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Tests
Group: Python 2.6
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Matt Kraai (kraai)
Assigned to: Nobody/Anonymous (nobody)
Summary: Expect skips by platform

Initial Comment:
Some tests are expected to be skipped on all but one or two platforms by being included in the lists of tests to be skipped for all but those one or two platforms.

This patch removes such tests from those lists and expects to skip them if the platform isn't one of the few where they aren't skipped.

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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-07-12 09:24

Message:
Logged In: YES 
user_id=849994
Originator: NO

Extended and committed in rev. 56304.

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

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

From noreply at sourceforge.net  Thu Jul 12 11:51:03 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Jul 2007 02:51:03 -0700
Subject: [Patches] [ python-Patches-1667546 ] Time zone-capable variant of
	time.localtime
Message-ID: <E1I8vKB-0001tN-1X@sc8-sf-web22.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Paul Boddie (pboddie)
Assigned to: Georg Brandl (gbrandl)
Summary: Time zone-capable variant of time.localtime

Initial Comment:
Patch related to #1493676: "time.strftime() %z error"

This provides a localtime_tz function whose return value is the usual localtime time tuple with an additional field reflecting the underlying tm_gmtoff data. Various internal function signatures are modified to support the flow of time zone information, with the gettmarg most noticably changed (probably quite inelegantly - I don't do Python core development).

This patch is against the Python 2.4.4 release sources.

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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-07-12 09:51

Message:
Logged In: YES 
user_id=849994
Originator: NO

I still have a failing test with the latest patch:

======================================================================
FAIL: test_mktimetz (test.test_time.TimeTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/gbr/devel/python/Lib/test/test_time.py", line 272, in
test_mktimetz
    self.assert_(time.mktimetz(lt) == time.mktimetz(gt))
AssertionError

======================================================================
FAIL: test_timegm (test.test_time.TimeTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/gbr/devel/python/Lib/test/test_time.py", line 253, in
test_timegm
    self.assert_(0 <= dt < 1)
AssertionError

----------------------------------------------------------------------
Ran 17 tests in 1.249s

FAILED (failures=2)
test test_time failed -- errors occurred; run in verbose mode for details
1 test failed:
    test_time


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

Comment By: Paul Boddie (pboddie)
Date: 2007-03-23 00:21

Message:
Logged In: YES 
user_id=226443
Originator: YES

I've enhanced your version of the patch to work with the following
defines:

#define HAVE_TZNAME 1
#undef HAVE_TM_ZONE
#undef HAVE_STRUCT_TM_TM_ZONE
#undef HAVE_ALTZONE

It now uses struct_time in such an environment to provide the extra offset
information used in the unixtime function rather than accessing tm_gmtoff.
I suppose one could do that for all cases, in fact, since this is done
independently of any mktime invocation.

The above defines probably represent the next most "sane" of environments
after those which have tm_gmtoff. If one starts to remove other things,
other more established tests seem to fail, too.
File Added: time-1-improved.diff

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

Comment By: Georg Brandl (gbrandl)
Date: 2007-03-21 10:25

Message:
Logged In: YES 
user_id=849994
Originator: NO

I'm attaching a patch with some corrections of mine. It looks very good
now.

However, your tests fail if HAVE_STRUCT_TM_TM_ZONE is not defined. Can
that be repaired? If not, the tests must be skipped in this case.
File Added: time-1.diff

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

Comment By: Paul Boddie (pboddie)
Date: 2007-03-20 00:20

Message:
Logged In: YES 
user_id=226443
Originator: YES

File Added: tm_gmtoff_zone_timegm_mktimetz_26.diff

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

Comment By: Paul Boddie (pboddie)
Date: 2007-03-20 00:19

Message:
Logged In: YES 
user_id=226443
Originator: YES

Yet another round. Fixed timegm, hopefully. Added mktimetz which uses time
zone information to convert local and UMT times to UNIX times. Added tests
and updated the docs.

The usual caveats apply: I'm new to all this, so some things may need
sanity checking.
File Added: tm_gmtoff_zone_timegm_mktimetz.diff

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

Comment By: Paul Boddie (pboddie)
Date: 2007-03-14 22:43

Message:
Logged In: YES 
user_id=226443
Originator: YES

Looking at this a bit more, it seems like timegm (which is a pretty
desirable function to have) really is as simple as the calendar.timegm
function, as far as I can tell: it just throws time zone information away.
So the timegm implementation in the patches so far is actually wrong (and
broken in the way it attempts to use tm_gmtoff, anyway).

However, it might be nice to have a function which actually interprets
times properly in order to produce a UNIX time. In other words, something
which returns zero for both time.localtime(0) and time.gmtime(0), along
with other times which happen to refer to the epoch but in other time
zones.

I'll upload a fixed patch in the next day or so, hopefully. Sorry for the
noise!

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

Comment By: Georg Brandl (gbrandl)
Date: 2007-03-12 14:13

Message:
Logged In: YES 
user_id=849994
Originator: NO

The patch looks good so far -- but I'd be comfortable with a few more
tests, for example
for strptime and strftime.

Also, the documentation must be updated for every user-visible change (the
addition
of timegm(), the additional timetuple fields, the now-working (?) %z and
%Z in str[fp]time
and behavior changes).

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

Comment By: Paul Boddie (pboddie)
Date: 2007-03-11 21:02

Message:
Logged In: YES 
user_id=226443
Originator: YES

SourceForge "replay" added new attachment - now deleted.

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

Comment By: Paul Boddie (pboddie)
Date: 2007-03-11 20:15

Message:
Logged In: YES 
user_id=226443
Originator: YES

File Added: tm_gmtoff_zone_timegm_26.diff

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

Comment By: Paul Boddie (pboddie)
Date: 2007-03-11 17:00

Message:
Logged In: YES 
user_id=226443
Originator: YES

File Added: tm_gmtoff_zone_timegm_26.diff

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

Comment By: Paul Boddie (pboddie)
Date: 2007-03-11 17:00

Message:
Logged In: YES 
user_id=226443
Originator: YES

New patches against 2.4.4 and the trunk, providing tm_gmtoff, tm_zone,
strptime enhancements, a timegm function, plus tests. Where a platform
supports the timezone and altzone module attributes but not tm_gmtoff and
tm_zone struct tm fields, the code attempts to populate the struct_time
fields appropriately, setting None values only if no timezone information
exists whatsoever. Limitations include the inability to parse/obtain
timezone information beyond that provided by system calls, which is an
existing limitation that affects the strptime implementation amongst other
things.

Again, testing for "deficient" platforms with limited struct tm
definitions has been limited.
File Added: tm_gmtoff_zone_timegm.diff

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

Comment By: Paul Boddie (pboddie)
Date: 2007-03-10 22:59

Message:
Logged In: YES 
user_id=226443
Originator: YES

After some thought, perhaps the population of timezone fields is more
difficult than described below. Will need to look at other parts of the
module code to see what the complications are. What a headache!

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

Comment By: Paul Boddie (pboddie)
Date: 2007-03-08 23:57

Message:
Logged In: YES 
user_id=226443
Originator: YES

File Added: tm_gmtoff_zone_26.diff

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

Comment By: Paul Boddie (pboddie)
Date: 2007-03-08 23:57

Message:
Logged In: YES 
user_id=226443
Originator: YES

Attached are two patches (for 2.4.4 and against the trunk). Apart from the
addition of tm_zone, there's one big change: if no timezone fields/members
exist on struct tm, the code attempts to read that data from the module's
timezone and tzname attributes in order to populate tm_gmtoff and tm_zone;
if that fails then both tm_gmtoff and tm_zone are set to None.

The logic for all this is tested in test_time.py, but it really needs
checking for suitability and testing on something like HP-UX. Details for
the logic here:

http://devrsrc1.external.hp.com/STKT/impacts/i117.html
File Added: tm_gmtoff_zone.diff

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-03-08 00:52

Message:
Logged In: YES 
user_id=6380
Originator: NO

No immediate time for review, but this sounds encouraging.  Would you mind
adding tm_zone (a string) as well?  And how about working relative to the
2.6 trunk (since that's the earliest version where this new feature can be
introduced)?

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

Comment By: Paul Boddie (pboddie)
Date: 2007-03-08 00:28

Message:
Logged In: YES 
user_id=226443
Originator: YES

One learns new things about time and stat tuples every day! Made a much
cleaner patch which provides an extra named attribute (tm_gmtoff) whilst
preserving the 9-tuple layout. Where no time zone support exists, tm_gmtoff
is None; otherwise it's the GMT/UTC offset.

I had weird test issues with range(7) giving "TypeError: an integer is
required" in the code employed (deep down) in test_strptime at some point
during development, probably due to memory issues, so it might be worth
checking that I've dealt properly with such things.
File Added: tm_gmtoff.diff

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-03-02 15:52

Message:
Logged In: YES 
user_id=6380
Originator: NO

Without even looking at the patch, IMO it would be much better to add
tm_gmtoff and tm_zone (and any other fields) to the record returned by
localtime(), but in such a way that when accessed as a tuple it still has
only 9 fields.  There is infrastructure for doing so somewhere for the stat
structure that I'm sure could be borrowed or generalized (if it isn't
already general).  That's much better than adding a new function.

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

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

From noreply at sourceforge.net  Thu Jul 12 11:59:32 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Jul 2007 02:59:32 -0700
Subject: [Patches] [ python-Patches-1675424 ] Zipfile tweaks and test
	coverage improvement
Message-ID: <E1I8vSO-00021l-BW@sc8-sf-web21.sourceforge.net>

Patches item #1675424, was opened at 2007-03-07 03:14
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1675424&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Alan McIntyre (alanmcintyre)
Assigned to: Nobody/Anonymous (nobody)
Summary: Zipfile tweaks and test coverage improvement

Initial Comment:
This patch adds 12 tests for zipfile behavior that didn't appear to be covered by existing tests:

  - appending to an existing zipfile
  - appending to an existing file that is not a zipfile
  - check that calling ZipFile.write without arcname specified produces the expected result
  - check that files within a Zip archive can have different compression options
  - check that trying to call write() on a readonly ZipFile object raises a RuntimeError
  - check that PyZipFile.writepy won't accept a file that doesn't have a .py extension
  - check that bad modes passed to ZipFile constructor are caught
  - check that bad modes passed to ZipFile.open are caught
  - check that calling read(0) on a ZipExtFile object returns an empty string and doesn't advance file pointer
  - check that attempting to call open() for an item that doesn't exist in the archive raises a RuntimeError
  - check that bad compression methods passed to ZipFile.open are caught
  - check that a filename containing a null byte is properly terminated

These other miscellaneous changes were made to test_zipfile.py:
  - FIXEDTEST_SIZE was changed to 1000 (I mistakenly left it at 10 instead of the original test size of 1000 when I last posted patch 1121142)
  - An existing test that checks for a RuntimeError when calling testzip on a closed ZipFile also now checks for the same exception on calls to read, open, write, and writestr.
  - In TestsWithSourceFile, the line_gen attribute was changed from a generator to a list because some of the tests iterate over lines in the test data.

The following changes were made to zipfile.ZipFile:
- A check was added to ZipFile constructor to check for bogus modes (and a couple of statements before the previously existing argument validation were moved below said validation)
- ZipFile.getinfo now raises a RuntimeError when attempting to retrieve information for a file not in the archive (this seems more helpful than getting a cryptic KeyError)
- checks were added to ZipFile.write and writestr to raise a RuntimeError when attempting to write to a closed ZipFile (note that this probably makes other checks further down in the code for these methods redundant)

There are still some portions of zipfile.py that aren't covered, but if somebody commits this patch before I get around to writing tests for them I won't complain about having to submit a separate patch for them. ;-)

If anybody has any thoughts on whether or not things like "calling ZipFile.getinfo for an item not in the archive raises a RuntimeError" should be in the docs, please let me know.  I can add such documentation changes if necessary.

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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-07-12 09:59

Message:
Logged In: YES 
user_id=849994
Originator: NO

Committed as rev. 56308.

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

Comment By: Jim Jewett (jimjjewett)
Date: 2007-03-19 03:02

Message:
Logged In: YES 
user_id=764593
Originator: NO

sorry; I meant "cookielib"; clientcookie is the name of the independently
distributed package.  (Though last I checked, John Lee was using roughly
the same code in both.)

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

Comment By: Jim Jewett (jimjjewett)
Date: 2007-03-19 03:01

Message:
Logged In: YES 
user_id=764593
Originator: NO

It is possible to define a new Exception class which inherits from both
RuntimeError and IOError, and raise that.  Then document IOError, with a
footnote mentioning that in 2.x it is also a RuntimeError for backwards
compatibility.  

clientcookie does something similar; LoadError is derived from IOError
only for backwards compatibility.

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

Comment By: Collin Winter (collinwinter)
Date: 2007-03-12 18:43

Message:
Logged In: YES 
user_id=1344176
Originator: NO

I'm definitely in favor of the docs and test changes, and the extra error
checking seems like a good idea. Both test_zipfile and test_zipfile64 pass
for me with the patch applied.

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

Comment By: Alan McIntyre (alanmcintyre)
Date: 2007-03-08 17:32

Message:
Logged In: YES 
user_id=1115903
Originator: YES

I've modified ZipFile.getinfo to raise a KeyError instead of a
RuntimeError.  It would appear that RuntimeError is what stuff in this
module raises for IO problems, so I'm assuming this means we're stuck with
it (even though I agree that IOError would seem more appropriate for trying
to write to closed files). 

I documented some of the exceptions raised by various methods. However, I
focused mainly on the items listed in my original post, so there's probably
code that raise exceptions that still aren't properly documented.

I also noticed that the existing docs list "error" as the exception that
is raised for bad zip files.  Since no such exception is raised, I included
a change to the docs so that it says BadZipfile instead. 

I included a change to the NEWS file as well, since it was mentioned in
py-dev discussion that such updates can be helpful. :-)
File Added: zipfile_coverage2.diff

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

Comment By: Georg Brandl (gbrandl)
Date: 2007-03-07 08:18

Message:
Logged In: YES 
user_id=849994
Originator: NO

I'd continue raising KeyError in the case the info wasn't found,
but set a different message so that backwards compatibility doesn't
break.
In any case, it would be good to document it.

Isn't raising IOError customary for writing to closed files? (If zipfile
never raises IOError elsewhere, this is probably not applicable.)

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

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

From noreply at sourceforge.net  Thu Jul 12 12:17:00 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Jul 2007 03:17:00 -0700
Subject: [Patches] [ python-Patches-1617699 ] slice-object support for
	ctypes Pointer/Array
Message-ID: <E1I8vjI-0001Az-7O@sc8-sf-web24.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Modules
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Thomas Wouters (twouters)
Assigned to: Thomas Heller (theller)
Summary: slice-object support for ctypes Pointer/Array

Initial Comment:
Support for slicing ctypes' Pointer and Array types with slice objects, although only for step=1 case.
(Backported from p3yk-noslice branch.)


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

>Comment By: Thomas Heller (theller)
Date: 2007-07-12 12:17

Message:
Logged In: YES 
user_id=11105
Originator: NO

I think that full slicing support for pointers/arrays would be great. 
Presonally I have a use case for step = -1, in other words, I need to
iterate backwards over a ctypes array.

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

Comment By: Thomas Wouters (twouters)
Date: 2007-07-12 09:54

Message:
Logged In: YES 
user_id=34209
Originator: YES

Thomas, do you consider non-step-1 slicing important? I'd really like to
get the noslice branch merged into p3yk soon-ish, and I need to know which
bits I need to commit to the trunk first (to avoid merge conflicts for the
rest of the lifetime of the 2.x codebase.)

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

Comment By: Thomas Wouters (twouters)
Date: 2007-01-15 12:48

Message:
Logged In: YES 
user_id=34209
Originator: YES

The point is that simple slicing will go away, and extended slices (with
sliceobjects) are used in various places, and currently can't be passed on
to ctypes arrays and pointers. That is to say, a Python class defining
__getitem__ but not __getslice__ still supports slice syntax, but it can't
do 'pointer[sliceobj]' -- it would have to do
'pointer[sliceobj.start:sliceobj.end]'. Also, because simple slices will go
away, this code will have to be added to the p3yk branch in any case;
having it in the trunk just makes for easier maintenance.

Oh, and the non-support for steps other than 1 is not a fundamental issue,
I just couldn't bear to write the code for that if you didn't think it
would be useful, as I'd already written the same logic and arithmetic for
array, tupleseq, mmap and I forget what else :P You can consider this code
half-done, if you wish; I'll get to it again soon enough.

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

Comment By: Thomas Heller (theller)
Date: 2007-01-12 21:48

Message:
Logged In: YES 
user_id=11105
Originator: NO

Thomas, a question:  Since steps != 1 are not supported, does this patch
have any value?
IIUC, array[x:y] returns exactly the same as array[x:y:1] for all x and y
values.

Formally, the patch is missing unittests and documentation ;-).

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

Comment By: Thomas Heller (theller)
Date: 2006-12-20 19:45

Message:
Logged In: YES 
user_id=11105
Originator: NO

Unfortunately I'm unable to review or work on this patch *this year*.  I
will definitely take a look in January.  Sorry.

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

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

From noreply at sourceforge.net  Thu Jul 12 12:35:53 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Jul 2007 03:35:53 -0700
Subject: [Patches] [ python-Patches-1739468 ] Add a -z interpreter flag to
	execute a zip file
Message-ID: <E1I8w1Z-0003wi-Ub@sc8-sf-web23.sourceforge.net>

Patches item #1739468, was opened at 2007-06-19 04:40
Message generated for change (Comment added) made by pmoore
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1739468&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: andy-chu (andy-chu)
Assigned to: Nick Coghlan (ncoghlan)
Summary: Add a -z interpreter flag to execute a zip file

Initial Comment:
The motivation for this is that distributing a zip file is a very light and easy way to distribute a python program with multiple packages/modules.  I have done this on Linux, Mac and Windows and it works very nicely -- except that you need a few extra files to bootstrap it: set PYTHONPATH to the zip file and run the main function.

With this small patch, you get rid of the need for extra files.  At the bottom is a demo on Linux.

On Windows, you can do a similar thing by making a file that is both a zip file and a batch file.  The batch file will pass %~f0 (itself) to the -z flag of the Python interpreter.

I ran this by Guido and he seemed to think it was a fine idea.  At Google, we have numerous platform-specific hacks in a program called "autopar" to solve this problem.

I have included the basic patch, but if you guys agree with this, I will add some tests and documentation.  And I think it might be useful to include something in the Tools/ directory to do what update_zip.sh does below (add a __zipmain__ module and a shebang/batch file header to a zip file, to make it executable)?

I think this may also help to fix a bug with eggs:

http://peak.telecommunity.com/DevCenter/setuptools#eggsecutable-scripts

IMPORTANT NOTE: Eggs with an "eggsecutable" header cannot be renamed, or invoked via symlinks. They must be invoked using their original filename, in order to ensure that, once running, pkg_resources will know what project and version is in use. The header script will check this and exit with an error if the .egg file has been renamed or is invoked via a symlink that changes its base name.



andychu testdata$ ls
__zipmain__.py  foo.py  foo.pyc  foo.zip  foo_exe.zip  header.txt  update_zip.sh


# The main program you're going to run in "development mode"

andychu testdata$ ./foo.py foo bar
argv: ['./foo.py', 'foo', 'bar']


# Same program, packaged into a zip file

andychu testdata$ ./foo_exe.zip foo bar
argv: ['-c', 'foo', 'bar']


# Contents of the zip file

andychu testdata$ unzip -l foo_exe.zip
Archive:  foo_exe.zip
warning [foo_exe.zip]:  51 extra bytes at beginning or within zipfile
  (attempting to process anyway)
  Length     Date   Time    Name
 --------    ----   ----    ----
      243  06-18-07 20:01   __zipmain__.py
      301  06-18-07 19:58   foo.py
 --------                   -------
      544                   2 files


# Demo script to build an executable zip file.

andychu testdata$ cat header.txt
#!/usr/local/google/clients/python/trunk/python -z


andychu testdata$ cat update_zip.sh
#!/bin/bash

# Make a regular zip file.
zip foo.zip foo.py __zipmain__.py

# Add a shebang line to it.
cat header.txt foo.zip > foo_exe.zip

# Make it executable.
chmod 750 foo_exe.zip


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

Comment By: Paul Moore (pmoore)
Date: 2007-07-12 11:35

Message:
Logged In: YES 
user_id=113328
Originator: NO

I like the -z option - I'm in favour of that as it stands (you need to add
documentation). This is what the patch covers, and I'd like to see it
implemented as is.

The helper script is useful, but not essential. To include in the
distribution, you'd have to consider how to deploy it: module executable
via -m, .py file in the Scripts directory, shell script/.bat file in the
Scripts directory. Of these, only a module using -m is really portable. It
may be easier just to just have it as sample code in the documentation
which can be cut and pasted as required. (That's what I'd recommend).

For Windows, if you expect to define a file extension for these files, you
need to consider console vs GUI issues. File extensions are more useful in
a GUI context, so maybe .pyz files should be executed with "pythonw -z". Or
maybe there should be 2 extensions, .pyz (console) and .pwz (GUI)? I don't
have an answer to this, and honestly, if there's any controversy, I
wouldn't bother, but just leave it to the user to decide and implement a
local solution (much as Python doesn't add its directory to %PATH%) If you
wanted to define a standard, you'd need patches to the Windows MSI builder
to implement it.

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

Comment By: Martin v. L?wis (loewis)
Date: 2007-07-12 06:34

Message:
Logged In: YES 
user_id=21627
Originator: NO

I don't see the need for that on Linux: you can do the same thing already
with a shell script.
In the example below, foo.zip contains foo.py.

martin at mira:~$ cat runzip.sh
#!/bin/sh
export PYTHONPATH=$0
exec python -c 'import foo;foo.main()'
# THE END

martin at mira:~$ cat runzip.sh foo.zip >bar
martin at mira:~$ chmod +x bar.zip
martin at mira:~$ ./bar
hello

So unless that adds a functionality that I'm missing, I'm -1 on this
patch.

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

Comment By: andy-chu (andy-chu)
Date: 2007-07-11 07:25

Message:
Logged In: YES 
user_id=1821575
Originator: YES

Good point, however I decided to set sys.path[0] and sys.argv[0] a little
differently, based on some more testing, as you can see explained in the
new patch I just uploaded.

Those are details; I'll post to python-dev and see what people think of
the general idea.  If it's accepted then we can figure out the details. 
For now I made the function very specific to the -z flag.

I'm not sure I have a use case for invoking a zip file from another python
module.  If we were to put that back in, it might be better to have 2
separate functions anyway, since this one is only 3 lines basically.


File Added: runzip8.diff

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

Comment By: Nick Coghlan (ncoghlan)
Date: 2007-07-08 09:15

Message:
Logged In: YES 
user_id=1038590
Originator: NO

The new patch looks much better - the only thing is that run_zip needs to
do sys.path.pop(0) to correctly remove the zipfile from the front of the
path.

However, I do see your point about whether or not including the current
directory on sys.path is the right thing to do for this case - it may be
better to set <zipfile_name>/__zipmain__.py as argv[0] before invoking
PySys_SetArgv, and then use __zipmain__ as the module to be executed on the
same code path as the -m switch normally uses.

Rather than continuing this discussion here on SF, it may be best to post
your proposal to python-dev. I personally like the idea, but a new idiom
for running Python scripts will need broader support than just me. Getting
input from the py2exe and py2app folks that can be found on python-dev
would also be good. 

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

Comment By: andy-chu (andy-chu)
Date: 2007-07-07 19:33

Message:
Logged In: YES 
user_id=1821575
Originator: YES

Nick, have you had a chance to look this over again?  I mainly care about
the -z flag support.  The makepyz.py script is just a demo, though I think
it is useful as documentation as well.


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

Comment By: Nick Coghlan (ncoghlan)
Date: 2007-06-29 15:40

Message:
Logged In: YES 
user_id=1038590
Originator: NO

I'm going to be off the net for a few days - I'll have a look at the
updated patch when I get back late next week,

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

Comment By: andy-chu (andy-chu)
Date: 2007-06-28 06:17

Message:
Logged In: YES 
user_id=1821575
Originator: YES

Here is a script that documents how to make such files.  I think the
important part is just documenting the format.  Then people can write
whatever tools they need around it.  Many people could get by with this
simple tool, but others might want something more elaborate.

Demo:

andychu testprog$ find
.
./__init__.py
./package1
./package1/__init__.py
./package1/foo.py
./package1/lib.py
./package1/__init__.pyc
./package1/lib.pyc
./package1/foo.pyc

andychu testprog$ find -name "*.py" | xargs ../Tools/scripts/makepyz.py -a
zip,pyz,unix -z foo.zip -p package1 -m foo -y
/usr/local/google/clients/python/trunk/python
Added ./__init__.py to foo.zip
Added ./package1/__init__.py to foo.zip
Added ./package1/foo.py to foo.zip
Added ./package1/lib.py to foo.zip
Added __zipmain__.py to foo.zip
Prepended #!/usr/local/google/clients/python/trunk/python -z to foo.zip.
chmod foo.zip 0700

andychu testprog$ ./foo.zip
lib module here
argv: ['-c']
andychu testprog$ echo $?
3

File Added: makepyz.py

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

Comment By: andy-chu (andy-chu)
Date: 2007-06-27 06:35

Message:
Logged In: YES 
user_id=1821575
Originator: YES

Nick, I've updated the code to use a new runpy.run_zip function, which
calls run_module.  This does make it a bit cleaner.

Let me know what you think.  If the code is good I'll write some tests and
documentation.

Also, I'm not sure if the '-c' is really appropriate in sys.argv, but that
seems to be what the -m flag uses.  It seems like it might make sense to
have sys.argv[0] be the zip file, if it is really a first class
executable.

And I think a script to build one of these files would be appropriate,
which I can add.  You could pass it the main module and main function, and
it would generate a __zipmain__ stub and add it to the zip file.  And it is
a good idea if the file is cross platform, so a .pyz extension would work.

Sorry the delayed response, I was a bit busy at work this week... but I'll
respond sooner this time. : )

Example:

andychu trunk$ testdata/foo_exe.zip foo bar
__name__: __main__
argv: ['-c', 'foo', 'bar']
andychu trunk$ echo $?
3

File Added: runzip7.diff

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

Comment By: andy-chu (andy-chu)
Date: 2007-06-21 01:54

Message:
Logged In: YES 
user_id=1821575
Originator: YES

Nick, you're right, I think it can use run_module and be in the runpy
module.  Let me make those changes and send you another patch.


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

Comment By: Nick Coghlan (ncoghlan)
Date: 2007-06-19 12:21

Message:
Logged In: YES 
user_id=1038590
Originator: NO

I like the general idea, but it should be possible to use runpy.run_module
to get __name__ set correctly (as that is what happens when you execute a
module from a zipfile with -m). Another advantage of using run_module is
that it would allow runzip() to take a second argument (possibly defaulting
to "__zipmain__") which would specify the module to be executed from the
zipfile (the remaining 3 run_module arguments could also be passed in, and
set appropriately from main.c).

Adding the new function as runpy.run_zip() (instead of adding a new
module) would also be good.

For Windows, an alternative to making the zip file both a batch and a zip
file would be to adopt a .pyz extension convention for these files - the
file associations can then be set up to invoke the script appropriately
with python -z (similar to the way that .pyw files are associated with
pythonw instead of the standard python executable). That way the same file
could be executed on both Linux (via an embedded shebang line) and on
Windows (via filename association), as is the case with standard .py Python
scripts.

My final question is whether the change to sys.path should be reverted
once the module execution is complete - my suspicion is that it should, but
I need to look into it a bit more before giving a definite answer (for the
command line flag case, this behaviour obviously doesn't matter - it is
only significant if the Python method is invoked directly in the context of
a larger program).

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

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

From noreply at sourceforge.net  Thu Jul 12 13:29:53 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Jul 2007 04:29:53 -0700
Subject: [Patches] [ python-Patches-1752225 ] struni: _fileio fixes for
	Windows
Message-ID: <E1I8wrp-0005lV-IY@sc8-sf-web22.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 3000
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Amaury Forgeot d'Arc (amauryf)
Assigned to: Thomas Heller (theller)
Summary: struni: _fileio fixes for Windows

Initial Comment:
Theses patches correct two problems in the _fileio module on Windows:
- fileio-1.diff: Support for wide filenames: we use _wopen() with a unicode string.
- fileio-2.diff: Replaces ftruncate with Win32 API functions. Code borrowed from fileobject.c


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

>Comment By: Thomas Heller (theller)
Date: 2007-07-12 13:29

Message:
Logged In: YES 
user_id=11105
Originator: NO

Commited both changes.  Thanks for the great work.

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

Comment By: Amaury Forgeot d'Arc (amauryf)
Date: 2007-07-11 22:58

Message:
Logged In: YES 
user_id=389140
Originator: YES

File Added: fileio-2.diff

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

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

From noreply at sourceforge.net  Thu Jul 12 15:45:45 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Jul 2007 06:45:45 -0700
Subject: [Patches] [ python-Patches-1752647 ] fix failing unit tests in mmap
	in struni branch
Message-ID: <E1I8yzJ-0004Mf-Fh@sc8-sf-web22.sourceforge.net>

Patches item #1752647, was opened at 2007-07-12 13:45
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=1752647&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Tests
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Joe Gregorio (jcgregorio)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix failing unit tests in mmap in struni branch

Initial Comment:
Fixes to make test_mmap.py pass unit tests in the py3k-struni branch. 

Moves the interface from being string based to being bytes based. 

This patch also includes changes to io.py and associated unit tests that allow flush() to be called on closed files.


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

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

From noreply at sourceforge.net  Thu Jul 12 16:46:52 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Jul 2007 07:46:52 -0700
Subject: [Patches] [ python-Patches-1665292 ] Datetime enhancements
Message-ID: <E1I8zwS-0004h9-JW@sc8-sf-web22.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 2.6
Status: Closed
Resolution: Rejected
Priority: 5
Private: No
Submitted By: Christian Heimes (tiran)
Assigned to: Nobody/Anonymous (nobody)
Summary: Datetime enhancements

Initial Comment:
I'm proposing some small enhancements to the datetime module:

Add a totimestamp() method to datetime.datetime that returns the seconds since 1/1/1970 00:00:00. The datetime class has already a fromtimestamp() factory but is missing a totimestamp() method.

Add a __int__() and __float__() method to datetime.timedelta which return the seconds (seconds + 86400 * days) as int and seconds + miliseconds as float. It would save some typing if somebody needs an integer representation of a timedelta object :]

The datetime module is implemented in C. I've never written a Python C extension so I can't help with a patch.

Thx

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

>Comment By: Christian Heimes (tiran)
Date: 2007-07-12 16:46

Message:
Logged In: YES 
user_id=560817
Originator: YES

Oh, I didn't know that hash() *AND* == are used in dictionaries. Well, you
are the experts and I'm just a noob. :)

I'm going to remove the compare part from my patch. I still like to get
int(td) and float(td) into Python. I find it very useful.

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

Comment By: Georg Brandl (gbrandl)
Date: 2007-07-12 10:22

Message:
Logged In: YES 
user_id=849994
Originator: NO

Agreed. (A separate patch can be submitted for totimestamp().)

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

Comment By: Bj?rn Lindqvist (sonderblade)
Date: 2007-06-06 18:52

Message:
Logged In: YES 
user_id=51702
Originator: NO

Seems like it is safe to close this patch. If you need a timedelta in
seconds it isn't that much work to write td.days*86400+td.seconds to
convert it to an int. Converting it to a float doesn't seem useful enough.

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

Comment By: Jason Orendorff (jorend)
Date: 2007-04-21 00:19

Message:
Logged In: YES 
user_id=18139
Originator: NO

tiran, having timedelta objects comparable with numbers is going a bit too
far.  You end up with:

timedelta(0, 1) == 1   but   hash(timedelta(0, 1)) != hash(1)

This breaks dictionaries.


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

Comment By: Christian Heimes (tiran)
Date: 2007-03-23 03:38

Message:
Logged In: YES 
user_id=560817
Originator: YES

Here is a new patch. I've updated the documentation and enhanced the
compare function to compare with ints, longs and floats. This part of the
patch should be complete. I'm going to submit a different patch for the
other features later. Shall I start a new tracker entry?
File Added: timedelta_intfloat.diff

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

Comment By: Johann C. Rocholl (jcrocholl)
Date: 2007-03-09 17:33

Message:
Logged In: YES 
user_id=656137
Originator: NO

The patch confuses microseconds with milliseconds.
The divisor in delta_float should be 1000000.0, not 1000.0.
The result of the last test should be 86401.000001, not 86401.001.

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

Comment By: Christian Heimes (tiran)
Date: 2007-02-21 17:16

Message:
Logged In: YES 
user_id=560817
Originator: YES

File Added: timedelta.patch

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

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

From noreply at sourceforge.net  Thu Jul 12 17:16:35 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Jul 2007 08:16:35 -0700
Subject: [Patches] [ python-Patches-1752703 ] chown() does not handle UID >
	INT_MAX
Message-ID: <E1I90PD-0006rK-CW@sc8-sf-web23.sourceforge.net>

Patches item #1752703, was opened at 2007-07-12 11:16
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=1752703&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Andrew Ferguson (owsla)
Assigned to: Nobody/Anonymous (nobody)
Summary: chown() does not handle UID > INT_MAX

Initial Comment:
On at least some Unix platforms, uid_t and gid_t are mapped to unsigned int. Python parses the values for chown() into signed ints. This causes an exception when a UID is greater than INT_MAX.

For a few releases now, 64-bit Fedora has used UINT_MAX-1 as the UID of the nfsnobody user. Python programs chown'ing to the nfsnobody user encounter this problem.

The fix is only two lines and is attached. This issue is also documented in Bug 1747858.

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

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

From noreply at sourceforge.net  Fri Jul 13 09:18:51 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 13 Jul 2007 00:18:51 -0700
Subject: [Patches] [ python-Patches-1753245 ] Add RegEnableReflectionKey and
	RegDisableReflectionKey
Message-ID: <E1I9FQR-00086M-4v@sc8-sf-web21.sourceforge.net>

Patches item #1753245, was opened at 2007-07-13 17:18
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=1753245&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Mark Hammond (mhammond)
Assigned to: Mark Hammond (mhammond)
Summary: Add RegEnableReflectionKey and RegDisableReflectionKey

Initial Comment:
This adds 2 new Windows registry functions, useful for 32bit applications running on a 64bit Windows.

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

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

From noreply at sourceforge.net  Fri Jul 13 10:56:14 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 13 Jul 2007 01:56:14 -0700
Subject: [Patches] [ python-Patches-1753310 ] Lib/regrtest.py -x 'test_xxx'
	does not work
Message-ID: <E1I9Gwg-0003V1-S5@sc8-sf-web21.sourceforge.net>

Patches item #1753310, was opened at 2007-07-13 10:56
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=1753310&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Tests
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Thomas Heller (theller)
Assigned to: Nobody/Anonymous (nobody)
Summary: Lib/regrtest.py -x 'test_xxx' does not work

Initial Comment:
The -x option for Lib/regrtest.py does not work any longer.  The attached patch fixes this.

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

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

From noreply at sourceforge.net  Fri Jul 13 11:43:33 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 13 Jul 2007 02:43:33 -0700
Subject: [Patches] [ python-Patches-1752184 ] PyHeapTypeObject fix
Message-ID: <E1I9HgT-0000W8-GS@sc8-sf-web21.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Thomas Heller (theller)
Assigned to: Guido van Rossum (gvanrossum)
Summary: PyHeapTypeObject fix

Initial Comment:
This patch makes sure that the PyHeapTypeObject's ht_name member always contains a PyUnicode_Object.  Other code relies on this.

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

>Comment By: Thomas Heller (theller)
Date: 2007-07-13 11:43

Message:
Logged In: YES 
user_id=11105
Originator: YES

I did not understand the SystemError in test_ast, but the second version
of the patch does not trigger it any longer.  It also does no longer accept
PyString in type_set_name, and removes the refcount leak.

The test for null bytes I did not change, a generic api would be great to
replace it.
File Added: typeobject.diff

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-11 23:31

Message:
Logged In: YES 
user_id=6380
Originator: NO

Some test results: with this patch, test_ast fails weirdly:
test test_ast crashed -- <type 'SystemError'>: bad format char passed to
Py_BuildValue

I added assert(PyUnicode_Check(value)); to the top of the function and it
never triggered during any of the unit tests (I am in a debug build).  So
that's a safe assumption.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-11 23:15

Message:
Logged In: YES 
user_id=6380
Originator: NO

You're right there's a refcount leak.  Can you rework the patch to avoid
this?  One way would be to remove the later INCREF(value) and move that
into the code for when value is already a unicode. Then all the error
returns from them on must DECREF(value).

Also, the test for null bytes is not correct if there can be non-ASCII
characters in the name (as Martin will eventually implement), since it is
comparing the strlen() of the 8-bit string (which is UTF-8) with the length
of the Unicode string.  I wonder if we shouldn't add a generic API that
checks for null characters in a string, as I expect we'll need this in
other places too and the correct idiom is much more complicated now.

I also think that you might be able to simply insist on unicode, rather
than accepting both string and unicode.  That way we'll find any remaining
offenders more quickly (probably there aren't many).

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

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

From noreply at sourceforge.net  Fri Jul 13 12:07:42 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 13 Jul 2007 03:07:42 -0700
Subject: [Patches] [ python-Patches-1753310 ] Lib/regrtest.py -x 'test_xxx'
	does not work
Message-ID: <E1I9I3q-0002tt-39@sc8-sf-web24.sourceforge.net>

Patches item #1753310, was opened at 2007-07-13 08:56
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1753310&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Tests
Group: Python 3000
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Thomas Heller (theller)
Assigned to: Nobody/Anonymous (nobody)
Summary: Lib/regrtest.py -x 'test_xxx' does not work

Initial Comment:
The -x option for Lib/regrtest.py does not work any longer.  The attached patch fixes this.

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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-07-13 10:07

Message:
Logged In: YES 
user_id=849994
Originator: NO

Fixed in rev. 56339 with a set.

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

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

From isnya at takeone.net  Fri Jul 13 12:56:47 2007
From: isnya at takeone.net (Beatrix)
Date: Fri, 13 Jul 2007 06:56:47 -0400
Subject: [Patches] notification.pdf
Message-ID: <46975A6F.3060003@wayne.edu>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: notification.pdf
Type: application/pdf
Size: 14078 bytes
Desc: not available
Url : http://mail.python.org/pipermail/patches/attachments/20070713/9721743e/attachment.pdf 

From noreply at sourceforge.net  Fri Jul 13 13:36:56 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 13 Jul 2007 04:36:56 -0700
Subject: [Patches] [ python-Patches-1753310 ] Lib/regrtest.py -x 'test_xxx'
	does not work
Message-ID: <E1I9JSC-0007z0-PL@sc8-sf-web23.sourceforge.net>

Patches item #1753310, was opened at 2007-07-13 10:56
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1753310&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Tests
Group: Python 3000
Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Thomas Heller (theller)
Assigned to: Nobody/Anonymous (nobody)
Summary: Lib/regrtest.py -x 'test_xxx' does not work

Initial Comment:
The -x option for Lib/regrtest.py does not work any longer.  The attached patch fixes this.

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

>Comment By: Thomas Heller (theller)
Date: 2007-07-13 13:36

Message:
Logged In: YES 
user_id=11105
Originator: YES

This should be fixed in the py3k-struni branch also, or will this be
merged sometimes?

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

Comment By: Georg Brandl (gbrandl)
Date: 2007-07-13 12:07

Message:
Logged In: YES 
user_id=849994
Originator: NO

Fixed in rev. 56339 with a set.

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

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

From bgssb at vcbob.com  Fri Jul 13 21:46:55 2007
From: bgssb at vcbob.com (Beck P.Charles)
Date: Fri, 13 Jul 2007 15:46:55 -0400
Subject: [Patches] Fwd:
Message-ID: <4697D6AF.7070704@gonowmail.com>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: 
Type: application/pdf
Size: 11385 bytes
Desc: not available
Url : http://mail.python.org/pipermail/patches/attachments/20070713/bcfbaef0/attachment-0001.pdf 

From noreply at sourceforge.net  Fri Jul 13 22:00:50 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 13 Jul 2007 13:00:50 -0700
Subject: [Patches] [ python-Patches-1753310 ] Lib/regrtest.py -x 'test_xxx'
	does not work
Message-ID: <E1I9RJq-0003gM-84@sc8-sf-web22.sourceforge.net>

Patches item #1753310, was opened at 2007-07-13 08:56
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1753310&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Tests
Group: Python 3000
Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Thomas Heller (theller)
Assigned to: Nobody/Anonymous (nobody)
Summary: Lib/regrtest.py -x 'test_xxx' does not work

Initial Comment:
The -x option for Lib/regrtest.py does not work any longer.  The attached patch fixes this.

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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-07-13 20:00

Message:
Logged In: YES 
user_id=849994
Originator: NO

Sure, p3yk is merged to struni regularly.

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

Comment By: Thomas Heller (theller)
Date: 2007-07-13 11:36

Message:
Logged In: YES 
user_id=11105
Originator: YES

This should be fixed in the py3k-struni branch also, or will this be
merged sometimes?

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

Comment By: Georg Brandl (gbrandl)
Date: 2007-07-13 10:07

Message:
Logged In: YES 
user_id=849994
Originator: NO

Fixed in rev. 56339 with a set.

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

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

From noreply at sourceforge.net  Fri Jul 13 22:00:54 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 13 Jul 2007 13:00:54 -0700
Subject: [Patches] [ python-Patches-1753310 ] Lib/regrtest.py -x 'test_xxx'
	does not work
Message-ID: <E1I9RJu-0003gV-Nt@sc8-sf-web22.sourceforge.net>

Patches item #1753310, was opened at 2007-07-13 08:56
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1753310&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Tests
Group: Python 3000
Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Thomas Heller (theller)
Assigned to: Nobody/Anonymous (nobody)
Summary: Lib/regrtest.py -x 'test_xxx' does not work

Initial Comment:
The -x option for Lib/regrtest.py does not work any longer.  The attached patch fixes this.

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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-07-13 20:00

Message:
Logged In: YES 
user_id=849994
Originator: NO

Sure, p3yk is merged to struni regularly.

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

Comment By: Georg Brandl (gbrandl)
Date: 2007-07-13 20:00

Message:
Logged In: YES 
user_id=849994
Originator: NO

Sure, p3yk is merged to struni regularly.

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

Comment By: Thomas Heller (theller)
Date: 2007-07-13 11:36

Message:
Logged In: YES 
user_id=11105
Originator: YES

This should be fixed in the py3k-struni branch also, or will this be
merged sometimes?

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

Comment By: Georg Brandl (gbrandl)
Date: 2007-07-13 10:07

Message:
Logged In: YES 
user_id=849994
Originator: NO

Fixed in rev. 56339 with a set.

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

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

From noreply at sourceforge.net  Sat Jul 14 04:56:01 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 13 Jul 2007 19:56:01 -0700
Subject: [Patches] [ python-Patches-1753889 ] test_urllib2.test_fie passes
Message-ID: <E1I9Xnd-0000g7-0B@sc8-sf-web23.sourceforge.net>

Patches item #1753889, was opened at 2007-07-13 19:56
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=1753889&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Tests
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Hasan Diwan (hdiwan650)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_urllib2.test_fie passes

Initial Comment:
I'm working on Lib/test/test_urllib2.py and submitting as I go along

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

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

From noreply at sourceforge.net  Sat Jul 14 22:19:46 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 14 Jul 2007 13:19:46 -0700
Subject: [Patches] [ python-Patches-1739468 ] Add a -z interpreter flag to
	execute a zip file
Message-ID: <E1I9o5i-0007Xa-KS@sc8-sf-web23.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: andy-chu (andy-chu)
Assigned to: Nick Coghlan (ncoghlan)
Summary: Add a -z interpreter flag to execute a zip file

Initial Comment:
The motivation for this is that distributing a zip file is a very light and easy way to distribute a python program with multiple packages/modules.  I have done this on Linux, Mac and Windows and it works very nicely -- except that you need a few extra files to bootstrap it: set PYTHONPATH to the zip file and run the main function.

With this small patch, you get rid of the need for extra files.  At the bottom is a demo on Linux.

On Windows, you can do a similar thing by making a file that is both a zip file and a batch file.  The batch file will pass %~f0 (itself) to the -z flag of the Python interpreter.

I ran this by Guido and he seemed to think it was a fine idea.  At Google, we have numerous platform-specific hacks in a program called "autopar" to solve this problem.

I have included the basic patch, but if you guys agree with this, I will add some tests and documentation.  And I think it might be useful to include something in the Tools/ directory to do what update_zip.sh does below (add a __zipmain__ module and a shebang/batch file header to a zip file, to make it executable)?

I think this may also help to fix a bug with eggs:

http://peak.telecommunity.com/DevCenter/setuptools#eggsecutable-scripts

IMPORTANT NOTE: Eggs with an "eggsecutable" header cannot be renamed, or invoked via symlinks. They must be invoked using their original filename, in order to ensure that, once running, pkg_resources will know what project and version is in use. The header script will check this and exit with an error if the .egg file has been renamed or is invoked via a symlink that changes its base name.



andychu testdata$ ls
__zipmain__.py  foo.py  foo.pyc  foo.zip  foo_exe.zip  header.txt  update_zip.sh


# The main program you're going to run in "development mode"

andychu testdata$ ./foo.py foo bar
argv: ['./foo.py', 'foo', 'bar']


# Same program, packaged into a zip file

andychu testdata$ ./foo_exe.zip foo bar
argv: ['-c', 'foo', 'bar']


# Contents of the zip file

andychu testdata$ unzip -l foo_exe.zip
Archive:  foo_exe.zip
warning [foo_exe.zip]:  51 extra bytes at beginning or within zipfile
  (attempting to process anyway)
  Length     Date   Time    Name
 --------    ----   ----    ----
      243  06-18-07 20:01   __zipmain__.py
      301  06-18-07 19:58   foo.py
 --------                   -------
      544                   2 files


# Demo script to build an executable zip file.

andychu testdata$ cat header.txt
#!/usr/local/google/clients/python/trunk/python -z


andychu testdata$ cat update_zip.sh
#!/bin/bash

# Make a regular zip file.
zip foo.zip foo.py __zipmain__.py

# Add a shebang line to it.
cat header.txt foo.zip > foo_exe.zip

# Make it executable.
chmod 750 foo_exe.zip


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

Comment By: Alexandre Vassalotti (avassalotti)
Date: 2007-07-14 16:19

Message:
Logged In: YES 
user_id=1826340
Originator: NO

Martin, your trick won't work if you remove "foo.py" from the directory
you ran "bar". ;)

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

Comment By: Paul Moore (pmoore)
Date: 2007-07-12 06:35

Message:
Logged In: YES 
user_id=113328
Originator: NO

I like the -z option - I'm in favour of that as it stands (you need to add
documentation). This is what the patch covers, and I'd like to see it
implemented as is.

The helper script is useful, but not essential. To include in the
distribution, you'd have to consider how to deploy it: module executable
via -m, .py file in the Scripts directory, shell script/.bat file in the
Scripts directory. Of these, only a module using -m is really portable. It
may be easier just to just have it as sample code in the documentation
which can be cut and pasted as required. (That's what I'd recommend).

For Windows, if you expect to define a file extension for these files, you
need to consider console vs GUI issues. File extensions are more useful in
a GUI context, so maybe .pyz files should be executed with "pythonw -z". Or
maybe there should be 2 extensions, .pyz (console) and .pwz (GUI)? I don't
have an answer to this, and honestly, if there's any controversy, I
wouldn't bother, but just leave it to the user to decide and implement a
local solution (much as Python doesn't add its directory to %PATH%) If you
wanted to define a standard, you'd need patches to the Windows MSI builder
to implement it.

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

Comment By: Martin v. L?wis (loewis)
Date: 2007-07-12 01:34

Message:
Logged In: YES 
user_id=21627
Originator: NO

I don't see the need for that on Linux: you can do the same thing already
with a shell script.
In the example below, foo.zip contains foo.py.

martin at mira:~$ cat runzip.sh
#!/bin/sh
export PYTHONPATH=$0
exec python -c 'import foo;foo.main()'
# THE END

martin at mira:~$ cat runzip.sh foo.zip >bar
martin at mira:~$ chmod +x bar.zip
martin at mira:~$ ./bar
hello

So unless that adds a functionality that I'm missing, I'm -1 on this
patch.

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

Comment By: andy-chu (andy-chu)
Date: 2007-07-11 02:25

Message:
Logged In: YES 
user_id=1821575
Originator: YES

Good point, however I decided to set sys.path[0] and sys.argv[0] a little
differently, based on some more testing, as you can see explained in the
new patch I just uploaded.

Those are details; I'll post to python-dev and see what people think of
the general idea.  If it's accepted then we can figure out the details. 
For now I made the function very specific to the -z flag.

I'm not sure I have a use case for invoking a zip file from another python
module.  If we were to put that back in, it might be better to have 2
separate functions anyway, since this one is only 3 lines basically.


File Added: runzip8.diff

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

Comment By: Nick Coghlan (ncoghlan)
Date: 2007-07-08 04:15

Message:
Logged In: YES 
user_id=1038590
Originator: NO

The new patch looks much better - the only thing is that run_zip needs to
do sys.path.pop(0) to correctly remove the zipfile from the front of the
path.

However, I do see your point about whether or not including the current
directory on sys.path is the right thing to do for this case - it may be
better to set <zipfile_name>/__zipmain__.py as argv[0] before invoking
PySys_SetArgv, and then use __zipmain__ as the module to be executed on the
same code path as the -m switch normally uses.

Rather than continuing this discussion here on SF, it may be best to post
your proposal to python-dev. I personally like the idea, but a new idiom
for running Python scripts will need broader support than just me. Getting
input from the py2exe and py2app folks that can be found on python-dev
would also be good. 

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

Comment By: andy-chu (andy-chu)
Date: 2007-07-07 14:33

Message:
Logged In: YES 
user_id=1821575
Originator: YES

Nick, have you had a chance to look this over again?  I mainly care about
the -z flag support.  The makepyz.py script is just a demo, though I think
it is useful as documentation as well.


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

Comment By: Nick Coghlan (ncoghlan)
Date: 2007-06-29 10:40

Message:
Logged In: YES 
user_id=1038590
Originator: NO

I'm going to be off the net for a few days - I'll have a look at the
updated patch when I get back late next week,

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

Comment By: andy-chu (andy-chu)
Date: 2007-06-28 01:17

Message:
Logged In: YES 
user_id=1821575
Originator: YES

Here is a script that documents how to make such files.  I think the
important part is just documenting the format.  Then people can write
whatever tools they need around it.  Many people could get by with this
simple tool, but others might want something more elaborate.

Demo:

andychu testprog$ find
.
./__init__.py
./package1
./package1/__init__.py
./package1/foo.py
./package1/lib.py
./package1/__init__.pyc
./package1/lib.pyc
./package1/foo.pyc

andychu testprog$ find -name "*.py" | xargs ../Tools/scripts/makepyz.py -a
zip,pyz,unix -z foo.zip -p package1 -m foo -y
/usr/local/google/clients/python/trunk/python
Added ./__init__.py to foo.zip
Added ./package1/__init__.py to foo.zip
Added ./package1/foo.py to foo.zip
Added ./package1/lib.py to foo.zip
Added __zipmain__.py to foo.zip
Prepended #!/usr/local/google/clients/python/trunk/python -z to foo.zip.
chmod foo.zip 0700

andychu testprog$ ./foo.zip
lib module here
argv: ['-c']
andychu testprog$ echo $?
3

File Added: makepyz.py

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

Comment By: andy-chu (andy-chu)
Date: 2007-06-27 01:35

Message:
Logged In: YES 
user_id=1821575
Originator: YES

Nick, I've updated the code to use a new runpy.run_zip function, which
calls run_module.  This does make it a bit cleaner.

Let me know what you think.  If the code is good I'll write some tests and
documentation.

Also, I'm not sure if the '-c' is really appropriate in sys.argv, but that
seems to be what the -m flag uses.  It seems like it might make sense to
have sys.argv[0] be the zip file, if it is really a first class
executable.

And I think a script to build one of these files would be appropriate,
which I can add.  You could pass it the main module and main function, and
it would generate a __zipmain__ stub and add it to the zip file.  And it is
a good idea if the file is cross platform, so a .pyz extension would work.

Sorry the delayed response, I was a bit busy at work this week... but I'll
respond sooner this time. : )

Example:

andychu trunk$ testdata/foo_exe.zip foo bar
__name__: __main__
argv: ['-c', 'foo', 'bar']
andychu trunk$ echo $?
3

File Added: runzip7.diff

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

Comment By: andy-chu (andy-chu)
Date: 2007-06-20 20:54

Message:
Logged In: YES 
user_id=1821575
Originator: YES

Nick, you're right, I think it can use run_module and be in the runpy
module.  Let me make those changes and send you another patch.


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

Comment By: Nick Coghlan (ncoghlan)
Date: 2007-06-19 07:21

Message:
Logged In: YES 
user_id=1038590
Originator: NO

I like the general idea, but it should be possible to use runpy.run_module
to get __name__ set correctly (as that is what happens when you execute a
module from a zipfile with -m). Another advantage of using run_module is
that it would allow runzip() to take a second argument (possibly defaulting
to "__zipmain__") which would specify the module to be executed from the
zipfile (the remaining 3 run_module arguments could also be passed in, and
set appropriately from main.c).

Adding the new function as runpy.run_zip() (instead of adding a new
module) would also be good.

For Windows, an alternative to making the zip file both a batch and a zip
file would be to adopt a .pyz extension convention for these files - the
file associations can then be set up to invoke the script appropriately
with python -z (similar to the way that .pyw files are associated with
pythonw instead of the standard python executable). That way the same file
could be executed on both Linux (via an embedded shebang line) and on
Windows (via filename association), as is the case with standard .py Python
scripts.

My final question is whether the change to sys.path should be reverted
once the module execution is complete - my suspicion is that it should, but
I need to look into it a bit more before giving a definite answer (for the
command line flag case, this behaviour obviously doesn't matter - it is
only significant if the Python method is invoked directly in the context of
a larger program).

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

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

From noreply at sourceforge.net  Sat Jul 14 22:38:17 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 14 Jul 2007 13:38:17 -0700
Subject: [Patches] [ python-Patches-1754094 ] Tighter co_stacksize
	computation in stackdepth_walk
Message-ID: <E1I9oNd-000435-GO@sc8-sf-web21.sourceforge.net>

Patches item #1754094, was opened at 2007-07-14 16:38
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=1754094&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Christopher Tur Lesniewski-Laas (ctl)
Assigned to: Nobody/Anonymous (nobody)
Summary: Tighter co_stacksize computation in stackdepth_walk

Initial Comment:
The existing code in stackdepth_walk gives conservative, but not very tight, bounds for stack depth.  Some of this is simply bugs: for example,
  import a,b,c,d,e,f,...,z
will leak a stack slot for each import, and
  a[:],b[:],c[:],...,z[:]
leaks a stack slot for each SLICE+0 opcode.

Some of it is because stackdepth_walk assumes that the stack effect of jumps is the same at the target.  In particular, a sequence of for-loops will leak 2 stack slots for each for-loop.

The attached patch fixes both of these problems.  It corrects the stack effect for several opcodes that were simply incorrect (perhaps from an older version?).  It also changes stackdepth_walk to treat FOR_ITER, SETUP_EXCEPT, and SETUP_FINALLY specially when following their targets.

Note: this patch also introduces a dependency from stackdepth_walk to the compiler, because it assumes that END_FINALLY is always preceded by the target of a SETUP_EXCEPT or SETUP_FINALLY.

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

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

From noreply at sourceforge.net  Sun Jul 15 12:55:43 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 15 Jul 2007 03:55:43 -0700
Subject: [Patches] [ python-Patches-1754271 ] Deprecation warning for
	`backticks`
Message-ID: <E1IA1lP-0005ok-RQ@sc8-sf-web24.sourceforge.net>

Patches item #1754271, was opened at 2007-07-15 20:55
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=1754271&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Tom Lee (thomasglee)
Assigned to: Nobody/Anonymous (nobody)
Summary: Deprecation warning for `backticks`

Initial Comment:
Patch is attached which generates a DeprecationWarning for the use of `backticks` if the -3 argument is passed on the command line:

tom at localhost:~/src/python-trunk$ ./python -3
warning: callable() not supported in 3.x
warning: callable() not supported in 3.x
warning: callable() not supported in 3.x
warning: callable() not supported in 3.x
warning: callable() not supported in 3.x
warning: callable() not supported in 3.x
warning: callable() not supported in 3.x
warning: callable() not supported in 3.x
Python 2.6a0 (trunk:56394M, Jul 15 2007, 20:54:01) 
[GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> `1`
sys:1: DeprecationWarning: backquote not supported in 3.x
'1'
>>> 


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

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

From noreply at sourceforge.net  Sun Jul 15 13:01:24 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 15 Jul 2007 04:01:24 -0700
Subject: [Patches] [ python-Patches-1754273 ] Deprecation warning for <>
	(NOTEQUAL)
Message-ID: <E1IA1qu-0006UD-CT@sc8-sf-web24.sourceforge.net>

Patches item #1754273, was opened at 2007-07-15 21: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=1754273&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Tom Lee (thomasglee)
Assigned to: Nobody/Anonymous (nobody)
Summary: Deprecation warning for <> (NOTEQUAL)

Initial Comment:
Generates a DeprecationWarning for the use of <>. Is it a hack to do this within Parser/tokenizer.c? Can't see any other immediate way to do it without generating an alternate token code for <> vs. !=:

tom at localhost:~/src/python-trunk$ ./python -3
warning: callable() not supported in 3.x
warning: callable() not supported in 3.x
warning: callable() not supported in 3.x
warning: callable() not supported in 3.x
warning: callable() not supported in 3.x
warning: callable() not supported in 3.x
warning: callable() not supported in 3.x
warning: callable() not supported in 3.x
Python 2.6a0 (trunk:56394M, Jul 15 2007, 21:00:33) 
[GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 1 <> 2
sys:1: DeprecationWarning: <> not supported in 3.x
True
>>> 1 != 2
True
>>> 


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

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

From noreply at sourceforge.net  Sun Jul 15 17:54:34 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 15 Jul 2007 08:54:34 -0700
Subject: [Patches] [ python-Patches-1754339 ] struni: Bytes support for
	TextIOWrapper.write()
Message-ID: <E1IA6Qc-0004FW-Hs@sc8-sf-web24.sourceforge.net>

Patches item #1754339, was opened at 2007-07-15 17:54
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=1754339&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Christian Heimes (tiran)
Assigned to: Nobody/Anonymous (nobody)
Summary: struni: Bytes support for TextIOWrapper.write() 

Initial Comment:
The patch fixes support for bytes in TextIOWrapper.write(). It also fixes some unit test like test_uu, too.

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

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

From noreply at sourceforge.net  Mon Jul 16 00:40:12 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 15 Jul 2007 15:40:12 -0700
Subject: [Patches] [ python-Patches-1754483 ] linecache package handling
Message-ID: <E1IAClA-0002N2-EA@sc8-sf-web23.sourceforge.net>

Patches item #1754483, was opened at 2007-07-15 15:40
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=1754483&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Kevin Goodsell (kevingoodsell)
Assigned to: Nobody/Anonymous (nobody)
Summary: linecache package handling

Initial Comment:
The linecache module does not handle packages at all (Guido mentions here that he wrote it before Python had packages: http://mail.python.org/pipermail/python-dev/2005-September/056870.html).

This seems to cause problems with pdb and pydoc, as illustrated by this example:

$ mkdir pydoc_test
$ cd pydoc_test
$ echo "#" > __init__.py
$ pydoc logging

This gives a traceback due to an out of range index, resulting essentially from ./__init__.py being confused with logging/__init__.py. A line number from the latter is used as an index into a list of the lines from the former.

Patch attached, and a bit more explanation can be seen here:

https://bugs.launchpad.net/ubuntu/+source/python-defaults/+bug/70902

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

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

From noreply at sourceforge.net  Mon Jul 16 00:54:04 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 15 Jul 2007 15:54:04 -0700
Subject: [Patches] [ python-Patches-1754484 ] struni: Various patches for
	windows
Message-ID: <E1IACya-0004Yn-UQ@sc8-sf-web21.sourceforge.net>

Patches item #1754484, was opened at 2007-07-16 00:54
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=1754484&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Amaury Forgeot d'Arc (amauryf)
Assigned to: Nobody/Anonymous (nobody)
Summary: struni: Various patches for windows

Initial Comment:
Here are three patches for errors I found by running random tests on windows:

1 - bltin.diff: MSVC compiler does not accept #ifdef inside macro parameters (http://support.microsoft.com/kb/38291). 
Seems ugly, but I think I respected the spirit of the PyDoc_ macros.

2 - unicode.diff: a 'off-by-one' pointer error in PyUnicode_FromFormat that crashes the interpreter when an item cannot be converted by %U:
print(OSError(1, str8(b'\xe9')))

3 - windowserror.diff: UnicodeDecodeError is raised when the error message returned by the w32 function FormatMessage() contains French accented characters.
(it crashed the interpreted before patch#2...)

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

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

From noreply at sourceforge.net  Mon Jul 16 00:55:20 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 15 Jul 2007 15:55:20 -0700
Subject: [Patches] [ python-Patches-1754484 ] struni: Various patches for
	windows
Message-ID: <E1IACzo-0004fz-Uu@sc8-sf-web21.sourceforge.net>

Patches item #1754484, was opened at 2007-07-16 00:54
Message generated for change (Comment added) made by amauryf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1754484&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Amaury Forgeot d'Arc (amauryf)
Assigned to: Nobody/Anonymous (nobody)
Summary: struni: Various patches for windows

Initial Comment:
Here are three patches for errors I found by running random tests on windows:

1 - bltin.diff: MSVC compiler does not accept #ifdef inside macro parameters (http://support.microsoft.com/kb/38291). 
Seems ugly, but I think I respected the spirit of the PyDoc_ macros.

2 - unicode.diff: a 'off-by-one' pointer error in PyUnicode_FromFormat that crashes the interpreter when an item cannot be converted by %U:
print(OSError(1, str8(b'\xe9')))

3 - windowserror.diff: UnicodeDecodeError is raised when the error message returned by the w32 function FormatMessage() contains French accented characters.
(it crashed the interpreted before patch#2...)

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

>Comment By: Amaury Forgeot d'Arc (amauryf)
Date: 2007-07-16 00:55

Message:
Logged In: YES 
user_id=389140
Originator: YES

File Added: unicode.diff

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

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

From noreply at sourceforge.net  Mon Jul 16 00:56:26 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 15 Jul 2007 15:56:26 -0700
Subject: [Patches] [ python-Patches-1754484 ] struni: Various patches for
	windows
Message-ID: <E1IAD0s-0004n1-5Y@sc8-sf-web21.sourceforge.net>

Patches item #1754484, was opened at 2007-07-16 00:54
Message generated for change (Comment added) made by amauryf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1754484&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Amaury Forgeot d'Arc (amauryf)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: struni: Various patches for windows

Initial Comment:
Here are three patches for errors I found by running random tests on windows:

1 - bltin.diff: MSVC compiler does not accept #ifdef inside macro parameters (http://support.microsoft.com/kb/38291). 
Seems ugly, but I think I respected the spirit of the PyDoc_ macros.

2 - unicode.diff: a 'off-by-one' pointer error in PyUnicode_FromFormat that crashes the interpreter when an item cannot be converted by %U:
print(OSError(1, str8(b'\xe9')))

3 - windowserror.diff: UnicodeDecodeError is raised when the error message returned by the w32 function FormatMessage() contains French accented characters.
(it crashed the interpreted before patch#2...)

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

>Comment By: Amaury Forgeot d'Arc (amauryf)
Date: 2007-07-16 00:56

Message:
Logged In: YES 
user_id=389140
Originator: YES

File Added: windowserror.diff

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

Comment By: Amaury Forgeot d'Arc (amauryf)
Date: 2007-07-16 00:55

Message:
Logged In: YES 
user_id=389140
Originator: YES

File Added: unicode.diff

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

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

From noreply at sourceforge.net  Mon Jul 16 01:07:19 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 15 Jul 2007 16:07:19 -0700
Subject: [Patches] [ python-Patches-1754489 ] Non-portable address length
	calculation for AF_UNIX sockets
Message-ID: <E1IADBP-00016F-Ek@sc8-sf-web22.sourceforge.net>

Patches item #1754489, was opened at 2007-07-16 01: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=1754489&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Vlado Handziski (vlahan)
Assigned to: Nobody/Anonymous (nobody)
Summary: Non-portable address length calculation for AF_UNIX sockets

Initial Comment:
The calculation of the address length for AF_UNIX sockets in the getsockaddrarg function in socketmodule.c returns wrong values on platforms with padded struct sockaddr_un:

*len_ret = len + sizeof(*addr) - sizeof(addr->sun_path);

sizeof(*addr) is for example 112 on an ARM (NSLU2) platforms, while it is 110 on a i386 PC.

The correct way to calculate the length is by directly using the offset of the sun_path field:

*len_ret = len + offsetof(struct sockaddr_un, sun_path);

as suggested in the GNU libc manual:

http://www.gnu.org/software/libc/manual/html_node/Local-Socket-Example.html

The correction also needs to be applied to the makesockaddr function when reversing the above addition in the case of abstract namespace sockets on linux.

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

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

From richard_kaihara at comcast.net  Mon Jul 16 09:52:18 2007
From: richard_kaihara at comcast.net (richard kaihara)
Date: Mon, 16 Jul 2007 00:52:18 -0700
Subject: [Patches] Virus Activity Detected!
References: <3383e1a7a85955ab65e8517a32e6b9ea@>
Message-ID: <00dd01c7c77e$3c5db790$6901a8c0@FAMILY>

Please stop sending me e-mail and close my account.

Thankyou

Rich Kaihara
  ----- Original Message ----- 
  From: Customer Support 
  To: patches at python.org 
  Sent: Monday, July 09, 2007 3:13 PM
  Subject: [Patches] Virus Activity Detected!


  Dear Customer,

  Our robot has detected an abnormal activity from your IP adress 
  on sending e-mails. Probably it is connected with the last epidemic 
  of a worm which does not have official patches at the moment.

  We recommend you to install this patch to remove worm files 
  and stop email sending, otherwise your account will be blocked.

  Customer Support



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


  _______________________________________________
  Patches mailing list
  Patches at python.org
  http://mail.python.org/mailman/listinfo/patches
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/patches/attachments/20070716/0e6ddc5a/attachment-0001.htm 

From noreply at sourceforge.net  Mon Jul 16 21:50:22 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 16 Jul 2007 12:50:22 -0700
Subject: [Patches] [ python-Patches-1754339 ] struni: Bytes support for
	TextIOWrapper.write()
Message-ID: <E1IAWaM-0005k3-9m@sc8-sf-web24.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 3000
>Status: Closed
>Resolution: Rejected
Priority: 5
Private: No
Submitted By: Christian Heimes (tiran)
Assigned to: Nobody/Anonymous (nobody)
Summary: struni: Bytes support for TextIOWrapper.write() 

Initial Comment:
The patch fixes support for bytes in TextIOWrapper.write(). It also fixes some unit test like test_uu, too.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-16 15:50

Message:
Logged In: YES 
user_id=6380
Originator: NO

This looks like the wrong approach.  Instead, I'm changing uu.py to
explcitly turn the bytes returned by b2a_uu() into a string.  (The
alternative would be to require the output file to be opened in binary
mode, which makes less sense IMO.)  The change is r56402.

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

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

From noreply at sourceforge.net  Mon Jul 16 22:35:38 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 16 Jul 2007 13:35:38 -0700
Subject: [Patches] [ python-Patches-1031213 ] Patch for bug #780725
Message-ID: <E1IAXIA-0000tY-AS@sc8-sf-web23.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: None
Status: Open
Resolution: None
Priority: 6
Private: No
Submitted By: atsuo ishimoto (ishimoto)
>Assigned to: Martin v. L?wis (loewis)
Summary: Patch for bug #780725 

Initial Comment:
When SyntaxError occurs and the module contains 
source encodings definition, current implementation 
prints error line in UTF8. This patch reverts the line into 
original encoding for printing.

This patch calls some memory-allocation APIs such as 
PyUnicode_DecodeUTF8. I'm not sure I can (or should) 
call PyErr_Clear() here if error happened.


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-16 16:35

Message:
Logged In: YES 
user_id=6380
Originator: NO

I think Martin von Loewis knows more about this.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-30 13:04

Message:
Logged In: YES 
user_id=33168

Note to self (or anyone interested): remember to look into this.

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

Comment By: atsuo ishimoto (ishimoto)
Date: 2006-03-18 02:06

Message:
Logged In: YES 
user_id=463672

Sorry for my laziness. I revised a patch for current trunk.

- Use "replace" for recoding source
- Reports error with PyErr_Print()
- Test case


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

Comment By: atsuo ishimoto (ishimoto)
Date: 2005-10-13 02:38

Message:
Logged In: YES 
user_id=463672

Thanks for your comments. I'll post a revised patch and test
case later.

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2005-10-02 14:08

Message:
Logged In: YES 
user_id=38388

Please use the "replace" error handler when recoding the
source line
to Unicode - this will reduce the probability of the
conversion failing.

If you do get an error, it's likely going to be an unknown
encoding or
less likely a memory problem. Please add some logic to deal
with these
errors as well - currently you don't call PyError_Clear() or
take some
other action which may lead to confusing error reports (e.g.
error
popping up randomly during program execution due to the set
error).

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-02 01:45

Message:
Logged In: YES 
user_id=33168

I'm hoping that someone more familiar with unicode could
take a look at this.  The patch looks ok to me, but I
don't know how to test that it works.  I'm inclined to accept
it, unless I hear otherwise.

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

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

From noreply at sourceforge.net  Mon Jul 16 22:47:01 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 16 Jul 2007 13:47:01 -0700
Subject: [Patches] [ python-Patches-1754484 ] struni: Various patches for
	windows
Message-ID: <E1IAXTB-0003iT-55@sc8-sf-web24.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 3000
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Amaury Forgeot d'Arc (amauryf)
Assigned to: Guido van Rossum (gvanrossum)
Summary: struni: Various patches for windows

Initial Comment:
Here are three patches for errors I found by running random tests on windows:

1 - bltin.diff: MSVC compiler does not accept #ifdef inside macro parameters (http://support.microsoft.com/kb/38291). 
Seems ugly, but I think I respected the spirit of the PyDoc_ macros.

2 - unicode.diff: a 'off-by-one' pointer error in PyUnicode_FromFormat that crashes the interpreter when an item cannot be converted by %U:
print(OSError(1, str8(b'\xe9')))

3 - windowserror.diff: UnicodeDecodeError is raised when the error message returned by the w32 function FormatMessage() contains French accented characters.
(it crashed the interpreted before patch#2...)

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-16 16:47

Message:
Logged In: YES 
user_id=6380
Originator: NO

Committed revision 56403.

I can't verify #3 since I don't have a Windows box, but I trust you.

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

Comment By: Amaury Forgeot d'Arc (amauryf)
Date: 2007-07-15 18:56

Message:
Logged In: YES 
user_id=389140
Originator: YES

File Added: windowserror.diff

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

Comment By: Amaury Forgeot d'Arc (amauryf)
Date: 2007-07-15 18:55

Message:
Logged In: YES 
user_id=389140
Originator: YES

File Added: unicode.diff

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

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

From noreply at sourceforge.net  Mon Jul 16 22:52:51 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 16 Jul 2007 13:52:51 -0700
Subject: [Patches] [ python-Patches-1753889 ] test_urllib2.test_fie passes
Message-ID: <E1IAXYp-0000e7-Na@sc8-sf-web21.sourceforge.net>

Patches item #1753889, was opened at 2007-07-13 22:56
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1753889&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Tests
Group: Python 3000
>Status: Closed
>Resolution: Rejected
Priority: 5
Private: No
Submitted By: Hasan Diwan (hdiwan650)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: test_urllib2.test_fie passes

Initial Comment:
I'm working on Lib/test/test_urllib2.py and submitting as I go along

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-16 16:52

Message:
Logged In: YES 
user_id=6380
Originator: NO

I'm rejecting this fix; the proper fix instead is to make the variable
'towrite' a bytes literal. I've checked in that fix as r56404.

How is your research into the other errors coming along?

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

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

From noreply at sourceforge.net  Mon Jul 16 22:53:58 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 16 Jul 2007 13:53:58 -0700
Subject: [Patches] [ python-Patches-1752647 ] fix failing unit tests in mmap
	in struni branch
Message-ID: <E1IAXZu-0000lO-1I@sc8-sf-web21.sourceforge.net>

Patches item #1752647, was opened at 2007-07-12 09:45
Message generated for change (Settings changed) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1752647&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Tests
Group: Python 3000
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Joe Gregorio (jcgregorio)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: fix failing unit tests in mmap in struni branch

Initial Comment:
Fixes to make test_mmap.py pass unit tests in the py3k-struni branch. 

Moves the interface from being string based to being bytes based. 

This patch also includes changes to io.py and associated unit tests that allow flush() to be called on closed files.


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-16 16:53

Message:
Logged In: YES 
user_id=6380
Originator: NO

I've checked in the fix to mmap.  I'm rejecting the fixes to io.

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

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

From noreply at sourceforge.net  Mon Jul 16 22:55:53 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 16 Jul 2007 13:55:53 -0700
Subject: [Patches] [ python-Patches-1753889 ] test_urllib2.test_fie passes
Message-ID: <E1IAXbl-0004ja-OZ@sc8-sf-web24.sourceforge.net>

Patches item #1753889, was opened at 2007-07-13 19:56
Message generated for change (Comment added) made by hdiwan650
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1753889&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Tests
Group: Python 3000
Status: Closed
Resolution: Rejected
Priority: 5
Private: No
Submitted By: Hasan Diwan (hdiwan650)
Assigned to: Guido van Rossum (gvanrossum)
Summary: test_urllib2.test_fie passes

Initial Comment:
I'm working on Lib/test/test_urllib2.py and submitting as I go along

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

>Comment By: Hasan Diwan (hdiwan650)
Date: 2007-07-16 13:55

Message:
Logged In: YES 
user_id=1185570
Originator: YES

Slowly, as I'm trying to do other things at the same time.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-16 13:52

Message:
Logged In: YES 
user_id=6380
Originator: NO

I'm rejecting this fix; the proper fix instead is to make the variable
'towrite' a bytes literal. I've checked in that fix as r56404.

How is your research into the other errors coming along?

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

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

From noreply at sourceforge.net  Mon Jul 16 22:57:41 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 16 Jul 2007 13:57:41 -0700
Subject: [Patches] [ python-Patches-1753889 ] test_urllib2.test_fie passes
Message-ID: <E1IAXdV-0004xG-Km@sc8-sf-web24.sourceforge.net>

Patches item #1753889, was opened at 2007-07-13 19:56
Message generated for change (Comment added) made by hdiwan650
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1753889&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Tests
Group: Python 3000
Status: Closed
Resolution: Rejected
Priority: 5
Private: No
Submitted By: Hasan Diwan (hdiwan650)
Assigned to: Guido van Rossum (gvanrossum)
Summary: test_urllib2.test_fie passes

Initial Comment:
I'm working on Lib/test/test_urllib2.py and submitting as I go along

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

>Comment By: Hasan Diwan (hdiwan650)
Date: 2007-07-16 13:57

Message:
Logged In: YES 
user_id=1185570
Originator: YES

Slowly, as I'm trying to do other things at the same time.

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

Comment By: Hasan Diwan (hdiwan650)
Date: 2007-07-16 13:55

Message:
Logged In: YES 
user_id=1185570
Originator: YES

Slowly, as I'm trying to do other things at the same time.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-16 13:52

Message:
Logged In: YES 
user_id=6380
Originator: NO

I'm rejecting this fix; the proper fix instead is to make the variable
'towrite' a bytes literal. I've checked in that fix as r56404.

How is your research into the other errors coming along?

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

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

From noreply at sourceforge.net  Mon Jul 16 23:27:00 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 16 Jul 2007 14:27:00 -0700
Subject: [Patches] [ python-Patches-1755133 ] urllib2 tests pass
Message-ID: <E1IAY5s-0005dN-Dk@sc8-sf-web21.sourceforge.net>

Patches item #1755133, was opened at 2007-07-16 14: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=1755133&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Hasan Diwan (hdiwan650)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 tests pass

Initial Comment:
Tests pass for urllib2

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

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

From noreply at sourceforge.net  Mon Jul 16 23:39:08 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 16 Jul 2007 14:39:08 -0700
Subject: [Patches] [ python-Patches-1752184 ] PyHeapTypeObject fix
Message-ID: <E1IAYHc-0001Fp-PV@sc8-sf-web24.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Thomas Heller (theller)
Assigned to: Guido van Rossum (gvanrossum)
Summary: PyHeapTypeObject fix

Initial Comment:
This patch makes sure that the PyHeapTypeObject's ht_name member always contains a PyUnicode_Object.  Other code relies on this.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-16 17:39

Message:
Logged In: YES 
user_id=6380
Originator: NO

Hm...  Python-ast.c is the *output* of a generating step, according to the
top comment.  So that fix ought to be applied somewhere else.

Also, please add XXX in front of the comment "This test is buggy".

Otherwise, looks fine.

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

Comment By: Thomas Heller (theller)
Date: 2007-07-13 05:43

Message:
Logged In: YES 
user_id=11105
Originator: YES

I did not understand the SystemError in test_ast, but the second version
of the patch does not trigger it any longer.  It also does no longer accept
PyString in type_set_name, and removes the refcount leak.

The test for null bytes I did not change, a generic api would be great to
replace it.
File Added: typeobject.diff

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-11 17:31

Message:
Logged In: YES 
user_id=6380
Originator: NO

Some test results: with this patch, test_ast fails weirdly:
test test_ast crashed -- <type 'SystemError'>: bad format char passed to
Py_BuildValue

I added assert(PyUnicode_Check(value)); to the top of the function and it
never triggered during any of the unit tests (I am in a debug build).  So
that's a safe assumption.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-11 17:15

Message:
Logged In: YES 
user_id=6380
Originator: NO

You're right there's a refcount leak.  Can you rework the patch to avoid
this?  One way would be to remove the later INCREF(value) and move that
into the code for when value is already a unicode. Then all the error
returns from them on must DECREF(value).

Also, the test for null bytes is not correct if there can be non-ASCII
characters in the name (as Martin will eventually implement), since it is
comparing the strlen() of the 8-bit string (which is UTF-8) with the length
of the Unicode string.  I wonder if we shouldn't add a generic API that
checks for null characters in a string, as I expect we'll need this in
other places too and the correct idiom is much more complicated now.

I also think that you might be able to simply insist on unicode, rather
than accepting both string and unicode.  That way we'll find any remaining
offenders more quickly (probably there aren't many).

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

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

From noreply at sourceforge.net  Mon Jul 16 23:51:37 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 16 Jul 2007 14:51:37 -0700
Subject: [Patches] [ python-Patches-1755133 ] urllib2 tests pass
Message-ID: <E1IAYTh-0002d9-1O@sc8-sf-web24.sourceforge.net>

Patches item #1755133, was opened at 2007-07-16 14:27
Message generated for change (Comment added) made by hdiwan650
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1755133&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Hasan Diwan (hdiwan650)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 tests pass

Initial Comment:
Tests pass for urllib2

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

>Comment By: Hasan Diwan (hdiwan650)
Date: 2007-07-16 14:51

Message:
Logged In: YES 
user_id=1185570
Originator: YES

File Added: test_urllib2.pat

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

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

From noreply at sourceforge.net  Tue Jul 17 00:19:49 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 16 Jul 2007 15:19:49 -0700
Subject: [Patches] [ python-Patches-1755133 ] urllib2 tests pass
Message-ID: <E1IAYuz-0003HH-2n@sc8-sf-web21.sourceforge.net>

Patches item #1755133, was opened at 2007-07-16 14:27
Message generated for change (Comment added) made by hdiwan650
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1755133&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Hasan Diwan (hdiwan650)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 tests pass

Initial Comment:
Tests pass for urllib2

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

>Comment By: Hasan Diwan (hdiwan650)
Date: 2007-07-16 15:19

Message:
Logged In: YES 
user_id=1185570
Originator: YES

File Added: test_urllib2.pat

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

Comment By: Hasan Diwan (hdiwan650)
Date: 2007-07-16 14:51

Message:
Logged In: YES 
user_id=1185570
Originator: YES

File Added: test_urllib2.pat

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

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

From noreply at sourceforge.net  Tue Jul 17 00:58:14 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 16 Jul 2007 15:58:14 -0700
Subject: [Patches] [ python-Patches-1754483 ] linecache package handling
Message-ID: <E1IAZWA-0004rM-I8@sc8-sf-web22.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Kevin Goodsell (kevingoodsell)
Assigned to: Nobody/Anonymous (nobody)
Summary: linecache package handling

Initial Comment:
The linecache module does not handle packages at all (Guido mentions here that he wrote it before Python had packages: http://mail.python.org/pipermail/python-dev/2005-September/056870.html).

This seems to cause problems with pdb and pydoc, as illustrated by this example:

$ mkdir pydoc_test
$ cd pydoc_test
$ echo "#" > __init__.py
$ pydoc logging

This gives a traceback due to an out of range index, resulting essentially from ./__init__.py being confused with logging/__init__.py. A line number from the latter is used as an index into a list of the lines from the former.

Patch attached, and a bit more explanation can be seen here:

https://bugs.launchpad.net/ubuntu/+source/python-defaults/+bug/70902

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

>Comment By: Kevin Goodsell (kevingoodsell)
Date: 2007-07-16 15:58

Message:
Logged In: YES 
user_id=1845643
Originator: YES

New patch upload, typo fix.
File Added: linecache.py.patch

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

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

From noreply at sourceforge.net  Tue Jul 17 01:25:25 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 16 Jul 2007 16:25:25 -0700
Subject: [Patches] [ python-Patches-1755176 ] struni: corrections for
	test_cProfile
Message-ID: <E1IAZwT-0007sz-Au@sc8-sf-web22.sourceforge.net>

Patches item #1755176, was opened at 2007-07-17 01:25
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=1755176&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Amaury Forgeot d'Arc (amauryf)
Assigned to: Nobody/Anonymous (nobody)
Summary: struni: corrections for test_cProfile

Initial Comment:
test_cProfile passes

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

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

From noreply at sourceforge.net  Tue Jul 17 01:25:46 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 16 Jul 2007 16:25:46 -0700
Subject: [Patches] [ python-Patches-1755176 ] struni: corrections for
	test_cProfile
Message-ID: <E1IAZwo-00046T-Gg@sc8-sf-web23.sourceforge.net>

Patches item #1755176, was opened at 2007-07-17 01:25
Message generated for change (Settings changed) made by amauryf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1755176&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Amaury Forgeot d'Arc (amauryf)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: struni: corrections for test_cProfile

Initial Comment:
test_cProfile passes

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

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

From noreply at sourceforge.net  Tue Jul 17 01:36:17 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 16 Jul 2007 16:36:17 -0700
Subject: [Patches] [ python-Patches-1755176 ] struni: corrections for
	test_cProfile
Message-ID: <E1IAa6z-0005K7-Kl@sc8-sf-web23.sourceforge.net>

Patches item #1755176, was opened at 2007-07-16 19:25
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1755176&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 3000
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Amaury Forgeot d'Arc (amauryf)
Assigned to: Guido van Rossum (gvanrossum)
Summary: struni: corrections for test_cProfile

Initial Comment:
test_cProfile passes

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-16 19:36

Message:
Logged In: YES 
user_id=6380
Originator: NO

Thanks again!!

Committed revision 56406.


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

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

From noreply at sourceforge.net  Tue Jul 17 02:46:10 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 16 Jul 2007 17:46:10 -0700
Subject: [Patches] [ python-Patches-1755206 ] struni: corrections in ftplib
Message-ID: <E1IAbCc-00065d-L4@sc8-sf-web24.sourceforge.net>

Patches item #1755206, was opened at 2007-07-17 02:46
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=1755206&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Amaury Forgeot d'Arc (amauryf)
Assigned to: Nobody/Anonymous (nobody)
Summary: struni: corrections in ftplib

Initial Comment:
test_ftplib now passes, but it only tests socket timeouts...
My corrections were based on runs like:
python -m ftplib ftp.gnu.org -l emacs

Note: In this kind of code, byte objects make the code more difficult:
- it is easy to forget the b prefix 
eg:    resp[:3] in (b'250', '200')
- getitem does not return a single byte:
eg:    resp[0] == b'2'

Or should ftplib decode all the lines it receives?

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

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

From noreply at sourceforge.net  Tue Jul 17 02:47:21 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 16 Jul 2007 17:47:21 -0700
Subject: [Patches] [ python-Patches-1755206 ] struni: corrections in ftplib
Message-ID: <E1IAbDl-0006Ch-GV@sc8-sf-web24.sourceforge.net>

Patches item #1755206, was opened at 2007-07-17 02:46
Message generated for change (Settings changed) made by amauryf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1755206&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Amaury Forgeot d'Arc (amauryf)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: struni: corrections in ftplib

Initial Comment:
test_ftplib now passes, but it only tests socket timeouts...
My corrections were based on runs like:
python -m ftplib ftp.gnu.org -l emacs

Note: In this kind of code, byte objects make the code more difficult:
- it is easy to forget the b prefix 
eg:    resp[:3] in (b'250', '200')
- getitem does not return a single byte:
eg:    resp[0] == b'2'

Or should ftplib decode all the lines it receives?

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

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

From noreply at sourceforge.net  Tue Jul 17 03:14:51 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 16 Jul 2007 18:14:51 -0700
Subject: [Patches] [ python-Patches-1755214 ] struni: correction for sockets
	on win32
Message-ID: <E1IAbeN-0003Ao-Ix@sc8-sf-web22.sourceforge.net>

Patches item #1755214, was opened at 2007-07-17 03: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=1755214&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Amaury Forgeot d'Arc (amauryf)
Assigned to: Nobody/Anonymous (nobody)
Summary: struni: correction for sockets on win32

Initial Comment:
On Windows, os.dup() works on files, but not on socket handles.
Thus I changed the condition from
_os_has_dup = hasattr(os, "dup")
to
_can_dup_socket = hasattr(_socket, "dup")

This corrects many tests involving a socket server (test_ftplib at least).

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

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

From noreply at sourceforge.net  Tue Jul 17 03:15:20 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 16 Jul 2007 18:15:20 -0700
Subject: [Patches] [ python-Patches-1755214 ] struni: correction for sockets
	on win32
Message-ID: <E1IAbeq-0003HF-7C@sc8-sf-web22.sourceforge.net>

Patches item #1755214, was opened at 2007-07-17 03:14
Message generated for change (Settings changed) made by amauryf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1755214&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Amaury Forgeot d'Arc (amauryf)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: struni: correction for sockets on win32

Initial Comment:
On Windows, os.dup() works on files, but not on socket handles.
Thus I changed the condition from
_os_has_dup = hasattr(os, "dup")
to
_can_dup_socket = hasattr(_socket, "dup")

This corrects many tests involving a socket server (test_ftplib at least).

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

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

From noreply at sourceforge.net  Tue Jul 17 04:23:37 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 16 Jul 2007 19:23:37 -0700
Subject: [Patches] [ python-Patches-1755229 ] struni: correction for _winreg
	module
Message-ID: <E1IAciv-0004E1-63@sc8-sf-web22.sourceforge.net>

Patches item #1755229, was opened at 2007-07-17 04:23
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=1755229&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Amaury Forgeot d'Arc (amauryf)
Assigned to: Nobody/Anonymous (nobody)
Summary: struni: correction for _winreg module

Initial Comment:
test_winreg now passes (on Windows, of course)

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

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

From noreply at sourceforge.net  Tue Jul 17 04:23:54 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 16 Jul 2007 19:23:54 -0700
Subject: [Patches] [ python-Patches-1755229 ] struni: correction for _winreg
	module
Message-ID: <E1IAcjC-0004ET-TC@sc8-sf-web22.sourceforge.net>

Patches item #1755229, was opened at 2007-07-17 04:23
Message generated for change (Settings changed) made by amauryf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1755229&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Amaury Forgeot d'Arc (amauryf)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: struni: correction for _winreg module

Initial Comment:
test_winreg now passes (on Windows, of course)

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

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

From wqgf at erols.com  Tue Jul 17 16:03:39 2007
From: wqgf at erols.com (Portia)
Date: Tue, 17 Jul 2007 18:03:39 +0400
Subject: [Patches] Fwd:
Message-ID: <469CCC3B.2020807@mcmahanlawfirm.com>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: Invoice.pdf
Type: application/pdf
Size: 14757 bytes
Desc: not available
Url : http://mail.python.org/pipermail/patches/attachments/20070717/2ae26338/attachment.pdf 

From noreply at sourceforge.net  Tue Jul 17 21:15:20 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 17 Jul 2007 12:15:20 -0700
Subject: [Patches] [ python-Patches-1755206 ] struni: corrections in ftplib
Message-ID: <E1IAsW0-0003ia-Ao@sc8-sf-web24.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Amaury Forgeot d'Arc (amauryf)
Assigned to: Guido van Rossum (gvanrossum)
Summary: struni: corrections in ftplib

Initial Comment:
test_ftplib now passes, but it only tests socket timeouts...
My corrections were based on runs like:
python -m ftplib ftp.gnu.org -l emacs

Note: In this kind of code, byte objects make the code more difficult:
- it is easy to forget the b prefix 
eg:    resp[:3] in (b'250', '200')
- getitem does not return a single byte:
eg:    resp[0] == b'2'

Or should ftplib decode all the lines it receives?

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-17 15:15

Message:
Logged In: YES 
user_id=6380
Originator: NO

You're right, it's ugly. I wonder if it makes more sense to change the
makefile() call to use 'r' for the mode, and adjust the various put*
methods to convert their argument to bytes?  We could use "ASCII",
"Latin-1" or "UTF-8" for encoding, I don't really know if there are ftp
servers that do anything with non-ASCII characters or encodings.  Maybe
adding the encoding as an option would be useful.

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

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

From noreply at sourceforge.net  Tue Jul 17 22:41:30 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 17 Jul 2007 13:41:30 -0700
Subject: [Patches] [ python-Patches-1755214 ] struni: correction for sockets
	on win32
Message-ID: <E1IAtrO-0000a8-8K@sc8-sf-web24.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 3000
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Amaury Forgeot d'Arc (amauryf)
Assigned to: Guido van Rossum (gvanrossum)
Summary: struni: correction for sockets on win32

Initial Comment:
On Windows, os.dup() works on files, but not on socket handles.
Thus I changed the condition from
_os_has_dup = hasattr(os, "dup")
to
_can_dup_socket = hasattr(_socket, "dup")

This corrects many tests involving a socket server (test_ftplib at least).

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-17 16:41

Message:
Logged In: YES 
user_id=6380
Originator: NO

Committed revision 56415.


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

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

From noreply at sourceforge.net  Tue Jul 17 22:45:40 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 17 Jul 2007 13:45:40 -0700
Subject: [Patches] [ python-Patches-1755206 ] struni: corrections in ftplib
Message-ID: <E1IAtvQ-00012h-OH@sc8-sf-web24.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 3000
>Status: Closed
>Resolution: Rejected
Priority: 5
Private: No
Submitted By: Amaury Forgeot d'Arc (amauryf)
Assigned to: Guido van Rossum (gvanrossum)
Summary: struni: corrections in ftplib

Initial Comment:
test_ftplib now passes, but it only tests socket timeouts...
My corrections were based on runs like:
python -m ftplib ftp.gnu.org -l emacs

Note: In this kind of code, byte objects make the code more difficult:
- it is easy to forget the b prefix 
eg:    resp[:3] in (b'250', '200')
- getitem does not return a single byte:
eg:    resp[0] == b'2'

Or should ftplib decode all the lines it receives?

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-17 16:45

Message:
Logged In: YES 
user_id=6380
Originator: NO

I've checked in minimal changes that make ftplib work along those lines.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-17 15:15

Message:
Logged In: YES 
user_id=6380
Originator: NO

You're right, it's ugly. I wonder if it makes more sense to change the
makefile() call to use 'r' for the mode, and adjust the various put*
methods to convert their argument to bytes?  We could use "ASCII",
"Latin-1" or "UTF-8" for encoding, I don't really know if there are ftp
servers that do anything with non-ASCII characters or encodings.  Maybe
adding the encoding as an option would be useful.

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

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

From noreply at sourceforge.net  Tue Jul 17 22:51:47 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 17 Jul 2007 13:51:47 -0700
Subject: [Patches] [ python-Patches-1755229 ] struni: correction for _winreg
	module
Message-ID: <E1IAu1L-0001kv-2C@sc8-sf-web24.sourceforge.net>

Patches item #1755229, was opened at 2007-07-16 22:23
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1755229&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 3000
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Amaury Forgeot d'Arc (amauryf)
Assigned to: Guido van Rossum (gvanrossum)
Summary: struni: correction for _winreg module

Initial Comment:
test_winreg now passes (on Windows, of course)

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-17 16:51

Message:
Logged In: YES 
user_id=6380
Originator: NO

Committed revision 56417.

I would like to see more tests for unicode strings containing non-ASCII
characters though.  Also, there's an XXX still in PySetValue(): /* XXX -
need Unicode support */.  Can you look into this?

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

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

From noreply at sourceforge.net  Tue Jul 17 22:56:01 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 17 Jul 2007 13:56:01 -0700
Subject: [Patches] [ python-Patches-1755133 ] urllib2 tests pass
Message-ID: <E1IAu5R-0002Fk-VZ@sc8-sf-web24.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Hasan Diwan (hdiwan650)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 tests pass

Initial Comment:
Tests pass for urllib2

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-17 16:56

Message:
Logged In: YES 
user_id=6380
Originator: NO

With the latest version I still get three errors:
test_basic_and_digest_auth_handlers, test_basic_auth,
test_proxy_basic_auth, all failing here: 

  File "Lib/test/test_urllib2.py", line 990, in _test_basic_auth
    r = opener.open(request_url)
  File "/usr/local/google/home/guido/python/py3k-struni/Lib/urllib2.py",
line 374, in open
    response = self._open(req, data)
  File "/usr/local/google/home/guido/python/py3k-struni/Lib/urllib2.py",
line 392, in _open
    '_open', req)
  File "/usr/local/google/home/guido/python/py3k-struni/Lib/urllib2.py",
line 352, in _call_chain
    result = func(*args)
  File "Lib/test/test_urllib2.py", line 363, in http_open
    "http", req, MockFile(), self.code, name, msg)
  File "/usr/local/google/home/guido/python/py3k-struni/Lib/urllib2.py",
line 412, in error
    result = self._call_chain(*args)
  File "/usr/local/google/home/guido/python/py3k-struni/Lib/urllib2.py",
line 352, in _call_chain
    result = func(*args)
  File "/usr/local/google/home/guido/python/py3k-struni/Lib/urllib2.py",
line 831, in http_error_407
    authority, req, headers)
  File "/usr/local/google/home/guido/python/py3k-struni/Lib/urllib2.py",
line 795, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/usr/local/google/home/guido/python/py3k-struni/Lib/urllib2.py",
line 801, in retry_http_basic_auth
    auth = 'Basic %s' % base64.b64encode(raw).strip()
TypeError: strip() takes exactly one argument (0 given)

Also:

(1) I'd like to see the interact_netscape call fixed rather than commented
out

(2) I wonder if urllib shouldn't use text strings instead of bytes for
headers and values.

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

Comment By: Hasan Diwan (hdiwan650)
Date: 2007-07-16 18:19

Message:
Logged In: YES 
user_id=1185570
Originator: YES

File Added: test_urllib2.pat

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

Comment By: Hasan Diwan (hdiwan650)
Date: 2007-07-16 17:51

Message:
Logged In: YES 
user_id=1185570
Originator: YES

File Added: test_urllib2.pat

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

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

From noreply at sourceforge.net  Wed Jul 18 04:32:18 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 17 Jul 2007 19:32:18 -0700
Subject: [Patches] [ python-Patches-1755841 ] Patch for [ 735515 ] urllib2
	should cache 301 redir
Message-ID: <E1IAzKs-00085N-Rd@sc8-sf-web22.sourceforge.net>

Patches item #1755841, was opened at 2007-07-18 08:02
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=1755841&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: O.R.Senthil Kumaran (orsenthil)
Assigned to: Nobody/Anonymous (nobody)
Summary: Patch for [ 735515 ] urllib2 should cache 301 redir

Initial Comment:
Tracker item python.org/sf/735515 mentions about urllib2 to cache 301 redirections.
Attached patch tries to implement the same.

Comments on Version 1 of patch:
a) Initializes a dictionary to store the redirection.
b) If req already in cache, return the previous Request object.
c) Otherwise handle the same as 302 and store the Request object.
d) Checks for loop errors in 301.

Just noticed, that it I missed max-redirect checks.
Please comment on this patch, with next version I shall add the max redirect check.



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

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

From noreply at sourceforge.net  Wed Jul 18 05:37:44 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 17 Jul 2007 20:37:44 -0700
Subject: [Patches] [ python-Patches-1741308 ] Fix Decimal.sqrt bugs
	described in #1725899
Message-ID: <E1IB0MC-00072b-P9@sc8-sf-web24.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Mark Dickinson (marketdickinson)
Assigned to: Facundo Batista (facundobatista)
Summary: Fix Decimal.sqrt bugs described in #1725899

Initial Comment:
This patch fixes a number of (yet-to-be-confirmed-as-) bugs in Decimal.sqrt();  see bug report 1725899 for details of these.

As a side benefit the modified version of Decimal.sqrt() runs significantly faster than the original, since it's based on integer arithmetic instead of carrying out Newton's method entirely in decimal;  on my iBook G4 the speedup is between 20 and 25 times with the default precision.

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

>Comment By: Mark Dickinson (marketdickinson)
Date: 2007-07-18 03:37

Message:
Logged In: YES 
user_id=703403
Originator: YES

Final(?) version of the patch is attached.  The extra testcases for sqrt
have been vetted, corrected (see below) and slightly expanded by Mike
Cowlishaw, and are, I believe, going to be included in the next update on
his website.   The file squareroot_extra.decTest included in the patch is
exactly the file I received back from Cowlishaw, with no changes. The code
and comments have been cleaned up a little.
The patch also fixes another bug in the _fixexponents method: in the
following, the Underflow flag should not be raised.

Python 2.5.1 (r251:54863, May 10 2007, 20:59:25) 
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from decimal import *
>>> c = getcontext()
>>> c.Emin = -9
>>> c.Emax = 9
>>> Decimal(2).sqrt()  # Inexact but not Subnormal
Decimal("1.414213562373095048801688724")
>>> +Decimal("100E-38") # Subnormal but not Inexact
Decimal("1E-36")
>>> c
Context(prec=28, rounding=ROUND_HALF_EVEN, Emin=-9, Emax=9, capitals=1,
flags=[Rounded, Underflow, Subnormal, Inexact], traps=[DivisionByZero,
Overflow, InvalidOperation])

There's still one outstanding issue:  Cowlishaw says that for a general
arithmetic operation, underflow of a nonzero result to zero should result
in the Clamped flag being raised;  I believe that the current testcases
from Cowlishaw's website reflect this, while the older ones in the
decimaltestdata directory don't.  (This is the source of the only
corrections to the previous test cases.)  Currently sqrt() does raise
Clamped on underflow to 0, but none of the other arithmetic operations do,
which is inconsistent.  I'd be happy to fix this, but I think discussion is
needed first:  should sqrt be `fixed' to not raise Clamped here (this would
be trivial to do);  should
the other arithmetic operations be fixed to raise Clamped on underflow to
0 (also trivial, except that it would require updating many
of the testcases), or should things be left as they are?  Any
suggestions?

(By the way, I also have a working Decimal.log, if anyone's
interested...)

Mark

Mark
File Added: decimal_sqrt_3.patch

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

Comment By: Mark Dickinson (marketdickinson)
Date: 2007-07-02 14:34

Message:
Logged In: YES 
user_id=703403
Originator: YES

File Added: decimal_sqrt_2.patch

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

Comment By: Mark Dickinson (marketdickinson)
Date: 2007-07-02 14:33

Message:
Logged In: YES 
user_id=703403
Originator: YES

Here's an updated patch, with:
 -- several hundred extra testcases, in a new file
squareroot_extra.decTest
 -- fixes for two bugs in the previous patch; one where the context
rounding mode was occasionally used instead of ROUND-HALF-EVEN, and one
involving underflow to 0.
 -- a fix for the following problem in Decimal._fixexponents():  (should I
submit a separate patch for this instead?)

>>> from decimal import *
>>> getcontext().Emax = 9
>>> getcontext().Emin = -9
>>> getcontext()._clamp = 1
>>> +Decimal("1E10")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/local/lib/python2.5/decimal.py", line 935, in __pos__
    ans = self._fix(context)
  File "/opt/local/lib/python2.5/decimal.py", line 1530, in _fix
    ans = self._fixexponents(context)
  File "/opt/local/lib/python2.5/decimal.py", line 1565, in _fixexponents
    ans = ans._rescale(Etop, context=context)
  File "/opt/local/lib/python2.5/decimal.py", line 1913, in _rescale
    return context._raise_error(InvalidOperation, 'Rescale > prec')
  File "/opt/local/lib/python2.5/decimal.py", line 2325, in _raise_error
    raise error, explanation
decimal.InvalidOperation: Rescale > prec

I've been in contact with Cowlishaw;  he's agreed that it looks as though
the C reference implementation needs a few changes, but hasn't had a chance
to look at things properly yet;  I've sent him the extra testcases above as
well.  Please let me know if there's anything else I can do to help.

Mark

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

Comment By: Facundo Batista (facundobatista)
Date: 2007-06-22 12:29

Message:
Logged In: YES 
user_id=752496
Originator: NO

Yes, I'll handle this and the mentioned bug. Thanks.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-06-22 07:09

Message:
Logged In: YES 
user_id=33168
Originator: NO

Facundo, could you take a look?

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

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

From noreply at sourceforge.net  Wed Jul 18 07:36:32 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 17 Jul 2007 22:36:32 -0700
Subject: [Patches] [ python-Patches-1755885 ] Show Location of Unicode
	Escape Errors
Message-ID: <E1IB2DA-0002Iw-N2@sc8-sf-web21.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Kurt B. Kaiser (kbk)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Show Location of Unicode Escape Errors

Initial Comment:
ref http://mail.python.org/pipermail/python-3000/2007-July/008762.html

This patch massages a unicode escape decoding error encountered during compilation into a syntax error, making it much easier to locate.

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

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

From noreply at sourceforge.net  Wed Jul 18 07:42:42 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 17 Jul 2007 22:42:42 -0700
Subject: [Patches] [ python-Patches-1690201 ] Added support for custom
	readline functions
Message-ID: <E1IB2J8-0003tC-GN@sc8-sf-web22.sourceforge.net>

Patches item #1690201, was opened at 2007-03-28 17:52
Message generated for change (Comment added) made by btimby
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1690201&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ben Timby (btimby)
Assigned to: Nobody/Anonymous (nobody)
Summary: Added support for custom readline functions

Initial Comment:
This patch allows for binding a key or keyseq to a custom function named custom. A custom handler can be registered and will be called by readline when the registered sequence input.

Example:

rl.py
--
import readline

def handler():
    print "need some help?"

readline.set_custom_hook(handler)
readline.parse_and_bind("\"?\": custom")

text = raw_input("type ? for help# ")
--

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

>Comment By: Ben Timby (btimby)
Date: 2007-07-18 01:42

Message:
Logged In: YES 
user_id=932679
Originator: YES

Jim, here is what I don't understand (item 3).

Currently, my patch (which is now an extension:
http://ben.timby.com/pub/bt.tar.gz) works like so:

1. Module is initialized. rl_add_defun is called to register
on_custom_hook as a handler for named function "custom".
2. User calls set_custom_hook. This simply sets custom_hook and
custom_hook_tstate to proper values.
3. User calls readline.parse_and_bind to bind a key to the named function
"custom".
4. When the bound key is pressed, readline invokes on_custom_hook, which
in turn invokes the function provided by the user as a parameter to
set_custom_hook (if it was valid).

This is simple, because there is only one custom function and one handler
for it. In order to provide functionality for multiple handlers, you would
as you described require a list. However, what would on_custom_hook look
like? It receives only (int count, int key) how can it use these to look up
the proper python function to invoke? Basically, how can it differentiate
between the various registered handlers? Here is an example.

1. Module is initialized.
2. User calls set_custom_hook, and provides a function name and handler.
3. The function name and handler are stored in a list.
4. rl_add_defun is used to register ?? as a handler for the named
function.
5. User calls readline.parse_and_bind to bind a key to their named
function.
6. ?? does ?? when invoked to find the python handler for the named
function.

Does that make any sense?

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

Comment By: Jim Jewett (jimjjewett)
Date: 2007-04-24 18:56

Message:
Logged In: YES 
user_id=764593
Originator: NO

It looks as though you may have code from python 2.3.4 -- readline.c has
been updated somewhat since then, particularly around threading.

I'm not sure I fully understand what you're asking in step 3.  It looks
like on_hook(obj) will already call the python function well enough; you
just need a way of keeping a reference to (and registering) a list of
functions.

The module uses (single) static variables for the hooks it predefines, and
you followed that model; you could just add a list of objects.  Instead of



Then in set_custom_hook, instead of calling set_hook immediately, 

    /* Not tested, you might want a dict instead, you should error check,

       you should pre-declare for C89, etc */

    if (NULL == custom_hooks) custom_hooks=PyList_New(0); /* no initial
elements */

    PyList_Append(custom_hooks, args);  /* add your custom func, etc to
the list */
    set_hook("  ", &(PyList_GET_ITEM(custom_hooks,
PyList_GET_SIZE(custom_hooks))), *args);


(Or you could just inline the checks from set_hook.)

If you're feeling ambitious, you could fix set_hook itself to use a
dictionary instead of specific pointers, or to get the name from the
function.__name__, or to use a newer calling convention (As I understand
it, the registration may really be METH_ONE, instead of METH_VARARGS.)


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

Comment By: Ben Timby (btimby)
Date: 2007-04-03 07:59

Message:
Logged In: YES 
user_id=932679
Originator: YES

Paul, thank you for clarifying. I agree with you completely. The reason I
was unable to implement the API fully is the following problem (probably as
you said due to the lack of dynamic features in C).

1. User defines python function.
2. User calls python readline.add_defun()
3. readline.add_defun() must whip up a C handler that will call the python
function and in turn call rl_add_defun to register it. Problem being that
multiple custom python functions registered with readline to a single C
handler will have no way to determine which python function to call on
invocation.
4. User calls readline.parse_and_bind()

I have no clue how to do step 3, so I avoided it. If anyone has
suggestions, ideas or examples, I am happy to do the work, I simply have
not had to do something like this before in C. I don't even know what this
would be called in order to google for it.

The patch is certainly not as useful as the full API, however, I DID
implement it to solve a problem, thus there is some use to it :-). I
learned recently that I can maintain this feature as an extension (outside
of) python, thus allowing me to continue to use it without depending on
python maintainers to perceive usefulness. I will do this for the time
being and if I am able to figure out item 3 I will resubmit the patch with
a full implementation.

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

Comment By: Paul Hankin (paulhankin)
Date: 2007-04-02 13:28

Message:
Logged In: YES 
user_id=1740099
Originator: NO

Hi Ben, I'm sorry if you thought my short reply suggested I hadn't looked
at the patch properly. I'll try to clarify what I meant.

Gnu readline provides an interface to custom functions: you declare a
function that takes a 'count' and a 'key' and returns 0 or an error. You
then call rl_add_defunc to declare it. You use the name you used in
'rl_add_defunc' in the readline init file to bind the command to a key.

The patch uses a different interface: the user provides a function that
takes no arguments. He declares it by calling 'set_custom_hook', and calls
it by using the name 'custom' in the init file to bind it to a key.

An interface consistent between python and readline would be:

def say_hello(key, count):
   ...
readline.add_defunc("say_hello", say_hello)
readline.parse_and_bind('"?" : say_hello')

(Perhaps the 'add_defun' is an artefact of lack of dynamic features of C
and would be dropped from the python interface).

The patch's use of a 'custom' hook is more complicated than using the
function name directly in the init file, and provides less functionality (a
single command, and removes the arguments that the c command would have).
Accepting this patch will cause minor compatibility trouble in future if
anyone works out a way round the admittedly difficult technical problems of
doing things the 'right' way.

Given the interface troubles, I'm not convinced enough of the usefulness
of the patch.


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

Comment By: Ben Timby (btimby)
Date: 2007-04-01 21:53

Message:
Logged In: YES 
user_id=932679
Originator: YES

If by adopt you mean adapt, that is what I have done. I simplified things
to allow a single named function "custom" but it uses the gnu readline
custom function interface (rl_add_defunc) . Have you even looked at the
patch?

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

Comment By: Paul Hankin (paulhankin)
Date: 2007-04-01 17:47

Message:
Logged In: YES 
user_id=1740099
Originator: NO

Gnu readline supports custom functions in C - it would be better to adopt
the gnu readline custom function interface to python, rather than using the
'custom' handler which smells of a hack.


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

Comment By: Ben Timby (btimby)
Date: 2007-03-28 19:01

Message:
Logged In: YES 
user_id=932679
Originator: YES

new Example:

rl.py
--
#!/usr/bin/python
import readline

def say_hello():
	print
	print "this is my help text..."
	readline.on_new_line()

readline.set_custom_hook(say_hello)
readline.parse_and_bind("\"?\": custom")

while True:
	data = raw_input("input# ")
	print "data: ", data
--

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

Comment By: Ben Timby (btimby)
Date: 2007-03-28 19:00

Message:
Logged In: YES 
user_id=932679
Originator: YES

File Added: python-2.3.4-readline_custom.patch

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

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

From noreply at sourceforge.net  Wed Jul 18 19:19:34 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 18 Jul 2007 10:19:34 -0700
Subject: [Patches] [ python-Patches-1755885 ] Show Location of Unicode
	Escape Errors
Message-ID: <E1IBDBW-0007Mx-JS@sc8-sf-web23.sourceforge.net>

Patches item #1755885, was opened at 2007-07-18 01:36
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1755885&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.6
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Kurt B. Kaiser (kbk)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Show Location of Unicode Escape Errors

Initial Comment:
ref http://mail.python.org/pipermail/python-3000/2007-July/008762.html

This patch massages a unicode escape decoding error encountered during compilation into a syntax error, making it much easier to locate.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-18 13:19

Message:
Logged In: YES 
user_id=6380
Originator: NO

Thanks! I checked a slightly modified version in.
Committed revision 56441.


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

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

From noreply at sourceforge.net  Thu Jul 19 22:17:54 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 19 Jul 2007 13:17:54 -0700
Subject: [Patches] [ python-Patches-1757118 ] utilize 2.5 try/except/finally
	in contextlib
Message-ID: <E1IBcRe-0001Fh-SI@sc8-sf-web24.sourceforge.net>

Patches item #1757118, was opened at 2007-07-19 21:17
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=1757118&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Philip Jenvey (pjenvey)
Assigned to: Nobody/Anonymous (nobody)
Summary: utilize 2.5 try/except/finally in contextlib

Initial Comment:
Lib/contextlib.py was added in Python 2.5, but doesn't take advantage of the combined try/except/finally block also added in 2.5.

This small patch has contextlib.contextmanager use it.

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

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

From noreply at sourceforge.net  Thu Jul 19 22:29:36 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 19 Jul 2007 13:29:36 -0700
Subject: [Patches] [ python-Patches-1757126 ] Fix ptcp154 encoding
	cyrillic_asian alias
Message-ID: <E1IBccy-0001xu-3r@sc8-sf-web23.sourceforge.net>

Patches item #1757126, was opened at 2007-07-19 21:29
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=1757126&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Philip Jenvey (pjenvey)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix ptcp154 encoding cyrillic_asian alias

Initial Comment:
This small patch fixes a typo in Lib/encodings/aliases.py, breaking an alias of the ptcp154 codec to cyrillic_asian

The alias is currently marked as 'cyrillic-asian', which isn't a valid normalized encoding name. The '-' should be normalized to '_' -- it should be 'cyrillic_asian'. Aliases are looked up from the aliases.py mapping by their noramlized name, described as:

def normalize_encoding(encoding):

    """ Normalize an encoding name.

        Normalization works as follows: all non-alphanumeric
        characters except the dot used for Python package names are
        collapsed and replaced with a single underscore, e.g. '  -;#'
        becomes '_'. Leading and trailing underscores are removed.

        Note that encoding names should be ASCII only; if they do use
        non-ASCII characters, these must be Latin-1 compatible.

    """

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

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

From richard_kaihara at comcast.net  Thu Jul 19 23:24:59 2007
From: richard_kaihara at comcast.net (richard kaihara)
Date: Thu, 19 Jul 2007 14:24:59 -0700
Subject: [Patches] (no subject)
Message-ID: <005201c7ca4b$48f56c30$6901a8c0@FAMILY>

please remove me from your mailing list.

thanlkyou, 

rich kaihara

415-519-1396
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/patches/attachments/20070719/dd335cc4/attachment.htm 

From noreply at sourceforge.net  Fri Jul 20 19:10:34 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 20 Jul 2007 10:10:34 -0700
Subject: [Patches] [ python-Patches-1757683 ] Add support for
	seeking/writing beyond EOF to io.BytesIO
Message-ID: <E1IBvzu-0007tj-6y@sc8-sf-web23.sourceforge.net>

Patches item #1757683, was opened at 2007-07-20 13:10
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=1757683&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alexandre Vassalotti (avassalotti)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add support for seeking/writing beyond EOF to io.BytesIO

Initial Comment:
The patch makes BytesIO inserts null bytes between the current EOF and the new write position.

See discussion on the Python-3000 mailing list:
http://mail.python.org/pipermail/python-3000/2007-June/008592.html

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

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

From noreply at sourceforge.net  Fri Jul 20 21:36:46 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 20 Jul 2007 12:36:46 -0700
Subject: [Patches] [ python-Patches-1757758 ] struni: make test_ucn pass
Message-ID: <E1IByHO-0007Ke-3U@sc8-sf-web21.sourceforge.net>

Patches item #1757758, was opened at 2007-07-20 15:36
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=1757758&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Tests
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alexandre Vassalotti (avassalotti)
Assigned to: Nobody/Anonymous (nobody)
Summary: struni: make test_ucn pass

Initial Comment:
The test was failing because it was trying to decode unicode objects. My solution is to make it decode bytes instead.

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

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

From noreply at sourceforge.net  Fri Jul 20 22:07:26 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 20 Jul 2007 13:07:26 -0700
Subject: [Patches] [ python-Patches-1757774 ] struni: fix str/bytes errors
	for test_oldmailbox
Message-ID: <E1IByl4-0002Yn-WE@sc8-sf-web22.sourceforge.net>

Patches item #1757774, was opened at 2007-07-20 16: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=1757774&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alexandre Vassalotti (avassalotti)
Assigned to: Nobody/Anonymous (nobody)
Summary: struni: fix str/bytes errors for test_oldmailbox

Initial Comment:
This patch replaces isinstance(s, str) by isinstance(s, bytes) for checking non-unicode strings. It also makes _ProxyFile.get_file() open files in "standard" mode (non-binary). 

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

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

From noreply at sourceforge.net  Fri Jul 20 22:27:37 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 20 Jul 2007 13:27:37 -0700
Subject: [Patches] [ python-Patches-1757782 ] setuptools support for bazaar
	vcs
Message-ID: <E1IBz4b-0004lr-DD@sc8-sf-web21.sourceforge.net>

Patches item #1757782, was opened at 2007-07-20 16: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=1757782&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils and setup.py
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Barry A. Warsaw (bwarsaw)
Assigned to: Phillip J. Eby (pje)
Summary: setuptools support for bazaar vcs

Initial Comment:
Here is a plugin that adds support for the Bazaar revision control system for setuptools.


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

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

From noreply at sourceforge.net  Fri Jul 20 22:49:23 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 20 Jul 2007 13:49:23 -0700
Subject: [Patches] [ python-Patches-1757774 ] struni: fix str/bytes errors
	for test_oldmailbox
Message-ID: <E1IBzPf-0007Hn-Ro@sc8-sf-web21.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alexandre Vassalotti (avassalotti)
Assigned to: Nobody/Anonymous (nobody)
Summary: struni: fix str/bytes errors for test_oldmailbox

Initial Comment:
This patch replaces isinstance(s, str) by isinstance(s, bytes) for checking non-unicode strings. It also makes _ProxyFile.get_file() open files in "standard" mode (non-binary). 

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

>Comment By: Alexandre Vassalotti (avassalotti)
Date: 2007-07-20 16:49

Message:
Logged In: YES 
user_id=1826340
Originator: YES

My change to _ProxyFile.get_file() is bad idea. Please wait for my updated
patch that will also fix test_mailbox.

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

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

From noreply at sourceforge.net  Fri Jul 20 23:10:58 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 20 Jul 2007 14:10:58 -0700
Subject: [Patches] [ python-Patches-1757782 ] setuptools support for bazaar
	vcs
Message-ID: <E1IBzkY-0007KS-Nu@sc8-sf-web23.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils and setup.py
Group: Python 2.6
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Barry A. Warsaw (bwarsaw)
Assigned to: Phillip J. Eby (pje)
Summary: setuptools support for bazaar vcs

Initial Comment:
Here is a plugin that adds support for the Bazaar revision control system for setuptools.


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

>Comment By: Phillip J. Eby (pje)
Date: 2007-07-20 21:10

Message:
Logged In: YES 
user_id=56214
Originator: NO

Hi Barry.  It's not necessary to submit a patch for this.  Just give your
module a name, add a setup.py with the entry points declared, and upload it
to the Cheeseshop.  Anyone who wants to use Bazaar can then just
easy_install your plugin -- and of course bzrlib.  (If bzrlib is on the
cheeseshop, or you can provide a download link for it in your setup script,
then it can be easy_installed automatically with your plugin.)

Sorry if there was any confusion; at one time the setuptools manual said
to submit patches, but that part actually predated the ability to add
support via plugins, and hadn't been removed.

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

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

From noreply at sourceforge.net  Sat Jul 21 00:45:08 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 20 Jul 2007 15:45:08 -0700
Subject: [Patches] [ python-Patches-1757839 ] struni: make test_mailbox and
	test_old_mailbox pass
Message-ID: <E1IC1Dg-000711-NE@sc8-sf-web21.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alexandre Vassalotti (avassalotti)
Assigned to: Nobody/Anonymous (nobody)
Summary: struni: make test_mailbox and test_old_mailbox pass

Initial Comment:
This patch make reads to a file return a string of the str type. This required to change the mode of certain call to open() to non-binary. I have no idea if this will cause problem, but at least the tests pass. If someone wants to keep opening these file in binary mode, then he will have to create a "proxy" class, like _ProxyFile in mailbox.py but with writing support, since file opened in binary mode always return string of the bytes type. Another solution would be to wrap every read() and readline() calls, on these files, with str().

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

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

From noreply at sourceforge.net  Sat Jul 21 00:46:29 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 20 Jul 2007 15:46:29 -0700
Subject: [Patches] [ python-Patches-1757774 ] struni: fix str/bytes errors
	for test_oldmailbox
Message-ID: <E1IC1Ez-00078N-FM@sc8-sf-web21.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 3000
>Status: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: Alexandre Vassalotti (avassalotti)
Assigned to: Nobody/Anonymous (nobody)
Summary: struni: fix str/bytes errors for test_oldmailbox

Initial Comment:
This patch replaces isinstance(s, str) by isinstance(s, bytes) for checking non-unicode strings. It also makes _ProxyFile.get_file() open files in "standard" mode (non-binary). 

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

>Comment By: Alexandre Vassalotti (avassalotti)
Date: 2007-07-20 18:46

Message:
Logged In: YES 
user_id=1826340
Originator: YES

Superseded by patch #1757839
Changing status to closed.

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

Comment By: Alexandre Vassalotti (avassalotti)
Date: 2007-07-20 16:49

Message:
Logged In: YES 
user_id=1826340
Originator: YES

My change to _ProxyFile.get_file() is bad idea. Please wait for my updated
patch that will also fix test_mailbox.

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

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

From noreply at sourceforge.net  Sat Jul 21 00:49:13 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 20 Jul 2007 15:49:13 -0700
Subject: [Patches] [ python-Patches-1757839 ] struni: make test_mailbox and
	test_old_mailbox pass
Message-ID: <E1IC1Hd-0005ss-Nn@sc8-sf-web22.sourceforge.net>

Patches item #1757839, was opened at 2007-07-20 18:45
Message generated for change (Comment added) made by avassalotti
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1757839&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alexandre Vassalotti (avassalotti)
Assigned to: Nobody/Anonymous (nobody)
Summary: struni: make test_mailbox and test_old_mailbox pass

Initial Comment:
This patch make reads to a file return a string of the str type. This required to change the mode of certain call to open() to non-binary. I have no idea if this will cause problem, but at least the tests pass. If someone wants to keep opening these file in binary mode, then he will have to create a "proxy" class, like _ProxyFile in mailbox.py but with writing support, since file opened in binary mode always return string of the bytes type. Another solution would be to wrap every read() and readline() calls, on these files, with str().

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

>Comment By: Alexandre Vassalotti (avassalotti)
Date: 2007-07-20 18:49

Message:
Logged In: YES 
user_id=1826340
Originator: YES

Here another patch that makes the failure message a little more
descriptive.

To apply both:

   cat 01_fix_mailbox.patch 02_better_failure_msg.patch | patch -p0

File Added: 02_better_failure_msg.patch

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

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

From noreply at sourceforge.net  Sat Jul 21 02:15:43 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 20 Jul 2007 17:15:43 -0700
Subject: [Patches] [ python-Patches-1757758 ] struni: make test_ucn pass
Message-ID: <E1IC2dL-0001IK-Vp@sc8-sf-web24.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Tests
Group: Python 3000
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Alexandre Vassalotti (avassalotti)
Assigned to: Nobody/Anonymous (nobody)
Summary: struni: make test_ucn pass

Initial Comment:
The test was failing because it was trying to decode unicode objects. My solution is to make it decode bytes instead.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-20 20:15

Message:
Logged In: YES 
user_id=6380
Originator: NO

Committed revision 56473.

Thanks!!

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

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

From noreply at sourceforge.net  Sat Jul 21 02:20:18 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 20 Jul 2007 17:20:18 -0700
Subject: [Patches] [ python-Patches-1757839 ] struni: make test_mailbox and
	test_old_mailbox pass
Message-ID: <E1IC2hm-0001r2-BX@sc8-sf-web24.sourceforge.net>

Patches item #1757839, was opened at 2007-07-20 18:45
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1757839&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alexandre Vassalotti (avassalotti)
Assigned to: Nobody/Anonymous (nobody)
Summary: struni: make test_mailbox and test_old_mailbox pass

Initial Comment:
This patch make reads to a file return a string of the str type. This required to change the mode of certain call to open() to non-binary. I have no idea if this will cause problem, but at least the tests pass. If someone wants to keep opening these file in binary mode, then he will have to create a "proxy" class, like _ProxyFile in mailbox.py but with writing support, since file opened in binary mode always return string of the bytes type. Another solution would be to wrap every read() and readline() calls, on these files, with str().

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-20 20:20

Message:
Logged In: YES 
user_id=6380
Originator: NO

Am I supposed to apply both patches one after another?

I still get two errors:

======================================================================
ERROR: test_add_and_close (__main__.TestMbox)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_mailbox.py", line 737, in test_add_and_close
    self.assertEqual(contents == open(self._path, 'r').read())
TypeError: failUnlessEqual() takes at least 3 positional arguments (2
given)

======================================================================
ERROR: test_add_and_close (__main__.TestMMDF)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_mailbox.py", line 737, in test_add_and_close
    self.assertEqual(contents == open(self._path, 'r').read())
TypeError: failUnlessEqual() takes at least 3 positional arguments (2
given)

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



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

Comment By: Alexandre Vassalotti (avassalotti)
Date: 2007-07-20 18:49

Message:
Logged In: YES 
user_id=1826340
Originator: YES

Here another patch that makes the failure message a little more
descriptive.

To apply both:

   cat 01_fix_mailbox.patch 02_better_failure_msg.patch | patch -p0

File Added: 02_better_failure_msg.patch

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

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

From noreply at sourceforge.net  Sat Jul 21 02:21:53 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 20 Jul 2007 17:21:53 -0700
Subject: [Patches] [ python-Patches-1757839 ] struni: make test_mailbox and
	test_old_mailbox pass
Message-ID: <E1IC2jJ-0001yT-MN@sc8-sf-web24.sourceforge.net>

Patches item #1757839, was opened at 2007-07-20 18:45
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1757839&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 3000
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Alexandre Vassalotti (avassalotti)
Assigned to: Nobody/Anonymous (nobody)
Summary: struni: make test_mailbox and test_old_mailbox pass

Initial Comment:
This patch make reads to a file return a string of the str type. This required to change the mode of certain call to open() to non-binary. I have no idea if this will cause problem, but at least the tests pass. If someone wants to keep opening these file in binary mode, then he will have to create a "proxy" class, like _ProxyFile in mailbox.py but with writing support, since file opened in binary mode always return string of the bytes type. Another solution would be to wrap every read() and readline() calls, on these files, with str().

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-20 20:21

Message:
Logged In: YES 
user_id=6380
Originator: NO

Looks like that was a bug in the second patch.  I'll ignore it for now.

The main patch is:
Committed revision 56474.


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-20 20:20

Message:
Logged In: YES 
user_id=6380
Originator: NO

Am I supposed to apply both patches one after another?

I still get two errors:

======================================================================
ERROR: test_add_and_close (__main__.TestMbox)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_mailbox.py", line 737, in test_add_and_close
    self.assertEqual(contents == open(self._path, 'r').read())
TypeError: failUnlessEqual() takes at least 3 positional arguments (2
given)

======================================================================
ERROR: test_add_and_close (__main__.TestMMDF)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_mailbox.py", line 737, in test_add_and_close
    self.assertEqual(contents == open(self._path, 'r').read())
TypeError: failUnlessEqual() takes at least 3 positional arguments (2
given)

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



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

Comment By: Alexandre Vassalotti (avassalotti)
Date: 2007-07-20 18:49

Message:
Logged In: YES 
user_id=1826340
Originator: YES

Here another patch that makes the failure message a little more
descriptive.

To apply both:

   cat 01_fix_mailbox.patch 02_better_failure_msg.patch | patch -p0

File Added: 02_better_failure_msg.patch

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

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

From noreply at sourceforge.net  Sat Jul 21 02:25:45 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 20 Jul 2007 17:25:45 -0700
Subject: [Patches] [ python-Patches-1757683 ] Add support for
	seeking/writing beyond EOF to io.BytesIO
Message-ID: <E1IC2n3-0002Pi-H5@sc8-sf-web24.sourceforge.net>

Patches item #1757683, was opened at 2007-07-20 13:10
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1757683&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 3000
Status: Open
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Alexandre Vassalotti (avassalotti)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add support for seeking/writing beyond EOF to io.BytesIO

Initial Comment:
The patch makes BytesIO inserts null bytes between the current EOF and the new write position.

See discussion on the Python-3000 mailing list:
http://mail.python.org/pipermail/python-3000/2007-June/008592.html

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-20 20:25

Message:
Logged In: YES 
user_id=6380
Originator: NO

Committed revision 56475.

Would you mind adding a unit test for this?

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

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

From noreply at sourceforge.net  Sat Jul 21 02:52:25 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 20 Jul 2007 17:52:25 -0700
Subject: [Patches] [ python-Patches-1757683 ] Add support for
	seeking/writing beyond EOF to io.BytesIO
Message-ID: <E1IC3Cr-0002hD-IL@sc8-sf-web22.sourceforge.net>

Patches item #1757683, was opened at 2007-07-20 13:10
Message generated for change (Comment added) made by avassalotti
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1757683&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 3000
Status: Open
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Alexandre Vassalotti (avassalotti)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add support for seeking/writing beyond EOF to io.BytesIO

Initial Comment:
The patch makes BytesIO inserts null bytes between the current EOF and the new write position.

See discussion on the Python-3000 mailing list:
http://mail.python.org/pipermail/python-3000/2007-June/008592.html

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

>Comment By: Alexandre Vassalotti (avassalotti)
Date: 2007-07-20 20:52

Message:
Logged In: YES 
user_id=1826340
Originator: YES

I already have one in my unittests for BytesIO/StringIO in my branch.

 
http://svn.python.org/view/python/branches/cpy_merge/Lib/test/test_memoryio.py?rev=56445&view=markup

It is called test_overseek and it is in the PyBytesIOTest class.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-20 20:25

Message:
Logged In: YES 
user_id=6380
Originator: NO

Committed revision 56475.

Would you mind adding a unit test for this?

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

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

From noreply at sourceforge.net  Sat Jul 21 03:17:38 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 20 Jul 2007 18:17:38 -0700
Subject: [Patches] [ python-Patches-1757839 ] struni: make test_mailbox and
	test_old_mailbox pass
Message-ID: <E1IC3bG-0005V0-Mm@sc8-sf-web22.sourceforge.net>

Patches item #1757839, was opened at 2007-07-20 18:45
Message generated for change (Comment added) made by avassalotti
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1757839&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 3000
Status: Closed
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Alexandre Vassalotti (avassalotti)
Assigned to: Nobody/Anonymous (nobody)
Summary: struni: make test_mailbox and test_old_mailbox pass

Initial Comment:
This patch make reads to a file return a string of the str type. This required to change the mode of certain call to open() to non-binary. I have no idea if this will cause problem, but at least the tests pass. If someone wants to keep opening these file in binary mode, then he will have to create a "proxy" class, like _ProxyFile in mailbox.py but with writing support, since file opened in binary mode always return string of the bytes type. Another solution would be to wrap every read() and readline() calls, on these files, with str().

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

>Comment By: Alexandre Vassalotti (avassalotti)
Date: 2007-07-20 21:17

Message:
Logged In: YES 
user_id=1826340
Originator: YES

I corrected the patch. It was a small error that slipped through when I
separated to two changes to make them easier to review. (Sometime, I wish
svn had a checkpoint feature or offline commits for this...)     

File Added: 02_better_failure_msg.patch

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-20 20:21

Message:
Logged In: YES 
user_id=6380
Originator: NO

Looks like that was a bug in the second patch.  I'll ignore it for now.

The main patch is:
Committed revision 56474.


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-20 20:20

Message:
Logged In: YES 
user_id=6380
Originator: NO

Am I supposed to apply both patches one after another?

I still get two errors:

======================================================================
ERROR: test_add_and_close (__main__.TestMbox)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_mailbox.py", line 737, in test_add_and_close
    self.assertEqual(contents == open(self._path, 'r').read())
TypeError: failUnlessEqual() takes at least 3 positional arguments (2
given)

======================================================================
ERROR: test_add_and_close (__main__.TestMMDF)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_mailbox.py", line 737, in test_add_and_close
    self.assertEqual(contents == open(self._path, 'r').read())
TypeError: failUnlessEqual() takes at least 3 positional arguments (2
given)

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



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

Comment By: Alexandre Vassalotti (avassalotti)
Date: 2007-07-20 18:49

Message:
Logged In: YES 
user_id=1826340
Originator: YES

Here another patch that makes the failure message a little more
descriptive.

To apply both:

   cat 01_fix_mailbox.patch 02_better_failure_msg.patch | patch -p0

File Added: 02_better_failure_msg.patch

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

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

From noreply at sourceforge.net  Sat Jul 21 11:06:33 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 21 Jul 2007 02:06:33 -0700
Subject: [Patches] [ python-Patches-1718153 ] PEP 3123 implementation
Message-ID: <E1ICAv3-0005R1-Em@sc8-sf-web21.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 3000
Status: Open
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Martin v. L?wis (loewis)
Assigned to: Martin v. L?wis (loewis)
Summary: PEP 3123 implementation

Initial Comment:
This patch implements the changes need for PEP 3123, in Py3k. Rather than checking this into the 3k branch, a backport of those bulk of the patch to 2.6 should be made, omitting the actual changes to PyObject_HEAD

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

>Comment By: Martin v. L?wis (loewis)
Date: 2007-07-21 11:06

Message:
Logged In: YES 
user_id=21627
Originator: YES

I found that steps 1 and 2 where not necessary, since you already had done

merging before I started. I then did 3 and 4, with these commits:

r56476: 2.6 changes
r56477: merged to 3k
r56478: change struct inheritance
r56479, 56480: fix strict-aliasing bugs related to True/False; many more
remain

Now I'm stuck; trying to do "merge -S p3yk" in the py3k-struni branch
gives me
a conflict on ".", and dir_conflicts.prej says

Trying to change property 'svnmerge-integrated' from
'/python/trunk:1-56465' to '/python/trunk:1-56476',
but property already exists with value '/python/branches/p3yk:1-56466
/python/trunk:1-54987'

I don't know how to fix this.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-12 10:26

Message:
Logged In: YES 
user_id=6380
Originator: NO

OK, sounds like this is fully compatible with 2.5.  So we will have two
compatibility ranges: [2.5, 2.6] and [2.6, 3.0] (but these use different
code variants).

To submit it, I propose the following procedure:

1. merge trunk -> p3yk (this should be easy as we've done this regularly
and recently)

2. merge p3yk -> py3k-struni (ditto)

3. submit this patch to the trunk

4. merge trunk -> p3yk (I fear this will require lots of conflict
resolutions)

5. merge p3yk -> py3k-struni (I expect some but not many conflicts)

I hope you can do all these; you know most about the code so you're most
likely to be able to pull off #4 successfully.

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

Comment By: Martin v. L?wis (loewis)
Date: 2007-07-12 10:16

Message:
Logged In: YES 
user_id=21627
Originator: YES

The 2.6 version of the patch is fully backwards-compatible. It provides a
few new macros, and reformulates a lot of code to use these macros. The 3.0
version of the same macros looks different; for 2.6, these macros don't
have to be used - but I propose to use them in the core anyhow to avoid the
two code bases diverging.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-12 09:08

Message:
Logged In: YES 
user_id=6380
Originator: NO

Hm. How fully backwards compatible is the patch? As part of the Py3k
transition strategy, I've been trying to paint a picture of the transition
from 2.x to 2.6 as super-easy, because we're not changing any existing
functionality, we're just adding Py3k forward compatibility features that
are easily ignoreable. Even if only 5% of 3rd party extension modules were
to need work because of this change, that would already defeat the purpose
IMO.

OTOH I'm all for doing this in 3.0.  If the 2.6 changes are fully
compatible I have no objection in doing it there as well.

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

Comment By: Martin v. L?wis (loewis)
Date: 2007-07-11 23:43

Message:
Logged In: YES 
user_id=21627
Originator: YES

Depends on the precise procedure to follow. I have a patch that works for
2.6 (but it's not included here); should I commit that?

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-11 14:38

Message:
Logged In: YES 
user_id=6380
Originator: NO

Is this ready to be committed?

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

Comment By: Martin v. L?wis (loewis)
Date: 2007-05-23 23:55

Message:
Logged In: YES 
user_id=21627
Originator: YES

I don't think API compatibility between 2.5 and 3.0 should be a
requirement - I expect that there will be much more breakage, making such
compatibility very difficult for other reasons.

Anyway, for everything that can be done with a macro (including
HEAD_INIT), code that wants compatibility with 2.5 and earlier should do

#ifndef MACRO
#define MACRO 2.6-content of macro
#endif

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-23 07:29

Message:
Logged In: YES 
user_id=33168
Originator: NO

I like this patch would like it to be applied to 2.6.  However, I'm
concerned about extension modules maintaining compatibility for 2.5 and
3.0.  What would that look like (ie, an extension module that can compile
with both versions)?  How would the modules need to be changed to support
both versions?  For Py_{Type,Refcnt,Size}, it looks pretty straightforward
to define the macros in 2.x and things should work fine.  But I'm not sure
about the HEAD_INIT macros.

Martin, did you try disabling the -fno-strict-aliasing with this patch to
see if there were any warnings?

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

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

From noreply at sourceforge.net  Sat Jul 21 17:05:54 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 21 Jul 2007 08:05:54 -0700
Subject: [Patches] [ python-Patches-1718153 ] PEP 3123 implementation
Message-ID: <E1ICGWo-0001rg-Va@sc8-sf-web22.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 3000
Status: Open
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Martin v. L?wis (loewis)
Assigned to: Martin v. L?wis (loewis)
Summary: PEP 3123 implementation

Initial Comment:
This patch implements the changes need for PEP 3123, in Py3k. Rather than checking this into the 3k branch, a backport of those bulk of the patch to 2.6 should be made, omitting the actual changes to PyObject_HEAD

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-21 11:05

Message:
Logged In: YES 
user_id=6380
Originator: NO

If the only conflict left is on '.', I've always gotten away with just
saying "svn resolved ." -- I have no idea why it does that but it seems
innocuous.  Generally you also need to do another svn up (which typically
doesn't do anything) before the submit passes.

Thanks for getting this in!

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

Comment By: Martin v. L?wis (loewis)
Date: 2007-07-21 05:06

Message:
Logged In: YES 
user_id=21627
Originator: YES

I found that steps 1 and 2 where not necessary, since you already had done

merging before I started. I then did 3 and 4, with these commits:

r56476: 2.6 changes
r56477: merged to 3k
r56478: change struct inheritance
r56479, 56480: fix strict-aliasing bugs related to True/False; many more
remain

Now I'm stuck; trying to do "merge -S p3yk" in the py3k-struni branch
gives me
a conflict on ".", and dir_conflicts.prej says

Trying to change property 'svnmerge-integrated' from
'/python/trunk:1-56465' to '/python/trunk:1-56476',
but property already exists with value '/python/branches/p3yk:1-56466
/python/trunk:1-54987'

I don't know how to fix this.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-12 04:26

Message:
Logged In: YES 
user_id=6380
Originator: NO

OK, sounds like this is fully compatible with 2.5.  So we will have two
compatibility ranges: [2.5, 2.6] and [2.6, 3.0] (but these use different
code variants).

To submit it, I propose the following procedure:

1. merge trunk -> p3yk (this should be easy as we've done this regularly
and recently)

2. merge p3yk -> py3k-struni (ditto)

3. submit this patch to the trunk

4. merge trunk -> p3yk (I fear this will require lots of conflict
resolutions)

5. merge p3yk -> py3k-struni (I expect some but not many conflicts)

I hope you can do all these; you know most about the code so you're most
likely to be able to pull off #4 successfully.

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

Comment By: Martin v. L?wis (loewis)
Date: 2007-07-12 04:16

Message:
Logged In: YES 
user_id=21627
Originator: YES

The 2.6 version of the patch is fully backwards-compatible. It provides a
few new macros, and reformulates a lot of code to use these macros. The 3.0
version of the same macros looks different; for 2.6, these macros don't
have to be used - but I propose to use them in the core anyhow to avoid the
two code bases diverging.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-12 03:08

Message:
Logged In: YES 
user_id=6380
Originator: NO

Hm. How fully backwards compatible is the patch? As part of the Py3k
transition strategy, I've been trying to paint a picture of the transition
from 2.x to 2.6 as super-easy, because we're not changing any existing
functionality, we're just adding Py3k forward compatibility features that
are easily ignoreable. Even if only 5% of 3rd party extension modules were
to need work because of this change, that would already defeat the purpose
IMO.

OTOH I'm all for doing this in 3.0.  If the 2.6 changes are fully
compatible I have no objection in doing it there as well.

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

Comment By: Martin v. L?wis (loewis)
Date: 2007-07-11 17:43

Message:
Logged In: YES 
user_id=21627
Originator: YES

Depends on the precise procedure to follow. I have a patch that works for
2.6 (but it's not included here); should I commit that?

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-11 08:38

Message:
Logged In: YES 
user_id=6380
Originator: NO

Is this ready to be committed?

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

Comment By: Martin v. L?wis (loewis)
Date: 2007-05-23 17:55

Message:
Logged In: YES 
user_id=21627
Originator: YES

I don't think API compatibility between 2.5 and 3.0 should be a
requirement - I expect that there will be much more breakage, making such
compatibility very difficult for other reasons.

Anyway, for everything that can be done with a macro (including
HEAD_INIT), code that wants compatibility with 2.5 and earlier should do

#ifndef MACRO
#define MACRO 2.6-content of macro
#endif

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-23 01:29

Message:
Logged In: YES 
user_id=33168
Originator: NO

I like this patch would like it to be applied to 2.6.  However, I'm
concerned about extension modules maintaining compatibility for 2.5 and
3.0.  What would that look like (ie, an extension module that can compile
with both versions)?  How would the modules need to be changed to support
both versions?  For Py_{Type,Refcnt,Size}, it looks pretty straightforward
to define the macros in 2.x and things should work fine.  But I'm not sure
about the HEAD_INIT macros.

Martin, did you try disabling the -fno-strict-aliasing with this patch to
see if there were any warnings?

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

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

From noreply at sourceforge.net  Sat Jul 21 20:52:16 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 21 Jul 2007 11:52:16 -0700
Subject: [Patches] [ python-Patches-1718153 ] PEP 3123 implementation
Message-ID: <E1ICK3s-0005Wp-KN@sc8-sf-web24.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 3000
>Status: Closed
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Martin v. L?wis (loewis)
Assigned to: Martin v. L?wis (loewis)
Summary: PEP 3123 implementation

Initial Comment:
This patch implements the changes need for PEP 3123, in Py3k. Rather than checking this into the 3k branch, a backport of those bulk of the patch to 2.6 should be made, omitting the actual changes to PyObject_HEAD

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

>Comment By: Martin v. L?wis (loewis)
Date: 2007-07-21 20:52

Message:
Logged In: YES 
user_id=21627
Originator: YES

Ok, I merged the 3k branch to struni in 56483, and then fixed the
resulting breakage in 56484.

So I think this PEP is done.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-21 17:05

Message:
Logged In: YES 
user_id=6380
Originator: NO

If the only conflict left is on '.', I've always gotten away with just
saying "svn resolved ." -- I have no idea why it does that but it seems
innocuous.  Generally you also need to do another svn up (which typically
doesn't do anything) before the submit passes.

Thanks for getting this in!

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

Comment By: Martin v. L?wis (loewis)
Date: 2007-07-21 11:06

Message:
Logged In: YES 
user_id=21627
Originator: YES

I found that steps 1 and 2 where not necessary, since you already had done

merging before I started. I then did 3 and 4, with these commits:

r56476: 2.6 changes
r56477: merged to 3k
r56478: change struct inheritance
r56479, 56480: fix strict-aliasing bugs related to True/False; many more
remain

Now I'm stuck; trying to do "merge -S p3yk" in the py3k-struni branch
gives me
a conflict on ".", and dir_conflicts.prej says

Trying to change property 'svnmerge-integrated' from
'/python/trunk:1-56465' to '/python/trunk:1-56476',
but property already exists with value '/python/branches/p3yk:1-56466
/python/trunk:1-54987'

I don't know how to fix this.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-12 10:26

Message:
Logged In: YES 
user_id=6380
Originator: NO

OK, sounds like this is fully compatible with 2.5.  So we will have two
compatibility ranges: [2.5, 2.6] and [2.6, 3.0] (but these use different
code variants).

To submit it, I propose the following procedure:

1. merge trunk -> p3yk (this should be easy as we've done this regularly
and recently)

2. merge p3yk -> py3k-struni (ditto)

3. submit this patch to the trunk

4. merge trunk -> p3yk (I fear this will require lots of conflict
resolutions)

5. merge p3yk -> py3k-struni (I expect some but not many conflicts)

I hope you can do all these; you know most about the code so you're most
likely to be able to pull off #4 successfully.

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

Comment By: Martin v. L?wis (loewis)
Date: 2007-07-12 10:16

Message:
Logged In: YES 
user_id=21627
Originator: YES

The 2.6 version of the patch is fully backwards-compatible. It provides a
few new macros, and reformulates a lot of code to use these macros. The 3.0
version of the same macros looks different; for 2.6, these macros don't
have to be used - but I propose to use them in the core anyhow to avoid the
two code bases diverging.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-12 09:08

Message:
Logged In: YES 
user_id=6380
Originator: NO

Hm. How fully backwards compatible is the patch? As part of the Py3k
transition strategy, I've been trying to paint a picture of the transition
from 2.x to 2.6 as super-easy, because we're not changing any existing
functionality, we're just adding Py3k forward compatibility features that
are easily ignoreable. Even if only 5% of 3rd party extension modules were
to need work because of this change, that would already defeat the purpose
IMO.

OTOH I'm all for doing this in 3.0.  If the 2.6 changes are fully
compatible I have no objection in doing it there as well.

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

Comment By: Martin v. L?wis (loewis)
Date: 2007-07-11 23:43

Message:
Logged In: YES 
user_id=21627
Originator: YES

Depends on the precise procedure to follow. I have a patch that works for
2.6 (but it's not included here); should I commit that?

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-11 14:38

Message:
Logged In: YES 
user_id=6380
Originator: NO

Is this ready to be committed?

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

Comment By: Martin v. L?wis (loewis)
Date: 2007-05-23 23:55

Message:
Logged In: YES 
user_id=21627
Originator: YES

I don't think API compatibility between 2.5 and 3.0 should be a
requirement - I expect that there will be much more breakage, making such
compatibility very difficult for other reasons.

Anyway, for everything that can be done with a macro (including
HEAD_INIT), code that wants compatibility with 2.5 and earlier should do

#ifndef MACRO
#define MACRO 2.6-content of macro
#endif

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-23 07:29

Message:
Logged In: YES 
user_id=33168
Originator: NO

I like this patch would like it to be applied to 2.6.  However, I'm
concerned about extension modules maintaining compatibility for 2.5 and
3.0.  What would that look like (ie, an extension module that can compile
with both versions)?  How would the modules need to be changed to support
both versions?  For Py_{Type,Refcnt,Size}, it looks pretty straightforward
to define the macros in 2.x and things should work fine.  But I'm not sure
about the HEAD_INIT macros.

Martin, did you try disabling the -fno-strict-aliasing with this patch to
see if there were any warnings?

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

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

From noreply at sourceforge.net  Sun Jul 22 15:57:18 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 22 Jul 2007 06:57:18 -0700
Subject: [Patches] [ python-Patches-1717170 ] "Really  print?" Dialog
Message-ID: <E1ICbvy-0001IV-47@sc8-sf-web23.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: None
Status: Open
Resolution: None
Priority: 3
Private: No
Submitted By: Tal Einat (taleinat)
Assigned to: Nobody/Anonymous (nobody)
Summary: "Really  print?" Dialog

Initial Comment:
Currently, hitting the keyboard shortcut for the Print command sends whatever is in the current window to be printed. This happens by accident often enough to be a significant annoyance.

This simple patch to IOBinding.py makes the print command pop up a simple yes/no dialog which asks "Are you sure you want to print the window's contents?".

Some colleagues and I have been using this for several months to our satisfaction. It has saved me from printing by accident 3 times already.

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

>Comment By: Tal Einat (taleinat)
Date: 2007-07-22 16:57

Message:
Logged In: YES 
user_id=1330769
Originator: YES

Uploaded updated patch, with extremely minor fix: use tkMessageBox.YES
instead of "yes" when checking the dialog's result.

On a different note, this is a very simple and minor patch, but will be
very helpful to all users. Please give it a quick look...
File Added: IDLE_PrintDialog.070722.patch

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

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

From noreply at sourceforge.net  Sun Jul 22 23:17:42 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 22 Jul 2007 14:17:42 -0700
Subject: [Patches] [ python-Patches-1758570 ] struni: Fix test_macostools
Message-ID: <E1ICioA-0001Na-5d@sc8-sf-web22.sourceforge.net>

Patches item #1758570, was opened at 2007-07-22 21:17
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=1758570&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jeffrey Yasskin (jyasskin)
Assigned to: Jack Jansen (jackjansen)
Summary: struni: Fix test_macostools

Initial Comment:
I made Carbon.File.pathname return unicode, by analogy with macpath.abspath. There could easily be other bugs of the same sort in this file. The uses of PyString_FromString*() in particular look sketchy.

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

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

From noreply at sourceforge.net  Mon Jul 23 18:23:54 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 23 Jul 2007 09:23:54 -0700
Subject: [Patches] [ python-Patches-1759016 ] pyexpat unit tests - str/uni
	branch
Message-ID: <E1ID0hO-0006DH-8D@sc8-sf-web22.sourceforge.net>

Patches item #1759016, was opened at 2007-07-23 16:23
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=1759016&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Tests
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Joe Gregorio (jcgregorio)
Assigned to: Nobody/Anonymous (nobody)
Summary: pyexpat unit tests - str/uni branch

Initial Comment:
Fixes to module and unit tests so that unit tests pass.
Changes:

1. Removed "returns_unicode" attribute, associated code
   in the module to support that attribute, and all tests
   associated with it.
2. Parsed data is now returned as unicode strings.
3. Changed input tests to use io.BytesIO instead
   of StringIO, to reflect the byte processing
   nature of expat.


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

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

From noreply at sourceforge.net  Mon Jul 23 18:35:04 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 23 Jul 2007 09:35:04 -0700
Subject: [Patches] [ python-Patches-1759016 ] pyexpat unit tests - str/uni
	branch
Message-ID: <E1ID0sC-0007Z2-OO@sc8-sf-web22.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Tests
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Joe Gregorio (jcgregorio)
Assigned to: Nobody/Anonymous (nobody)
Summary: pyexpat unit tests - str/uni branch

Initial Comment:
Fixes to module and unit tests so that unit tests pass.
Changes:

1. Removed "returns_unicode" attribute, associated code
   in the module to support that attribute, and all tests
   associated with it.
2. Parsed data is now returned as unicode strings.
3. Changed input tests to use io.BytesIO instead
   of StringIO, to reflect the byte processing
   nature of expat.


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

>Comment By: Joe Gregorio (jcgregorio)
Date: 2007-07-23 16:35

Message:
Logged In: YES 
user_id=81604
Originator: YES

Discussion of only processing bytes:

  http://mail.python.org/pipermail/python-3000/2007-July/008861.html

Discussion of removing 'returns_unicode':

  http://mail.python.org/pipermail/python-3000/2007-July/008895.html

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

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

From noreply at sourceforge.net  Mon Jul 23 19:00:19 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 23 Jul 2007 10:00:19 -0700
Subject: [Patches] [ python-Patches-1759016 ] pyexpat unit tests - str/uni
	branch
Message-ID: <E1ID1Gd-0008Pe-99@sc8-sf-web21.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Tests
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Joe Gregorio (jcgregorio)
Assigned to: Nobody/Anonymous (nobody)
Summary: pyexpat unit tests - str/uni branch

Initial Comment:
Fixes to module and unit tests so that unit tests pass.
Changes:

1. Removed "returns_unicode" attribute, associated code
   in the module to support that attribute, and all tests
   associated with it.
2. Parsed data is now returned as unicode strings.
3. Changed input tests to use io.BytesIO instead
   of StringIO, to reflect the byte processing
   nature of expat.


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-23 13:00

Message:
Logged In: YES 
user_id=6380
Originator: NO

When trying to apply the patch I get:

Hunk #14 FAILED at 878.
1 out of 21 hunks FAILED -- saving rejects to file Modules/pyexpat.c.rej

Can you svn up, fix the patch, and upload it again?

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

Comment By: Joe Gregorio (jcgregorio)
Date: 2007-07-23 12:35

Message:
Logged In: YES 
user_id=81604
Originator: YES

Discussion of only processing bytes:

  http://mail.python.org/pipermail/python-3000/2007-July/008861.html

Discussion of removing 'returns_unicode':

  http://mail.python.org/pipermail/python-3000/2007-July/008895.html

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

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

From noreply at sourceforge.net  Mon Jul 23 19:08:46 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 23 Jul 2007 10:08:46 -0700
Subject: [Patches] [ python-Patches-1758570 ] struni: Fix test_macostools
Message-ID: <E1ID1Oo-0005LJ-2J@sc8-sf-web24.sourceforge.net>

Patches item #1758570, was opened at 2007-07-22 17:17
Message generated for change (Settings changed) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1758570&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: Python 3000
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Jeffrey Yasskin (jyasskin)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: struni: Fix test_macostools

Initial Comment:
I made Carbon.File.pathname return unicode, by analogy with macpath.abspath. There could easily be other bugs of the same sort in this file. The uses of PyString_FromString*() in particular look sketchy.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-23 13:08

Message:
Logged In: YES 
user_id=6380
Originator: NO

Committed revision 56510.


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

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

From noreply at sourceforge.net  Mon Jul 23 19:10:38 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 23 Jul 2007 10:10:38 -0700
Subject: [Patches] [ python-Patches-1757683 ] Add support for
	seeking/writing beyond EOF to io.BytesIO
Message-ID: <E1ID1Qc-0005ZV-SF@sc8-sf-web24.sourceforge.net>

Patches item #1757683, was opened at 2007-07-20 13:10
Message generated for change (Settings changed) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1757683&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 3000
>Status: Closed
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Alexandre Vassalotti (avassalotti)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add support for seeking/writing beyond EOF to io.BytesIO

Initial Comment:
The patch makes BytesIO inserts null bytes between the current EOF and the new write position.

See discussion on the Python-3000 mailing list:
http://mail.python.org/pipermail/python-3000/2007-June/008592.html

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

Comment By: Alexandre Vassalotti (avassalotti)
Date: 2007-07-20 20:52

Message:
Logged In: YES 
user_id=1826340
Originator: YES

I already have one in my unittests for BytesIO/StringIO in my branch.

 
http://svn.python.org/view/python/branches/cpy_merge/Lib/test/test_memoryio.py?rev=56445&view=markup

It is called test_overseek and it is in the PyBytesIOTest class.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-20 20:25

Message:
Logged In: YES 
user_id=6380
Originator: NO

Committed revision 56475.

Would you mind adding a unit test for this?

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

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

From noreply at sourceforge.net  Mon Jul 23 19:21:21 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 23 Jul 2007 10:21:21 -0700
Subject: [Patches] [ python-Patches-1759016 ] pyexpat unit tests - str/uni
	branch
Message-ID: <E1ID1az-0001JZ-1E@sc8-sf-web24.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Tests
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Joe Gregorio (jcgregorio)
Assigned to: Nobody/Anonymous (nobody)
Summary: pyexpat unit tests - str/uni branch

Initial Comment:
Fixes to module and unit tests so that unit tests pass.
Changes:

1. Removed "returns_unicode" attribute, associated code
   in the module to support that attribute, and all tests
   associated with it.
2. Parsed data is now returned as unicode strings.
3. Changed input tests to use io.BytesIO instead
   of StringIO, to reflect the byte processing
   nature of expat.


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

>Comment By: Joe Gregorio (jcgregorio)
Date: 2007-07-23 17:21

Message:
Logged In: YES 
user_id=81604
Originator: YES

Sorry about that.

Here is a new patch after updating to the latest svn.

This one also contains the updates to the Docs. Let me
know if you want me to drop that from the patch.
File Added: pyexpat.2.diff

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-23 17:00

Message:
Logged In: YES 
user_id=6380
Originator: NO

When trying to apply the patch I get:

Hunk #14 FAILED at 878.
1 out of 21 hunks FAILED -- saving rejects to file Modules/pyexpat.c.rej

Can you svn up, fix the patch, and upload it again?

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

Comment By: Joe Gregorio (jcgregorio)
Date: 2007-07-23 16:35

Message:
Logged In: YES 
user_id=81604
Originator: YES

Discussion of only processing bytes:

  http://mail.python.org/pipermail/python-3000/2007-July/008861.html

Discussion of removing 'returns_unicode':

  http://mail.python.org/pipermail/python-3000/2007-July/008895.html

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

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

From noreply at sourceforge.net  Mon Jul 23 19:42:42 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 23 Jul 2007 10:42:42 -0700
Subject: [Patches] [ python-Patches-1759016 ] pyexpat unit tests - str/uni
	branch
Message-ID: <E1ID1ve-0003hw-IK@sc8-sf-web24.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Tests
Group: Python 3000
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Joe Gregorio (jcgregorio)
Assigned to: Nobody/Anonymous (nobody)
Summary: pyexpat unit tests - str/uni branch

Initial Comment:
Fixes to module and unit tests so that unit tests pass.
Changes:

1. Removed "returns_unicode" attribute, associated code
   in the module to support that attribute, and all tests
   associated with it.
2. Parsed data is now returned as unicode strings.
3. Changed input tests to use io.BytesIO instead
   of StringIO, to reflect the byte processing
   nature of expat.


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-23 13:42

Message:
Logged In: YES 
user_id=6380
Originator: NO

Committed revision 56512.


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

Comment By: Joe Gregorio (jcgregorio)
Date: 2007-07-23 13:21

Message:
Logged In: YES 
user_id=81604
Originator: YES

Sorry about that.

Here is a new patch after updating to the latest svn.

This one also contains the updates to the Docs. Let me
know if you want me to drop that from the patch.
File Added: pyexpat.2.diff

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-23 13:00

Message:
Logged In: YES 
user_id=6380
Originator: NO

When trying to apply the patch I get:

Hunk #14 FAILED at 878.
1 out of 21 hunks FAILED -- saving rejects to file Modules/pyexpat.c.rej

Can you svn up, fix the patch, and upload it again?

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

Comment By: Joe Gregorio (jcgregorio)
Date: 2007-07-23 12:35

Message:
Logged In: YES 
user_id=81604
Originator: YES

Discussion of only processing bytes:

  http://mail.python.org/pipermail/python-3000/2007-July/008861.html

Discussion of removing 'returns_unicode':

  http://mail.python.org/pipermail/python-3000/2007-July/008895.html

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

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

From noreply at sourceforge.net  Mon Jul 23 22:24:10 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 23 Jul 2007 13:24:10 -0700
Subject: [Patches] [ python-Patches-1759169 ] clean up Solaris port and
	allow C99 extension modules
Message-ID: <E1ID4Ru-000385-1f@sc8-sf-web23.sourceforge.net>

Patches item #1759169, was opened at 2007-07-23 20:24
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=1759169&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Zooko O'Whielacronx (zooko)
Assigned to: Nobody/Anonymous (nobody)
Summary: clean up Solaris port and allow C99 extension modules

Initial Comment:
I wanted to build a Python extension module written in C99, but Solaris's headers ("sys/feature_test.h") declare that you can't have an XPG 4.2 application using C99.

Investigating led me eventually to Solaris hacker John Levon, who kindly pointed out to me that in the Sun-maintained port of Python, they use a perl script to strip out _XOPEN_SOURCE, _XOPEN_SOURCE_EXTENDED, and _POSIX_SOURCE from pyconfig.h:

http://src.opensolaris.org/source/xref/jds/spec-files/trunk/SUNWPython.spec

(See lines 123-125.)

The attached patch accomplishes the same goal more cleanly by changing the contents of configure.in.  With this patch, I can now build python trunk and release25-maint and also build a C99 extension module:

http://cheeseshop.python.org/pypi/zfec

This patch might also impact "[ 1306253 ] Python 2.4.2c1 fails to build on 64-bit Solaris 10":

https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306253&group_id=5470

I think perhaps this patch should supercede the patch mentioned in "[ 1116722 ] Solaris 10 fails to compile complexobject.c [FIX incl.]":

https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1116722&group_id=5470


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

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

From noreply at sourceforge.net  Tue Jul 24 05:56:40 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 23 Jul 2007 20:56:40 -0700
Subject: [Patches] [ python-Patches-1755841 ] Patch for [ 735515 ] urllib2
	should cache 301 redir
Message-ID: <E1IDBVo-0001Yu-Tn@sc8-sf-web23.sourceforge.net>

Patches item #1755841, was opened at 2007-07-18 08:02
Message generated for change (Comment added) made by orsenthil
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1755841&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: O.R.Senthil Kumaran (orsenthil)
Assigned to: Nobody/Anonymous (nobody)
Summary: Patch for [ 735515 ] urllib2 should cache 301 redir

Initial Comment:
Tracker item python.org/sf/735515 mentions about urllib2 to cache 301 redirections.
Attached patch tries to implement the same.

Comments on Version 1 of patch:
a) Initializes a dictionary to store the redirection.
b) If req already in cache, return the previous Request object.
c) Otherwise handle the same as 302 and store the Request object.
d) Checks for loop errors in 301.

Just noticed, that it I missed max-redirect checks.
Please comment on this patch, with next version I shall add the max redirect check.



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

>Comment By: O.R.Senthil Kumaran (orsenthil)
Date: 2007-07-24 09:26

Message:
Logged In: YES 
user_id=942711
Originator: YES

I have made some changes to patch. Made it use just the self.cache to
cache and follow the same logic for redirect and loop as 302 would follow.
I thought this is ok. Did a basic testing to verify if it caught 301
redirect, yes it does.

File Added: urllib2-cache-301.patch

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

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

From noreply at sourceforge.net  Tue Jul 24 23:22:03 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 24 Jul 2007 14:22:03 -0700
Subject: [Patches] [ python-Patches-1759922 ] struni pulldom: Don't use
	'types' to check strings
Message-ID: <E1IDRpT-0004Tn-Fa@sc8-sf-web22.sourceforge.net>

Patches item #1759922, was opened at 2007-07-24 17: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=1759922&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alexandre Vassalotti (avassalotti)
Assigned to: Nobody/Anonymous (nobody)
Summary: struni pulldom: Don't use 'types' to check strings

Initial Comment:
This patch removes the use of the types module for checking if an object is a string. This fix some of the unit tests in minidom.py but not all.    

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

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

From noreply at sourceforge.net  Wed Jul 25 00:02:46 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 24 Jul 2007 15:02:46 -0700
Subject: [Patches] [ python-Patches-1759169 ] clean up Solaris port and
	allow C99 extension modules
Message-ID: <E1IDSSs-0006gu-5K@sc8-sf-web24.sourceforge.net>

Patches item #1759169, was opened at 2007-07-23 20:24
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1759169&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Zooko O'Whielacronx (zooko)
>Assigned to: Martin v. L?wis (loewis)
Summary: clean up Solaris port and allow C99 extension modules

Initial Comment:
I wanted to build a Python extension module written in C99, but Solaris's headers ("sys/feature_test.h") declare that you can't have an XPG 4.2 application using C99.

Investigating led me eventually to Solaris hacker John Levon, who kindly pointed out to me that in the Sun-maintained port of Python, they use a perl script to strip out _XOPEN_SOURCE, _XOPEN_SOURCE_EXTENDED, and _POSIX_SOURCE from pyconfig.h:

http://src.opensolaris.org/source/xref/jds/spec-files/trunk/SUNWPython.spec

(See lines 123-125.)

The attached patch accomplishes the same goal more cleanly by changing the contents of configure.in.  With this patch, I can now build python trunk and release25-maint and also build a C99 extension module:

http://cheeseshop.python.org/pypi/zfec

This patch might also impact "[ 1306253 ] Python 2.4.2c1 fails to build on 64-bit Solaris 10":

https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306253&group_id=5470

I think perhaps this patch should supercede the patch mentioned in "[ 1116722 ] Solaris 10 fails to compile complexobject.c [FIX incl.]":

https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1116722&group_id=5470


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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-07-24 22:02

Message:
Logged In: YES 
user_id=849994
Originator: NO

Looks like a patch for you, Martin...

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

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

From noreply at sourceforge.net  Wed Jul 25 08:09:40 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 24 Jul 2007 23:09:40 -0700
Subject: [Patches] [ python-Patches-1760089 ] Cross Compiling Python
Message-ID: <E1IDa44-0006zp-N0@sc8-sf-web24.sourceforge.net>

Patches item #1760089, was opened at 2007-07-25 06:09
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=1760089&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Yegnesh (yegnesh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cross Compiling Python

Initial Comment:
Hi,

I am cross compiling python 2.4 for powerpc-860.
Steps I followed are :
$ patch -p3 < ./python-patch
$ ./configure --host=powerpc-860-linux-gnu --build=i686-pc-linux-gnu
$ make

Error found is listed below:

ar cr libpython2.4.a Modules/config.o Modules/getpath.o Modules/main.o Modules/gcmodule.o
ar: Modules/config.o: No such file or directory
make[1]: *** [libpython2.4.a] Error 1

Though the file is existing in the directory listing.
Can you suggest any reason why this error occurs?

Thanks in advance,
Yegnesh


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

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

From noreply at sourceforge.net  Wed Jul 25 08:19:20 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 24 Jul 2007 23:19:20 -0700
Subject: [Patches] [ python-Patches-1760089 ] Cross Compiling Python
Message-ID: <E1IDaDQ-00087C-Iw@sc8-sf-web24.sourceforge.net>

Patches item #1760089, was opened at 2007-07-25 06:09
Message generated for change (Settings changed) made by yegnesh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1760089&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 2.4
Status: Open
Resolution: None
>Priority: 9
Private: No
Submitted By: Yegnesh (yegnesh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cross Compiling Python

Initial Comment:
Hi,

I am cross compiling python 2.4 for powerpc-860.
Steps I followed are :
$ patch -p3 < ./python-patch
$ ./configure --host=powerpc-860-linux-gnu --build=i686-pc-linux-gnu
$ make

Error found is listed below:

ar cr libpython2.4.a Modules/config.o Modules/getpath.o Modules/main.o Modules/gcmodule.o
ar: Modules/config.o: No such file or directory
make[1]: *** [libpython2.4.a] Error 1

Though the file is existing in the directory listing.
Can you suggest any reason why this error occurs?

Thanks in advance,
Yegnesh


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

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

From noreply at sourceforge.net  Wed Jul 25 08:20:01 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 24 Jul 2007 23:20:01 -0700
Subject: [Patches] [ python-Patches-1760089 ] Cross Compiling Python
Message-ID: <E1IDaE5-00089z-Uj@sc8-sf-web24.sourceforge.net>

Patches item #1760089, was opened at 2007-07-25 06:09
Message generated for change (Settings changed) made by yegnesh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1760089&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 2.4
Status: Open
Resolution: None
>Priority: 5
Private: No
Submitted By: Yegnesh (yegnesh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cross Compiling Python

Initial Comment:
Hi,

I am cross compiling python 2.4 for powerpc-860.
Steps I followed are :
$ patch -p3 < ./python-patch
$ ./configure --host=powerpc-860-linux-gnu --build=i686-pc-linux-gnu
$ make

Error found is listed below:

ar cr libpython2.4.a Modules/config.o Modules/getpath.o Modules/main.o Modules/gcmodule.o
ar: Modules/config.o: No such file or directory
make[1]: *** [libpython2.4.a] Error 1

Though the file is existing in the directory listing.
Can you suggest any reason why this error occurs?

Thanks in advance,
Yegnesh


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

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

From noreply at sourceforge.net  Wed Jul 25 16:54:52 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 25 Jul 2007 07:54:52 -0700
Subject: [Patches] [ python-Patches-1760357 ] ZipFile.write fails with bad
	modification time
Message-ID: <E1IDiGK-0002SC-2k@sc8-sf-web22.sourceforge.net>

Patches item #1760357, was opened at 2007-07-25 16:54
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=1760357&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Grzegorz Adam Hankiewicz (gradha)
Assigned to: Nobody/Anonymous (nobody)
Summary: ZipFile.write fails with bad modification time

Initial Comment:
Running on Windows XP against a networked file server with Windows 2003 I have a file which due to some obscure reason it has a negative modification time as returned by Python os functions. When I look at the file in the explorer the modification time column is blank, and when I view the properties of the file there the modification time is set to the 25th of April of 1906 at 2:03:44.

If I try to zip this file the zip creation fails with a Value error when the file's st_mtime value is passed to time.localtime().

I'm attaching a debug session log along with a possible patch to avoid such problems, though maybe the function that returns st_mtime should never return negative values because other library functions expect zero or positive values too.

In the log you will see that it is a custom rastertech\zipfile.py file that is failing. This is just the SVN development version of zipfile along with some modifications since changes like 1739648 seem to be very low priority. The patch is generated against a clean SVN version.

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

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

From noreply at sourceforge.net  Wed Jul 25 16:56:07 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 25 Jul 2007 07:56:07 -0700
Subject: [Patches] [ python-Patches-1760357 ] ZipFile.write fails with bad
	modification time
Message-ID: <E1IDiHX-0002ap-1m@sc8-sf-web24.sourceforge.net>

Patches item #1760357, was opened at 2007-07-25 16:54
Message generated for change (Comment added) made by gradha
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1760357&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Grzegorz Adam Hankiewicz (gradha)
Assigned to: Nobody/Anonymous (nobody)
Summary: ZipFile.write fails with bad modification time

Initial Comment:
Running on Windows XP against a networked file server with Windows 2003 I have a file which due to some obscure reason it has a negative modification time as returned by Python os functions. When I look at the file in the explorer the modification time column is blank, and when I view the properties of the file there the modification time is set to the 25th of April of 1906 at 2:03:44.

If I try to zip this file the zip creation fails with a Value error when the file's st_mtime value is passed to time.localtime().

I'm attaching a debug session log along with a possible patch to avoid such problems, though maybe the function that returns st_mtime should never return negative values because other library functions expect zero or positive values too.

In the log you will see that it is a custom rastertech\zipfile.py file that is failing. This is just the SVN development version of zipfile along with some modifications since changes like 1739648 seem to be very low priority. The patch is generated against a clean SVN version.

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

>Comment By: Grzegorz Adam Hankiewicz (gradha)
Date: 2007-07-25 16:56

Message:
Logged In: YES 
user_id=153159
Originator: YES

File Added: ignore_negative_modification_time.txt

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

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

From noreply at sourceforge.net  Thu Jul 26 16:38:36 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 26 Jul 2007 07:38:36 -0700
Subject: [Patches] [ python-Patches-1755841 ] Patch for [ 735515 ] urllib2
	should cache 301 redir
Message-ID: <E1IE4U8-0001ke-4s@sc8-sf-web24.sourceforge.net>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: O.R.Senthil Kumaran (orsenthil)
Assigned to: Nobody/Anonymous (nobody)
Summary: Patch for [ 735515 ] urllib2 should cache 301 redir

Initial Comment:
Tracker item python.org/sf/735515 mentions about urllib2 to cache 301 redirections.
Attached patch tries to implement the same.

Comments on Version 1 of patch:
a) Initializes a dictionary to store the redirection.
b) If req already in cache, return the previous Request object.
c) Otherwise handle the same as 302 and store the Request object.
d) Checks for loop errors in 301.

Just noticed, that it I missed max-redirect checks.
Please comment on this patch, with next version I shall add the max redirect check.



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

>Comment By: Skip Montanaro (montanaro)
Date: 2007-07-26 09:38

Message:
Logged In: YES 
user_id=44345
Originator: NO

Looks reasonable to me, however I wonder if you shouldn't purge cached
information periodically.  Does RFC 2616 provide any guidance?

Skip


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

Comment By: O.R.Senthil Kumaran (orsenthil)
Date: 2007-07-23 22:56

Message:
Logged In: YES 
user_id=942711
Originator: YES

I have made some changes to patch. Made it use just the self.cache to
cache and follow the same logic for redirect and loop as 302 would follow.
I thought this is ok. Did a basic testing to verify if it caught 301
redirect, yes it does.

File Added: urllib2-cache-301.patch

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

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

From cbv at scican.net  Thu Jul 26 19:09:37 2007
From: cbv at scican.net (Henry Burris)
Date: Thu, 26 Jul 2007 10:09:37 -0700
Subject: [Patches] (no subject)
Message-ID: <46A8D551.1080307@chw.edu>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: Publication.pdf
Type: application/pdf
Size: 19369 bytes
Desc: not available
Url : http://mail.python.org/pipermail/patches/attachments/20070726/e2ece36b/attachment-0001.pdf 

From noreply at sourceforge.net  Thu Jul 26 20:37:06 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 26 Jul 2007 11:37:06 -0700
Subject: [Patches] [ python-Patches-1761465 ] struni: Fix test_aepack by
	converting 4cc's to bytes
Message-ID: <E1IE8Cw-00008D-2m@sc8-sf-web24.sourceforge.net>

Patches item #1761465, was opened at 2007-07-26 18:37
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=1761465&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jeffrey Yasskin (jyasskin)
Assigned to: Jack Jansen (jackjansen)
Summary: struni: Fix test_aepack by converting 4cc's to bytes

Initial Comment:
Also includes a simple fix for test_applesingle.

The core of this fix is to change Python/mactoolboxglue.c:PyMac_BuildOSType(OSType) to return a bytes object instead of a str8, and then to go through the python code and change the four-character-codes to bytes. This hits a snag when they're used as dictionary keys, since bytes isn't hashable, so a hacky little b2i() function converts them to ints first. b2i() should go away when someone writes the general bytes/int conversion api.

This is discussed some at http://mail.python.org/pipermail/python-3000/2007-July/008935.html. If Talin's and Ronald's preference from that thread is taken, then PyMac_BuildOSType should return their new type instead.

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

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

From kdjds at pontii.net  Fri Jul 27 02:34:14 2007
From: kdjds at pontii.net (Lily)
Date: Thu, 26 Jul 2007 20:34:14 -0400
Subject: [Patches] (no subject)
Message-ID: <46A93D86.2060307@attglobal.net>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: bill.pdf
Type: application/pdf
Size: 4760 bytes
Desc: not available
Url : http://mail.python.org/pipermail/patches/attachments/20070726/4417b14f/attachment.pdf 

From noreply at sourceforge.net  Fri Jul 27 06:42:30 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 26 Jul 2007 21:42:30 -0700
Subject: [Patches] [ python-Patches-1761465 ] struni: Fix test_aepack by
	converting 4cc's to bytes
Message-ID: <E1IEHeo-0007KH-3p@sc8-sf-web21.sourceforge.net>

Patches item #1761465, was opened at 2007-07-26 14:37
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1761465&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: Python 3000
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Jeffrey Yasskin (jyasskin)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: struni: Fix test_aepack by converting 4cc's to bytes

Initial Comment:
Also includes a simple fix for test_applesingle.

The core of this fix is to change Python/mactoolboxglue.c:PyMac_BuildOSType(OSType) to return a bytes object instead of a str8, and then to go through the python code and change the four-character-codes to bytes. This hits a snag when they're used as dictionary keys, since bytes isn't hashable, so a hacky little b2i() function converts them to ints first. b2i() should go away when someone writes the general bytes/int conversion api.

This is discussed some at http://mail.python.org/pipermail/python-3000/2007-July/008935.html. If Talin's and Ronald's preference from that thread is taken, then PyMac_BuildOSType should return their new type instead.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-27 00:42

Message:
Logged In: YES 
user_id=6380
Originator: NO

Committed revision 56560.

(Except I changed the open mode from the unconventional 'bw' to 'wb'. :-)

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

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

From noreply at sourceforge.net  Fri Jul 27 07:18:24 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 26 Jul 2007 22:18:24 -0700
Subject: [Patches] [ python-Patches-1757839 ] struni: make test_mailbox and
	test_old_mailbox pass
Message-ID: <E1IEIDY-0002wa-Fo@sc8-sf-web21.sourceforge.net>

Patches item #1757839, was opened at 2007-07-20 18:45
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1757839&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 3000
Status: Closed
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Alexandre Vassalotti (avassalotti)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: struni: make test_mailbox and test_old_mailbox pass

Initial Comment:
This patch make reads to a file return a string of the str type. This required to change the mode of certain call to open() to non-binary. I have no idea if this will cause problem, but at least the tests pass. If someone wants to keep opening these file in binary mode, then he will have to create a "proxy" class, like _ProxyFile in mailbox.py but with writing support, since file opened in binary mode always return string of the bytes type. Another solution would be to wrap every read() and readline() calls, on these files, with str().

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-27 01:18

Message:
Logged In: YES 
user_id=6380
Originator: NO

Applied 02_better_failure_msg.patch as well (with minor tweaks to remove
redundant trailing \ and one you missed :-).
Committed revision 56563.



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

Comment By: Alexandre Vassalotti (avassalotti)
Date: 2007-07-20 21:17

Message:
Logged In: YES 
user_id=1826340
Originator: YES

I corrected the patch. It was a small error that slipped through when I
separated to two changes to make them easier to review. (Sometime, I wish
svn had a checkpoint feature or offline commits for this...)     

File Added: 02_better_failure_msg.patch

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-20 20:21

Message:
Logged In: YES 
user_id=6380
Originator: NO

Looks like that was a bug in the second patch.  I'll ignore it for now.

The main patch is:
Committed revision 56474.


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-20 20:20

Message:
Logged In: YES 
user_id=6380
Originator: NO

Am I supposed to apply both patches one after another?

I still get two errors:

======================================================================
ERROR: test_add_and_close (__main__.TestMbox)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_mailbox.py", line 737, in test_add_and_close
    self.assertEqual(contents == open(self._path, 'r').read())
TypeError: failUnlessEqual() takes at least 3 positional arguments (2
given)

======================================================================
ERROR: test_add_and_close (__main__.TestMMDF)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_mailbox.py", line 737, in test_add_and_close
    self.assertEqual(contents == open(self._path, 'r').read())
TypeError: failUnlessEqual() takes at least 3 positional arguments (2
given)

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



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

Comment By: Alexandre Vassalotti (avassalotti)
Date: 2007-07-20 18:49

Message:
Logged In: YES 
user_id=1826340
Originator: YES

Here another patch that makes the failure message a little more
descriptive.

To apply both:

   cat 01_fix_mailbox.patch 02_better_failure_msg.patch | patch -p0

File Added: 02_better_failure_msg.patch

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1757839&group_id=5470

From noreply at sourceforge.net  Fri Jul 27 08:11:36 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 26 Jul 2007 23:11:36 -0700
Subject: [Patches] [ python-Patches-1761786 ] distutils.util.get_platform()
	return value on 64bit Windows
Message-ID: <E1IEJ32-0005N6-RL@sc8-sf-web24.sourceforge.net>

Patches item #1761786, was opened at 2007-07-27 16:11
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=1761786&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils and setup.py
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Mark Hammond (mhammond)
Assigned to: Mark Hammond (mhammond)
Summary: distutils.util.get_platform() return value on 64bit Windows

Initial Comment:
As discussed recently on distutils-sig (http://mail.python.org/pipermail/distutils-sig/2007-July/007877.html), it is desirable for get_platform() to return different values for different Windows architectures, to easily differentiate the files and directories created.  This patch arranges for either 'win-x86_64' or 'win-ia64' to be returned for the 2 64bit Windows platforms; all other platforms, including 32bit windows, are unchanged.

Patch also includes a change to bdist_msi so get_platform() is used instead of 'win32' to create the final .msi.  Note that get_platform() *is* already used for the name of the  'build' directories, so this hard-coding of win32 doesn't appear intentional.  No similar patch exists for bdist_wininst, as there is no intention to support x64 with bdist_wininst.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1761786&group_id=5470

From noreply at sourceforge.net  Fri Jul 27 08:19:37 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 26 Jul 2007 23:19:37 -0700
Subject: [Patches] [ python-Patches-1761465 ] struni: Fix test_aepack by
	converting 4cc's to bytes
Message-ID: <E1IEJAn-00052n-0X@sc8-sf-web22.sourceforge.net>

Patches item #1761465, was opened at 2007-07-26 18:37
Message generated for change (Comment added) made by jyasskin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1761465&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: Python 3000
Status: Closed
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Jeffrey Yasskin (jyasskin)
Assigned to: Guido van Rossum (gvanrossum)
Summary: struni: Fix test_aepack by converting 4cc's to bytes

Initial Comment:
Also includes a simple fix for test_applesingle.

The core of this fix is to change Python/mactoolboxglue.c:PyMac_BuildOSType(OSType) to return a bytes object instead of a str8, and then to go through the python code and change the four-character-codes to bytes. This hits a snag when they're used as dictionary keys, since bytes isn't hashable, so a hacky little b2i() function converts them to ints first. b2i() should go away when someone writes the general bytes/int conversion api.

This is discussed some at http://mail.python.org/pipermail/python-3000/2007-July/008935.html. If Talin's and Ronald's preference from that thread is taken, then PyMac_BuildOSType should return their new type instead.

----------------------------------------------------------------------

>Comment By: Jeffrey Yasskin (jyasskin)
Date: 2007-07-27 06:19

Message:
Logged In: YES 
user_id=581856
Originator: YES

But I like black'n'white files. ;)

I've attached a patch changing b2i to str for using 4CCs in dicts. Since
this file, at least, never needs to convert back, nothing's ambiguous about
it, and I do like the idea of being able to read these while debugging. The
test still passes.
File Added: aepack_b2i_to_str.diff

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-27 04:42

Message:
Logged In: YES 
user_id=6380
Originator: NO

Committed revision 56560.

(Except I changed the open mode from the unconventional 'bw' to 'wb'. :-)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1761465&group_id=5470

From noreply at sourceforge.net  Fri Jul 27 08:57:45 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 26 Jul 2007 23:57:45 -0700
Subject: [Patches] [ python-Patches-1761803 ] Some fix abount _WIN32_WINNT
Message-ID: <E1IEJlh-00086L-TV@sc8-sf-web22.sourceforge.net>

Patches item #1761803, was opened at 2007-07-27 15: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=1761803&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Hirokazu Yamamoto (ocean-city)
Assigned to: Nobody/Anonymous (nobody)
Summary: Some fix abount _WIN32_WINNT

Initial Comment:
http://mail.python.org/pipermail/python-checkins/2007-July/061251.html
Due to r56561 change, VC6 fails to compile Module/posixmodule.c, becaue Crypt API needs _WIN32_WINNT  definition. I'll atach the fix patch.

1. Fix a typo in PC/pyconfig.h.
2. Still compile fails, because Py_BUILD_CORE seems not to be defined on VC6 build system. I greped, and found that it's only defined on VC8(PCBuild8/pythoncore/pythoncore.vcproj). Maybe it's right fix to define Py_BUILD_CORE on all platforms, but I don't know the meaning of this macro, so I simply reverted r55103 change which removed local _WIN32_WINNT definition in Module/posixmodule.c.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1761803&group_id=5470

From cxp at saber.net  Fri Jul 27 13:40:28 2007
From: cxp at saber.net (Sanders Frazier)
Date: Fri, 27 Jul 2007 13:40:28 +0200
Subject: [Patches] Information
Message-ID: <46A9D9AC.7020502@fuse.net>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: Information.pdf
Type: application/pdf
Size: 23046 bytes
Desc: not available
Url : http://mail.python.org/pipermail/patches/attachments/20070727/dc745c6d/attachment-0001.pdf 

From noreply at sourceforge.net  Fri Jul 27 14:55:54 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 27 Jul 2007 05:55:54 -0700
Subject: [Patches] [ python-Patches-1761465 ] struni: Fix test_aepack by
	converting 4cc's to bytes
Message-ID: <E1IEPMI-0005NV-IY@sc8-sf-web22.sourceforge.net>

Patches item #1761465, was opened at 2007-07-26 14:37
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1761465&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: Python 3000
>Status: Open
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Jeffrey Yasskin (jyasskin)
Assigned to: Guido van Rossum (gvanrossum)
Summary: struni: Fix test_aepack by converting 4cc's to bytes

Initial Comment:
Also includes a simple fix for test_applesingle.

The core of this fix is to change Python/mactoolboxglue.c:PyMac_BuildOSType(OSType) to return a bytes object instead of a str8, and then to go through the python code and change the four-character-codes to bytes. This hits a snag when they're used as dictionary keys, since bytes isn't hashable, so a hacky little b2i() function converts them to ints first. b2i() should go away when someone writes the general bytes/int conversion api.

This is discussed some at http://mail.python.org/pipermail/python-3000/2007-July/008935.html. If Talin's and Ronald's preference from that thread is taken, then PyMac_BuildOSType should return their new type instead.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-27 08:55

Message:
Logged In: YES 
user_id=6380
Originator: NO

Hmm...  What if there's a 4CC containing a non-ASCII byte?

----------------------------------------------------------------------

Comment By: Jeffrey Yasskin (jyasskin)
Date: 2007-07-27 02:19

Message:
Logged In: YES 
user_id=581856
Originator: YES

But I like black'n'white files. ;)

I've attached a patch changing b2i to str for using 4CCs in dicts. Since
this file, at least, never needs to convert back, nothing's ambiguous about
it, and I do like the idea of being able to read these while debugging. The
test still passes.
File Added: aepack_b2i_to_str.diff

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-27 00:42

Message:
Logged In: YES 
user_id=6380
Originator: NO

Committed revision 56560.

(Except I changed the open mode from the unconventional 'bw' to 'wb'. :-)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1761465&group_id=5470

From noreply at sourceforge.net  Fri Jul 27 19:26:26 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 27 Jul 2007 10:26:26 -0700
Subject: [Patches] [ python-Patches-1759922 ] struni pulldom: Don't use
	'types' to check strings
Message-ID: <E1IETa6-000754-5u@sc8-sf-web24.sourceforge.net>

Patches item #1759922, was opened at 2007-07-24 17:22
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1759922&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 3000
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Alexandre Vassalotti (avassalotti)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: struni pulldom: Don't use 'types' to check strings

Initial Comment:
This patch removes the use of the types module for checking if an object is a string. This fix some of the unit tests in minidom.py but not all.    

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-27 13:26

Message:
Logged In: YES 
user_id=6380
Originator: NO

Committed revision 56586.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1759922&group_id=5470

From noreply at sourceforge.net  Fri Jul 27 19:26:27 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 27 Jul 2007 10:26:27 -0700
Subject: [Patches] [ python-Patches-1759922 ] struni pulldom: Don't use
	'types' to check strings
Message-ID: <E1IETa7-00069f-Si@sc8-sf-web21.sourceforge.net>

Patches item #1759922, was opened at 2007-07-24 17:22
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1759922&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 3000
Status: Closed
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Alexandre Vassalotti (avassalotti)
Assigned to: Guido van Rossum (gvanrossum)
Summary: struni pulldom: Don't use 'types' to check strings

Initial Comment:
This patch removes the use of the types module for checking if an object is a string. This fix some of the unit tests in minidom.py but not all.    

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-27 13:26

Message:
Logged In: YES 
user_id=6380
Originator: NO

Committed revision 56586.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-27 13:26

Message:
Logged In: YES 
user_id=6380
Originator: NO

Committed revision 56586.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1759922&group_id=5470

From noreply at sourceforge.net  Fri Jul 27 23:03:22 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 27 Jul 2007 14:03:22 -0700
Subject: [Patches] [ python-Patches-1762412 ] struni: test_xml_etree.py
Message-ID: <E1IEWy2-0007eh-Sl@sc8-sf-web23.sourceforge.net>

Patches item #1762412, was opened at 2007-07-27 21:03
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=1762412&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Tests
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Joe Gregorio (jcgregorio)
Assigned to: Nobody/Anonymous (nobody)
Summary: struni: test_xml_etree.py

Initial Comment:
Fixes to ElementTree.py so that the unit tests now pass on the struni branch. 

When writing to a file the output file is now opened in binary mode and the text is converted to bytes before writing. 

In several cases, like _escape_attrib, and _escape_cdata, the encoding was removed and pull out to be as close
to the write() as possible.




----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1762412&group_id=5470

From jeebf at ngc.com  Sat Jul 28 06:11:30 2007
From: jeebf at ngc.com (Archibald)
Date: Sat, 28 Jul 2007 00:11:30 -0400
Subject: [Patches] Log
Message-ID: <46AAC1F2.1020804@eganahk.com>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: Log.pdf
Type: application/pdf
Size: 12187 bytes
Desc: not available
Url : http://mail.python.org/pipermail/patches/attachments/20070728/6c815a66/attachment-0001.pdf 

From noreply at sourceforge.net  Sat Jul 28 10:41:18 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 28 Jul 2007 01:41:18 -0700
Subject: [Patches] [ python-Patches-1762561 ] unable to serialize Infinity
	or NaN on ARM using marshal
Message-ID: <E1IEhrS-0004Nz-Lc@sc8-sf-web23.sourceforge.net>

Patches item #1762561, was opened at 2007-07-28 10: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=1762561&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: unable to serialize Infinity or NaN on ARM using marshal

Initial Comment:
forwarded from http://bugs.debian.org/434905, patch by
Aurelien Jarno.

python2.5 is unable to serialize a floating point variable which equals Infinity or NaN on ARM using marshal.

The problem is that python2.5 wants to manage the floating points in memory by itself, and assume that they are only little and big endian IEEE formats. Otherwise it fallback to a generic code, which does not handle NaN or Infinity.

The attached patched fixed that by adding mixed-endian IEEE format, as it can be found on ARM old-ABI.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1762561&group_id=5470

From noreply at sourceforge.net  Sat Jul 28 13:41:08 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 28 Jul 2007 04:41:08 -0700
Subject: [Patches] [ python-Patches-1762412 ] struni: test_xml_etree.py
Message-ID: <E1IEkfU-0005S7-Ar@sc8-sf-web24.sourceforge.net>

Patches item #1762412, was opened at 2007-07-27 23:03
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1762412&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Tests
Group: Python 3000
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Joe Gregorio (jcgregorio)
Assigned to: Nobody/Anonymous (nobody)
Summary: struni: test_xml_etree.py

Initial Comment:
Fixes to ElementTree.py so that the unit tests now pass on the struni branch. 

When writing to a file the output file is now opened in binary mode and the text is converted to bytes before writing. 

In several cases, like _escape_attrib, and _escape_cdata, the encoding was removed and pull out to be as close
to the write() as possible.




----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2007-07-28 13:41

Message:
Logged In: YES 
user_id=21627
Originator: NO

Thanks for the patch. Committed as r56603

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1762412&group_id=5470

From noreply at sourceforge.net  Sat Jul 28 13:43:11 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 28 Jul 2007 04:43:11 -0700
Subject: [Patches] [ python-Patches-1761803 ] Some fix abount _WIN32_WINNT
Message-ID: <E1IEkhT-0005ft-0K@sc8-sf-web24.sourceforge.net>

Patches item #1761803, was opened at 2007-07-27 08:57
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1761803&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Hirokazu Yamamoto (ocean-city)
>Assigned to: Mark Hammond (mhammond)
Summary: Some fix abount _WIN32_WINNT

Initial Comment:
http://mail.python.org/pipermail/python-checkins/2007-July/061251.html
Due to r56561 change, VC6 fails to compile Module/posixmodule.c, becaue Crypt API needs _WIN32_WINNT  definition. I'll atach the fix patch.

1. Fix a typo in PC/pyconfig.h.
2. Still compile fails, because Py_BUILD_CORE seems not to be defined on VC6 build system. I greped, and found that it's only defined on VC8(PCBuild8/pythoncore/pythoncore.vcproj). Maybe it's right fix to define Py_BUILD_CORE on all platforms, but I don't know the meaning of this macro, so I simply reverted r55103 change which removed local _WIN32_WINNT definition in Module/posixmodule.c.



----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2007-07-28 13:43

Message:
Logged In: YES 
user_id=21627
Originator: NO

Mark, since this was your checkin: Can you take a look?

If not, please unassign.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1761803&group_id=5470

From noreply at sourceforge.net  Sun Jul 29 03:12:36 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 28 Jul 2007 18:12:36 -0700
Subject: [Patches] [ python-Patches-1762940 ] struni: test_urllib2,
	test_cookielib
Message-ID: <E1IExKm-0001MI-8G@sc8-sf-web21.sourceforge.net>

Patches item #1762940, was opened at 2007-07-29 01: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=1762940&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Tests
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Joe Gregorio (jcgregorio)
Assigned to: Nobody/Anonymous (nobody)
Summary: struni: test_urllib2, test_cookielib

Initial Comment:
This patch fixes the unit tests of both test_urllib2 and test_cookielib. The reason for combining them is that they both needed the changes to urllib.quote().

The largest part of this patch is to urllib.quote(), which would operate on unicode strings, but only so long as they didn't stray out of the ASCII range. The old code would create a dictionary with 256 entries that mapped incoming chars to their 'safe' replacements, and that dict was created once in its entirety when the function was first called and cached for later calls. Since the incoming character string is now unicode that method won't work. 

The new code does not build the dict in its entirety, instead it memoizes the ASCII range translations as it runs. It does not memoize translations outside of the ASCII range as that would be hole by which you could exhaust a programs memory.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1762940&group_id=5470

From noreply at sourceforge.net  Sun Jul 29 20:25:16 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 29 Jul 2007 11:25:16 -0700
Subject: [Patches] [ python-Patches-1762940 ] struni: test_urllib2,
	test_cookielib
Message-ID: <E1IFDS8-0006lx-Hr@sc8-sf-web22.sourceforge.net>

Patches item #1762940, was opened at 2007-07-29 01:12
Message generated for change (Comment added) made by jcgregorio
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1762940&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Tests
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Joe Gregorio (jcgregorio)
Assigned to: Nobody/Anonymous (nobody)
Summary: struni: test_urllib2, test_cookielib

Initial Comment:
This patch fixes the unit tests of both test_urllib2 and test_cookielib. The reason for combining them is that they both needed the changes to urllib.quote().

The largest part of this patch is to urllib.quote(), which would operate on unicode strings, but only so long as they didn't stray out of the ASCII range. The old code would create a dictionary with 256 entries that mapped incoming chars to their 'safe' replacements, and that dict was created once in its entirety when the function was first called and cached for later calls. Since the incoming character string is now unicode that method won't work. 

The new code does not build the dict in its entirety, instead it memoizes the ASCII range translations as it runs. It does not memoize translations outside of the ASCII range as that would be hole by which you could exhaust a programs memory.


----------------------------------------------------------------------

>Comment By: Joe Gregorio (jcgregorio)
Date: 2007-07-29 18:25

Message:
Logged In: YES 
user_id=81604
Originator: YES

This is an updated patch that simplifies the translation of characters. 

Instead of having a closure for the quoting and then wrapping it
in a Memoize instance, this patch just creates a simple
Quoter class that does the translation and caching.

File Added: urllib2-cookie-quote-2.patch

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1762940&group_id=5470

From kder at cjdiamonds.com  Sun Jul 29 21:02:58 2007
From: kder at cjdiamonds.com (Winter)
Date: Sun, 29 Jul 2007 12:02:58 -0700
Subject: [Patches] notification
Message-ID: <46ACE462.4070305@signet6.com>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: notification.pdf
Type: application/pdf
Size: 15194 bytes
Desc: not available
Url : http://mail.python.org/pipermail/patches/attachments/20070729/37443aa9/attachment.pdf 

From noreply at sourceforge.net  Mon Jul 30 02:45:50 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 29 Jul 2007 17:45:50 -0700
Subject: [Patches] [ python-Patches-1761803 ] Some fix abount _WIN32_WINNT
Message-ID: <E1IFJOQ-000175-8e@sc8-sf-web22.sourceforge.net>

Patches item #1761803, was opened at 2007-07-27 16:57
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1761803&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 2.6
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Hirokazu Yamamoto (ocean-city)
Assigned to: Mark Hammond (mhammond)
Summary: Some fix abount _WIN32_WINNT

Initial Comment:
http://mail.python.org/pipermail/python-checkins/2007-July/061251.html
Due to r56561 change, VC6 fails to compile Module/posixmodule.c, becaue Crypt API needs _WIN32_WINNT  definition. I'll atach the fix patch.

1. Fix a typo in PC/pyconfig.h.
2. Still compile fails, because Py_BUILD_CORE seems not to be defined on VC6 build system. I greped, and found that it's only defined on VC8(PCBuild8/pythoncore/pythoncore.vcproj). Maybe it's right fix to define Py_BUILD_CORE on all platforms, but I don't know the meaning of this macro, so I simply reverted r55103 change which removed local _WIN32_WINNT definition in Module/posixmodule.c.



----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2007-07-30 10:45

Message:
Logged In: YES 
user_id=14198
Originator: NO

This was my fault - Py_BUILD_CORE is defined in that same .h file - but
after my new block which tested for it.  I'd forgotten the build systems
still  define USE_DL_EXPORT instead of directly defining Py_BUILD_CORE and
I should have checked.

The error was compounded by the fact that a VC2003 build does *not*
require these definitions.  I can't see VC6 build files for the svn trunk,
so I'm unable to test that posixmodule works with that compiler - but it
*should* work, assuming my fix means that posixmodule will now see the
#define in pyconfig.h

Fixed in r56624

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-07-28 21:43

Message:
Logged In: YES 
user_id=21627
Originator: NO

Mark, since this was your checkin: Can you take a look?

If not, please unassign.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1761803&group_id=5470

From noreply at sourceforge.net  Mon Jul 30 03:48:00 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 29 Jul 2007 18:48:00 -0700
Subject: [Patches] [ python-Patches-1761803 ] Some fix abount _WIN32_WINNT
Message-ID: <E1IFKMa-0003Kg-KJ@sc8-sf-web24.sourceforge.net>

Patches item #1761803, was opened at 2007-07-27 15:57
Message generated for change (Comment added) made by ocean-city
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1761803&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 2.6
Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Hirokazu Yamamoto (ocean-city)
Assigned to: Mark Hammond (mhammond)
Summary: Some fix abount _WIN32_WINNT

Initial Comment:
http://mail.python.org/pipermail/python-checkins/2007-July/061251.html
Due to r56561 change, VC6 fails to compile Module/posixmodule.c, becaue Crypt API needs _WIN32_WINNT  definition. I'll atach the fix patch.

1. Fix a typo in PC/pyconfig.h.
2. Still compile fails, because Py_BUILD_CORE seems not to be defined on VC6 build system. I greped, and found that it's only defined on VC8(PCBuild8/pythoncore/pythoncore.vcproj). Maybe it's right fix to define Py_BUILD_CORE on all platforms, but I don't know the meaning of this macro, so I simply reverted r55103 change which removed local _WIN32_WINNT definition in Module/posixmodule.c.



----------------------------------------------------------------------

>Comment By: Hirokazu Yamamoto (ocean-city)
Date: 2007-07-30 10:48

Message:
Logged In: YES 
user_id=1200846
Originator: YES

Thank you, I confirmed your fix worked fine.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2007-07-30 09:45

Message:
Logged In: YES 
user_id=14198
Originator: NO

This was my fault - Py_BUILD_CORE is defined in that same .h file - but
after my new block which tested for it.  I'd forgotten the build systems
still  define USE_DL_EXPORT instead of directly defining Py_BUILD_CORE and
I should have checked.

The error was compounded by the fact that a VC2003 build does *not*
require these definitions.  I can't see VC6 build files for the svn trunk,
so I'm unable to test that posixmodule works with that compiler - but it
*should* work, assuming my fix means that posixmodule will now see the
#define in pyconfig.h

Fixed in r56624

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-07-28 20:43

Message:
Logged In: YES 
user_id=21627
Originator: NO

Mark, since this was your checkin: Can you take a look?

If not, please unassign.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1761803&group_id=5470

From noreply at sourceforge.net  Mon Jul 30 08:38:01 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 29 Jul 2007 23:38:01 -0700
Subject: [Patches] [ python-Patches-1763387 ] socket close fixed
Message-ID: <E1IFOtF-0001i3-19@sc8-sf-web24.sourceforge.net>

Patches item #1763387, was opened at 2007-07-29 23:38
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=1763387&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Hasan Diwan (hdiwan650)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket close fixed

Initial Comment:
Patch fixes the race condition causing tests to mysteriously fail.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1763387&group_id=5470

From noreply at sourceforge.net  Mon Jul 30 12:06:39 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 30 Jul 2007 03:06:39 -0700
Subject: [Patches] [ python-Patches-1763387 ] socket close fixed
Message-ID: <E1IFS99-0008SY-K4@sc8-sf-web24.sourceforge.net>

Patches item #1763387, was opened at 2007-07-30 02:38
Message generated for change (Comment added) made by kuran
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1763387&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Hasan Diwan (hdiwan650)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket close fixed

Initial Comment:
Patch fixes the race condition causing tests to mysteriously fail.

----------------------------------------------------------------------

Comment By: Jp Calderone (kuran)
Date: 2007-07-30 06:06

Message:
Logged In: YES 
user_id=366566
Originator: NO

SO_REUSEADDR is a flag.  It's not a period of time measured in seconds. 
So using it with time.sleep() is conceptually broken, even though it
happens to do something without raising an exception.

And socket.close() really, really, really should not sleep for any length
of time at all.  It does what it needs to do by making the low-level call,
and then it can return.  If the port shouldn't be re-used for some period
of time, that is up to the application using the socket to deal with.

Since this ticket doesn't actually explain what the test failures _are_, I
can't really suggest an alternate solution.  I assume it is something to do
with binding to ports failing, though.  In this case, the tests should just
be changed to bind port 0, which will force the platform to select an
unused port.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1763387&group_id=5470

From noreply at sourceforge.net  Mon Jul 30 15:28:27 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 30 Jul 2007 06:28:27 -0700
Subject: [Patches] [ python-Patches-1763387 ] socket close fixed
Message-ID: <E1IFVIR-0006ru-Bl@sc8-sf-web22.sourceforge.net>

Patches item #1763387, was opened at 2007-07-30 03:38
Message generated for change (Comment added) made by facundobatista
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1763387&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Private: No
Submitted By: Hasan Diwan (hdiwan650)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket close fixed

Initial Comment:
Patch fixes the race condition causing tests to mysteriously fail.

----------------------------------------------------------------------

>Comment By: Facundo Batista (facundobatista)
Date: 2007-07-30 10:28

Message:
Logged In: YES 
user_id=752496
Originator: NO

This patch

  a) does not address the problem that appeared in the tests (it should be
solved in a very different way)
  b) as kuran correctly says, is conceptually wrong (see his comment)

Regards,

----------------------------------------------------------------------

Comment By: Jp Calderone (kuran)
Date: 2007-07-30 07:06

Message:
Logged In: YES 
user_id=366566
Originator: NO

SO_REUSEADDR is a flag.  It's not a period of time measured in seconds. 
So using it with time.sleep() is conceptually broken, even though it
happens to do something without raising an exception.

And socket.close() really, really, really should not sleep for any length
of time at all.  It does what it needs to do by making the low-level call,
and then it can return.  If the port shouldn't be re-used for some period
of time, that is up to the application using the socket to deal with.

Since this ticket doesn't actually explain what the test failures _are_, I
can't really suggest an alternate solution.  I assume it is something to do
with binding to ports failing, though.  In this case, the tests should just
be changed to bind port 0, which will force the platform to select an
unused port.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1763387&group_id=5470

From noreply at sourceforge.net  Tue Jul 31 01:06:40 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 30 Jul 2007 16:06:40 -0700
Subject: [Patches] [ python-Patches-1764087 ] tiny addition to peephole
	optimizer
Message-ID: <E1IFeK0-0006NZ-Pv@sc8-sf-web22.sourceforge.net>

Patches item #1764087, was opened at 2007-07-31 02:06
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=1764087&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Paul Pogonyshev (doublep)
Assigned to: Nobody/Anonymous (nobody)
Summary: tiny addition to peephole optimizer

Initial Comment:
Tiny optimization that replaces Replace STORE_FAST x LOAD_FAST x with DUP_TOP STORE_FAST x (for the same slot x).  Targeted at quite common case:

    foo = self.foo
    if foo > 0:
        ...

No regression, seems to do what it is supposed to do on several test cases.

However, there is drawback:

    def f(x):
        y = x.y
        if y is not None:
            print y

is disassembled as follows:

  2           0 LOAD_FAST                0 (x)
              3 LOAD_ATTR                0 (y)
              6 DUP_TOP

  3           7 STORE_FAST               1 (y)
             10 LOAD_CONST               0 (None)
             13 COMPARE_OP               9 (is not)
             16 JUMP_IF_FALSE            9 (to 28)
             19 POP_TOP

  4          20 LOAD_FAST                1 (y)
             23 PRINT_ITEM
             24 PRINT_NEWLINE
             25 JUMP_FORWARD             1 (to 29)
        >>   28 POP_TOP
        >>   29 LOAD_CONST               0 (None)
             32 RETURN_VALUE

Note that STORE_FAST "migrated" to another line.  I'm not sure how important that is.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1764087&group_id=5470

From noreply at sourceforge.net  Tue Jul 31 08:58:38 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 30 Jul 2007 23:58:38 -0700
Subject: [Patches] [ python-Patches-1764087 ] tiny addition to peephole
	optimizer
Message-ID: <E1IFlgk-00016I-ID@sc8-sf-web21.sourceforge.net>

Patches item #1764087, was opened at 2007-07-30 18:06
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1764087&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Paul Pogonyshev (doublep)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: tiny addition to peephole optimizer

Initial Comment:
Tiny optimization that replaces Replace STORE_FAST x LOAD_FAST x with DUP_TOP STORE_FAST x (for the same slot x).  Targeted at quite common case:

    foo = self.foo
    if foo > 0:
        ...

No regression, seems to do what it is supposed to do on several test cases.

However, there is drawback:

    def f(x):
        y = x.y
        if y is not None:
            print y

is disassembled as follows:

  2           0 LOAD_FAST                0 (x)
              3 LOAD_ATTR                0 (y)
              6 DUP_TOP

  3           7 STORE_FAST               1 (y)
             10 LOAD_CONST               0 (None)
             13 COMPARE_OP               9 (is not)
             16 JUMP_IF_FALSE            9 (to 28)
             19 POP_TOP

  4          20 LOAD_FAST                1 (y)
             23 PRINT_ITEM
             24 PRINT_NEWLINE
             25 JUMP_FORWARD             1 (to 29)
        >>   28 POP_TOP
        >>   29 LOAD_CONST               0 (None)
             32 RETURN_VALUE

Note that STORE_FAST "migrated" to another line.  I'm not sure how important that is.


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2007-07-31 01:58

Message:
Logged In: YES 
user_id=80475
Originator: NO

I'll look at this one again.  It was tried once and rejected for some
reason that I've since forgotten (lack of measurable speed-up, interference
with some other optimization, or some such).



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1764087&group_id=5470

From noreply at sourceforge.net  Tue Jul 31 09:03:40 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 31 Jul 2007 00:03:40 -0700
Subject: [Patches] [ python-Patches-1749857 ] itertools.getitem()
Message-ID: <E1IFllc-0001ft-PU@sc8-sf-web21.sourceforge.net>

Patches item #1749857, was opened at 2007-07-08 04:33
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1749857&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Modules
Group: Python 2.6
>Status: Closed
>Resolution: Rejected
Priority: 5
Private: No
Submitted By: Walter D?rwald (doerwalter)
Assigned to: Raymond Hettinger (rhettinger)
Summary: itertools.getitem()

Initial Comment:
This patch adds itertools.getitem() which is basically equivalent to the following python code:

_default = object()

def getitem(iterable, index, default=_default):
   try:
      return list(iterable)[index]
   except IndexError:
      if default is _default:
         raise
      return default

but without materializing the complete list. Negative indexes are supported too.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2007-07-31 02:03

Message:
Logged In: YES 
user_id=80475
Originator: NO

Rejected after an offline discussion with the OP.

The use case for getitem(n) with n as a negative number depended on an
unlikely combination of circumstances:

* you have an iterable that is not a sequence (otherwise, just use
s[-n]).
* the iterable is somewhat large (otherwise, just list it into memory)
* the iterable is finite (otherwise, getitem() dies in a infinite loop)
* you only want one entry (otherwise, you'll have make multiple passes)
* that entry is located near the end (otherwise getitem() is memory
intensive)
* you know the entry's offset from the end but not from the beginning
* identifying the record of interest depends only on its position, not its
content

In the common case where the index is zero, the preferred spelling is to
use the next() method -- that is its purpose.  For cases where the index is
a positive integer, uing islice(it, n).next() suffices though it doesn't
have the cute feature for a default value.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1749857&group_id=5470

From noreply at sourceforge.net  Tue Jul 31 20:38:54 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 31 Jul 2007 11:38:54 -0700
Subject: [Patches] [ python-Patches-1764815 ] Fix for test_socketserver for
	Py3k
Message-ID: <E1IFwcQ-0007Vi-TU@sc8-sf-web21.sourceforge.net>

Patches item #1764815, was opened at 2007-07-31 21:38
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=1764815&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: ??PC?? (zpcz)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix for test_socketserver for Py3k

Initial Comment:
Well, it's quite small.
I think I'm right with changing StringIO to BytesIO

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1764815&group_id=5470